OK I'll give a little bit more detail about what I'm talking about. But
first I'll describe what I think the JBoss mechanism is (which I have only
looked at briefly), so you guys can correct me if I'm wrong.
I understand that you have a configuration agent that observes JMX
registrations and when it see's an object that it knows about it
configures components with XML that really is just
a series of JMX set calls. After this, you assume a start() method exists
and call that.
Jetty exposes the majority of it's configuration API via JMX with the
approximate hierarchy of MBeans:
HttpServerMBean
+ 0 or more HttpListenerMBeans
+ 0 or more HandlerContextMBeans
+ 0 or 1 LogSinkMBeans
Each of these MBeans implements the LifeCycleMBean api (start/stop)
The ListenerMBeans can also be ThreadedServer and/or SocketListener MBeans
The HandlerContextMBean may be a WebApplicationMBean
The LogSinkMBean may be a OutputStreamMBean or something else....
In a JMX environment - two main approaches can be taken to configure this
bunch of MBeans. Consider the LogSink within the HttpServer - which is used
for the request log.
The first is to do just set's on the HttpServer - ie call the setLogSink
method passing it a complex object. We achieve this in XML as follows
<Set name="LogSink">
<New class="org.mortbay.util.OutputStreamLogSink">
<Arg><SystemProperty name="jetty.log"
default="./logs"/>/yyyy_mm_dd.request.log</Arg>
<Set name="RetainDays">90</Set>
<Set name="Append">true</Set>
<Set name="flushOn">false</Set>
</New>
</Set>
So a configured LogSink is passed to the JMX setLogSink on HttpServer
The second approach is to arrange for a default LogSink to be added to
the HttpServer - whose JMX name will be derived from the JMX name of the
HTTP server. The configuration agent will spot the registration of the
LogSinkMBean and configure that in the normal way (calling sets etc.)
The problem with both of the above appraches - is who calls start?
In Jetty - everything implements the lifecycle interface, so it has
start and stop methods. If you call start on HttpServer, it calls
start on all the components within it. So you don't really want
a config agent calling start on every component that it see's registered
along the way
Another problem is sometimes you may need to be a little more procedural
than just a straight set. For example in the Jetty demo config, we call
getServletHandler in order to set some specific attribute on it:
<Call name="addContext">
<Arg>/</Arg>
<Set name="ClassPath"><SystemProperty name="jetty.home"
default="."/>/servlets/</Set>
<Set name="DynamicServletPathSpec">/servlet/*</Set>
<Get name="ServletHandler">
<Set name="ServeDynamicSystemServlets" type="boolean">FALSE</Set>
</Get>
....
OK - looking at the above, it is all pretty incoherent and I don't expect anybody
to understand it. Unless you know Jetty. So I will try from a
different angle.
I have found it very valuable in another project to have a JMX configuration
agent that work very similar to the one I've assumed in JBoss, but slightly
more powerful. It supports Set, Get, Call and New tags to be run like a
script to configure newly registered JMX objects.
The following example configures the JMX config agent to trigger on the
registration of the com.mortbay.Jetty:name=Jetty,Server=0 MBean.
Once triggered it:
+ Sets the statsOn attribute of the HttpServer.
+ does a Call to addListener with a complex object
arg to configure the HTTP port.
+ Does a Set of logsink with a complex object arg.
+ Calls start
The XML for this is:
<Configure jmxname="org.mortbay.jetty:name=Jetty,Server=0">
<Set name="statsOn" type="boolean">FALSE</Set>
<Call name="addListener">
<Arg>
<New class="org.mortbay.http.SocketListener">
<Set name="port"><SystemProperty name="application.portno"
default="8080"/></Set>
<Set name="minThreads">5</Set>
<Set name="maxThreads">255</Set>
<Set name="maxIdleTimeMs">60000</Set>
<Set name="maxReadTimeMs">60000</Set>
</New>
</Arg>
</Call>
<Set name="logSink">
<New class="org.mortbay.util.WriterLogSink">
<Arg><SystemProperty name="application.log"
default="./logs"/>/yyyy_mm_dd.request.log</Arg>
<Set name="retainDays">90</Set>
<Set name="append">true</Set>
</New>
</Set>
<Call name="start"/>
</Configure>
Note that no webapplication is configured by this (it could be) as I expect the normal
EAR deployer will do that. This just configures the things that are not included in
an EAR.
An alternative way to write this configuration would be to use the listeners and
logSinks own
MBeans to do the configuration:
<Configure jmxname="org.mortbay.jetty:name=Jetty,Server=0">
<Set name="statsOn" type="boolean">FALSE</Set>
<Call name="addListener"><Arg><New
class="com.mortbay.HTTP.SocketListener"/></Arg></Call>
<Set name="logSink"><New class="com.mortbay.Util.WriterLogSink"/></Set>
<Call name="start"/>
</Configure>
<Configure jmxname="com.mortbay.jetty:name=Jetty,Server=0,SocketListener=0>
<Set name="port"><SystemProperty name="application.portno" default="8080"/></Set>
<Set name="minThreads">5</Set>
<Set name="maxThreads">255</Set>
<Set name="maxIdleTimeMs">60000</Set>
<Set name="maxReadTimeMs">60000</Set>
</Configure>
<Configure jmxname="com.mortbay.jetty:name=Jetty,Server=0,WriterLogSink=0" >
<Set name="filename"><SystemProperty name="application.log"
default="./logs"/>/yyyy_mm_dd.request.log</Set>
<Set name="retainDays">90</Set>
<Set name="append">true</Set>
</Configure>
But this second style of config assumes that the config agent has triggered and
configured
the SocketListener and WriterLogSink during the configuration of HttpServer - thus
they will
be configured before the start call on the HttpServer
I guess the point that I am trying to make is that some components such as Listeners
and
log sinks can very easily be configured with a sequence of sets. But something as
complex
as a HTTP server and servlet container, needs a little more than a sequence of sets.
So either you config agent needs to support Set, Call, New tags! Or something
else must coordinate the creation of all the component MBeans that can be configured
with just a simple sequence of Sets ~(but who calls start() would still be a problem).
MMmmmmm I don't think this describes what I'm talking about much better?????
So if you are confused - it is my fault. I'll try to have more of a look at the
JBoss stuff and make my suggestions using your XML as examples rather than mine.
marc fleury wrote:
> |It should not be too much work to do away with the Jetty config files
> |all together and configure Jetty entirely via JMX.
>
> remember that what we are aiming for is filesystem independence.
>
> The fact that the configuration is in a file with XML is not the problem it
> is the fact that it is expected from a filesystem file that is problematic.
> JBoss loads its own configuration with jboss-services.xml (ex.jboss.jcml)
> and then bit by bit through XML snippets but the vehicle that delivers them
> to the main system is not important. Right now we use URL to create Element
> to pass to the core. The core is fed "Elements" where those elements come
> from today are URLs (file or http). JMX is the core that applies the
> changes how these changes get there is through URLClassLoaders.
>
> |For the cisco deployment, this is exactly what they do and they have
> |a JMX configuration architecture not unlike JBosses. The main difference
> |is that:
> |
> | + The lifecycle methods are not expected. (ie don't have to have a
> | start();
>
> That's bad :(
>
> | + Arbitrary methods can be called as well as attributes set.
>
> Ok that I am interested in seeing, is that your scripting language? the XML
> semantic that recreates invocation?
>
> |So I think the aim of the integration, should be to remove all trace of
> |the jetty configuration mechanism from a standard jboss/jetty installation.
>
> The best would be to deliver that configuration either as part of sar that
> julian was talking about and we provide a way for you to find a fileSystem
> file (simplest is a file at teh top of the hierarchy that you look for) or
> even better URL based.
>
> |This may be simple? As jetty configuration for most purposes can be
> |reduced to a series of JMX sets followed by a call to start(). My
>
> That would nicely map to the ELement parser that is in there.
>
> |However they may be more complex configurations that require arbitrary
> |methods to be called on the jetty mbeans. These will have to be
>
> "arbitrary methods called" sounds strange. Give me an example of that. Do
> you mean something like the dynamic MBeans?
>
> |addressed either by changing the jetty mbeans so everything can be
> |done as sets, then start() - or improving the jboss mechanism so that
> |more arbitrary jmx calls can be made.
>
> be more precise, this doesn't tell me much, there are predefined MBeans
> (standard) and dynamic MBeans. We support standard MBeans right now, we
> could proxy the calls to "invoke" as well.
>
> |Again for the cisco deployment, I used a config file format very similar
> |to that of Jetty's XML - but which was able to call arbitrary JMX methods.
>
> If you are talking about your scripting language, I think it might be very
> interesting as we build more evolved frameworks for management. But I am
> curious to see what kind of scenarios you are talking about that require
> these files.
>
> marcf
>
--
Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com AU Phone: +61-(0)2 98107029
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
