Re: Tomcat 7 JDBC Connection Pool - question about usage from Java code

2014-10-26 Thread Neven Cvetkovic
Hey Ric,

Thanks for asking these questions. Hopefully, this discussion will benefit
many on this list.

Here's the summary of your options obtaining connections in your
application.

As you suggested, database connections are typically obtained through a
javax.sql.DataSource object (wrapped pool of database connections). There
are few ways that database connections could be managed in a Tomcat web
application, e.g.


(1) NOT MANAGED.

Database connections are created on demand, they are not pooled, and
typically not a great way to get database connections, especially in a web
app where you have 1000s of users/requests. For simplicity, we might use
this for batch applications, since we typically control how often and how
many times the code is executed, i.e. not in 1000s of requests, as with web
application requests. Here's the code for that ...

Class.forName(some.jdbc.driver.here);
Connection c = DriverManager.getConnection();
...

So, don't use this if you are in a context of web application.



(2) CONTAINER-MANAGED CONNECTION POOL.

This is a typical JEE way to manage and pool your resources. Connection
pool is implemented as part of the application server (Tomcat, WebSphere,
Weblogic, JBoss, etc...) and each appserver has its own way to configure
and implement connection pools. In Tomcat, you need to define a Resource
... / element somewhere in your appserver configuration
(GlobalNamingResources will be in global context, or per application in
Context element of particular application). See more details here:
http://tomcat.apache.org/tomcat-7.0-doc/config/resources.html

On Tomcat, this is now implemented by Tomcat JDBC Connection Pool (
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html) and has replaced
the older traditional Apache Commons DBCP project (
http://commons.apache.org/proper/commons-dbcp).

Here's an example configuration:
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#As_a_Resource

In order to configure this, you also need to add specific database JDBC
drivers (e.g. postgresql JDBC drivers) to the server class path, typically
just copying them to CATALINA_HOME/lib directory.

Once it is configured, the connection pool will be created and registered
with JNDI on the startup of the server.

You would then get the reference to this connection pool through standard
JNDI lookups:

  (a) using container injection

@Resource(name=)
private DataSource datasource


  (b) traditional JNDI lookup

Context naming = new InitialContext();
DataSource datasource = (DataSource) naming.lookup();


  (c) or even using Spring JEE context, e.g.

jee:jndi-lookup id=mydatasource jndi-name=/




For each database (schema), you will need to create a separate JDBC
connection pool. Each one will have a separate JNDI name that you can use
to lookup/inject into your code.

And finally, third way that developers manage their connections is:



(3) APPLICATION-MANAGED CONNECTION POOL.

This way, connection pools are created per application. Container doesn't
know about the connection pool. This is very typical in Spring
applications, where you define your own datasources. Here, you can to use
any of the connection pool implementations. You could use Tomcat JDBC
Connection Pool or any other third-party connection pools, e.g.

- C3P0 (http://www.mchange.com/projects/c3p0/)
- HikariCP (http://brettwooldridge.github.io/HikariCP/)
- Apache Commons DBCP (http://commons.apache.org/proper/commons-dbcp/)

or many other ones.

Spring also provides a simple JDBC wrapper class
(org.springframework.jdbc.datasource.DriverManagerDataSource) that is not
really implementing a connection pool, but rather simplification for the
lack of better connection pool implementation. We often use this
connection pool in development, as it is simple to configure and no need
for other connection pool libraries.

More details here:
http://docs.spring.io/spring-framework/docs/4.1.1.RELEASE/javadoc-api/org/springframework/jdbc/datasource/DriverManagerDataSource.html


The connection pool is managed by the application, typically created at the
application deployment. Since the drivers are isolated to a particular
application, you don't have to place drivers in shared library folder
(CATALINA_HOME/lib) as in (2) CONTAINER-MANAGED, but rather can include
drivers in the application, e.g. WEB-INF/lib folder.

It is important that the creation of the connection pool is done at some
application-scoped level, not per request! Because, the pool itself is
putting the limits on the total number of connections to a database. Each
connection pool is independent of other connection pools that might exist.

So, in this third way - connection pool management and configuration is
done by the developer, not administrator like in CONTAINER-MANAGED
CONNECTION POOLS.

Hopefully, this sheds some light on the options we have when we need a
connection pool.

I will try to answer your other specific questions in a separate email.

Cheers!
Neven


Re: Tomcat 7 JDBC Connection Pool - question about usage from Java code

2014-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ric,

On 10/25/14 9:06 PM, Ric Bernat wrote:
 Thanks. That makes sense. Pooling for the duration of that single
 web service call is not our main goal. However, JAX-RS allows me
 to persist objects in memory across web service calls, so I can
 keep a collection of DataSource instances (e.g., by database name,
 in a ConcurrentHashMap). No problem keeping DataSource instances in
 memory for an extended period of time, is there?
 
 btw, I have worked with Microsoft tools in the past, including SQL 
 Server ADO.NET connection pooling. There, you get one connection
 pool per connection string, regardless of what object instance you
 use to instantiate your connection objects. That is doubtlessly why
 I came to Tomcat connection pooling with a 
 connection-URL-equals-connection-pool mindset.
 
 On a tangent, I am very eager to monitor Tomcat connection pooling
 so that I can see what is going on with the connection pools. To
 that end, I have configured both the JMXProxyServlet (via the
 manage webapp), and PSI Probe. And I have set 
 poolProperties.setJmxEnabled(true). However, neither of these 
 monitoring tools let me see any information about Tomcat
 connection pool state. Perhaps these tools required that I JNDI to
 configure my database connections, and cannot monitor connection
 pools created via Java code?
 
 Unless I am using those two monitoring tools incorrectly (quite 
 possible), and they really do offer a view of connection pool
 state, it seems that my only choice is to configure JMX monitoring,
 which seems non-trivial. (I am assuming that JMX will give me a
 view of connection pool state.)
 
 Or perhaps I should go the JNDI route (guessing that my two
 current monitoring apps can show connection pooling information
 for JNDI-created connection pools). However, since we create
 databases at runtime, I'm not sure that I would be able to create
 JNDI declarations for just-created databases on the fly.

I haven't used non-JNDI connection pools, so I'm not absolutely sure
about this.

- From the tomcat-pool documentation[1]:

The connection pool object exposes an MBean that can be registered. In
order for the connection pool object to create the MBean, the flag
jmxEnabled has to be set to true. This doesn't imply that the pool
will be registered with an MBean server, merely that the MBean is
created. In a container like Tomcat, Tomcat itself registers the
DataSource with the MBean server, the
org.apache.tomcat.jdbc.pool.DataSource object will then register the
actual connection pool MBean. If you're running outside of a
container, you can register the DataSource yourself under any object
name you specify, and it propagates the registration to the underlying
pool. To do this you would call
mBeanServer.registerMBean(dataSource.getPool().getJmxPool(),objectname).
Prior to this call, ensure that the pool has been created by calling
dataSource.createPool().


So, the JMX bean is being created, but it's not registered with the
JMX server so you can't see the bean remotely. You'll have to register
it yourself as described above.

That one-line call isn't entirely straightforward, so let me refer you
to a presentation on monitoring Tomcat via JMX which shows you how to
register your own beans. (In your case, the bean exists already, so
you'll just be registering the bean from tomcat-pool):
http://people.apache.org/~schultz/ApacheCon%20NA%202014/Monitoring%20Apache%20Tomcat%20with%20JMX.pdf

Hope that helps,
- -chris

[1] http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#JMX
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUTPLAAAoJEBzwKT+lPKRYJ1wP/0FhZoL/VgASr3rKUps61ocX
SV1DKdwtUalt8f++MuPODJflBEkxsjeO6tmHLlHi1Ew5yCUVDz6/GQFPJDM0j16v
tCv0veB6H+5AR4AcSvIvHZLdwnocYN3NY0mIAuxHCwfMNDxgZ5fg6m6r05/7lc6h
Q0ZZyIEpx3NT1DpwJ6Qy/4junQ0IkwkVgFaB2NY07M9Ec00uujbn2eMdFiqk0LEo
P/qTPTui0V8Y3Pe45NSwgjWzO66O6CrwB2lpt5gZyOcdQ4FQ8RCkaUw4KyPB6xjk
cbFl+Lxz7PnpXOu6OTLrVEDbhvevPKdrYUl4wk7/GL5aeIextY4pfV8VeLl6eddj
lu5gKNV0kEjgt8j+6HUP4ItGQVKxndYWBm7+TCSdAb+Md0/X9TuJISmYinniK6Mw
93ygRx2M9oSSiqR+LCUz+fXDkDcRNpEMY196OI2T077Gxyyejjsn6238f9p/Uuwr
5Q+9LA8jqHgE00bXl03ZMa8Yq5mc15W+OVG08rPqE7FQmSV6sezTClct+SJ9Jj73
vxoEDFTa0aLQu9SWaZ2V/3md0ydqeVqzBDwehSo6W33+3cau+xIG8+Kkv7RDlQJr
QPHCDAnpHmMmbcD4Lwleuua8mxqsq+RGw1X9j4aJB8cTroEvMIvd2DhW70W9O0Fm
+PWW7OpOvMQ3NffY01ZF
=bYDS
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: tomcat websocket communication with external java program

2014-10-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jason,

On 10/25/14 3:41 PM, Jason Ricles wrote:
 I have a tomcat webpage with a websocket server written in java to 
 communicate with the webpage. I want this websocket server to be
 able to communicate with an external java program without an
 sockets, so something like this
 
 webpagewebsocket serverexternal
 java program
 
 
 However I am having trouble getting that to work, since to use the 
 websocket server I need to make an instance of it and thus it
 thinks there are no session.

What do you mean websocket session?

Are you trying to use the HttpSession from a websocket call? Or only
for the HTTP call that precedes the websocket upgrade?

If you just want to inherit the session, then make sure you send a
JSESSIONID cookie or ;jsessionid path parameter in your URL with
your initial connection.

Are you launching your own Websocket server, or are you allowing
Tomcat to host the Websocket server like in a normal configuration?

 So currently I have done it the following way
 
 webpage-websocket 
 server--socket---external
 java program
 
 This is kinda messy however, so is there some way to get my
 external java program and my webpage to communicate through
 websockets without a socket go between?

I don't think this extra step is necessary, but it's pretty tough to
understand what you are trying to do.

Thanks,
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUTPOPAAoJEBzwKT+lPKRYAhAQAJghL4HjgjuEWBIbO0NQSRa7
D5i+raJCmN2dQSC0sfnsEW5NrMpKr6I0KWVBp3kjBYjXzXZ1VDbU1vPYP+O391xK
kCSqEWmwz642uCHC060DES2u9AaWkJ9RoLMRKv2LcQ0VwEFeudxe1GP8Mjjk7kYq
WtfsF0e1XU4ncYr6p1qUR0jK3Ipk4UrfnxTkU5//eqy10478uLvCIE+mdOSEjfS5
bzBy3ZMIQ0teTVkNNT4WxfUX5gxieYBsXWPLcoup01Rn1FCXwrf2x+YEZwRVJxl3
j40vWMj3O+oHCfhJcJTFhUlpeCU8kTZZdNV29qP4NKLgH7v6x+lkNor7THhNznLE
ei0t4j5pX0KeLRRA+3K+tPMRLTE514aFwmrsCmw1zyE8SKrUxl8flxwcftJUMgBO
6gyGbm8drkdqmTSusDMBquuDi+TaGkaBGftAWMPH2ev5Cvklu+YS0JwWJ8N9/8NF
lZ2hT2YabXmac+7n0PyDWT3d1CquuE/mxrtGAMZ8OP5ji6U00uStrUZiWLiFuKkX
ikX0tGgsvYvVs9Hjpwjiy+zPGx231qnsfnJzrjiA0L3TxT/l7nnUMqWDlt9E3JgM
dJy34nk49z6ic3JyC1vdOztJc/M1SzrkZBSwqk+A922JBSI8CZz0p3sYS03ePcjv
3fb4POPO8ilqsHskSLcX
=oalw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



HTTPS / URLs with no port number / Tomcat only

2014-10-26 Thread Léa Massiot
Hello and thank you for reading my post.

I was willing to run only a Tomcat server and not a Tomcat server + an
Apache HTTP server.
Mostly because:
-  an article like this one:
http://www.tomcatexpert.com/blog/2011/11/02/best-practices-securing-apache-tomcat-7
says, if I understand properly, that Tomcat is secure enough with what it
basically implements, 
- and because, if possible, I don't want to have to secure an Apache HTTP
server in addition to the rest of the architecture... (Actually I already
made a solution work with an Apache server but I was wondering if I could do
without it).

So, I am willing to serve HTTPS pages only with Tomcat and with URLs not
including a port number.

I did some config (mostly taken from
http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html and
http://java.dzone.com/articles/setting-ssl-tomcat-5-minutes)
I could make this work:
https://localhost:8443/my_webapp/a_page.jsp

And this:
http://localhost/my_webapp/a_page.jsp
automatically redirects to:
https://localhost:8443/my_webapp/a_page.jsp

Now, in all possible cases, I would like to have this URL instead:
https://localhost/my_webapp/a_page.jsp
(which doesn't work presently).

Can this be achieved with Tomcat ONLY? And how?

Best regards.



--
View this message in context: 
http://tomcat.10.x6.nabble.com/HTTPS-URLs-with-no-port-number-Tomcat-only-tp5024482.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Tomcat 7 JDBC Connection Pool - question about usage from Java code

2014-10-26 Thread Ric Bernat
Thanks, Nevin. I certainly appreciate your deep treatment of my question/issue!

I would like to ask for clarification about a point in your #2:

 (2) CONTAINER-MANAGED CONNECTION POOL.
   (a) using container injection

 @Resource(name=)
 private DataSource datasource

   (b) traditional JNDI lookup

 Context naming = new InitialContext();
 DataSource datasource = (DataSource) naming.lookup();

With either 2a or 2b, for a given JNDI resource name, regardless of where in my 
JAX-RS Java code I get the DataSource, I can be certain that I am getting a 
DataSource/connection from a container-managed connection pool, and so there is 
no need to cache anything within my application, right?

The only stumbling block for me is that in our application, databases are added 
at runtime, and I don't believe there is a way to add a JNDI Resource 
definition at runtime (i.e., GlobalNamingResources or Context element of 
particular application). Since databases are not added rapid-fire, I suppose 
each time one is added I could dynamically generate a new server configuration 
file under a temporary name, adding Resources for all databases, then run a 
script that shuts down Tomcat, replaces the server configuration copy with the 
newly generated one, and restart Tomcat. A little clumsy, I suppose, but the 
benefit would be significant.

 (3) APPLICATION-MANAGED CONNECTION POOL.

Alternatively, I can manage my own cache of connection pools (i.e., 
org.apache.tomcat.jdbc.pool.DataSource instances), keyed off of database name 
in a HashMap, for example, and storing that cache in an object that is 
persisted across web service calls (using JAX-RS Features). Do you see any 
problem with retaining org.apache.tomcat.jdbc.pool.DataSource instances in 
memory and re-using them for extended periods of time?



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: HTTPS / URLs with no port number / Tomcat only

2014-10-26 Thread Hassan Schroeder
On Sun, Oct 26, 2014 at 9:04 AM, Léa Massiot lmhe...@orange.fr wrote:

 Now, in all possible cases, I would like to have this URL instead:
 https://localhost/my_webapp/a_page.jsp
 (which doesn't work presently).

 Can this be achieved with Tomcat ONLY? And how?

Configure your https connector to use port 443 and start with jsvc --
see the Apache Commons Daemon section of the RUNNING.txt
file in the distribution.  You *could* run as root, but that's definitely
NOT RECOMMENDED :-)

Alternatively, use iptables to route port 443 requests to your current
port 8443 connector.

HTH,
-- 
Hassan Schroeder  hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 7 JDBC Connection Pool - question about usage from Java code

2014-10-26 Thread Neven Cvetkovic
Hey Ric,

Here's another thing you could do:
http://stackoverflow.com/questions/7195556/how-to-manage-connections-to-dynamically-created-databases

If your databases are all on the same db instance, but different
schema/database name, you could avoid connecting to the specific database
name, but rather set that up on the connection object, e.g.

@Resource(name=)
private DataSource datasource;

public void someMethod() {

  try
(
  Connection c = datasource.getConnection();
  c.setCatalog(dynamic_dbname);
  PreparedStatement ps = c.prepareStatement(SOME SQL HERE);
)
  {
...
  } catch (SQLException sqle) {
...
  }

}

I haven't tried this myself, but I guess this could work. Off course,
working with Spring JdbcTemplate makes it even nicer :))

How long do these dbs live? How often do you create them? Why do you have a
need for that many databases? etc...

Hope that helps!

Cheers!
Neven


INFO: TLD skipped Messages in logs

2014-10-26 Thread Kiran Badi

Hi,

I am getting below messages in the logs,

Oct 26, 2014 4:05:46 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/xml_rt is already defined
Oct 26, 2014 4:05:46 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/xml is already defined
Oct 26, 2014 4:05:46 PM org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jsp/jstl/xml is already defined

I have jstl.jar in web/lib app folder and probably have jstl jar in the 
tomcat lib directory.


I wanted to understand if this messages are related to duplicate jstl 
jar or something else .


- Kiran Badi

-



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org