funny you mention, I am actually looking at this right this minute. The state stuff as part of the serviceMBean was defined by Rickard.
It makes total sense. It is going to be part of the JSR77 spec the state stuff is. I know the Iona guy and myself pushed for the adoption of the state stuff, just give you a runtime view of who is active and all. So it is going to be a part of the spec to be sure whether you need or not I don't know. What I have a problem with is with the implementation of ServiceMBeanSupport, it gives a lot of generic code but eats up the "extends" bit obviously.... and I am stuck with a current implementation of the invokers that need to do a Remote and this extends... so I need to rewrite the code in there. Bottom line, we could argue that Service should only have start/stop preregister/postregister (for a init/start) in a separate interface, and that the state stuff is in another interface. I kind of find natural to have the "state and state management" in the same interface so would argue for keeping this in one place, minor points really. On the point of MBean not being declared, we are moving to the "dynamic mbean" route, well in fact the ModelMBean and since juha is almost done with the reviews of the book we will work on this soon I hope hopefully by next week. This is going to buy us a very important point: installation is going to be clusterable through the model persistence engines that will be backed up by ejbs with xml persistence. So I see different points in your mails. As for the ServiceMbean api I say leave it as the kid designed, it was a genius design. The standard MBean approach can be improved upon that is what lindfors/oberg approaches to mmbean give you I plan on seriously moving in that direction next week. If only I can go below 1348 compilation errors on my rewrite of the detached jmx invokers and generic proxy layers :) marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Friday, November 30, 2001 1:12 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Service MBeans questions | | |First off, thanks David J. for adding the test case. | |Anyway, | |For my own project, I have made a base Dynamic MBean for my own code |that all my MBeans are based on. | |Mainly to avoid the whole MyClass.java must have a MyClassMBean.java |type thing that really doesn't work for me given what I use my custom |mbeans for. | |And to allow the subclasses to define their own descriptions of |methods/params etc.. | |I added to my base class start() and stop(), which JBoss sees and does |indeed call. | |I don't (yet) however, define Name, State, StateString attributes that |are in ServiceMBean. | |Just start() and stop() | |Does JBoss make use of the ServiceMBean attributes? Or are they just |for informational purposes? | |And, are start()/stop() JBoss-isms? Or some kind of standard thing? I |couldn't find them in the JMX spec. | |Would I magically get better managability by making my dynamic base |implement ServiceMBean, and make them work like ServiceMBeanSupport? | |-David | |_______________________________________________ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
