Peter Donald wrote:
>On Mon, 2 Sep 2002 02:45, Huw Roberts wrote:
>
>
>>>>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 )
>>>>
>>>>Job jobOne = ... get the job somehow
>>>>ctx.register( "jobs", jobOne.getName(), jobOne );
>>>>...
>>>>ctx.unregister( "jobs", jobOne.getName() );
>>>>
>>>>The reason for this is that then we don't have to expose SystemManager
>>>>to clients and thus we are free to evolve it as we see fit. However it
>>>>exposes all the information needed to manage object.
>>>>Like?
>>>>
>>>>
>>I have 3 issues:
>>1) The ability to add more than one level of hierarchy beneath the
blocks.
>>2) Using an interface will make the client code cleaner and more
portable.
>>3) Client code will be hooking into this, meaning we are committed to
>>supporting it going forward.
>>
>>I can live with this for now, but i want to consider how it fits into
>>the longer term direction. What I'd like to do, is add a
>>ManagementContext interface to Framework, and then have SystemManager
>>extend this. That would be the first step towards making the
>>functionality available in other containers. Does that sound ok? If
>>so, how do we proceed in that direction? If its not too big a deal
>>maybe we could skip this intermediate step?
>>
>>
>
>I would still prefer to go with the
>
>BlockContext.register( String topic, String name, Object object )
>BlockContext.unregister( String topic, String name )
>
>
-1
>The reason is that we have discussed that feature in the past without
really
>coming to any conclusion.
>
Adding behaviour to an context implementation over and above the
framework defintion of context means that you are defining a
specilization of the Avalon Component Model for Phoenix. Components
that include a dependency on that model are no longer portable.
Alternative solutions to introducing the functionality you are
describing is totally possible without introducing the complication
associated with BlockContext - i..e. use the context object to aquire an
abject implementing the interface the component needs, then apply
register/unregister against that interface, or, havbe the copmponent
declare a depedency on a registery service of some kind.
This was discussed in respect to the shutdown request handler - this
requirement is no different.
Cheers, Steve.
--
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]>
