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 03:06:00 GMT
On Thu, 25 Apr 2002 12:46, Peter Donald wrote:
> On Thu, 25 Apr 2002 12:30, Adam Murdoch wrote:
> > > yep. But now we start to get into territory that is a bit icky. We will
> > > end up creating a fully fledged services kernel if we are not careful.
> > > The above strategy was one the Cocoon project used to use until they
> > > realized that some services/components were accessing other components
> > > before those other components were fully initialized. (The same thing
> > > happened in Avalon/Phoenix kernel). I believe they ended up creating a
> > > directed graph for dependencies between services and so forth which
> > > seems like a little overkill for Ant - what do you think?
> >
> > Definitely overkill.  I think we can get pretty close to what we need by
> > doing what DefaultEmbeddor does: create all the services, add them to the
> > service manager, and only then start moving them through the lifecycle
> > stages. Perhaps if we were to also move all the services through a
> > lifecycle stage, before moving to the next stage, might be useful.
> The problem with this is that it is going to break in some systems. If you
> write a service that accesses other services in any of the lifecycle
> methods then there is a chance you are accessing an unconfigured service
> and the system goes belly up. Most of our services currently fall into this
> category.

That's what I meant by 'pretty close'.  It ain't perfect, but good enough for 

> The ordering in embeddor is required for current set of implementations -
> if we were ever to change the implementations radically we would need to
> rewrite the embeddor code which is a bit icky.
> I guess we kinda do need proper manager for this stuff but I would really
> like to avoid the complexity of it all. Can you think of any way of
> avoiding all this complexity?

It might be worth biting the bullet, and dealing with this properly, so that 
we know things will work when services are replaced.  Dealing with ordering 
isn't too nasty - in a past life I put together a container that did the 
dependency tracking thing.  I could certainly put together something for us 
to use.


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

View raw message