On Tue, Apr 29, 2025 at 10:54 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> > 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. > > I have a team of developers - but, at this moment, the customer does not want a path that includes code changes. We may change in the future, but I was investigating a no-code change option. > > > 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. > > We can keep that in mind for the future - but due to other priorities from the customer, code changes for this are not on the table. > > 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 > <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. :) > I might put them straight in the appname.xml in my sandbox - changing META-INF/context.xml changes what deploys with the app and that's still in the "not right now" currently. > > 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 > Thanks Chris. I'll sandbox the appname.xml idea and see what happens. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
