Please don't top-post . . .
Comments at the bottom.
On 1/30/2014 1:43 PM, Jerry Malcolm wrote:
ok... I'm going to bite the bullet and move forward... I've set up a
sandbox and downloaded 7.0.50.
As I started comparing my server.xml to the template in the 7.0.50, I
realized that I actually did start from the template for 7.0.27 for
everything except the context blocks. That's where I hit a brick wall
and just copied all of the contexts from the original
who-knows-how-far-back config.
Here's my main problem that I simply cannot figure out at this
point.... In my environment, I have the same web app deployed across
several virtual hosts. With each host I have a different database.
The way I learned to configure things eternities ago was to simply
include all of the context blocks inside the <host> blocks in
server.xml. And then I'd define different <resource> tags referencing
the different databases inside each context block:
<host> 1
<context 'myApp1'.....
<resource database = "host1dbForMyApp1".....
</context>
</host>
<host> 2
<context 'myApp1'.....
<resource database = "host2dbForMyApp1".....
</context>
</host>
That's worked fine. I have known for a while that the recommendation
is to NOT include <context> blocks in server.xml and to rather create
context.xml files in META-INF directory. Fine.... but here's the wall
I'm hitting.... if I have one context.xml for myApp1 that now is
common to all hosts, HOW do I tell myApp1 to use one db resource for
host1 and a different db resource for host2? I've read through tons
of the how-to pages in the docs, and I'm coming up empty. I would
think it would make sense to define the resource at the host level.
But according to what I can find in the docs, a resource tag is not
legal directly under a host tag.
If you can help me out with this, I'll be well on my way....
Thanks.
On Thu, Jan 30, 2014 at 2:02 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 1/30/14, 2:49 PM, Jerry Malcolm wrote:
The <Logger> element hasn't been valid in Tomcat for longer
than I can remember. This config smacks of someone blindly
copying over a very, very old setup into a more recent
installation. Bad idea.
You're making my point precisely about why I don't upgrade every
time a new release comes out. Yes..... I'm someone who 'blindly
copies' a config file, bad idea or not.... I've got a major
environment that works and is in critical business path production
for my client.
All the more reason why you should clean everything up.
I guess I'm supposed to take a blank piece of paper or some canned
template and re-create my entire configuration from scratch each
time I upgrade the server code.
Not necessarily. It would be good for you to identify how your
(server) configuration differs from the default. For us, the only
differences are in the <Connector> and <Executor> elements: everything
else is the same. We keep a server.xml template file under revision
control for every major version of Tomcat on which we expect to deploy
(e.g. 5.5, 6.0, 7.0) and usually point-releases don't require
modification of those files at all. Our build process merges the
template with the required values (port numbers, for instance) and
builds a working Tomcat instance.
If you move your <Context> configuration out of server.xml, that will
help a lot, too.
But I'm going to have a tough time explaining the down time to my
client while I debug and try to get the brand new config file back
up and running
That's what test environments are for. You can even set one up on a
laptop: they aren't that complicated.
and researching, for example, why <logger> went away in the new
release and what I need to do to replace the functionality that
worked in an earlier release.
<Logger> went away in favor of a more standardized logging system
(which has caused a great deal of uproar within the community, I might
add).
This process may work for some users. But it would put me out of
business. This is why I'm on 7.0.27 and, sadly, will probably not
be moving soon.
Are there any config file migration tools available?
Not really. Configurations are mostly simple: connector/port, maybe a
<Host> or two. We use the default configuration for <Host> (everything
is localhost, i.e. we don't care about formal virtual hosts), and
access logging is configured in our web app's META-INF/context.xml file.
Do you have any idea where your original configuration came from? You
could do a diff against the "stock" version of that configuration and
then make similar changes to a fresh server.xml from tomcat.apache.org.
I'm sure there are folks on the list who would be available to help
you physically do all this (for a fee, of course) and walk you through
the process (I myself might be such a person). Otherwise, you are free
to post as many questions as you'd like and we'll try to answer them,
explain, etc.
It's really worth putting the time in to clean-up our configuration
and understand what is going on. That will make updates less painful
and scary.
- -chris
I think I remember this discussion from a while ago.
If I remember correctly, you're not fond of creating one WAR for each
virtual host, and using your build process to populate the appropriate
META-INF/context.xml for each web application / virtual host combination.
OK, here's another way to manage this.
1. Create a WAR file or exploded directory
2. Place it outside of ALL appBase directories
3. Create a separate appName.xml for EACH virtual host
a. if it's the default application, call it ROOT.xml
b. if it's appName, call it appName.xml
c. the location of the file is CATALINA_BASE/conf/Catalina/[hostname]
4. In each appName.xml
<Context docBase="absolute-path-to-WAR-or-directory">
<Resource "database stuff goes here"/>
</Context>
Another way to manage this:
1. Deploy the web application "normally" with the manager application
a. don't put any database resources in META-INF/context.xml
b. This means you'll have multiple physical copies (no big deal)
2. In each CATALINA_HOME/conf/Catalina/[hostname]
a. create a context.xml.default
b. put the following in:
<Context>
<Resource "database stuff goes here"/>
</Context>
3. This will be loaded by all applications in that particular host
See the documentation here:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
The above reference provides details for both of the above solutions.
. . . . just my two cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
