Ahh. ok. Well, it's obvious to me (as well as everyone else I assume). That you know a lot more about this stuff than I do.
So, I'll leave it to the experts. Thanks for replying. -David On Sun, 02 Dec 2001, Juha-P Lindfors wrote: > > > Hi, > > > Marc / everyone, > > > > When you asked about this Dynamic mbean thing I'm working on, were you > > thinking of me applying it to RequiredModelMBean? > > I wrote a ModelMBean implementation for the book and will commit an > implementation based on it (with some other stuff) in the next couple of > days. > > > > If I read correctly, we are required to supply an implementation of that > > class, no? > > Just implementing the ModelMBean interface will be enough. > > > > 1) What are the expectations for determining the MBeanInfo? Should we > > expect a XYZMBean interface to match the XYZ implementation the user > > provides? (similar to regular MBeans) > > > > This would be easy to add. Since I already have the code that walks the > > methods of any specified interface to compose the operation/attribute > > info structures. > > The metadata can be built using introspection on the resource class, read > from a database, read from a file, looked up from the JNDI. The > rules for introspection can follow the standard MBean rules, or you can > create your own naming rules for a specific resource type. > > > > 2) What should be the rules for determining the operations/attributes? > > I have written and re-written this logic in my own code about 15 times, > > never really happy with it. Example, how to handle: > > > > int getXYZ(); > > void setXYZ(float); > > > > Do you consider the get to be a RO attribute and one to be an operation? Or > > throw an exception for non-compliant naming? I see nothing in the spec > > regarding naming standards on dynamic mbean oper/attr > > > > or > > > > int getXYZ(); > > void setXYZ(int); > > void setXYZ(float); > > > > Do we consider get/set(int) to be a RW attr, and set(float) to be an > > operation? Or throw again? > > If you are talking about the Standard MBean behaviour, that would cause a > NotCompliantMBeanException to be thrown. However, for ModelMBeans you > could build your own resource types that allow this kind of interface to > be handled differently. > > > As for persistence, have you finished rolling on the floor laughing at > > my idea of using EJBs to store? I have noticed that no other components > > use EJBs for their JDBC based persistence. Is there a reason for this? > > The MMBean persistence can be abstracted behind a > simple PersistenceManager interface with load and store operations. The > persistence implementation may then be file based, direct JDBC, JDO or > EJB. > > > -- Juha > > > _______________________________________________ > 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
