Remy Maucherat wrote: > (This question is for Costin) > > As I've mentioned before, I'm writing a new mapper to replace the > current 5.0 request mapper, which is a major performance problem right > now. > > The implementation goes well enough (I'll likely commit something today > or tomorrow; in the end, there are no fancy algorithms involved), but > there's the problem of keeping the mapper structure in sync with > Catalina's structure. > > To do that, I was planning to use a simple MBean registration listener > (as all the components we're interested in register with JMX) with the > MBean server. (I can only see a way of doing that using JMX 1.2) > > So, is it ok to do that ? Is there a better way (I don't want to use the > Catalina listeners, obviously) ?
If the question is about using JMX1.2 - it was alredy proposed, and it seems nobody objected ( but nobody did it either ). If you want to do that - all you need is update the mbean descriptors, and change all the arrays to use the JNI names ( [Ljava.lang.String; instead of java.lang.String[] ). And of course - fix download to get jmxri instead of mx4j. When MX4J implements 1.2, we'll switch back. I'm using JMXRI1.2 - and so far it works very nice. Regarding the registration listener: there are 2 issues you need to be carefull. First, it would be good if the code is independent of the load order - i.e. listen for notifications but also do a query for the existing objects. You can do that using JMX query, or by using the attributes. After you take care of the existing mappings, you can start listening for registration - you can do both with plain JMX1.1. I don't know if all the components are registered - we do have the Context and Servlet, but you'll need to make sure the Context mbean is exposing the mappings. Unfortunately JSR77 ( or other standards I know ) do not define any standard attribute that a "WebModule" mbean would use to expose supported mappings - so the code will remain dependent of catalina, but with less cupling. BTW, I am now able to create Context mbeans and have them registered automatically - and I'll try to get the same working for Valves, Connectors and JkHandlers. If this is used with an mbean server that supports reloading ( like jboss.mx ) - we'll be able to replace modules without restarting the VM ( which is pretty cool ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
