On Wed, 26 Jun 2002, Simon Stewart wrote: > Will do. The most obvious thing that springs to mind is that the > config files don't look anything like the declarative xml that is used > when configuring other enterprise java components (I'm thinking of > web.xml, ejb-jar.xml, etc) or the pseudo-xml of httpd.conf. Since an > XML parser is included "for free" with JDK1.4, and tomcat can > obviously parse XML even without this (web.xml again) how hard would > it be to implement?
Not hard, and it could be done on the C side as well ( via expat ). Patches wellcomed :-) What I want to enforce is the 'plugability' of the config data repository, and make sure the code will work with simpler mecanisms like properties file ( i.e. we're not dependent on XML ). I believe it's important for scalability ( i.e. 100s of tomcats in a farm ) to be able to use a directory service ( like LDAP, NDS, active directory ) for configuration. And I believe it's important for integration of tomcat into another application or system to be able to adapt to that application's config mechanism. That may mean registry ( via JDK1.4 prefs or jk2 native code in <JDK1.3) or even JMX-persistence implementations or whatever an app is using. And is usefull for small footprint profiles - i.e. J2ME-class. > The format of the workers2.ini file is even more perplexing: it > doesn't look anything like a "normal" java properties file; more like > a windows INI file than anything else. It just doesn't "chime" with > the experience of your average admin or java developer, ime. Actually workers2.properties supports 'normal' properties syntax. [foo] a=b is the same as foo.a=b. The 'ini' syntax is IMHO easier to type and read - and is used in quite a few applications ( windows, but also gnome, kde, etc ). And is very close to a directory-service view and model. > > My goal was (is) to eventually support a preferences-like > > configuration, with multiple backends ( including directory services > > and win32 registry ). > > It sounds like an interesting thing to do, but won't this hamper > portability? It's nice to be able to take the jk2.properties and > workers2.properties and put them in the right place on any platform. I think the .properties are the baseline - they should work on any platform or server. Portability doesn't mean an app can't be integrated or shouldn't be able to take advantage of special features ( like an LDAP server or registry, or doors, unix sockets, etc ). As an example - it is possible to configure mod_jk2 using only httpd.conf. This is a bit faster ( but scales much better for large number of vhosts/mappings ). This is done using "JkSet name value" ( instead of name=value in the properties format ) and "JkUriSet name value" inside <Location>. A similar thing can be done with IIS for example ( where the 'natural' config is in registry ). Nacho already implemented a win32 logger ( again, the 'natural' thing for this case ). Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
