Craig R. McClanahan wrote: > (Breathing a sigh of relief that I don't actually have to *implement* this > stuff, but hoping to contribute a little anyway :-)
Well, the fact that I don't have to implement much is a relief for me too... Both the API and a lot of drivers ( including xml file ) are already written, we have a lot of support ( caching, etc ) already and Remy is an expert. >> For API - my initial approach was to create a clone of 1.4 prefs. > > Thinking outside the box a little, what would be the implications of > prereq'ing JDK 1.4 as the minimum for Tomcat 5? Then, we could consider > using prefs directly instead of via wrappers. The reason I prefer JNDI over prefs have nothing to do with the VM. JNDI is much more mature, more widely used, more powerfull, we already have a lot of support and knowledge, there are many drivers. And it supports the 'distributed / high-end' use case ( directory server ) out-of-box. I don't mind having prefs used by default if 1.4 is detected - i.e. registry on windows and .xml files on unix. It is quite easy to write a JNDI context that uses prefs underneath. I don't mind using 1.4 features - but using 1.4 as a minimm is a bit too much. Even 1.3 may be questionable. For me the baseline is what GCJ supports ( i.e. the classpath project ). I still believe in 'java everywhere' :-) > Using DirContext instead of just Context would also let us think about a > storage format with fewer objects in it -- one per managed object instead > of one per property -- because we could use JNDI attributes for the > individual properties themselves. Such an entry maps pretty directly to > *being* an MBean as well ... it might be possible to kill two birds with > one stone here. Exactly ! And one nice thing in JNDI is that we can do a lot of 'lazy' evaluation. If nobody is going to configure an object, there is no point introspecting it. Just bind it to a context and when someone asks for attributes we do the introspection. And you can also construct objects dynamically - which is even better. JMX will require you to register each object and most implementations will do a full introspection when you register. And that involves a lot of objects and overhead. > Some utility methods that perform direct conversion between the structured > name types would be well worth it performance-wise. We don't want to be > dealing with the String versions of these names any more than we'd have > to. +1 The jndi Name is not bad. And it maps well into JMX ObjectName. >> Using notifications it is possible to propagate any change via >> JMX to the store - but that should be optional ( i.e. you could >> choose to not change the store, but only the runtime ). >> > > Note that this would need to include configuration changes the component > does for itself (i.e. calculate the work directory path if one hasn't been > explicitly configured), not just those performed by external management > tools. I don't agree. The configuration is what the user specifies. What the component determines by itself shouldn't slip into the config file. Only user-initiated config must be stored ( exactly like if the user would edit the file directly and restart ). >> Any operation ( reload, etc ) will be done via JMX - only >> setting attributes is important for config. >> > > While on that topic, it would be useful for some managed objects to > support two "instances" of a component in memory simultaneously -- for > example, when upgrading a webapp you often want to leave the old version > running (and accepting requests) until the new version has been fully > initialized and is ready to start accepting requests. Probably a 'ver' component in the name ? We really need to reorganize the JMX names. > Part of the motivation for JMX in the first place was to support the > ability to have external management apps be able to talk with it. If we > didn't need that, we wouldn't really need it -- we could just use JNDI to > represent the internal component hierarchy (extending the way Catalina > already represents a webapp's static resources as a JNDI context). I know. JMX is also necesary to support 'operations' ( reload, start, etc ). But the nice thing about using JNDI as the 'first line' is that JMX can be used with less performance impact. For example we can have a 'master' jmx object that would register other on demand - using the information in the JNDI hierarchy. > One avenue to consider if the number of MBeans becomes an issue (I'm not > sure that it really is -- we've got an instance of the real component > class per component anyway) is to make MBeans only for coarse grained > things, and represent fine-grained things as attributes of the coarse > grained MBeans. Conceptually, this is the same sort of design choice you > make with entity EJBs about how fine grained you get. It's not > necessarily an all-or-nothing decision. Well, on MBean per servlet is important if you want statistical data ( times, number of request, etc). And that's quite usefull. One MBean per user is unacceptable if you are a big organization ( with thousands of users) Again, JNDI was designed to deal with this kind of situations - a directory server may store/manipulate large ammounts of data. And we would only 'bind it' - i.e. store the real object in a hashtable, and create the MBeans only on demand. Probably that would require special attention to the master MBean that would find and dynamically create other mbeans. As a note, representing the 'user' as just a DirContext with some attributes we care about can also simplify the user management and make the code more generic and flexible. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
