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 'd or '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: For additional commands, e-mail: