|There are two other simple approaches to getting the class loader fixed.
|1. Add the jboss.jar to the classpath
I want to break the jboss.jar in "jbossmx.jar" (or the spine) and jboss.jar
that is the containers and all the other stuff, so that you can start jboss
from the minimal configuration and load all the rest from HTML.
|2. Remove the jxmri.jar from the classpath and create a url
|classloader that
|contains the jmxri.jar and jboss.jar and use that to load MLet,
|MBeanServer,
|etc.
|
Yes,
|Personally I'm leaning to using the domain name as its a
|definative configuration
|item that your likely to set anyway.
yes, that is what I am thinking as well, simple. The only thing that
bothers me with this approach is you lose the "jini" feel of just plugin
services in the network and having them participate in the network that
makes up JBoss. For example a pre-existing service would not be able to
participate in a new configuration because the name would be set before
deployment. In short Jetty would need to register a new MBean "JBoss"
domain post deployment. The real underlying reason is that there is no
management API standardized (coming in JSR77, I know for sure, I am pushing
for it ;-) so designing with the assumption that the management API isn't
there (Jetty's problem) is not a good idea.
Bottom line? put a management API and the wrapper we were talking about
(call it JettyService if you want and this is a territorial issue) JBoss
should work on scoped names, a Service=:Jetty will not be called but a
Service=:Jetty:Subservice=:JBoss (wrapper) which will signify the
integration with JBoss will be called. ALl the beans that Jetty registers
as part of this subdomain are called.
JMX really designed for this,I find the idea interesting and appropriate,
Jules, does Jetty implement *any* lifecycle API on JMX ? (start/stop at
least?)
Time to look at JMX naming conventions
marc
|
|> riiiigght....
|>
|> the idea of "test the domain *name*" doesn't sound soo bad after all.
|>
|> The reason is that it is a simple place to define the integration (by
|> scoping your domain in JBoss's). Therefore JBoss will assume
|that you are
|> "JBoss" aware and that your management is in place... working on
|String will
|> for sure be safe :)
|>
|> hehe, I guess the second solution will have its problems too.
|That is when
|> you know your codebase is too big, a simple change triggers hell
|>
|> marc
|> |
|
|
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
