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 Eung-ju Park <co...@apache.org> on 2002/09/05 06:19:07 UTC
More configurable SystemManager.
Current MX4JSystemManager configuration is not flexible.
I don't know about JMX. But I think below form of configuration brings more
power to SystemManager.
JBoss's configuration has similar form.
I don't know below form is correct or incorrect. Please comment to me. :)
<component role="...SystemManager" class="...MX4JSystemManager"
logger="manager">
<mbean name="Http:name=HttpAdaptor" class="mx4j.adaptor.http.HttpAdaptor">
<attribute name="Port" type="java.lang.Integer">8082</attribute>
<attribute name="ProcessorName"
type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
<!-- or like JBOSS
<depends name="ProcessorName">Http:name=XSLTProcessor</depends>
-->
<invoke name="addAuthorization"/>
<parameter type="java.lang.String">mx4j</parameter>
<parameter type="java.lang.String">mx4j</parameter>
</invoke>
<invoke name="start"/>
</mbean>
<mbean name="Http:name=XSLTProcessor"
class="mx4j.adaptor.http.XSLTProcessor">
<attribute name="File"
type="java.lang.String">stylesheet.xsl</attribute>
<attribute name="UseCache" type="java.lang.Boolean">false</attribute>
</mbean>
</component>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Peter Donald <pe...@apache.org>.
On Fri, 6 Sep 2002 08:29, David W. wrote:
> Although the user one has reduced usefulness since I don't think there's a
> way for Blocks to refer to MBeans at the
> moment, since neither ServiceManager nor BlockContext have interfaces to it
yep. We are working on that at the moment ;)
> (although a commented out stub exists in BlockContext -- what's CM?):
A CM is a ComponentManager.
>
> /**
> * Retrieve the MBeanServer for this application.
> *
> * NOTE: Unsure if this will ever be implemented
> * may be retrievable via CM instead, or perhaps in
> * a directory or whatever.
> */
> //MBeanServer getMBeanServer();
>
> David Weitzman
>
> ----- Original Message -----
> From: "Eung-ju Park" <co...@apache.org>
> To: "Avalon-Phoenix Developers List"
> <av...@jakarta.apache.org> Sent: Thursday, September 05, 2002
> 12:19 AM
> Subject: More configurable SystemManager.
>
> > Current MX4JSystemManager configuration is not flexible.
> > I don't know about JMX. But I think below form of configuration brings
>
> more
>
> > power to SystemManager.
> > JBoss's configuration has similar form.
> > I don't know below form is correct or incorrect. Please comment to me. :)
> >
> > <component role="...SystemManager" class="...MX4JSystemManager"
> > logger="manager">
> > <mbean name="Http:name=HttpAdaptor"
>
> class="mx4j.adaptor.http.HttpAdaptor">
>
> > <attribute name="Port" type="java.lang.Integer">8082</attribute>
> > <attribute name="ProcessorName"
> > type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
> > <!-- or like JBOSS
> > <depends name="ProcessorName">Http:name=XSLTProcessor</depends>
> > -->
> >
> > <invoke name="addAuthorization"/>
> > <parameter type="java.lang.String">mx4j</parameter>
> > <parameter type="java.lang.String">mx4j</parameter>
> > </invoke>
> > <invoke name="start"/>
> > </mbean>
> >
> > <mbean name="Http:name=XSLTProcessor"
> > class="mx4j.adaptor.http.XSLTProcessor">
> > <attribute name="File"
> > type="java.lang.String">stylesheet.xsl</attribute>
> > <attribute name="UseCache" type="java.lang.Boolean">false</attribute>
> > </mbean>
> > </component>
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by "David W." <da...@optonline.net>.
Peter Donald wrote
> > I'd be content, in the short term at least, to see more descriptive
> > versions of the same thing (i.e. instead of
> > <manager-adaptor-port>number</...> to configure the http adaptor,
> > <http-adaptor><port>number</port></...>) until JMX configuration is
given
> > full consideration.
>
> If you could spec it out fully then I can do that. I just updated the
> kernel.xml to show all permutations possible. So if you could show me what
> you would change then that would be great.
The MX4J adaptors should probably be marked as MX4J-specific. This seems
brief but descriptive:
<mx4j-adaptors>
<http-adaptor port="8082"/>
<jrmp-adaptor/>
</mx4j-adaptors>
I don't think the fact the the naming factory currently used by default
supports RMI is particularly important -- am I wrong? I figure the
configuration for naming should be more generic.
<naming-factory class="..."/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by "David W." <da...@optonline.net>.
Peter Donald wrote:
> > Thought 4)
> >
> > Phoenix does not currently provide a configuration method that allows
the
> > user to execute/make available arbitrary JMX-compliant beans. That is
> > precisely the problem that the <mbean> format is designed to solve.
That
> > format is actually directly competing with Phoenix's own methods of
> > configuration, just without inherent support for features like the
Avalon
> > lifecycle (which could easily be made available). It is a separate and
> > complete solution -- why make it dependant on Phoenix configuration
files?
>
> Not sure what you mean. In the future it will hopefully be possible to
> integrate into other systems much easier. This includes being able to
process
> these mbean files.
I was just speculating that you could completely configure Phoenix with
nothing but the sort of <mbean> records in JBoss. All it would take is
a) The requirement that all Avalon/Phoenix managed objects have an MBean
interface. The MBean interface would be the place where support for Avalon
lifecycle interfaces is declared (i.e. class MyBlock implements
MyBlockMBean, and interface MBlockMBean extends Startable, Initializable,
etc.)
b) A prefix for the ObjectName that makes it clear something is to be
managed by Avalon. Example: <mbean code="pak.FooService"
name="phoenix.block:service=FooService">
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Peter Donald <pe...@apache.org>.
On Fri, 6 Sep 2002 13:04, David W. wrote:
> I'd be content, in the short term at least, to see more descriptive
> versions of the same thing (i.e. instead of
> <manager-adaptor-port>number</...> to configure the http adaptor,
> <http-adaptor><port>number</port></...>) until JMX configuration is given
> full consideration.
If you could spec it out fully then I can do that. I just updated the
kernel.xml to show all permutations possible. So if you could show me what
you would change then that would be great.
> Thought 1)
>
> Services like the HTTP and RMI are not directly dependant on SystemManager,
> nor vice versa. The need for them to be associated is that there is no
> other way to register MBeans at the moment.
yep. Long term we have always wanted the adaptors to be contained within .sar
files and loaded like any other application. We have just never gotten around
to enabling it ;)
> Thought 3)
>
> Since the <mbean> format already exists and can be implemented without
> relying on any particular JMX vendor, directly using DOM would make an
> implementation reusable outside of Avalon (which may not matter).
yep.
> Thought 4)
>
> Phoenix does not currently provide a configuration method that allows the
> user to execute/make available arbitrary JMX-compliant beans. That is
> precisely the problem that the <mbean> format is designed to solve. That
> format is actually directly competing with Phoenix's own methods of
> configuration, just without inherent support for features like the Avalon
> lifecycle (which could easily be made available). It is a separate and
> complete solution -- why make it dependant on Phoenix configuration files?
Not sure what you mean. In the future it will hopefully be possible to
integrate into other systems much easier. This includes being able to process
these mbean files.
--
Cheers,
Peter Donald
Sufficiently advanced science is
indistinguishable from magic"
-- Arthur C. Clarke
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by "David W." <da...@optonline.net>.
>
> Separated configuration is so complicate.
> Configuration is just for SystemManager's configuration.
>
I decided to think. Some of my thoughts are below if you care to read them.
Phoenix could, in theory, configure everything using the <mbean> format and
JMX (at least if it required all Blocks to be MBeans). It would probably
even be a more flexible solution, although more verbose. But currently it
has it's own configuration format, and the two are in direct competition.
In my opinion, keeping them separate would allow greater flexibility in the
future -- although I'm not really in a position at the moment to judge the
direction of the project ;).
I'd be content, in the short term at least, to see more descriptive versions
of the same thing (i.e. instead of <manager-adaptor-port>number</...> to
configure the http adaptor, <http-adaptor><port>number</port></...>) until
JMX configuration is given full consideration.
I'm not really very passionate about the issue, though -- just very bored
tonight.
David Weitzman
Some thoughts, which may be self-contradictory and unrelated:
Thought 1)
Services like the HTTP and RMI are not directly dependant on SystemManager,
nor vice versa. The need for them to be associated is that there is no
other way to register MBeans at the moment.
Thought 2)
The things currently managed by SystemManager come with the Phoenix
binaries, and aren't going to gain any new functionality between releases,
so dynamic configuration isn't strictly-speaking necessary. A simple but
expressive and complete custom configuration would be more concise and
require less knowledge of the inner workings of the services being
configured, but would require modification any time new ways to access JMX
are added..
Thought 3)
Since the <mbean> format already exists and can be implemented without
relying on any particular JMX vendor, directly using DOM would make an
implementation reusable outside of Avalon (which may not matter).
Thought 4)
Phoenix does not currently provide a configuration method that allows the
user to execute/make available arbitrary JMX-compliant beans. That is
precisely the problem that the <mbean> format is designed to solve. That
format is actually directly competing with Phoenix's own methods of
configuration, just without inherent support for features like the Avalon
lifecycle (which could easily be made available). It is a separate and
complete solution -- why make it dependant on Phoenix configuration files?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Eung-ju Park <co...@apache.org>.
----- Original Message -----
From: "David W." <da...@optonline.net>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Friday, September 06, 2002 7:29 AM
Subject: Re: More configurable SystemManager.
> I agree that SystemManager configuration could benift from a makeover.
>
> The mbeans could be seperated into entire mbean configuration files with
> something like this:
>
> <component role="org.apache.avalon.phoenix.interfaces.SystemManager"
>
class="org.apache.avalon.phoenix.components.manager.MX4JSystemManager"
> logger="manager" >
> <mbean-config>conf/system-mbeans.xml</mbean-config>
> <mbean-config>conf/user-mbeans.xml</mbean-config>
> </component>
Separated configuration is so complicate.
Configuration is just for SystemManager's configuration.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by "David W." <da...@optonline.net>.
I agree that SystemManager configuration could benift from a makeover.
The mbeans could be seperated into entire mbean configuration files with
something like this:
<component role="org.apache.avalon.phoenix.interfaces.SystemManager"
class="org.apache.avalon.phoenix.components.manager.MX4JSystemManager"
logger="manager" >
<mbean-config>conf/system-mbeans.xml</mbean-config>
<mbean-config>conf/user-mbeans.xml</mbean-config>
</component>
Although the user one has reduced usefulness since I don't think there's a
way for Blocks to refer to MBeans at the
moment, since neither ServiceManager nor BlockContext have interfaces to it
(although a commented out stub exists in BlockContext -- what's CM?):
/**
* Retrieve the MBeanServer for this application.
*
* NOTE: Unsure if this will ever be implemented
* may be retrievable via CM instead, or perhaps in
* a directory or whatever.
*/
//MBeanServer getMBeanServer();
David Weitzman
----- Original Message -----
From: "Eung-ju Park" <co...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Thursday, September 05, 2002 12:19 AM
Subject: More configurable SystemManager.
> Current MX4JSystemManager configuration is not flexible.
> I don't know about JMX. But I think below form of configuration brings
more
> power to SystemManager.
> JBoss's configuration has similar form.
> I don't know below form is correct or incorrect. Please comment to me. :)
>
> <component role="...SystemManager" class="...MX4JSystemManager"
> logger="manager">
> <mbean name="Http:name=HttpAdaptor"
class="mx4j.adaptor.http.HttpAdaptor">
> <attribute name="Port" type="java.lang.Integer">8082</attribute>
> <attribute name="ProcessorName"
> type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
> <!-- or like JBOSS
> <depends name="ProcessorName">Http:name=XSLTProcessor</depends>
> -->
>
> <invoke name="addAuthorization"/>
> <parameter type="java.lang.String">mx4j</parameter>
> <parameter type="java.lang.String">mx4j</parameter>
> </invoke>
> <invoke name="start"/>
> </mbean>
>
> <mbean name="Http:name=XSLTProcessor"
> class="mx4j.adaptor.http.XSLTProcessor">
> <attribute name="File"
> type="java.lang.String">stylesheet.xsl</attribute>
> <attribute name="UseCache" type="java.lang.Boolean">false</attribute>
> </mbean>
> </component>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Peter Donald <pe...@apache.org>.
On Thu, 5 Sep 2002 14:19, Eung-ju Park wrote:
> Current MX4JSystemManager configuration is not flexible.
true - nor was it compatible with our old configuration format. I just fixed
that ;)
> I don't know about JMX. But I think below form of configuration brings more
> power to SystemManager.
> JBoss's configuration has similar form.
looks interesting. It is less "configuration" and more a script that can be
executed on the MBean server. It could be interesting to do it this way.
However I think we should also support our old configuration format. Some
options so that we can use this would be to either;
1. create a new ScriptableMx4jSystemManager
2. Allow a subelement <script/> that we could use to "execute" script
I think I prefer (1) as it is the easiest to maintain. Thoughts?
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Eung-ju Park <co...@apache.org>.
I don't know about other JMX implementation.
Now just ExtendedMX4JSystemManager. MX4J dependant.
Separating JmxScripter from EMX4JSystemManager is good. I will do it and
review other JMX impls.
----- Original Message -----
From: "Peter Donald" <pe...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Friday, September 06, 2002 10:02 PM
Subject: Re: More configurable SystemManager.
Looks interesting. Would you mind doing 2 things. Separate out the "script"
execution part into another component (so we can reuse it elsewhere. And
also
create a ScriptableSystemManager (as per last mail) so we can retain
compatability with existing manager.
The ScriptableSystemManager may be as simple as
class ScriptableSystemManager
...
{
void initialize()
{
JMXScripter scripter = new JMXScripter();
scripter.execute( configuration );
}
}
Like?
On Fri, 6 Sep 2002 20:21, Eung-ju Park wrote:
> I implement it. Yeah :)
>
> * More powerful configuration.
> * Maybe easy to port another JMX impelemtation( I don't know about other
> JMX implementation. It is just my presumption.)
> * Break backward compatiblility
> * It is JMX specific configuration scheme. I think other kind of
> SystemManager need another configuration scheme.
>
> I don't know how to test with RMI Adaptor. RMI Adaptor is not tested.
>
> Diff is attached. And it require excalibur-convertor. Try it!
>
> commit it?
>
> ----- Original Message -----
> From: "Eung-ju Park" <co...@apache.org>
> To: "Avalon-Phoenix Developers List"
> <av...@jakarta.apache.org> Sent: Thursday, September 05, 2002
> 1:19 PM
> Subject: More configurable SystemManager.
>
> > Current MX4JSystemManager configuration is not flexible.
> > I don't know about JMX. But I think below form of configuration brings
>
> more
>
> > power to SystemManager.
> > JBoss's configuration has similar form.
> > I don't know below form is correct or incorrect. Please comment to me.
:)
> >
> > <component role="...SystemManager" class="...MX4JSystemManager"
> > logger="manager">
> > <mbean name="Http:name=HttpAdaptor"
>
> class="mx4j.adaptor.http.HttpAdaptor">
>
> > <attribute name="Port" type="java.lang.Integer">8082</attribute>
> > <attribute name="ProcessorName"
> > type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
> > <!-- or like JBOSS
> > <depends name="ProcessorName">Http:name=XSLTProcessor</depends>
> > -->
> >
> > <invoke name="addAuthorization"/>
> > <parameter type="java.lang.String">mx4j</parameter>
> > <parameter type="java.lang.String">mx4j</parameter>
> > </invoke>
> > <invoke name="start"/>
> > </mbean>
> >
> > <mbean name="Http:name=XSLTProcessor"
> > class="mx4j.adaptor.http.XSLTProcessor">
> > <attribute name="File"
> > type="java.lang.String">stylesheet.xsl</attribute>
> > <attribute name="UseCache"
type="java.lang.Boolean">false</attribute>
> > </mbean>
> > </component>
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
--
Cheers,
Peter Donald
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Peter Donald <pe...@apache.org>.
Looks interesting. Would you mind doing 2 things. Separate out the "script"
execution part into another component (so we can reuse it elsewhere. And also
create a ScriptableSystemManager (as per last mail) so we can retain
compatability with existing manager.
The ScriptableSystemManager may be as simple as
class ScriptableSystemManager
...
{
void initialize()
{
JMXScripter scripter = new JMXScripter();
scripter.execute( configuration );
}
}
Like?
On Fri, 6 Sep 2002 20:21, Eung-ju Park wrote:
> I implement it. Yeah :)
>
> * More powerful configuration.
> * Maybe easy to port another JMX impelemtation( I don't know about other
> JMX implementation. It is just my presumption.)
> * Break backward compatiblility
> * It is JMX specific configuration scheme. I think other kind of
> SystemManager need another configuration scheme.
>
> I don't know how to test with RMI Adaptor. RMI Adaptor is not tested.
>
> Diff is attached. And it require excalibur-convertor. Try it!
>
> commit it?
>
> ----- Original Message -----
> From: "Eung-ju Park" <co...@apache.org>
> To: "Avalon-Phoenix Developers List"
> <av...@jakarta.apache.org> Sent: Thursday, September 05, 2002
> 1:19 PM
> Subject: More configurable SystemManager.
>
> > Current MX4JSystemManager configuration is not flexible.
> > I don't know about JMX. But I think below form of configuration brings
>
> more
>
> > power to SystemManager.
> > JBoss's configuration has similar form.
> > I don't know below form is correct or incorrect. Please comment to me. :)
> >
> > <component role="...SystemManager" class="...MX4JSystemManager"
> > logger="manager">
> > <mbean name="Http:name=HttpAdaptor"
>
> class="mx4j.adaptor.http.HttpAdaptor">
>
> > <attribute name="Port" type="java.lang.Integer">8082</attribute>
> > <attribute name="ProcessorName"
> > type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
> > <!-- or like JBOSS
> > <depends name="ProcessorName">Http:name=XSLTProcessor</depends>
> > -->
> >
> > <invoke name="addAuthorization"/>
> > <parameter type="java.lang.String">mx4j</parameter>
> > <parameter type="java.lang.String">mx4j</parameter>
> > </invoke>
> > <invoke name="start"/>
> > </mbean>
> >
> > <mbean name="Http:name=XSLTProcessor"
> > class="mx4j.adaptor.http.XSLTProcessor">
> > <attribute name="File"
> > type="java.lang.String">stylesheet.xsl</attribute>
> > <attribute name="UseCache" type="java.lang.Boolean">false</attribute>
> > </mbean>
> > </component>
> >
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
--
Cheers,
Peter Donald
Duct tape is like the force. It has a light side, and a dark side, and
it binds the universe together ...
-- Carl Zwanzig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: More configurable SystemManager.
Posted by Eung-ju Park <co...@apache.org>.
I implement it. Yeah :)
* More powerful configuration.
* Maybe easy to port another JMX impelemtation( I don't know about other
JMX implementation. It is just my presumption.)
* Break backward compatiblility
* It is JMX specific configuration scheme. I think other kind of
SystemManager need another configuration scheme.
I don't know how to test with RMI Adaptor. RMI Adaptor is not tested.
Diff is attached. And it require excalibur-convertor. Try it!
commit it?
----- Original Message -----
From: "Eung-ju Park" <co...@apache.org>
To: "Avalon-Phoenix Developers List" <av...@jakarta.apache.org>
Sent: Thursday, September 05, 2002 1:19 PM
Subject: More configurable SystemManager.
> Current MX4JSystemManager configuration is not flexible.
> I don't know about JMX. But I think below form of configuration brings
more
> power to SystemManager.
> JBoss's configuration has similar form.
> I don't know below form is correct or incorrect. Please comment to me. :)
>
> <component role="...SystemManager" class="...MX4JSystemManager"
> logger="manager">
> <mbean name="Http:name=HttpAdaptor"
class="mx4j.adaptor.http.HttpAdaptor">
> <attribute name="Port" type="java.lang.Integer">8082</attribute>
> <attribute name="ProcessorName"
> type="javax.management.ObjectName">Http:name=XSLTProcessor</attribute>
> <!-- or like JBOSS
> <depends name="ProcessorName">Http:name=XSLTProcessor</depends>
> -->
>
> <invoke name="addAuthorization"/>
> <parameter type="java.lang.String">mx4j</parameter>
> <parameter type="java.lang.String">mx4j</parameter>
> </invoke>
> <invoke name="start"/>
> </mbean>
>
> <mbean name="Http:name=XSLTProcessor"
> class="mx4j.adaptor.http.XSLTProcessor">
> <attribute name="File"
> type="java.lang.String">stylesheet.xsl</attribute>
> <attribute name="UseCache" type="java.lang.Boolean">false</attribute>
> </mbean>
> </component>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>