> 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.
I assume this means unjar the .sar into some deploy/sar/<sarname>/... then
pass the reference to that base directory via jndi or something.
This sounds like a solid approach.
Support libs (other .jars & possibly native libs) could be packaged up with
it, similar to how web-inf/lib works.
> 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).
One problem that I have found with JMX configuration is that it is hard to
pass in a complex configuration object, short of supplying a classname and
having the MBean create a new instance of it.
I would like to see a richer xml configuration dialect which would allow me
to construct an object, call some methods on it and pass that object in to
the MBean for use.
One example of this would be the JMSProvider objects that we use to adapt
vendor specific JMS semantics into the JBoss scheme. This is currently done
by passing in a classname. I think that it would be much better if we could
construct a class, then call some methods on it, then pass that object in to
the MBean. This would allow us to provide generic configuration objects,
which could be used for many different providers.
I agree with Marc, that the Jetty config might offend some administrators,
or rather confuse them, but it seems that it might be the way to go if we
are to be able to plug in rather arbitrary objects, configure them and have
them run with out having to write anything JBoss specific.
Along those lines, we could also expose some mappings to show the
ServiceController how to call 'init', 'start', 'stop' and 'destroy' on an
arbitrary object too.
I would opt for the power of jetty config and provide tools for admins who
might be easily confused, rather than dumb down the configuration syntax.
my (not so) humble opinion.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development