Hey, I should drink my own medicine...
while I believe that what I outline below is the way to manage sets of
start/stopable objects with multiple set pertainings (wrappers per domain
and domains expressed in name) I believe we should keep it simple for now.
can we test the name of the class at all, the server.getClass().getName()
which if it returns Service is good for the management operations. Never
compare the class, it's a bitch go with the string if you can
marc
|-----Original Message-----
|From: marc fleury [mailto:[EMAIL PROTECTED]]
|Sent: Thursday, April 12, 2001 10:32 AM
|To: [EMAIL PROTECTED]
|Subject: RE: [JBoss-dev] Nested JMX Service Groups...??!
|
|
||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
