From ant-dev-return-31032-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Thu Apr 25 02:05:12 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 61557 invoked from network); 25 Apr 2002 02:05:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Apr 2002 02:05:11 -0000 Received: (qmail 7521 invoked by uid 97); 25 Apr 2002 02:05:16 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 7492 invoked by uid 97); 25 Apr 2002 02:05:16 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 7481 invoked from network); 25 Apr 2002 02:05:15 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Ant Developers List" Subject: Re: cvs commit: jakarta-ant-myrmidon/container/src/java/org/apache/myrmidon/interfaces/executor ExecutionFrame.java Date: Thu, 25 Apr 2002 12:02:50 +1000 X-Mailer: KMail [version 1.4] References: <20020423072105.9970.qmail@icarus.apache.org> <200204241337.32843.peter@apache.org> <200204241446.12911.adammurdoch@apache.org> In-Reply-To: <200204241446.12911.adammurdoch@apache.org> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200204251202.50203.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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, sa= y, > > > the type manager or configurer? > > > > It is similar to the PropertyStore, TypeManager and ServiceManager bu= t > > different to the configurer. It makes sense to have parent-child > > relationships with the above and when you create a new "partition" yo= u > > 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 ot= her > 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=20 came to mind were * Type Manager * TaskEventManager * PropertyStore * ServiceManager I also thought about RoleManager but given it's ClassLoader limitations I= =20 don't think it can be scoped. All the rest (Deployer, Configurer, Executo= r=20 etc) I was not going to change. > > The configurer is not expected to be scoped or partitioned and thus g= ets > > chucked into the ServiceManager. > > Actually, that's not entirely true. It's similar to the deployer, in t= hat > while these services aren't scoped themselves, they do use services tha= t > are. Which means that a new instance needs to be created for each > partition. We're doing that for deployer, but not configurer. This mea= ns > that you can't use types that are 'd or 'd with a type= d > adder (there's a todo somewhere to fix this). Damn. Forgot about this. How about I add a=20 interface Reserviceable { void reservice(ServiceManager sm) throws ServiceException; } to the Avalon Framework CVS. That may work and then again it may not.=20 Actually it probably wont. Hmmmmmmmm ... Unfortunately the whole recreation of these components feels like a hack = to=20 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 lifecyc= le > 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 t= o > figure out which services to create when partitioning. This would repl= ace > 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 operat= ion.=20 We don't know what context information is needed by each component to cre= ate=20 a child and even if we could we would need some extremely tricky stuff to= get=20 ordering semantics. ie child deployer needs to be created after TypeManager. TaskEventManager= =20 needs to know the relative name to use. Some services will need to know=20 information like where ant.home is in current scope etc. Definetly needs = to=20 be something here - not sure what though. --=20 Cheers, Peter Donald -- To unsubscribe, e-mail: For additional commands, e-mail: