Tomcat and web.xml

[Chris ( Val )]

Hi all,

Lets say I want to include some 'context' parameters for database
access as follows:

<context-param>
<param-name>DriverClassName</param-name>
<param-value>oracle.jdbc.driver.OracleDriver</param-value>
</context-param>

<context-param>
<param-name>JdbcURL</param-name>
<param-value>jdbcracle:thinlocalhost:1521:XE</param-value>
</context-param>

I obtain their values via the "getInitParameter(...)" method of the
application.

I have seen them used in both the Tomcat global 'web.xml' file
in the 'conf' directory, and also in the 'web.xml' file local to each
deployed application.

Is there a diffinitive answer on which is the best place do put
these parameters?

Also, is this form of database access still used, or is a databse
connection pool the preferred way?

If so, when is this kind of method used?

Thanks,

Chris

 

[Lew]

I have seen them used in both the Tomcat global 'web.xml' file
in the 'conf' directory, and also in the 'web.xml' file local to each
deployed application.

Is there a diffinitive answer on which is the best place do put
these parameters?

The same as for all "global vs. local" decisions: put information into a
global location if it's used by everything, put in a local location if it's
used only for that location.

Also, is this form of database access still used, or is a databse
connection pool the preferred way?

A database connection pool can be set up in exactly the same way, via context
parameters in the web.xml. It is an orthogonal issue.

If so, when is this kind of method used?

I am unable to parse the antecedents for "so" or "this" in this question.

 

[Chris ( Val )]

The same as for all "global vs. local" decisions: put information into a
global location if it's used by everything, put in a local location if it's
used only for that location.

Ok, I can understand that line of reasoning.

A database connection pool can be set up in exactly the same way, via context
parameters in the web.xml. It is an orthogonal issue.

Can you expand on that a little please?

Do you mean that I can I still use the "getInitParameter(...)"
method of the application object using a connection pool?

I am unable to parse the antecedents for "so" or "this" in this question.

Sorry. The 'this' above was relating to whether 'connection pooling'
was
the prefered way of obtaining a database connection over the previous
one
I presented.

Is there a preference?

At the moment I have all the code in a JSP for learning, but I imagine
that it should ultimately go into a servlet or Java Bean, right?

Thanks for your help.

Chris

 

[Lew]

Do you mean that I can I still use the "getInitParameter(...)"
method of the application object using a connection pool?
Yes.

Sorry. The 'this' above was relating to whether 'connection pooling'
was
the prefered way of obtaining a database connection over the previous
one
I presented.

Usually. Connections fall into one of three basic types: single connection
created on demand, connection pool, "XA" (transaction-aware) connection. The
difference is in which driver you use.

At the moment I have all the code in a JSP for learning, but I imagine
that it should ultimately go into a servlet or Java Bean, right?

Correct.

A servlet receives the request, parses it and farms it out to beans for
processing, collects a status, and forwards (RequestDispatcher forward()
method) to a JSP for presentation of the results.

 

[Chris ( Val )]

Usually. Connections fall into one of three basic types: single connection
created on demand, connection pool, "XA" (transaction-aware) connection. The
difference is in which driver you use.


Correct.

A servlet receives the request, parses it and farms it out to beans for
processing, collects a status, and forwards (RequestDispatcher forward()
method) to a JSP for presentation of the results.

Thanks Lew,

It's beginning to make sense, and I appreciate your help

Chris