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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJS6q+/AAoJEBzwKT+lPKRYmTYP/3PCNlck5jdP9gaRxGvjeg3m
> Y9VlfsPE2WkXCHXY0k+kxvmsIC8AOoz3x9olYlc0VVr2FqcB9m6go424RLPxNBK0
> TFICD8NEo1so31ZZekyK0waUZI6pu1Cbeb3bHJKdL60pfbuiEhm5RN4vJrGIdqph
> C3CtNOngCqolIc9VKXpc/n1GvO761gDH+nWwv2kz8XyrY/j0sMV5yiHfRc1WjXe/
> iNBXLFmjoQgWf5LfTv4leBca0QC67++c1C6kEopm+uF7M68tmt9vDcxjTee3MWHb
> IFzJEokjye7lmPXmZkr+ytoelMghK8EPVJXmtgezLl5yRD/qZif6mMm5ETNEuMS/
> fJWgmlNm14USGfgZg5BH1znm4yPlyU97VnfGz4EMf6qBr7tGEZqrKgEgzfl/ttGL
> MS4wxllpoG6yfPn5InD3heHbg9rVZ9DbtefjGhEWSNo9li0kCvaRhMdMlWEqQWni
> QKPdrmO/MsBh53N7RHuzS29E81RrExBFVANrklqhyqDgHbCJNFu3jnOYDu6IezzE
> Tzo2Oahh34U6T1XLt5X5QVnaX5UEFjP5IQxgQpX6FNGssVBR9jiKZ5W1C01XG5bh
> FPQCWV7SbMWMWv6MV+55ypAURZIzUON/c1ICBnrH+RyY6XlfBpewL7mp0utq1Ifa
> F2ydDKM7NRBbT2Z/IIsE
> =my7M
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
