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
