ABT,
On 4/29/25 8:23 AM, A Name wrote:
On Mon, Apr 28, 2025 at 1:07 PM Mark Thomas <ma...@apache.org> wrote:
On 28/04/2025 16:35, Christopher Schultz wrote:
ABT,
On 4/28/25 9:05 AM, A Name wrote:
We are looking at adding a second instance of our app (named
differently --
myappA and myappB) to our Tomcat 9. We currently have the app
installed at
a number of customer locations, we are looking at dropping 1 app
Currently, our database connections are established inside the GLOBAL
web.xml in /conf/web.xml - and have been forever. This was a design
decision made long ago - that way the app doesn't have a separate
configuration for each location - it is the same app WAR file, and the
connections are established at the server.
Our customer doesn't want any code changes - is there a way to have
some
sort of conditional statements in the web.xml?
No, but maybe you don't need them.
JDBC configurations are never stored in web.xml, regardless of
location.
So maybe you are talking about <datasource-ref> or something like that?
Unless your application is collecting some configuration from web.xml
and then making its own connections or establish its own JDBC data
source, your configuration should be in META-INF/context.xml in the
web
application. If you don't want to bundle that with your web
application,
you can deploy a site-specific configuration file in Tomcat's conf/
[Engine]/[Host]/[appname].xml file which contains this configuration.
Then your web.xml only has to reference the name of the data-source in
datasource-ref which can be static. The local configuration file gives
the details, and web.xml references them.
Will this approach not work for you?
Or if we set it up so Tomcat is hosting 2 sites (www.sitea.com/myapp
and
www.siteb.com/myapp) and have the global web.xml with different
settings
based on host/site?
As Mark says, "global is global".
Thinking about this some more and to expand on Chris's excellent
suggestion.
You can define multiple JDBC connection pools in conf/web.xml and then
use <ResourceLink /> in the context.xml
https://tomcat.apache.org/tomcat-11.0-doc/config/globalresources.html#Resource_Links
<https://tomcat.apache.org/tomcat-11.0-doc/config/globalresources.html#Resource_Links>
There are also Host level configuration files for context.xml and
web.xml that apply to all applications within that Host.
HTH,
Mark
Right now - in our conf/web.xml we have:
<context-param>
<param-name>type</parm-name>
<param-value>SIMPLE</param-value>
</context-param>
I can already tell that you are making your own data source, since
Tomcat does not process anything from context-params related to JDBC
DataSources.
<context-param>
<param-name>datasource</parm-name>
<param-value>mydatasource</param-value>
</context-param>
<context-param>
<param-name>driver</parm-name>
<param-value>oracle.jdbc.OracleDriver</param-value>
</context-param>
<context-param>
<param-name>url</parm-name>
<param-value>jdbc:oracle:thin:@dbserver:port:sid</param-value>
</context-param>
<context-param>
<param-name>username</parm-name>
<param-value>mydbuser</param-value>
</context-param>
<context-param>
<param-name>password</parm-name>
<param-value>mydbuserpassword</param-value>
</context-param>
I'm not "fluent" in tomcat - this is the configuration that has always been
there in the conf/web.xml. But I see those are Context-Params - so maybe
they'd be appropriate in the conf/Context.xml?
Not directly.
My guess is that your application is establishing its own JDBC
DataSource. That's not terribly unusual, but one of the services that
Tomcat provides is configuration and management of such data sources.
They are configured differently, however.
I wouldn't recommend that you simply change your configuration because
it may cause your code to fail.
Are you able to view the sources of the application? Are you (or your
team) knowledgeable enough about the code to make such changes? IMHO, I
would take the time to make these changes because it will simplify your
application (Tomcat would now be responsible for building and managing
the data source) and also allow you to configure your application in a
more flexible way -- essentially it makes it possible to achieve your
goal of decoupling the configuration from the application bundle itself.
In the new world, I'd need 2 sets of those parameters (basically with the
same names for the app to find them). one pointing to dbserver-site1 and
one pointing to dbserver-site2.
Basically I'm looking for ideas that would not involve App code changes if
possible. I can change the XML configs in the conf directory without
issue... but for program reasons, at this time, the app code (or the
META-INF/xml files) are not supposed to be touched on considering this
adventure.
An app code change would be best, but you can also use some well-work
hacks to get around that.
I think your host/site context.xml file ideas are interesting. Would I be
able to take the context info that I put here out of web.xml and put it in
the conf/Catalina/localhost/site1app.xml and put another copy in
conf/Catalina/localhost/site2app.xml with the different
url/username/password?
That would be an ideal and simple answer.
I can think of two other ways to do this. The first way requires no code
changes and should continue to work. It essentially uses the same
servlet context parameters you are already using, but re-locates them to
context.xml -- which I didn't actually know you could do until I just
re-re-re-re-read the documentation.
https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Context_Parameters
You can remove these from WEB-INF/web.xml:
<context-param>
<param-name>foo</param-name>
<param-value>bar</param-value>
</context-param>
And put them into META-INF/context.xml under <Context> (which is the
document-element for that file):
<Parameter name="foo" value="bar" override="true|false"/>
If you move those definitions and they work, then you can take the next
step and move the application's META-INF/context.xml file out of the
application and into Tomcat's conf/[engine]/[host]/[appname].xml
If that works, then enjoy your day. :)
Another option would be to use XML entities which is slightly more
tricky and would raise eyebrows of any attentive security reviewer.
As I was putting-together the instructions for this idea, I realized
that you can't have anything dynamic in the web.xml to identify which
application is trying to use the XML entity, which would be a file
containing the app-specific configuration. So forget I said anything
about XML entities and hope that the first solution works for you.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
