|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
