You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/08/30 22:57:48 UTC
JMX Integration
I want to know what is easiest for Phoenix to expose as a JMX interface.
The issue is that I have multiple Jobs that I am managing, each of them
needs to have some controls exposed. Here is what I need to be able
to control for each Job:
Start
Stop
Status
I also need to be able to load new jobs, remove old jobs, etc.
Now, I can do this through a set of directories, and poll the contents
every so often. However, I would like to have the management interface
ask for a file or a path to the file, and I build the Job from that.
What I have is a flat interface on the JobManager to do all of this,
but I want to know if some of interface can be moved to the Job itself.
If so, I would like to know if I can expose a *proxy* to the job....
Of course, there is much to learn, and with Phoenix I am but a Padawan.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Peter Donald <pe...@apache.org>.
On Sun, 1 Sep 2002 14:17, Igor Fedorenko wrote:
> Is this already implemented?
not at this stage.
> If not, do you need any help?
Help would be fantastic!
> In fact,
> something like that is a second item on my todo list, so I am going to
> do it in next couple of weeks anyways.
Assuming Huw likes the design then I say go for it!
>
> 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 )
> >
> > 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?
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
--
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>
Re: JMX Integration
Posted by Peter Donald <pe...@apache.org>.
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 Peter Donald <pe...@apache.org>.
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 Stephen McConnell <mc...@apache.org>.
Huw Roberts wrote:
> Igor Fedorenko wrote:
>
>> Is this already implemented? If not, do you need any help? In fact,
>> something like that is a second item on my todo list, so I am going to
>> do it in next couple of weeks anyways.
>>
>> 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 )
>>>
>>> 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.
+1
> 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?
There is a project - excalibur/container - that is dealing with things
like this.
http://jakarta.apache.org/avalon/excalibur/container
It contains utilities and services that are container independent. If
you look at the framework is is 99% about the client view of a
component. The excalibur/container package includes container indepedent
interfaces that enable different implementations of common services.
Something like a ManagementContext would make a lot of sense as a
container-indepedent resource.
As a case study, the lifestyle extension package is limited to two
interfaces and two abstract classes (very lightweight). Both Merlin and
Fortress provide alternative implementations of these interfaces. The
bottom line is that component authors are assured of the potential for
portability of component that leverage these sort of concepts.
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 Huw Roberts <hu...@apache.org>.
Igor Fedorenko wrote:
> Is this already implemented? If not, do you need any help? In fact,
> something like that is a second item on my todo list, so I am going to
> do it in next couple of weeks anyways.
>
> 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 )
>>
>> 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?
- Huw
--
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>.
Is this already implemented? If not, do you need any help? In fact,
something like that is a second item on my todo list, so I am going to
do it in next couple of weeks anyways.
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 )
>
> 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?
>
--
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>.
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: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 Peter Donald <pe...@apache.org>.
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 )
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?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JMX Integration
Posted by Huw Roberts <hu...@apache.org>.
Berin Loritsch wrote:
> I want to know what is easiest for Phoenix to expose as a JMX interface.
> The issue is that I have multiple Jobs that I am managing, each of them
> needs to have some controls exposed. Here is what I need to be able
> to control for each Job:
>
> Start
> Stop
> Status
>
> I also need to be able to load new jobs, remove old jobs, etc.
Let me play this back to you, using terms i'm more comfortable with, to
see if i understand what you're looking for.
There is a phoenix application. One feature of this application
involves managing 'jobs'. This feature is implemented via a JobManager
component (block). Each job has a number of attributes and operations.
These features should be exposed via the 'standard' management mechanism.
In a tree view it might look like this:
-+-> Phoenix
|
+--+-> Applications
| |
| +--+-> ApplicationThatHasJobs
| | |
| | +--+-> Blocks
| | |
| | +--+-> JobManager
| | | |
| | | +--+-> Jobs
| | | +----> Job 1
| | | +----> Job 2
| | |
| | +----> UserManager
| |
| +----> AnotherApplication
|
+--+-> Components
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.
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" );
Then the Block would register & unregister jobs on the jobMgmtContext:
Job jobOne = ... get the job somehow
jobMgmtContext.register( jobOne.getName(), jobOne );
The methods to expose by the job would be determined from its mxinfo file.
Does that start to address the issue?
- Huw
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>