You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/09/02 13:03:16 UTC
Re: JMX Integration
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 )
The reason is that we have discussed that feature in the past without really
coming to any conclusion.
For example, lets consider the things that you may want to do with a
"ManagementContext". Usually you will want to
* register/bind object to name
* unregister/unbind object to name
* get a sub context
* get a list of names bound to current context
* get a object bound with a specific name
This is the exact same sort of operations you may want to do if you wanted to
"remote" an object (via soap, altrmi, rmi, corba, or whatever). It is also
the same set of operations that you would do if you wanted to expose an
object in one application to an object in another application.
In effect, the act of registering into a management context is identical to
registering into any directory service. The manager then either exports all
services in directory or the directory itself is responsible for exporting
services.
Anyway the basic interface you end up with is something like
interface Directory
{
void register( String name, Object value ); /* possibly also have
attribute map here */
void unregister( String name );
String[] list();
Object get(String name);
Directory getSubDirectory(String name);
}
Anyways. A couple of years ago, me Berin and Stefano went through all the
different permutations of this (from a one method interface to JNDI with all
20+ methods + 15 classes). However there is no real way to decide what will
be sufficient for all purposes. Berin - any thing I left out from way back
when?
I would prefer we experiment with this and if in a year or so we come up with
a interface that everyone likes then we can promote that to framework and
deprecate the appropriate methods in BlockContext.
Also the architecture of Phoenix is not really friendly to hierarchy of
multiple layers at this stage so I don't see that as a real hinderance. Maybe
when we see it in action we can change it but until then I think we go with
the simple approach.
Thoughts?
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: JMX Integration
Posted by Berin Loritsch <bl...@apache.org>.
Bringing back the original use case (I have not had time to
look through all the responses), here are the interfaces I have
defined already. They assume only the JobManager interface
is exposed to management, but I have no clue if this even represents
something really doable as the system is defined. Attached are the
interfaces in question. (hopefully they will not be stripped).
I need to get this part of my book written now, so I need to know
the best way to go about it at this point in time. If my interfaces
need altering, please let me know.
I can come back to this part when we have something better that is
concrete, but I don't want to write about vapor-ware--which is what
we have when the feature is pure discussion no working code.
Re: JMX Integration
Posted by Peter Donald <pe...@apache.org>.
Hiya,
On Sun, 22 Sep 2002 11:37, Igor Fedorenko wrote:
> Hmm, I think I am starting to understand what I wanted to ask. ;-) I
> already have block factories which could be used as a generic way to use
> external services in phoenix application. My question -- do we need
> another solution which is optimized/simplified for a case when both
> phoenix application and "external" service live inside same java VM?
I have come across three different types of service "exporting".
* The first type will export to a directory of sorts (ie JMX, RMI Registry,
JNDI or whatever). The container can export/unexport at will without caring
about who is using exported services.
* the second case is where it is exporting to another component that container
controls. In which case the container needs to make sure they shutdown all
consumers before they shutdown the actuall provider components
* The last type is tricky. It exports to another component where this
component is not controlled by our container. In this case we need to allow
the consumer the option to listen to events about a providers shutdown. They
may also be given the opportunity to veto the shutdown. The Consumer also
needs a mechanism to "releasE" the provider when they are done with it.
--
Cheers,
Peter Donald
---------------------------------------------------------
Clarke's Third Law: "Any technology distinguishable from
magic is insufficiently advanced".
---------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
Hmm, I think I am starting to understand what I wanted to ask. ;-) I
already have block factories which could be used as a generic way to use
external services in phoenix application. My question -- do we need
another solution which is optimized/simplified for a case when both
phoenix application and "external" service live inside same java VM?
Stephen McConnell wrote:
>
> Igor:
>
> I think you definately on the right track here. I have been thinkinng
> about something similar in the work I've been doing in Merlin. If I
> understand correctly, what your describing is the ability for an
> application to be able to declare dependecies and export services. I'm
> thinking/experimenting and working on the same thing in terms of Merlin
> Containers. In both cases - (Phoenix and Merlin) the desired result is
> that the result of application/container deployment is the establishment
> of a new set of services. These services can then be picked up and used
> by other services (indepedently of the deployment infrastructure).
>
> Igor Fedorenko wrote:
>
>> I am thinking about implementing this in a generic way, so
>> (theoretically) block can access components deployed into Embeddor and
>> (later) into any application deployed into phoenix. I think we already
>> agreed that block developer will declare these external dependencies
>> as any other dependency, however we did not talk about assebly.xml
>> syntax that would support this. I see two slightly different solutions
>> and need your help to choose one of them.
>>
>> One option is to use block factory to define foreign blocks in
>> assembly.xml and use these blocks as any other block. Emberddor would
>> extend BlockFactory interface and phoenix would provide it as implicit
>> "system-manager" factory (i.e. it does not need to be configured). For
>> example,
>>
>> <assembly>
>> <block name="system-manager" factoyr="phoenix-kernel"
>> implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/>
>> <block name="my-block" class="test.MyClass">
>> <provide name="system-manager"
>> role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
>> </block>
>> </assembly>
>>
>>
>> Another option is to define new tag "foreign", "external" or something
>> like that that could be used in place of "provide" tag. For example
>>
>> <assembly>
>> <block name="my-block" class="test.MyClass">
>> <foreign container="phoenix-kernel"
>> role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
>> </block>
>> </assembly>
>>
>> In this case we will need to define new interface that will be
>> implemented by all block containers and will provide access to blocks
>> deployed into the containers.
>>
>> So, what do you think?
>
>
>
> I think that we need to keep the concepts of importing and exporting
> services as parrallel (equivalent?) to the component model. In the case
> of a Phoneix assembly defintion this would suggests that the assembly is
> defining a set of exported services. In the case of Merlin this would
> suggst that a container is defining/exporting the same thing. In both
> cases there is the problem of scalability - a block providing a
> management service runing under machine A should be assignable as a
> service provider to a component running under machine B without concern
> for the infrastructure support the component deployment - i.e.a Merlin
> hosted business component dependent on a Phoneix hosted management
> service or whatever.
> This ends up raising the requirement for a portable service defintion
> and protocol.
> Cheers, Steve.
>
>
>>
>>
>>
>> Stephen McConnell wrote:
>>
>>>
>>>
>>> Igor Fedorenko wrote:
>>>
>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> Sounds perfect - assuming that the component aquiring the
>>> SystemManager declares this as a dependency.
>>>
>>> Cheers, Steve.
>>>
>>
>
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Stephen McConnell <mc...@apache.org>.
Igor:
I think you definately on the right track here. I have been thinkinng
about something similar in the work I've been doing in Merlin. If I
understand correctly, what your describing is the ability for an
application to be able to declare dependecies and export services. I'm
thinking/experimenting and working on the same thing in terms of Merlin
Containers. In both cases - (Phoenix and Merlin) the desired result is
that the result of application/container deployment is the establishment
of a new set of services. These services can then be picked up and used
by other services (indepedently of the deployment infrastructure).
Igor Fedorenko wrote:
> I am thinking about implementing this in a generic way, so
> (theoretically) block can access components deployed into Embeddor and
> (later) into any application deployed into phoenix. I think we already
> agreed that block developer will declare these external dependencies
> as any other dependency, however we did not talk about assebly.xml
> syntax that would support this. I see two slightly different solutions
> and need your help to choose one of them.
>
> One option is to use block factory to define foreign blocks in
> assembly.xml and use these blocks as any other block. Emberddor would
> extend BlockFactory interface and phoenix would provide it as implicit
> "system-manager" factory (i.e. it does not need to be configured). For
> example,
>
> <assembly>
> <block name="system-manager" factoyr="phoenix-kernel"
> implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/>
> <block name="my-block" class="test.MyClass">
> <provide name="system-manager"
> role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
> </block>
> </assembly>
>
>
> Another option is to define new tag "foreign", "external" or something
> like that that could be used in place of "provide" tag. For example
>
> <assembly>
> <block name="my-block" class="test.MyClass">
> <foreign container="phoenix-kernel"
> role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
> </block>
> </assembly>
>
> In this case we will need to define new interface that will be
> implemented by all block containers and will provide access to blocks
> deployed into the containers.
>
> So, what do you think?
I think that we need to keep the concepts of importing and exporting
services as parrallel (equivalent?) to the component model. In the case
of a Phoneix assembly defintion this would suggests that the assembly is
defining a set of exported services. In the case of Merlin this would
suggst that a container is defining/exporting the same thing. In both
cases there is the problem of scalability - a block providing a
management service runing under machine A should be assignable as a
service provider to a component running under machine B without concern
for the infrastructure support the component deployment - i.e.a Merlin
hosted business component dependent on a Phoneix hosted management
service or whatever.
This ends up raising the requirement for a portable service defintion
and protocol.
Cheers, Steve.
>
>
>
> Stephen McConnell wrote:
>
>>
>>
>> Igor Fedorenko wrote:
>>
>>>
>>>
>>> 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.
>>>
>>
>> Sounds perfect - assuming that the component aquiring the
>> SystemManager declares this as a dependency.
>>
>> Cheers, Steve.
>>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
I am thinking about implementing this in a generic way, so
(theoretically) block can access components deployed into Embeddor and
(later) into any application deployed into phoenix. I think we already
agreed that block developer will declare these external dependencies as
any other dependency, however we did not talk about assebly.xml syntax
that would support this. I see two slightly different solutions and need
your help to choose one of them.
One option is to use block factory to define foreign blocks in
assembly.xml and use these blocks as any other block. Emberddor would
extend BlockFactory interface and phoenix would provide it as implicit
"system-manager" factory (i.e. it does not need to be configured). For
example,
<assembly>
<block name="system-manager" factoyr="phoenix-kernel"
implementation="org.apache.avalon.phoenix.interfaces.SystemManager"/>
<block name="my-block" class="test.MyClass">
<provide name="system-manager"
role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
</block>
</assembly>
Another option is to define new tag "foreign", "external" or something
like that that could be used in place of "provide" tag. For example
<assembly>
<block name="my-block" class="test.MyClass">
<foreign container="phoenix-kernel"
role="org.apache.avalon.phoenix.interfaces.SystemManage"/>
</block>
</assembly>
In this case we will need to define new interface that will be
implemented by all block containers and will provide access to blocks
deployed into the containers.
So, what do you think?
Stephen McConnell wrote:
>
>
> Igor Fedorenko wrote:
>
>>
>>
>> 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.
>>
>
> Sounds perfect - assuming that the component aquiring the SystemManager
> declares this as a dependency.
>
> Cheers, Steve.
>
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Stephen McConnell <mc...@apache.org>.
Igor Fedorenko wrote:
>
>
> 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.
>
Sounds perfect - assuming that the component aquiring the SystemManager
declares this as a dependency.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Igor Fedorenko <if...@thinkdynamics.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>