oops, I reversed getData() / setData() pseudo-implementations.
Man, I really need to start proofreading.
On Fri, 30 Nov 2001, David Budworth wrote:
> 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
