--- marc fleury <[EMAIL PROTECTED]> wrote:
> 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
>
Marc,
If you do this then you might as well just add
isAJBossService() to the Service API and call that.
Nobody has yet given me a good reason why we should
force a DynamicMBean to decide who manages it's
lifecycle, at compile time (what you are suggesting)
or at deployment time (stick it in a config file)
instead of at runtime (which I am suggesting).
If I have chosen to use DynamicMBeans it's because I
want to make decisions like this at run time. Do we
have an overwhelmingly good reason why this is such a
bad idea.
I promise not to mention this again,
Jules
>
> |-----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
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
