In other words JBossMX is going to be a full JMX implementation from mr lindfors, in the meantime I don't want you diverting resources by using our lists :) you fight your own war kid,
You know we have a history of squashing open* projects :) marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of marc |fleury |Sent: Sunday, December 02, 2001 1:06 PM |To: Bordet, Simone; David Budworth; Juha-P Lindfors |Cc: [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
