Ok as long as the management model of state is untouched your beans should
not implement JBoss centric APIs. If I understand what you are saying
correctly, there are other beans that Jetty generates, that have nothing to
do with JBoss integration, but that use JMX as a bus for communication but
do not go in as "services". pfffff... i go back to "be careful what you
expose as JMX" you can go "everything is JMX", jmx is a poor bus when it
comes down to it.
Re: the problem is that we register listening interest for every possible
MBean. Frankly I think the naming solution is possible in the sense that
you require a "JBoss domain" that signifies integration. The API one is
also good, even more "implicit" either one would work at this point.
It got me thinking about scoping JMX domains of management.
>From a management standpoint I must warn you about the non propagation of
lifecycle events. Init and start are "scoped" methods. You can init your
jetty stuff, and then "init" the integration with JBoss (hook up the naming
whatever you need to do for the integration). I would stop the server as a
unit and want the parts of the server to stop, if you are running jetty
separately I would still want to notify you of a "stop" event as a jboss
service. State management is important at each step of the domain
(functional microkernels).
Bottom line? we are standardizing this propagation in JSR77 as a "unit"
start/stop (state management at its bare minimum). That you don't want to
implement the jboss interface in *every* JMX class, I can see, that you
should implement a "similar" jsr77 one is a "strong recommendation" soon to
be the law. That we need to scope the registration and listening
(essentially creating subnaming domains of notification with cascading calls
in JMX) is also a trivial statement doing it explicetely by domain naming is
the simplest more expressive solution, doing it with class detection would
work but is more implicit. Either one is good at this point. Whoever
reaches CVS first wins :)
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Julian Gosnell
|Sent: Wednesday, April 11, 2001 4:52 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] Nested JMX Service Groups...??!
|
|
|
|--- Scott M Stark <[EMAIL PROTECTED]>
|wrote:
|> They can't create a wrapper because mbeans are being
|> created as a byproduct
|> of interaction with the Jetty JMX interface. This is
|> a generic issue with integrating
|> third party services that happen to be mbeans which
|> may be using the JMX bus
|> for whatever purpose. Its trivial to add a filter by
|> domain
|> that allows ServiceControl to not even attempt to
|> manage any mbeans in a given
|> domain. This does not break the JBoss management
|> model in any way that I see.
|> It simply adds the notion of non-service domains.
|>
|
|Yes !
|
|Thanks Scott,
|
|This is it.
|
|How you choose to differentiate between JBoss Service
|MBeans and 3rd party ones is what I think the
|discussion should hinge upon.
|
|Jules
|
|> ----- Original Message -----
|> From: "marc fleury" <[EMAIL PROTECTED]>
|> To: <[EMAIL PROTECTED]>
|> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
|> Sent: Tuesday, April 10, 2001 8:17 PM
|> Subject: RE: [JBoss-dev] Nested JMX Service
|> Groups...??!
|>
|>
|> > |The stack trace is coming from the Jetty
|> ModelMBeanImpl class, not JBoss's
|> > |ServiceControl. Although annoying, this is just a
|> cosmetic
|> > |exception. To clean
|> > |this up we could add a notification filter
|> attribute to the
|> > |ServiceControl mbean
|> >
|> > Again, implement the empty wrapper, that you don't
|> want to do anything about
|> > the integration is your problem but we should not
|> start breaking the
|> > management model in JBoss because you decide to
|> ignore it.
|> >
|> > marc
|> >
|>
|>
|>
|> _______________________________________________
|> 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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
