Mladen Turk wrote:
From: Jess HolleWell, you have a JK or that.
I can see eliminating all web-server-specific configuration options in the long-term -- though keeping the existing options around for a while as deprecated alternatives would be nice, i.e. to give everyone a conversion grace period.
Point taken.
No, though on this basis I can understand and concur with your general idea. I just firmly believe forcing an entire server's jk2 configuration including all web-apps' configurations into a single XML file lacks sufficient modularity.I cannot, however, see pushing everything into a single XML file. This is insufficiently modular for a web server that may have dozens of web apps with their own specific settings. Rather what I'd suggest is something like:Did you try to set up the JK2 on some other server then Apache?
Did you try to use your server.xml from TC on other platforms?Huh? server.xml is Tomcat-specific -- as are the <Context> elements. That's like saying "did you ever try to use mod_jk2 config files with JRun".
Now if what you mean is have I tried it with Tomcat on various OS and web server platforms, then the answer is, yes.
Until Tomcat allowed <Context> elements to be placed outside its server.xml into separate, per-web-app files, configuring (non-WAR) web apps led to ugly to a merging and general maintenance issue with server.xml. Once per-web-app XML config files were allowed things became 1000 times more manageable from a tooling and maintenance perspective.
[Now if your question is shouldn't everything be done via WAR files, then you're one of the lucky few for whom unexpanded WAR files actually fulfill your requirements.]
Having things Apache specific AFAICT was the major reason why so manyNothing about modular XML files should be Apache specific. I'm just suggesting we learn from Tomcat's experiences and not require every web-app's configuration be merged into a single XML file. It was not workable there and it won't be here.
project has failed.
-- Jess Holle
