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.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
