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