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?
> 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).
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.
> BTW it looks like you have locked the container/**/configurer/test
> directory via one of your cvs clients dieing during a commit. If you could
> log onto cvs box, kill the old process (started about 4 yesterday) and
> remove the lockfile (named something like .#lock.1234) in the physical
> directory then that would be great.
Fixed. So is the test :)
--
Adam
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|