|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
There is one thing that I really *love* about your stuff, it is the calling
semantics you show in XML. See that is really powerful. Right now
configuration in JBoss is done with static snippets that describe the setter
basically. Cycling was difficult.
Your stuff enables setting references on MBeans which is pretty cool. It
seems that if you do component only inside then the advantage about doing it
through your scripting language is missed. I think it is really powerful
for "external" references.
|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.
Adding complex objects is a power of your framework but couldn't we just set
the Name of another JMX object and have the calls be done through JMX? Do
you really think this scripting language is meant for administrators? do you
mean it for tools? tools would be interesting.
I think you could come up with a higher language than the scripting XML
which would become an intermediary step. Imho, the xml above, that really
mimics the java semantic will have most administrators recoiling in horror.
You must build a visual tool (again imho).
| + 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
It needs to be visual. I think it is the kind of thing that is very clear
picture wise but hard to read here. I think you must think of this language
as an intermediary form.
|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.
You need to pass reference, how about the String name of other MBeans...
would that be equivalent?
|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).
It seems to me (but I could be wrong) that from the example above you pass
reference to new tags. The power of this is that you can work on the
sub-objects. There seems to be no visibility outside of the encompassing
object.
The JMX framework offers you external references through the String name of
the MBean. That would really "script" the framework don't you think?
|MMmmmmm I don't think this describes what I'm talking about much
|better?????
It does, it describes it very well, but I think the problem Julian is seeing
is much much simpler something to do with the classloader visibility.
I was trying to understand what are you trying to access in the classes that
results in a error with the new classloader (the new classloader MBean is
your parent)
|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.
I see several possibilities.
1- We provide for the SAR directory in a jar approach. I find this kind of
elegant actually. We provide a way for a service to deploy to a target
node, install his own stuff in a directory for the duration of work and then
clean up. Jason request.
2- We adopt your scripting language, it would remain that we need to get the
xml file that describes the script to be downloaded from somewhere, that
somewhere being a URL would be much better imho, but for now a file based
one is ok (as in 1).
So just to focus the discussion as I understand it, providing a directory
for SARs is good, moving all configuration files to *URL* is good, but if
you don't we can still work.
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
