RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
yes and no yes: I strongly support the microkernel view, the basic server is just the JMX stuff (even stripped I think does anyone use the relationships out there?) and the service libraries (possibly unified with MLet). And that doesn't require anything else, certainly not an EJB container (or rather the MBeans that when assembled provide EJB behavior). The small servers, the embedded servers, the edge servers need not ship everything. no: the configuration server is a central server, he will not run inside my DVD player (while the microkernel will) he will run the central configuration server that David is talking about. Since the MMBeans in the edge servers have pluggable persistence we can use EJB for the persistence in case of clustering, and straight file in case of single server, the EJB in the case buys us location. BTW the persistence is not necessarily in JDBC it would be in file in the first pass, meaning the file persistence that we have in there already just remote under the EJB front. They are different servers and both configuration (at the same time) make total sense to me, the central server is a configuration server (possibly ha'ed itself) the edge ones are what you want, ejb clients if you want (rmi stacks necessary, proxy clients from JBoss, couple of k) or straight microkernel readers if you don't want to and they read their configurations and adminitstration through other means. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jiri |Luzny |Sent: Wednesday, December 05, 2001 4:54 AM |To: David Budworth |Cc: Dain Sundstrom; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |I have to support Dain's comment. |We see JBoss as a microkernel (container for containers) plus some |services that you can run on top of it. Sure, we also use the J2EE |"services" like EJB etc.., but for some parts of our system, we run |the thin JBoss's microkernel (without any EJB, DB) configuration ONLY. |We just deploy our custom services (MBeans) there. |Why to increase startup time and waste memory for something that is |not going to be used at all? | |Jiri. | | |On Sat, 1 Dec 2001 18:18:02 -0800, you wrote: | |>I hadn't thought of that. I have always viewed JBoss as an overall |>platform with replacable elements. |> |>It hadn't occured to me that you may want to run only one element of it. |> |>I saw it more like the JDK. If you don't want to use JDBC, don't use |>it. But you wouldn't go removing the java.sql.* classes from the jars. |> |>I didn't realize that was a goal of JBoss. |> |> |>-David |> |>On Sat, 01 Dec 2001, Dain Sundstrom wrote: |> |>> You are making 2 bold assumptions. |>> |>> 1. JBoss will always run with the EJB service installed. |>> 2. JBoss will always have a database available. |>> |>> Neither of these hold. As a quick example, I may want JBossMQ |with out a |>> database or EJB services. |>> |>> -dain |>> |>> -Original Message----- |>> From: David Budworth [mailto:[EMAIL PROTECTED]] |>> Sent: Saturday, December 01, 2001 6:04 PM |>> To: [EMAIL PROTECTED] |>> Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings |>> |>> |>> Marc / everyone, |>> |>> When you asked about this Dynamic mbean thing I'm working on, were you |>> thinking of me applying it to RequiredModelMBean? |>> |>> If I read correctly, we are required to supply an implementation of that |>> class, no? |>> |>> If not, ignore the rest. |>> |>> I'd be happy convert my stuff over to be the implementation of that, |>> since mainly the only difference with what I wrote and this is the |>> persistent storage stuff. |>> |>> I do have a few questions on how it should be done. |>> |>> 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. |>> |>> 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 o
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
I have to support Dain's comment. We see JBoss as a microkernel (container for containers) plus some services that you can run on top of it. Sure, we also use the J2EE "services" like EJB etc.., but for some parts of our system, we run the thin JBoss's microkernel (without any EJB, DB) configuration ONLY. We just deploy our custom services (MBeans) there. Why to increase startup time and waste memory for something that is not going to be used at all? Jiri. On Sat, 1 Dec 2001 18:18:02 -0800, you wrote: >I hadn't thought of that. I have always viewed JBoss as an overall >platform with replacable elements. > >It hadn't occured to me that you may want to run only one element of it. > >I saw it more like the JDK. If you don't want to use JDBC, don't use >it. But you wouldn't go removing the java.sql.* classes from the jars. > >I didn't realize that was a goal of JBoss. > > >-David > >On Sat, 01 Dec 2001, Dain Sundstrom wrote: > >> You are making 2 bold assumptions. >> >> 1. JBoss will always run with the EJB service installed. >> 2. JBoss will always have a database available. >> >> Neither of these hold. As a quick example, I may want JBossMQ with out a >> database or EJB services. >> >> -dain >> >> -Original Message- >> From: David Budworth [mailto:[EMAIL PROTECTED]] >> Sent: Saturday, December 01, 2001 6:04 PM >> To: [EMAIL PROTECTED] >> Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings >> >> >> Marc / everyone, >> >> When you asked about this Dynamic mbean thing I'm working on, were you >> thinking of me applying it to RequiredModelMBean? >> >> If I read correctly, we are required to supply an implementation of that >> class, no? >> >> If not, ignore the rest. >> >> I'd be happy convert my stuff over to be the implementation of that, >> since mainly the only difference with what I wrote and this is the >> persistent storage stuff. >> >> I do have a few questions on how it should be done. >> >> 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. >> >> 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? >> >> >> In my stuff, there is a protected Class[] getInterfaces() so an mbean >> can specify which interfaces it want's to expose to management. But, if >> that returns null(default impl), I just use all public methods not defined >> in the base >> or java.lang.Object to be a managed UI. >> >> Would you want that in the JBoss RequiredModelMBean? >> >> What I have now, basically allows the subclasses to specify any part of >> the MBeanInfo (ie, via "protected MBeanAttributeInfo[] >> getAttributeInfo()"), so the subclass can 'break the rules' that are >> defined in the base class. >> >> I wonder, is this too much complexity to offer in a generic base class >> to be supplied with JBoss? >> >> 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? >> >> >> Assuming Dain's engine has nothing to persist (MBean wise), there is no >> reason not to use it. If we don't believe in EJBs enough to use them >> ourselves, how can we tell others to use JBoss for their projects. >> Hell, configuration persistence is something that happens so rarely (in >> the application sense), I don't think performance is really an issue. >> >> >> >> A
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
You are correct sir! (doing my best Ed McMahon impression) JBoss is providing most of the infrustructure (we use JMX/JMS/EJB). And, we are planning on selling by January. So it may even be the first JBoss 3.0 based thing in commercial use. This is why I go on these little mini-rants about administration. At my previous job (eloan.com), the biggest cause for downtime was from administration mistakes. And that was in no way the fault of the actual admins. The admins were the best I've seen. It really came from having too many different non-connected pieces to manage. Every developer rolled their own for config data, file location, a thousand little cron jobs, etc.. Which is why I fully believe that central and *easy* administration is going to be the winner in this space. And JBoss has all the parts required to make this happen. No other app server can touch us here. But, I think I'm preaching to the choir here, as far as JBoss being the "Kwisatz Haderach" of app servers. (Dune reference, but I don't know a geek who hasn't seen Dune, so you probably already knew that) -David On Sun, 02 Dec 2001, marc fleury wrote: > 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
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
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); ||> |>
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 |&g
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
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
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
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
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
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
it isn't if we can have an admin that makes complete sense using our own infrastructure then so much the better, I really see no problem with that. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of David |Budworth |Sent: Saturday, December 01, 2001 9:18 PM |To: Dain Sundstrom |Cc: 'David Budworth'; [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |I hadn't thought of that. I have always viewed JBoss as an overall |platform with replacable elements. | |It hadn't occured to me that you may want to run only one element of it. | |I saw it more like the JDK. If you don't want to use JDBC, don't use |it. But you wouldn't go removing the java.sql.* classes from the jars. | |I didn't realize that was a goal of JBoss. | | |-David | |On Sat, 01 Dec 2001, Dain Sundstrom wrote: | |> You are making 2 bold assumptions. |> |> 1. JBoss will always run with the EJB service installed. |> 2. JBoss will always have a database available. |> |> Neither of these hold. As a quick example, I may want JBossMQ with out a |> database or EJB services. |> |> -dain |> |> -Original Message- |> From: David Budworth [mailto:[EMAIL PROTECTED]] |> Sent: Saturday, December 01, 2001 6:04 PM |> To: [EMAIL PROTECTED] |> Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings |> |> |> Marc / everyone, |> |> When you asked about this Dynamic mbean thing I'm working on, were you |> thinking of me applying it to RequiredModelMBean? |> |> If I read correctly, we are required to supply an implementation of that |> class, no? |> |> If not, ignore the rest. |> |> I'd be happy convert my stuff over to be the implementation of that, |> since mainly the only difference with what I wrote and this is the |> persistent storage stuff. |> |> I do have a few questions on how it should be done. |> |> 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. |> |> 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? |> |> |> In my stuff, there is a protected Class[] getInterfaces() so an mbean |> can specify which interfaces it want's to expose to management. But, if |> that returns null(default impl), I just use all public methods |not defined |> in the base |> or java.lang.Object to be a managed UI. |> |> Would you want that in the JBoss RequiredModelMBean? |> |> What I have now, basically allows the subclasses to specify any part of |> the MBeanInfo (ie, via "protected MBeanAttributeInfo[] |> getAttributeInfo()"), so the subclass can 'break the rules' that are |> defined in the base class. |> |> I wonder, is this too much complexity to offer in a generic base class |> to be supplied with JBoss? |> |> 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? |> |> |> Assuming Dain's engine has nothing to persist (MBean wise), there is no |> reason not to use it. If we don't believe in EJBs enough to use them |> ourselves, how can we tell others to use JBoss for their projects. |> Hell, configuration persistence is something that happens so rarely (in |> the application sense), I don't think performance is really an issue. |> |> |> |> As for clustering stuff, keeping in mind I haven't looked at it yet. |> Does anyone know if hypersonic get's clustered |> as well? I see that to get the EJBs mass deployed there is the farm |> directory, so that kind of implies that there is a master server |> somewhere (unless everyones farm propogates to everyone else). |> |> If hypersonic doesn't cluster, then is there the ability t
Re: [JBoss-dev] RequiredModelMBean.java? / general rantings
I hadn't thought of that. I have always viewed JBoss as an overall platform with replacable elements. It hadn't occured to me that you may want to run only one element of it. I saw it more like the JDK. If you don't want to use JDBC, don't use it. But you wouldn't go removing the java.sql.* classes from the jars. I didn't realize that was a goal of JBoss. -David On Sat, 01 Dec 2001, Dain Sundstrom wrote: > You are making 2 bold assumptions. > > 1. JBoss will always run with the EJB service installed. > 2. JBoss will always have a database available. > > Neither of these hold. As a quick example, I may want JBossMQ with out a > database or EJB services. > > -dain > > -Original Message- > From: David Budworth [mailto:[EMAIL PROTECTED]] > Sent: Saturday, December 01, 2001 6:04 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings > > > Marc / everyone, > > When you asked about this Dynamic mbean thing I'm working on, were you > thinking of me applying it to RequiredModelMBean? > > If I read correctly, we are required to supply an implementation of that > class, no? > > If not, ignore the rest. > > I'd be happy convert my stuff over to be the implementation of that, > since mainly the only difference with what I wrote and this is the > persistent storage stuff. > > I do have a few questions on how it should be done. > > 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. > > 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? > > > In my stuff, there is a protected Class[] getInterfaces() so an mbean > can specify which interfaces it want's to expose to management. But, if > that returns null(default impl), I just use all public methods not defined > in the base > or java.lang.Object to be a managed UI. > > Would you want that in the JBoss RequiredModelMBean? > > What I have now, basically allows the subclasses to specify any part of > the MBeanInfo (ie, via "protected MBeanAttributeInfo[] > getAttributeInfo()"), so the subclass can 'break the rules' that are > defined in the base class. > > I wonder, is this too much complexity to offer in a generic base class > to be supplied with JBoss? > > 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? > > > Assuming Dain's engine has nothing to persist (MBean wise), there is no > reason not to use it. If we don't believe in EJBs enough to use them > ourselves, how can we tell others to use JBoss for their projects. > Hell, configuration persistence is something that happens so rarely (in > the application sense), I don't think performance is really an issue. > > > > As for clustering stuff, keeping in mind I haven't looked at it yet. > Does anyone know if hypersonic get's clustered > as well? I see that to get the EJBs mass deployed there is the farm > directory, so that kind of implies that there is a master server > somewhere (unless everyones farm propogates to everyone else). > > If hypersonic doesn't cluster, then is there the ability to add to a DD > something like: > if (master) use local DB > else use master DB > > We store the JMS stuff (and maybe others, I haven't looked) on disk now. > With the option of using JDBC. I understand that there is a performance > issue, but from the admin point of view, they'd be much happier if > everything was all in one place, that was remotely viewable (ie. > whatever DefaultDS points to). > > I've heard Marc mention several times that the winner in this space is > going to be
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
h running JBoss with the EJB available, in this case a special EJB for clustering of configuration can be, will be a requirement. It is not the whooping 50k footprint that it takes that are going to make a difference. on 2 you are right about the db, but my first idea (well with juha really) was to have the ejb with a custom persistence engine, namely the one that reads and stores the xml files for configuration. This way you still have your familiar XML based configuration but the front end ejb enables you to lookup, read, load/store all that in a secure and transactional way. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Dain |Sundstrom |Sent: Saturday, December 01, 2001 7:24 PM |To: 'David Budworth'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |You are making 2 bold assumptions. | |1. JBoss will always run with the EJB service installed. |2. JBoss will always have a database available. | |Neither of these hold. As a quick example, I may want JBossMQ with out a |database or EJB services. | |-dain | |-Original Message- |From: David Budworth [mailto:[EMAIL PROTECTED]] |Sent: Saturday, December 01, 2001 6:04 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings | | |Marc / everyone, | |When you asked about this Dynamic mbean thing I'm working on, were you |thinking of me applying it to RequiredModelMBean? | |If I read correctly, we are required to supply an implementation of that |class, no? | |If not, ignore the rest. | |I'd be happy convert my stuff over to be the implementation of that, |since mainly the only difference with what I wrote and this is the |persistent storage stuff. | |I do have a few questions on how it should be done. | |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. | |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? | | |In my stuff, there is a protected Class[] getInterfaces() so an mbean |can specify which interfaces it want's to expose to management. But, if |that returns null(default impl), I just use all public methods not defined |in the base |or java.lang.Object to be a managed UI. | |Would you want that in the JBoss RequiredModelMBean? | |What I have now, basically allows the subclasses to specify any part of |the MBeanInfo (ie, via "protected MBeanAttributeInfo[] |getAttributeInfo()"), so the subclass can 'break the rules' that are |defined in the base class. | |I wonder, is this too much complexity to offer in a generic base class |to be supplied with JBoss? | |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? | | |Assuming Dain's engine has nothing to persist (MBean wise), there is no |reason not to use it. If we don't believe in EJBs enough to use them |ourselves, how can we tell others to use JBoss for their projects. |Hell, configuration persistence is something that happens so rarely (in |the application sense), I don't think performance is really an issue. | | | |As for clustering stuff, keeping in mind I haven't looked at it yet. |Does anyone know if hypersonic get's clustered |as well? I see that to get the EJBs mass deployed there is the farm |directory, so that kind of implies that there is a master server |somewhere (unless everyones farm propogates to everyone else). | |If hypersonic doesn't cluster, then is there the ability to add to a DD |something like: |if (master) use local DB |else use master DB | |We store the JMS stuff (and maybe others, I haven't looked) on disk now. |With the option of using JDBC. I understand that there is a performance |issue, but from the admin point of view, they'd be much happier if |everything was all in one place, that was remotely viewable (ie. |whatever DefaultDS points to). | |I've heard Marc mention several times that the winner in this space is |going to be the on
RE: [JBoss-dev] RequiredModelMBean.java? / general rantings
You are making 2 bold assumptions. 1. JBoss will always run with the EJB service installed. 2. JBoss will always have a database available. Neither of these hold. As a quick example, I may want JBossMQ with out a database or EJB services. -dain -Original Message- From: David Budworth [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 01, 2001 6:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] RequiredModelMBean.java? / general rantings Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? If I read correctly, we are required to supply an implementation of that class, no? If not, ignore the rest. I'd be happy convert my stuff over to be the implementation of that, since mainly the only difference with what I wrote and this is the persistent storage stuff. I do have a few questions on how it should be done. 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. 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? In my stuff, there is a protected Class[] getInterfaces() so an mbean can specify which interfaces it want's to expose to management. But, if that returns null(default impl), I just use all public methods not defined in the base or java.lang.Object to be a managed UI. Would you want that in the JBoss RequiredModelMBean? What I have now, basically allows the subclasses to specify any part of the MBeanInfo (ie, via "protected MBeanAttributeInfo[] getAttributeInfo()"), so the subclass can 'break the rules' that are defined in the base class. I wonder, is this too much complexity to offer in a generic base class to be supplied with JBoss? 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? Assuming Dain's engine has nothing to persist (MBean wise), there is no reason not to use it. If we don't believe in EJBs enough to use them ourselves, how can we tell others to use JBoss for their projects. Hell, configuration persistence is something that happens so rarely (in the application sense), I don't think performance is really an issue. As for clustering stuff, keeping in mind I haven't looked at it yet. Does anyone know if hypersonic get's clustered as well? I see that to get the EJBs mass deployed there is the farm directory, so that kind of implies that there is a master server somewhere (unless everyones farm propogates to everyone else). If hypersonic doesn't cluster, then is there the ability to add to a DD something like: if (master) use local DB else use master DB We store the JMS stuff (and maybe others, I haven't looked) on disk now. With the option of using JDBC. I understand that there is a performance issue, but from the admin point of view, they'd be much happier if everything was all in one place, that was remotely viewable (ie. whatever DefaultDS points to). I've heard Marc mention several times that the winner in this space is going to be the ones with the best ease of management. And I fully agree. Knowing what it took to manage eloan.com's website, and all the problems with what files are where, all the little cron jobs on different machines to make sure the old stuff gets nuked to avoid running out of disk space. I think that a system, with a single point of management (ie: everything in single DB) would have made our lives easier. Keep in mind, my view may be tainted. Our admins pretty much all came from Oracle (or oracle based companies). So to them, having a DB be the front for everything was nirvana. My current project has all my custom config info in the database. So I can easily make changes that all servers can see, as well as perform atomic changes (update 20 config items, then commit, rather than calling setXXX, setYYY and having each change propgate one at a time). But hey, maybe that's just me. Is my view of how things should work just completely misguided? I'll shut up (agai
[JBoss-dev] RequiredModelMBean.java? / general rantings
Marc / everyone, When you asked about this Dynamic mbean thing I'm working on, were you thinking of me applying it to RequiredModelMBean? If I read correctly, we are required to supply an implementation of that class, no? If not, ignore the rest. I'd be happy convert my stuff over to be the implementation of that, since mainly the only difference with what I wrote and this is the persistent storage stuff. I do have a few questions on how it should be done. 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. 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? In my stuff, there is a protected Class[] getInterfaces() so an mbean can specify which interfaces it want's to expose to management. But, if that returns null(default impl), I just use all public methods not defined in the base or java.lang.Object to be a managed UI. Would you want that in the JBoss RequiredModelMBean? What I have now, basically allows the subclasses to specify any part of the MBeanInfo (ie, via "protected MBeanAttributeInfo[] getAttributeInfo()"), so the subclass can 'break the rules' that are defined in the base class. I wonder, is this too much complexity to offer in a generic base class to be supplied with JBoss? 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? Assuming Dain's engine has nothing to persist (MBean wise), there is no reason not to use it. If we don't believe in EJBs enough to use them ourselves, how can we tell others to use JBoss for their projects. Hell, configuration persistence is something that happens so rarely (in the application sense), I don't think performance is really an issue. As for clustering stuff, keeping in mind I haven't looked at it yet. Does anyone know if hypersonic get's clustered as well? I see that to get the EJBs mass deployed there is the farm directory, so that kind of implies that there is a master server somewhere (unless everyones farm propogates to everyone else). If hypersonic doesn't cluster, then is there the ability to add to a DD something like: if (master) use local DB else use master DB We store the JMS stuff (and maybe others, I haven't looked) on disk now. With the option of using JDBC. I understand that there is a performance issue, but from the admin point of view, they'd be much happier if everything was all in one place, that was remotely viewable (ie. whatever DefaultDS points to). I've heard Marc mention several times that the winner in this space is going to be the ones with the best ease of management. And I fully agree. Knowing what it took to manage eloan.com's website, and all the problems with what files are where, all the little cron jobs on different machines to make sure the old stuff gets nuked to avoid running out of disk space. I think that a system, with a single point of management (ie: everything in single DB) would have made our lives easier. Keep in mind, my view may be tainted. Our admins pretty much all came from Oracle (or oracle based companies). So to them, having a DB be the front for everything was nirvana. My current project has all my custom config info in the database. So I can easily make changes that all servers can see, as well as perform atomic changes (update 20 config items, then commit, rather than calling setXXX, setYYY and having each change propgate one at a time). But hey, maybe that's just me. Is my view of how things should work just completely misguided? I'll shut up (again) now. -David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
