embedded tomcat and context.xml

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

embedded tomcat and context.xml

Rob Sargent
I'm old and easily confused: does an embedded tomcat server read (any)
context.xml file?  I find conflicting answers /out there./

Using tomcat 9.0.40

    embeddedTomcat =new Tomcat();
    embeddedTomcat.setPort(tomcatPort);
    embeddedTomcat.enableNaming();
    embeddedTomcat.getConnector();// an init, really String contextRootPath =System.getenv("CATALINA_HOME");
    Context contextTomcat =embeddedTomcat.addContext("",new File(contextRootPath +"/sgs").getAbsolutePath());

I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
servlets, none of which are not named in the web.xml.

Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Rob Sargent
typo: should read "none of which are named in the web.xml" (not "which
are NOT" as below)

On 12/2/20 11:31 AM, Rob Sargent wrote:

> I'm old and easily confused: does an embedded tomcat server read (any)
> context.xml file?  I find conflicting answers /out there./
>
> Using tomcat 9.0.40
>
>    embeddedTomcat =new Tomcat();
>    embeddedTomcat.setPort(tomcatPort);
>    embeddedTomcat.enableNaming();
>    embeddedTomcat.getConnector();// an init, really String
> contextRootPath =System.getenv("CATALINA_HOME");
>    Context contextTomcat =embeddedTomcat.addContext("",new
> File(contextRootPath +"/sgs").getAbsolutePath());
>
> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
> servlets, none of which are not named in the web.xml.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Christopher Schultz-2
In reply to this post by Rob Sargent
Rob,

On 12/2/20 13:31, Rob Sargent wrote:

> I'm old and easily confused: does an embedded tomcat server read (any)
> context.xml file?  I find conflicting answers /out there./
>
> Using tomcat 9.0.40
>
>     embeddedTomcat =new Tomcat();
>     embeddedTomcat.setPort(tomcatPort);
>     embeddedTomcat.enableNaming();
>     embeddedTomcat.getConnector();// an init, really String
> contextRootPath =System.getenv("CATALINA_HOME");
>     Context contextTomcat =embeddedTomcat.addContext("",new
> File(contextRootPath +"/sgs").getAbsolutePath());
>
> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
> servlets, none of which are named in the web.xml.

Tomcat should be reading your web application's META-INF/context.xml
file, if one exists.

If you call Tomcat.init(), it will attempt to locate the default
conf/server.xml, conf/web.xml, and conf/context.xml based upon your
configuration source.

What are you /really/ asking?

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Rob Sargent
Chris,
Thanks for you time. Your response goes a long way to explaining why there is so little specific information on embedding tomcat.
Really, just as I said.  I had convinced myself from several items encountered on the web that an embedded tomcat instance would not read the standard conf/*.xml.  If I hit any of those pages again I will react (either on the page or perhaps post here, if that would be appropriate).  

TL/DR: at heart I’m struggling with the proper initialization and consumption of the dbpc2 datasource which I add programmatically and might consider using the context.xml version.  A litany of small issues:
My @Resource(name, type) Datasource ds” doesn’t take (I have several more attempts planned)
Is that failure logged?
Is context.lookup() expensive?
Is there any configuration available only in xml?
DriverManager is working fine but it that the best access to the DataSource, which I need to be able to change the current database (in a postgres sense)


> On Dec 3, 2020, at 8:06 AM, Christopher Schultz <[hidden email]> wrote:
>
> Rob,
>
> On 12/2/20 13:31, Rob Sargent wrote:
>> I'm old and easily confused: does an embedded tomcat server read (any) context.xml file?  I find conflicting answers /out there./
>> Using tomcat 9.0.40
>>    embeddedTomcat =new Tomcat();
>>    embeddedTomcat.setPort(tomcatPort);
>>    embeddedTomcat.enableNaming();
>>    embeddedTomcat.getConnector();// an init, really String contextRootPath =System.getenv("CATALINA_HOME");
>>    Context contextTomcat =embeddedTomcat.addContext("",new File(contextRootPath +"/sgs").getAbsolutePath());
>> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my servlets, none of which are named in the web.xml.
>
> Tomcat should be reading your web application's META-INF/context.xml file, if one exists.
>
> If you call Tomcat.init(), it will attempt to locate the default conf/server.xml, conf/web.xml, and conf/context.xml based upon your configuration source.
>
> What are you /really/ asking?
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Christopher Schultz-2
Rob,

On 12/3/20 11:03, Rob Sargent wrote:
> Thanks for you time. Your response goes a long way to explaining why
> there is so little specific information on embedding tomcat.
Only programmers are interested in using embedded Tomcat, so having
"Tomcat Embedded For Dummies" isn't terribly useful. (I don't mean to be
insulting; I'm just trying to get my point across about "intro-level"
content regarding Tomcat as an embedded product.)

Embedding Tomcat into a product is done precisely because the standard
deployment model (which lends itself to system admins who don't really
need to know anything about Java programming) isn't sufficient for some
special-case. Indeed, every Tomcat embedded instance is by definition a
special-case so guides for "doing it" don't exist since nobody else
knows exactly what you are trying to do.

> Really, just as I said.  I had convinced myself from several items
> encountered on the web that an embedded tomcat instance would not
> read the standard conf/*.xml.  If I hit any of those pages again I
> will react (either on the page or perhaps post here, if that would be
> appropriate).
The best references for behavior of the Tomcat class would be:

1. The Tomcat javadoc
and
2. The source code for the Tomcat class

It's fairly readable, but most everything you need to read is in the
Javadoc.

> TL/DR: at heart I’m struggling with the proper initialization and
> consumption of the dbpc2 datasource which I add programmatically and
> might consider using the context.xml version.

Unless there is a particularly good reason not to use it, I would
recommend using META-INF/context.xml. There are some really great
reasons not to do that. For example, if you want to fetch your DBCP
configuration from Kubernetes and then use that to dynamically-configure
DBCP, then you'll probably have to forego XML-based configuration.

> A litany of small issues: >
> My @Resource(name, type) Datasource ds” doesn’t take (I have several more attempts planned)

Ooh. I tend to avoid @Annotations and I'm not really sure how that one
works, anyway. I'm not a good resource, here.

> Is that failure logged?

Dunno.

> Is context.lookup() expensive?

No. Tomcat's implementation of JNDI contexts isn't much more complicated
than a HashMap. In some other EE containers, context.lookup() might
indeed be expensive.

> Is there any configuration available only in xml?

I don't know for sure, but I suspect not. The XML configuration uses the
commons-digester to call setFoo("bar") for each foo="bar" attribute on
the <Resource>, so I don't think there is anything in there what
couldn't be done 100% in Java code. You might have to dig-around a
little to find the default implementations of various things (like
DataSource/DataSourceFactory) but that shouldn't be too tough.

> DriverManager is working fine but it that the best access to the
> DataSource, which I need to be able to change the current database
> (in a postgres sense)
Do you need to change the user after container-initialization, like
potentially for any given request? Is there anything wrong with
registering multiple database pools and then selecting the right one
depending upon the effective user during the request?

Maybe you don't even want a connection pool. I remember you saying you'd
be wildly successful if you had 2 users per day or something like that.

-chris

>> On Dec 3, 2020, at 8:06 AM, Christopher Schultz <[hidden email]> wrote:
>>
>> Rob,
>>
>> On 12/2/20 13:31, Rob Sargent wrote:
>>> I'm old and easily confused: does an embedded tomcat server read (any) context.xml file?  I find conflicting answers /out there./
>>> Using tomcat 9.0.40
>>>     embeddedTomcat =new Tomcat();
>>>     embeddedTomcat.setPort(tomcatPort);
>>>     embeddedTomcat.enableNaming();
>>>     embeddedTomcat.getConnector();// an init, really String contextRootPath =System.getenv("CATALINA_HOME");
>>>     Context contextTomcat =embeddedTomcat.addContext("",new File(contextRootPath +"/sgs").getAbsolutePath());
>>> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my servlets, none of which are named in the web.xml.
>>
>> Tomcat should be reading your web application's META-INF/context.xml file, if one exists.
>>
>> If you call Tomcat.init(), it will attempt to locate the default conf/server.xml, conf/web.xml, and conf/context.xml based upon your configuration source.
>>
>> What are you /really/ asking?
>>
>> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Rob Sargent
Again, much appreciated feedback.  (I never think what I'm doing is all
that special)

Though two concurrent users would really be "wildly successful", each of
those users will fire up hundreds (thousands if we get
permission/capacity) of EC2 instances and start pounding the db, so I
think connection pooling is in order.

I contemplated managing my own pools but didn't want

  - the hassle of resetting the "search_path" for each connection if I
used a single (initial) user (if I stuck with the tomcat pooler)

  - the overhead in terms of both my own code and actual resource
consumption(minimum connection held etc)

so I switched to the dbcp2 PerUserPoolDataSourceFactory in the hope that
the lookup for an available connection happens after I reset the user/db
(Recall that with postgres a db is just part of the same physical
server, of which there will be only one and for me a user is associated
with only one database.)

Really great to hear that lookup() is not my biggest concern;)

Thanks again,
rjs


On 12/3/20 3:18 PM, Christopher Schultz wrote:

> Rob,
>
> On 12/3/20 11:03, Rob Sargent wrote:
>> Thanks for you time. Your response goes a long way to explaining why
>> there is so little specific information on embedding tomcat.
> Only programmers are interested in using embedded Tomcat, so having
> "Tomcat Embedded For Dummies" isn't terribly useful. (I don't mean to
> be insulting; I'm just trying to get my point across about
> "intro-level" content regarding Tomcat as an embedded product.)
>
> Embedding Tomcat into a product is done precisely because the standard
> deployment model (which lends itself to system admins who don't really
> need to know anything about Java programming) isn't sufficient for
> some special-case. Indeed, every Tomcat embedded instance is by
> definition a special-case so guides for "doing it" don't exist since
> nobody else knows exactly what you are trying to do.
>
>> Really, just as I said.  I had convinced myself from several items
>> encountered on the web that an embedded tomcat instance would not
>> read the standard conf/*.xml.  If I hit any of those pages again I
>> will react (either on the page or perhaps post here, if that would be
>> appropriate).
> The best references for behavior of the Tomcat class would be:
>
> 1. The Tomcat javadoc
> and
> 2. The source code for the Tomcat class
>
> It's fairly readable, but most everything you need to read is in the
> Javadoc.
>
>> TL/DR: at heart I’m struggling with the proper initialization and
>> consumption of the dbpc2 datasource which I add programmatically and
>> might consider using the context.xml version.
>
> Unless there is a particularly good reason not to use it, I would
> recommend using META-INF/context.xml. There are some really great
> reasons not to do that. For example, if you want to fetch your DBCP
> configuration from Kubernetes and then use that to
> dynamically-configure DBCP, then you'll probably have to forego
> XML-based configuration.
>
>> A litany of small issues: >
>> My @Resource(name, type) Datasource ds” doesn’t take (I have several
>> more attempts planned)
>
> Ooh. I tend to avoid @Annotations and I'm not really sure how that one
> works, anyway. I'm not a good resource, here.
>
>> Is that failure logged?
>
> Dunno.
>
>> Is context.lookup() expensive?
>
> No. Tomcat's implementation of JNDI contexts isn't much more
> complicated than a HashMap. In some other EE containers,
> context.lookup() might indeed be expensive.
>
>> Is there any configuration available only in xml?
>
> I don't know for sure, but I suspect not. The XML configuration uses
> the commons-digester to call setFoo("bar") for each foo="bar"
> attribute on the <Resource>, so I don't think there is anything in
> there what couldn't be done 100% in Java code. You might have to
> dig-around a little to find the default implementations of various
> things (like DataSource/DataSourceFactory) but that shouldn't be too
> tough.
>
>> DriverManager is working fine but it that the best access to the
>> DataSource, which I need to be able to change the current database
>> (in a postgres sense)
> Do you need to change the user after container-initialization, like
> potentially for any given request? Is there anything wrong with
> registering multiple database pools and then selecting the right one
> depending upon the effective user during the request?
>
> Maybe you don't even want a connection pool. I remember you saying
> you'd be wildly successful if you had 2 users per day or something
> like that.
>
> -chris
>
>>> On Dec 3, 2020, at 8:06 AM, Christopher Schultz
>>> <[hidden email]> wrote:
>>>
>>> Rob,
>>>
>>> On 12/2/20 13:31, Rob Sargent wrote:
>>>> I'm old and easily confused: does an embedded tomcat server read
>>>> (any) context.xml file?  I find conflicting answers /out there./
>>>> Using tomcat 9.0.40
>>>>     embeddedTomcat =new Tomcat();
>>>>     embeddedTomcat.setPort(tomcatPort);
>>>>     embeddedTomcat.enableNaming();
>>>>     embeddedTomcat.getConnector();// an init, really String
>>>> contextRootPath =System.getenv("CATALINA_HOME");
>>>>     Context contextTomcat =embeddedTomcat.addContext("",new
>>>> File(contextRootPath +"/sgs").getAbsolutePath());
>>>> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
>>>> servlets, none of which are named in the web.xml.
>>>
>>> Tomcat should be reading your web application's META-INF/context.xml
>>> file, if one exists.
>>>
>>> If you call Tomcat.init(), it will attempt to locate the default
>>> conf/server.xml, conf/web.xml, and conf/context.xml based upon your
>>> configuration source.
>>>
>>> What are you /really/ asking?
>>>
>>> -chris
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: embedded tomcat and context.xml

Christopher Schultz-2
Rob,

On 12/3/20 17:46, Rob Sargent wrote:
> Again, much appreciated feedback.  (I never think what I'm doing is all
> that special)

At this point, the fact that you are using embedded Tomcat is really
just a detail that doesn't affect the greater question of how to manage
your complex database pooling needs.

> Though two concurrent users would really be "wildly successful", each of
> those users will fire up hundreds (thousands if we get
> permission/capacity) of EC2 instances and start pounding the db, so I
> think connection pooling is in order.

What do those EC2 instances actually do? Do they connect to your
application (which connects to the db), or do they connect directly to
the db?

> I contemplated managing my own pools but didn't want
>
>   - the hassle of resetting the "search_path" for each connection if I
> used a single (initial) user (if I stuck with the tomcat pooler)
>
>   - the overhead in terms of both my own code and actual resource
> consumption(minimum connection held etc)

I would highly recommend that you abstract this away from your
application with some kind of utility method like:

public Connection getConnection(whatever args you need);

Then you can change that method to do whatever is necessary. Maybe it's
determine which pool to use, and use it. Maybe it's create a new
connection every single time. Maybe it's a mixture of the two.

> so I switched to the dbcp2 PerUserPoolDataSourceFactory in the hope that
> the lookup for an available connection happens after I reset the user/db

I think Phil said that doesn't work. You can call
getConnection(username,password) but it won't pool those connections. I
haven't read the code, but I suspect that is what happens.

If you need to switch *databases*, there really is no way to do that.
Besides, you'd never want to restrict yourself to using the *same*
database connection(s) for more than one database, would you? You'd
never be able to separate the databases onto separate servers, clusters,
etc.

I seem to recall that tomcat-pool can actually do this, but maybe it
just implements the API and also just hands you a fresh connection every
time with your username and password. (i.e. not actually pooling).

> (Recall that with postgres a db is just part of the same physical
> server, of which there will be only one and for me a user is associated
> with only one database.)

Maybe you want to consider a multi-tenant database
(tablespace/schema/etc.) instead of having a distinct one for each customer.

Another option would be to spin-up a separate application (instance) for
each customer, each with its own one-and-only-one db connection pool.

> Really great to hear that lookup() is not my biggest concern;)

;)

-chris

> On 12/3/20 3:18 PM, Christopher Schultz wrote:
>> Rob,
>>
>> On 12/3/20 11:03, Rob Sargent wrote:
>>> Thanks for you time. Your response goes a long way to explaining why
>>> there is so little specific information on embedding tomcat.
>> Only programmers are interested in using embedded Tomcat, so having
>> "Tomcat Embedded For Dummies" isn't terribly useful. (I don't mean to
>> be insulting; I'm just trying to get my point across about
>> "intro-level" content regarding Tomcat as an embedded product.)
>>
>> Embedding Tomcat into a product is done precisely because the standard
>> deployment model (which lends itself to system admins who don't really
>> need to know anything about Java programming) isn't sufficient for
>> some special-case. Indeed, every Tomcat embedded instance is by
>> definition a special-case so guides for "doing it" don't exist since
>> nobody else knows exactly what you are trying to do.
>>
>>> Really, just as I said.  I had convinced myself from several items
>>> encountered on the web that an embedded tomcat instance would not
>>> read the standard conf/*.xml.  If I hit any of those pages again I
>>> will react (either on the page or perhaps post here, if that would be
>>> appropriate).
>> The best references for behavior of the Tomcat class would be:
>>
>> 1. The Tomcat javadoc
>> and
>> 2. The source code for the Tomcat class
>>
>> It's fairly readable, but most everything you need to read is in the
>> Javadoc.
>>
>>> TL/DR: at heart I’m struggling with the proper initialization and
>>> consumption of the dbpc2 datasource which I add programmatically and
>>> might consider using the context.xml version.
>>
>> Unless there is a particularly good reason not to use it, I would
>> recommend using META-INF/context.xml. There are some really great
>> reasons not to do that. For example, if you want to fetch your DBCP
>> configuration from Kubernetes and then use that to
>> dynamically-configure DBCP, then you'll probably have to forego
>> XML-based configuration.
>>
>>> A litany of small issues: >
>>> My @Resource(name, type) Datasource ds” doesn’t take (I have several
>>> more attempts planned)
>>
>> Ooh. I tend to avoid @Annotations and I'm not really sure how that one
>> works, anyway. I'm not a good resource, here.
>>
>>> Is that failure logged?
>>
>> Dunno.
>>
>>> Is context.lookup() expensive?
>>
>> No. Tomcat's implementation of JNDI contexts isn't much more
>> complicated than a HashMap. In some other EE containers,
>> context.lookup() might indeed be expensive.
>>
>>> Is there any configuration available only in xml?
>>
>> I don't know for sure, but I suspect not. The XML configuration uses
>> the commons-digester to call setFoo("bar") for each foo="bar"
>> attribute on the <Resource>, so I don't think there is anything in
>> there what couldn't be done 100% in Java code. You might have to
>> dig-around a little to find the default implementations of various
>> things (like DataSource/DataSourceFactory) but that shouldn't be too
>> tough.
>>
>>> DriverManager is working fine but it that the best access to the
>>> DataSource, which I need to be able to change the current database
>>> (in a postgres sense)
>> Do you need to change the user after container-initialization, like
>> potentially for any given request? Is there anything wrong with
>> registering multiple database pools and then selecting the right one
>> depending upon the effective user during the request?
>>
>> Maybe you don't even want a connection pool. I remember you saying
>> you'd be wildly successful if you had 2 users per day or something
>> like that.
>>
>> -chris
>>
>>>> On Dec 3, 2020, at 8:06 AM, Christopher Schultz
>>>> <[hidden email]> wrote:
>>>>
>>>> Rob,
>>>>
>>>> On 12/2/20 13:31, Rob Sargent wrote:
>>>>> I'm old and easily confused: does an embedded tomcat server read
>>>>> (any) context.xml file?  I find conflicting answers /out there./
>>>>> Using tomcat 9.0.40
>>>>>     embeddedTomcat =new Tomcat();
>>>>>     embeddedTomcat.setPort(tomcatPort);
>>>>>     embeddedTomcat.enableNaming();
>>>>>     embeddedTomcat.getConnector();// an init, really String
>>>>> contextRootPath =System.getenv("CATALINA_HOME");
>>>>>     Context contextTomcat =embeddedTomcat.addContext("",new
>>>>> File(contextRootPath +"/sgs").getAbsolutePath());
>>>>> I know it is finding WEB-INF/web.xml (under "sgs") and finds all my
>>>>> servlets, none of which are named in the web.xml.
>>>>
>>>> Tomcat should be reading your web application's META-INF/context.xml
>>>> file, if one exists.
>>>>
>>>> If you call Tomcat.init(), it will attempt to locate the default
>>>> conf/server.xml, conf/web.xml, and conf/context.xml based upon your
>>>> configuration source.
>>>>
>>>> What are you /really/ asking?
>>>>
>>>> -chris
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]