Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> 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 a Context should never be used by a Container for its services.
> If it is used, it's basically giving a service to everyone without IoC.
>
>> >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.
>
>
> I resist also this, since we are using services in a context, rather
> than be given them by the Container.
>
> I have looked in the archives and seen that once upon a time, Context
> was indeed used as a common service, and a common place to put services.
>
> I think that Context should never keep services where possible.
>
> For example, ServletContext is about instance data, not services.
>
>> This was discussed in respect to the shutdown request handler - this
>> requirement is no different.
What if we provide instance of SystemManager via
ServiceManager.lookup()? I would not bother getting block's management
subcontext -- it does not map into anything in JMX anyways -- just put
root system manager into appropriate ServiceManager instance.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
