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? > > <soapbox> > 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. > </soapbox> > > > 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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
