Simone, unless OpenJMX becomes a project of JBoss I don't really want you plugin your stuff on our lists :)
thanks marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of |Bordet, Simone |Sent: Sunday, December 02, 2001 12:48 PM |To: marc fleury; David Budworth; Juha-P Lindfors |Cc: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Hi, | |jumping in late... |OpenJMX will soon release an implementation of RMMB with pluggable |logging redirection and pluggable persistence mechanism. See |http://sourceforge.net/projects/openjmx for details. | |Cheers | |Simon | |> -----Original Message----- |> From: marc fleury [mailto:[EMAIL PROTECTED]] |> Sent: domenica 2 dicembre 2001 16:33 |> To: David Budworth; Juha-P Lindfors |> Cc: [EMAIL PROTECTED] |> Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings |> |> |> So much the better, you get to work on stuff that Juha wrote |> for the book |> and will save you some time. You even get to use it in your |> application if |> you want, seems like JBoss3.0 is providing a lot of |> infrastructure for you. |> |> Your help will be much appreciated on that base, |> |> marcf |> |> |-----Original Message----- |> |From: David Budworth [mailto:[EMAIL PROTECTED]] |> |Sent: Sunday, December 02, 2001 4:50 AM |> |To: Juha-P Lindfors |> |Cc: David Budworth; [EMAIL PROTECTED]; |> |[EMAIL PROTECTED] |> |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings |> | |> | |> |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 |> | |_______________________________________________ |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
