I've a connection pool to access a MySQL DB from a servlet. I get the data source using a JNDI, which is defined on my META-INF/context.xml file.
Everything is working fine, but I have to place the MySQL driver JAR within Tomcat's /common/lib folder, instead of webapp's WEB-INF/lib; otherwise the JNDI will not work (ClassNotFoundException: com.mysql.jdbc.Driver).
Is there any other way to get the datasource, which allows me to place the JAR inside WEB-INF/lib? All the examples I've found over the Internet are using JNDI...
(It's a quite simple application, I'd really prefer not to have to import 53 JARs of some framework in order to solve my problem :)
Thanks!
While most of these replies are about pools, I don't think that's your question?
I think the most direct answer to your question is, simply import and use the DataSource implementation provided by your driver. You're using MySQL Connector/J? then it's MysqlDataSource.
There are methods on it to set username, password, etc.
If you don't need it in JNDI, then you don't have to configure it in JNDI via Tomcat. You can keep the driver jar in WEB-INF/lib, sure. If you want pooling around that DataSource, indeed, just use Commons DBCP and Pool.
Here's an example of making your own pooling DataSource out of a given DataSource.
You might try what sun already suggests:
Connection Pooling
If you don't want to use JNDI, then you can't use Tomcat's connection pool mechanism, you'll need to incorporate one into your application, and that means adding 3rd-party libraries to your WAR file. It's one or the other, the choice is yours.
If you decide to go the 3rd-party route, I suggest using Apache Commons DBCP (which in turn requires Apache Commons Pool).
Simple apps grow. Frameworks may initially seem like overkill, but all too easily you gradually find that you are reinventing wheels and growing your own framework.
Consider the person who comes after you ... they go to the internet and look up a technique, find it commonly used, come back to your code and lo! you did it a different way.
The Java EE framework code, the JDBC drivers, everything should be in your server environment, no need to include it into your app. So the overhead should be quite small. This approach really pays off as you develop more applications.
Bite the bullet, save the creativity for the unsolved problems.
I definitely agree with you that datasource should stay out of context.xml. You will have to do this if you want externalize your configuration. We went through this process not long ago. It's quite easy. I can't give you the code but I can point you to the right direction,
You need to define <Resource> in your own configuration and find a way to parse it. You can use JAXP, Apache Digester. I am lazy so I use Apache Commons Configuration.
The <Resource> is just name-value pairs. You need to convert them into Properties.
You can make a datasource like this,
DataSource ds = org.apache.commons.dbcp.BasicDataSourceFactory.createDataSource(prop);
A side-effect of doing this is that you can disable JNDI (useNaming="false") to make server a little bit lighter.
Related
If I have a raw servlets application, how hard is it to integrate spring's jdbc templates into it?
I don't want to deal with the low level jdbc code, so I was thinking of using jdbc templates.
I'm not looking to use spring as a IOC or anything, just want to use the jdbc tooling to make db access a little less painful.
Does it have any dependencies or assume things to be in place other than the necessary jars?
I'm using tomcat's jdbc pool, so I have a datasource to pass to it.
It is very simple to add and it does not require you use IOC. If you use maven or ivy, the dependencies are handled for you otherwise it is likely you will need spring-core and possibly spring-beans (i dont know the specifics off the top of my head). Also, if you want transactions, then you will want IOC as the container would create proxy beans that implement the transactional behavior.
Is there a free and/or open-source library which provides a JNDI provider stored as something simple like a configuration file which includes encryption for passwords?
It seems like JNDI is the J2EE API for providing container-managed configurable items but I can't find a general, container-independent solution out there. Am I missing the point of JNDI? Alternate solutions are welcome but I'd like to avoid including large-scale dependencies (such as Spring or Maven).
It seems a bit like taking a drug because you want one of its side effects, but...
The POJava Persistence library has a JNDI provider intended for the purpose of supporting JUnit test cases running outside of a container. It's just an in-memory implementation, but the same library can also serialize objects to/from xml, so you could extend it to load from a file on init and drop to a file whenever appropriate.
We have a utility spring-mvc application that doesn't use a database, it is just a soap/rest wrapper. We would like to store an arbitrary message for display to users that persists between deployments. The application must be able to both read and write this data. Are there any best practices for this?
Multiple options.
Write something to the file system - Great for persistence. A little slow. Primary drawback is that it would probably have to be a shared file system, as any type of clustering wouldn't deal well with this. Then you get into file locking issues. Very easy implementation
Embedded DB - Similar benefits and pitfalls as just writing to the file system, but probably deals better with locking/transactional issues. Somewhat more difficult implementation.
Distributed Cache - Like Memcached - A bit faster than file, though not much. Deals with the clustering and locking issues. However, it's not persistent. Fairly reliable for a short webapp restart, but definitely not 100%. More difficult implementation, plus you need another server.
Why not use an embedded database? Options are:
H2
HSQL
Derby
Just include the jar file in the webapps classdir and configure the JDBC URL as normal.
Perfect for demos and easy to substitute when you want to switch to a bigger database server
I would simple store that in a file on a filesystem. It's possible to use an embedded database, or something like that, but for 1 message, a file will be fine.
I'd recommend you store the file outside of the application directory.
It might be alongside (next to) it, but don't go storing it inside your "webapps/" directory, or anything like that.
You'll probably also need to manage concurrency. A global (static) read/write lock should do fine.
I would use JNDI. Why over-complicate?
Currently, we store datasource definitions in the Tomcat container inside server.xml and expose environment variables through context.xml.
Any time we change an environment variable or datasource, it requires a server restart for those changes to be live.
Is there a way that we could create a web application to manage these things? Instead of storing them in the server context.xml and server.xml files, we could store them in another file and have them be modifiable through the webapp. When an application wants a datasource, it could request it from the webapp (maybe through messaging). I had thought about modifying the jndi elements at runtime and saving the changes in a file, but found that Tomcat does not allow that.
If it's not obvious, I have only a little experience with the technologies involved, but would like a direction to head in. I don't want to do anything hackish and would like to follow standards.
Would it be correct to have a webapp that handles global datasource and global variable management, requiring you to request these objects through messaging? If not, what are some preferable alternatives?
Well, you could have used the Tomcat "admin" package, if it existed. But then, it was never ported from version 5 to 6 for various reasons. The post itself states the right way on how one must right the admin tool.
In the meantime, you could possibly use the MBeans exposed by Tomcat, although I can't vouch for anything useful being present.
Look at migrating to a different application server.
For instance Glassfish might suit your requirements.
http://blogs.oracle.com/alexismp/entry/glassfish_ose_3_0_1
http://glassfish.java.net/
I have never connected to a database in java before. May I know if I should go about accessing a derby database with servlet?
I have checked this: How do I access a database from my servlet or JSP?
But I saw comments on the article saying that this is a bad way to connect. Could any one explain or show me the best way to that I should code to access my derby database?
Thank you very much.
They are all right indeed, in suggesting that. We don't don't access database directly from Servlets or JSPs, these both are meant to be web tier, isn't it?
So, what to do? Grab a JDBC tutorial. The official one is an excellent choice here. That will give you a good idea about connecting to database from Java, and grasp over JDBC API. After that you should go and read about DAO pattern, and how we employ that in real apps.
Moreover, I think you also should read about MVC pattern, because it seems to me that you are not very clear on that as well.
Once you understand all these and come up with a toy like application using all these stuff. Next step would be to have a look into Connection Pooling mechanism.
Since you are using servelt you must be using a container line Apache Tomcat. You should look to define a connection pool like this http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html. If you are using any other container then that will also have similar setup.
Other option is to create a separate DBManager kind of class which looks after initializing and returning connection. This class you can use in the servlet.
Using JDBC and having your app server's application pool is a good start. You can also use some API to make your life easier like Hibernate.
It is a "bad way", because it doesn't make use of a (JNDI-managed) connection pool to obtain connections. Although acquiring a connection costs "only" a few hundred milliseconds, this has impact in a busy multiuser environment. A connection pool will worry about opening and closing connections and release them immediately on every getConnection() call so that it effectively costs almost zero milliseconds. If you sum that up in a busy multiuser environment, then the differences are noticeable.
A connection pool is usually to be configured in flavor of a JNDI datasource which is managed by the servletcontainer in question. As you didn't mention which one you're using, I can at highest point to one of my answers which contains a Tomcat 6.0 targeted example: here.
Hope this helps.