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 Tue, 28 May 2002 05:57:24 GMT
On Tue, 28 May 2002 13:41, Peter Donald wrote:
> On Tue, 28 May 2002 13:20, Adam Murdoch wrote:
> > On Tue, 28 May 2002 12:00, wrote:
> > > donaldp     02/05/27 19:00:30
> > >
> > >   Modified:   
> > > container/src/java/org/apache/myrmidon/interfaces/executor
> > >
> > >   Log:
> > >   Ugly hack to put PropertyStore into ServiceManager.
> >
> > Eww.  What do we need this for?  The cast to DefaultServiceManager breaks
> > stuff, eg the ServiceManager used in
> > DefaultEmbeddor.createExecutionFrame() is a MultiSourceServiceManager.
> yep - Thats why I said it was UGLY ;) It still works (as the
> MSServiceManager gets wrapped in DSM later) but I am in middle of
> reorganizing that stuff.

So why does the property store need to be a service?

> > >   We really need to get a ServiceRegistry happening ;)
> >
> > What did you have in mind?
> Basically I was thinking that you should be able to pass
> * some metainfo object (ie info about type)
> * some metadata object (ie instance about instance)

What are some examples of the kind of info we'd need?

> The ServiceRegistry interface is just the "writing" counterpart to
> ServiceManager (like TypeRegistry/TypeManager etc).

Ok.  Would this be a scoped service?  One thing we need (and I'm not sure if 
ServiceRegistry is a good candidate) is some way to mess with the services 
contained in an execution frame - eg when creating a child execution frame, 
we need some way of adding new services, overriding others, and hiding 

Another thing that would be nice (this is more of a ServiceKernel thing) is to 
provide a hook so that a service can hand off the management of nested 
services to the kernel.  We have a few aggregate services, eg the vfs, with 
nested providers, or the deployer, with nested type deployers.  The extension 
manager should probably be an aggregate service, too.  Currently, each 
aggregate service has to manage the whole locate, instantiate, configure, 
initialise, cleanup lifecycle thing.  All they really need is something they 
hand a {role, type-name} to, and receive back a ready-to-use instance, that 
is private to the service and gets cleaned up when the service does.

Anything we can reuse from avalon to do this?


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

View raw message