ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: cvs commit: jakarta-ant-myrmidon/container/src/java/org/apache/myrmidon/interfaces/executor
Date Thu, 25 Apr 2002 02:58:14 GMT
On Thu, 25 Apr 2002 12:02, Peter Donald wrote:

> I also thought about RoleManager but given it's ClassLoader limitations I
> don't think it can be scoped.

Which ClassLoader limitations?

There definitely needs to be some kind of scoping going on, if we decide to 
keep human consumable role names.

> > > The configurer is not expected to be scoped or partitioned and thus
> > > gets chucked into the ServiceManager.
> >
> > Actually, that's not entirely true.  It's similar to the deployer, in
> > that while these services aren't scoped themselves, they do use services
> > that are. Which means that a new instance needs to be created for each
> > partition. We're doing that for deployer, but not configurer.  This means
> > that you can't use types that are <import>'d or <typedef>'d with a typed
> > adder (there's a todo somewhere to fix this).
> Damn. Forgot about this. How about I add a
> interface Reserviceable
> {
>   void reservice(ServiceManager sm) throws ServiceException;
> }
> to the Avalon Framework CVS.  That may work and then again it may not.
> Actually it probably wont. Hmmmmmmmm ...

Eww.  It definitely won't work once you get more than one thread cruising 
around reservicing stuff.

> Unfortunately the whole recreation of these components feels like a hack to
> me. We got to think of something better - not sure what at the moment.

Well, it's a hung-over public holiday, but let's see ..

Another option is to pass the execution frame in some form to the work methods 
for these services - like we do with Executor.  Problem with this approach is 
that the tasks are going to need to get at the execution frame to use the 
services - and that is a bad thing.  I guess we can add facade services for 
the tasks to use.

I don't reckon that recreating the components is too nasty.  One thing we do 
need to do is make sure that they're lightweight - deployer and configurer 
both have state info that would be better off in some global component (the 
parsed library descriptors in the case of deployer, and the introspection 
info in the case of configurer). 

> > What I'd like to do is to generalise service scoping with a new lifecycle
> > interface, something like:
> >
> > interface ScopedService
> > {
> >     Object createChild() throws SomeException;
> > }
> >
> > which would be implemented by any service that needs to be scoped.
> > DefaultExecutionFrame.createChildFrame() (or whatever) would use this to
> > figure out which services to create when partitioning.  This would
> > replace methods like TypeManager.createChildTypeManager(),
> > Deployer.createChildDeployer(), etc.  Getting rid of these methods from
> > the work interfaces would be a good thing, I think.
> The problem is that I don't think there is a way to genericise the
> operation. We don't know what context information is needed by each
> component to create a child and even if we could we would need some
> extremely tricky stuff to get ordering semantics.
> ie child deployer needs to be created after TypeManager. TaskEventManager
> needs to know the relative name to use. Some services will need to know
> information like where ant.home is in current scope etc. Definetly needs to
> be something here - not sure what though.

We can get close enough to a generic solution, I think.  All the services 
currently get contextualize()'d with the container config.  Initially, we can 
just keep pushing that down through the services created by the execution 
frames.  It would be read-only, but that's fine for our current crop of 
services.  Ultimately, a service context thing would be handy, with things 
like the base directory and so forth.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message