Yep - I know this got a little off topic, but I always react when I
hear people discuss "where do we put the Jetty config files" and I
try to encourage them to use a single configuration style for an
application and Jetty - be that Jetty's config files or their own.
What you say about the config files being a little unreadable is
true. Lots of people have talked about XSL front ends or some
other way to make them more approachable - but the problem is once
developers start using them, they are very straight forward for
them - so those efforts stop.
I think they would be a little too much for many admins type to
use. The unsolved problem with them is persistence. If you use
these scripts to configure a system, then an admin uses a graphical
JMX tool to change that config - how do you save that new configuration?
The beauty of Set only config, is that it can be saved with Gets.
Config that uses calling semantics is going to be harder to automatically
persist - without the objects themselves knowing about the XML format.
Cisco want me to persist configuration soon, so I will have to find a way
to solve this problem.
Anyway - this is probably enough on this for now. When you guys want
to consider updating you config mechanism, I'm more than happy to help
out - donate code from Jetty - or change jetty a bit to match whatever
you come up with.
cheers
marc fleury wrote:
> |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.
> |
>
--
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
