ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: cvs commit: jakarta-ant-myrmidon/container/src/java/org/apache/myrmidon/interfaces/executor ExecutionFrame.java
Date Thu, 25 Apr 2002 02:02:50 GMT
On Wed, 24 Apr 2002 14:46, Adam Murdoch wrote:
> On Wed, 24 Apr 2002 13:37, Peter Donald wrote:
> > > Why isn't TaskEventManager just another service?  Why does it need its
> > > own method?  What's special about the event manager compared to, say,
> > > the type manager or configurer?
> >
> > It is similar to the PropertyStore, TypeManager and ServiceManager but
> > different to the configurer. It makes sense to have parent-child
> > relationships with the above and when you create a new "partition" you
> > generally want modifications to be isolated from parent version.
> >
> > ie If you add aproperty in a project, register a new task or type in one
> > project these changes should not be visible in the workspace "scope" nor
> > be visible to any other projects in the workspace.
>
> Ok, let me rephase that:  Why is TaskEventManager different from the other
> scoped services?  Although the only other scoped service we have
> TypeManager (and PropertyStore too, if it is considered a service), I
> imagine we will end up with more.  So, why does TaskEventManager get
> special treatment?

I was going to treat all the "special ones" specially in time :) The ones that 
came to mind were
* Type Manager
* TaskEventManager
* PropertyStore
* ServiceManager

I also thought about RoleManager but given it's ClassLoader limitations I 
don't think it can be scoped. All the rest (Deployer, Configurer, Executor 
etc) I was not going to change.

> > 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 ...

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.

> 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.

-- 
Cheers,

Peter Donald


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message