Re: [JBoss-dev] current mbean structure confusing
David, 100% agree with you! Our architecture consists of independent services having their own build and runtime configuration. However we also do a master build that dynamically composes the services into one deployment configuration. In 3.0 it just means copying specified archives (with *-service.xml inside) to the deploy directory. Clean and straightforward! In 2.x we had to create an additional ANT's task that was merging the configuration of each service into one master jboss.jcml file. Messy! On the other hand, we are experiencing the same issue as Bill with the need to invoke our EJB from a MBean as soon as the EJB is deployed/available. Jiri. On Thu, 6 Dec 2001 15:04:48 -0500, you wrote: Marc, don't throw the baby out with the bath water. I agree the current situation is too confusing. However, IMHO, one of the main benefits of the multi-sar/service.xml packaging is exactly the control you get from so many files. It divides pieces of the server up into chunks you don't need to understand in order to select or use. For instance, to add or remove jbossmq, you just add/remove ONE FILE. You don't need to know anything about whats in it. To add or remove jetty, it's ONE FILE. To switch dbs you switch one file. If you put everything into the master jboss-service.xml you will lose the ability to construct the server you want out of complete pieces, and will have to figure out by hoping the comments are still accurate which mbeans go with which chunk of functionality. I've noticed that virtually noone seems to have noticed that you can force jboss to use the db of your choosing simply by replacing the hypersonic db config with one for your favorite database, and eliminating the hsqldb mbean. So, I don't think asking users to configure a large jboss-service.xml file for the particular pieces they want is realistic. With regard to adding stuff to the base jboss-service.xml, I don't recommend it, unless your mbeans really only depend on the beans in that file. I think in the long run it will be way more confusing. I think the best solution is to include a jboss-service.xml file in the ear for your application. (I'm not sure if this is working at the moment - there's some code for it in j2eedeployer, but I haven't tried it). Just my opinions. david jencks On 2001.12.06 13:52:36 -0500 marc fleury wrote: I AM WORKING ON IT RIGHT NOW Could somone possibly supply a v. brief summary of the current situation and what the final plan is? Some things it would be useful to know: The current situation is that simple jboss.jcml like deployment which was in the first Rabbit-hole release I did was removed to force the more advanced sar/dependency framework. for example: 1. I take it jboss-service.xml is loaded first - would it work if I put other (independent) services in here, even though it says not to ? See my previous mail, I am removing the comment, you are of course invited to put your mbeans in here. 2. Is the boot-server configuration only used for booting over the network - can we try this out just now, and how do you decide what configuration it obtains/supplies?? That I really don't know what it is doing there, see my previous mail on jetty here http://www.jboss.org/forums/thread.jsp?forum=66=4975 It's gone unless I hear from Jules in the next 30 seconds. 3. Why does the jetty mbean in the jboss-service.xml (in boot-server) refer to two files which don't exist (at least not in the current build): see above, 4. Do all my other services go in the deploy directory rather than conf/blah? This seems to make it a bit harder to set up several different static configurations (as you would do previously by just creating new dirs in jboss/conf). I guess the hot-deploy of services makes this less of an issue. this is where a feature made the default went haywire... the feature is can I hotdeploy parts of my server, example scenario (real life): a large fortune 1000 user is developing custom MBeans and they use it in their server, they want to hot-deploy the stuff to be able to DEVELOP FAST with JBoss as the infrastructure. In JBoss 2.x this is statically linked at boot time, we are building the modular kernel Linux2.0 style and that is good. SHOULD ALL THE CONFIGURATION GO THIS WAY ? hell no! can it? yes! should it? no! that is what imnsho david was missing. The work is done and is top class (REALLY) but it shouldn't be the default way to configure. About the only real criticism I have is that the support for adding base directory without specifying anything was removed, that was a mistake. 5. Should they be sars, or plain xml files, or does it matter. Are the sars only necessary if I want to supply additonal jar files without putting them in lib/ext? Good question that is something I am still thinking about here is my current understanding (disclaimer: research).
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? 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
Re: [JBoss-dev] Off-Topic: Mangement of Java Classes through SNMP
Take look at The lizzard lounge forum and Jboss and SNMP thread. It seems there is currently no a clean implementation of SNMP JMX adaptor... Jiri. On Tue, 25 Sep 2001 11:53:42 -0700, you wrote: Hi Geeks I am looking for information how Java Classes can be managed through SNMP (I know this sounds ugly). Does anyone has some info or a link about this ? Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
