Peter Donald wrote:
> On Sun, 1 Sep 2002 08:07, Huw Roberts wrote:
>
>>Everything is ok until we get down to the management of individual jobs
>>- the rest can be already be done. So the problem here is how is to
>>allow blocks to register additional objects for management 'beneath' them.
>
>
> yep.
>
>
>>Basically, the way I see this working is to have the BlockContext makes
>>it Management Context (an implementation of the SystemManager interface)
>>available to Block, and then use that to create a Jobs subcontext:
>>
>>SystemManager blockMgmtContext = blockContext.getManagementContext()
>>SystemManager jobMgmtContext = blockMgmtContext.getSubContext( "Blocks",
>>"Jobs" );
>
>
> Rather than this I think I may prefer something simpler - at least initially.
> Something like
>
> BlockContext.register( String topic, String name, Object object )
> BlockContext.unregister( String topic, String name )
Adding behaviour to a context object is inconsitent with the framework
defintion of Context. As soon as you do something like this you are
defining a special component model just for Phoneix.
The cleaner alternative is to (a) declare a dependecy on a registry
services (could be provided by another component or handled by Phoenix),
or alternatively, expose a registry via the context, and allow clients
to register/deregister against the context. Both approaches enable the
creation of portable registration mechanisms and ensure the potential
for component portability.
S.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
