On Wed, Jun 26, 2002 at 09:32:45AM -0700, [EMAIL PROTECTED] wrote:
> 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 :-)
Obviously ;)
> 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 ).
Via an interface on the java side, I guess?
> 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.
I can see how that would be useful.
<snip>
> > 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.
That's good news. When reading through a large file, a well laid out
properties file can be really easy to scan through, either visually,
or using perl or awk. The ini format makes this a bit more difficult,
especially in one liners.
> > > 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.
Agreed.
> 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 ).
Apologies. For some reason, I'd read your comment as "my goal is to
use the native config format of the platform" without thinking that
where-ever we go, Java is still the platform.
> 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>.
Now that is useful. If I get some time today, I'll have a play and
document it. Thanks for the pointer.
Cheers,
Simon
--
"The other day when I was walking through the woods, I saw a rabbit
standing in front of a candle making shadows of people on a tree."
Steven Wright
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
