On Wed, 14 Jul 2004, Jess Holle wrote:
|
| >>Using a modular multi-XML-file approach does not pollute the
| >>result with any additional server-specific or Tomcat-specific
| >>baggage. It just makes management and automated
| >>configuration/installation much more workable.
| >>
| >>
| >In contrary, it makes it simpler, cause you have a common denominator, and
| >that is 'well documented' config file, usable on any container.
| >
| >
| What I'm saying here is that I want modular per-web-app config-file
| support. I don't care if any/all server-specific and Tomcat-specific
| stuff is removed from them -- actually that is laudable in the long term
| even if a bit painful in the short term. I just don't want to be forced
| into shoving the whole configuration into a single file (or using XML
| entity reference hacks which are beyond ugly -- and require the main
| file to be modified to add extra entity references which is highly
| undesirable).
Couldn't agree more.
|
| >JkUriSet can be used only on the Apache server.
| >So, the question is, are we adapting the apache module to other servers, or
| >we have a
| >container independent module.
| >
| >
| I think you are missing my point:
|
| Go ahead and remove JkUriSet, just add equivalent functionality to
| do per-web-app configuration files. Just do it in a
| server-independent, XML-based way this time around.
Most definately.
But get them files understandable!!
(I, contrary to many others, apparently, like auto-stuff to a degree.
However, I most definately need to know -what- is assumed, possibly using
some "what-are-assumed" command, or log the assumptions to file on
startup)
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
