Jakob Praher wrote:
>> Right now catalina can be extended with Valves or connectors or >> listeners. >> Some of them (like jk connector ) can define MBeans. The major problem >> is having the admin interface recognize them - it should work >> but I never tried. > > I'll have to look at them. > > I only know that the default mbeans are plugged in with a > lifecyclelistener. The lifecycle listener generates model mbeans for components. A component can register its own mbeans. There is one major problem - if a component is not recognized by modeler ( which generates the mbean proxy ) you may see an exception. That will be fixed ( by using the META-INF and the introspection - and allowing external components to be loaded by modeler ). > but I like the idea of beeing able to add MBeans to webapps. > where is your code located in the jakarta-modeller source tree ? Registry.java. There are 2 pieces of code - one for loading descriptors from META-INF and another one for generating metadata using introspection. Using mbeans in webapps ( or adding modeler wrappers for any bean ) is easy, the real problem is integrating those mbeans with the admin and using the full power of the mbean model ( like jboss is doing ) ( for things like reloading modules, etc). The module-as-webapp stuff in tomcat3.3 tried to solve the same problem, but mbeans and mlets are a _far_ better solution. >> The only important thing is to get the MBeanServer using the same >> mechanisms ( i.e. get existing instead of creating new one ). >> > don't know exactly what you mean by this ... Don't create the mbean server - first look for existing instances. Look at Registry.java for the code that gets the mbean server. >> Another issue that wasn't much discussed is having mechanisms to >> use mbeans as extensions ( hooks, etc) - and use the mbean lifecycle >> and naming as a registration ( or alternatively, use a JNDI/JMX >> combination - the big problem with JMX is that you can't get the real >> object, all calls must be made via mbean server) > > yes that's the tradeof. this makes JMX so powerful ( no direct > references ) but it can make things slow ... For config stage - it doesn't matter most of the time, it's not a critical path. ( you don't do 100 config changes per second ). JMX notifications can be used to dynamically add/remove modules - but the problem is that inside the code you must use the real instance ( instead of invoke ). That's why I think JNDI + JMX is the right solution - catalina already has a very good JNDI support, and what we can do is use JNDI for naming and JMX for management ( the way they were intended :-). JMX notifications and name can be used to lookup in JNDI for the actual hook ( Valve, interceptor, handler, etc ), and combined with the mlet stuff this gives us the maximum flexibility ( i.e. you can add/remove/change/reconfig connectors and valves without restarting the server - if you want to ). All this is relatively easy to implement - but it requires a lot of preparation ( and agreement on the details ). > one thing I could imagine is to go both directions: > > a) via MBeans > b) via plain java interfaces ... That's my opinion as well ( with the "plain java interfaces" bound in the JNDI ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
