I'd be happy to contribute what I wrote. I'll give you the lowdown on
how it works so you can see if it may even be usefull:
Implements:
DynamicMBean, MBeanRegistration, NotificationBroadcaster,
and ServiceMBean (if it's going to be in spec, might as well prepare)
But not ModelMBean, so there is no persistent config. But after reading
your message, I think I'll be making it into a MMBean.
Normal deployment config is done via the <mbean><attribute> tags in the XML. Just
like any other mbean.
I had already planned on making the attributes persist.
But not in a way that would be acceptable for generic JBoss uses (I
suppose).
I was going to add a MBeanConfigEJB (CMP bean), that basically had 3
fields.
String pk = ObjectName.toString();
Object data; //explained below
Date lastModified;
Basically, load() would grab the EJB based on ObjectName.
And store() would would update the ejb.
For clustering, I would post a JMS message for each change, to avoid the
other instances from hitting the database when something changes.
This would all be done using select-for-update turned on. So other
instances in the cluster would have serialized access to the row, to
avoid them stepping on each others changes.
basically:
store(){
ut = getUserTransaction();
config = ConfigLocalHome.findByPk(objName.toString());
if ( config.lastMod != localLastMod )
//handle out of date resolution (ie. reload and
//re-apply my modified fields)
else
config.setData(getData(this));
}
load(){
ut = getUserTransaction();
config = ConfigHome.findByPk(objName.toString());
setData(config.getData());
}
getData(){
Map data;
ObjectInputStream ois = ... (byte[] reader, whatever)
String name = ois.readString();
Object val = ois.readObject();
data.put(name,val);
//loop mbean attribute info, restoring each field via it's set.
//that way attributes can be removed without failing to restore
//object
//Probably also want a state=LOADING, to avoid change notifications
//from being fired off when calling the setXXX()
}
setData(){
//loop attributeinfo[], and store name+serialized(val)
}
The idea here being someone can override getData() setData() to change
the storage format.
And since the EJB to perform storage would be configurable in the base
class (or maybe a more generic PM type class), the user could switch
datastore depending on needs of the specific mbean instance.
And if they want the CMP type store, they could always re-define the DD,
and deploy it under a different name to get different performance
abilities.
I also don't require a seperate interface to define the mbeans external
interface.
I have a Class[] getInterfaces method, that by default returns just
getClass()
So, if you want to take any stand alone class and make it an MBean, you
only need to extend my dynamic base class. I just publish any public
method as a operation/attribute (depending on name/params).
And was planning to add a dynamic mbean proxy type thing, where you just
pass it a class, and it reflects on that class. So if there is already
an existing object that extends something else, you can just MBeanify it
by specifing the class name, and constructor params (optional).
ok. That is probably a shit load more than you wanted to hear. But,
after a pot of coffee, and a 2 liter bottle of diet coke, I get a little
type-happy.
I'll shut up now.
-David
On Fri, 30 Nov 2001, marc fleury wrote:
> Upon re-reading your email I realize you already implemented the dmbean
> approach yourself, so keep that on the warmer and you could be making a
> significant contribution next week :)
>
> My question is how do you feed data to that dmbean? how do you configure it?
> where are your files? how do you persist them? do you persist changes? do
> you cluster them easily? that is part of what we are trying with the
> mmbeans... post snippets if you can
>
> marcf
>
> |-----Original Message-----
> |From: marc fleury [mailto:[EMAIL PROTECTED]]
> |Sent: Friday, November 30, 2001 1:34 PM
> |To: David Budworth; [EMAIL PROTECTED]
> |Subject: RE: [JBoss-dev] Service MBeans questions
> |
> |
> |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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
