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 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
