|<< Back to previous view|
[GLASSFISH-19451] Allow JDBC driver to be loaded from application archive Created: 15/Dec/12 Updated: 23/Feb/14
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Tags:||jdbc datasource war ear embedded|
|Participants:||arjan tijms, Darious3, martinandersson.com, reza_rahman and Shalini|
As one of the few application servers, GlassFish does not allow a JDBC driver to be loaded from a .war or .ear (see http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee). Instead, the driver is required to be stored inside the GlassFish installation directory.
Especially for applications that use an embedded database and an application scoped datasource (specifically those using @DataSourceDefinition), this is not convenient. Those applications can be coded to be almost portable, with the exception that for GlassFish a jar (the JDBC driver) has to be copied from the archive to the AS installation directory.
I would like to ask for the ability to load said JDBC driver directly from an application archive such as .war and .ear.
|Comment by Darious3 [ 20/Dec/12 10:43 AM ]|
You can now include glassfish-resources.xml in your war, where you can define JDBC resources. These resources have a lifetime scoped to the WAR (created and destroyed when the WAR is deployed/undeployed).
This behavior really should apply to the JDBC driver as well.
|Comment by Darious3 [ 04/Apr/13 07:13 PM ]|
Has anything happened for this yet?
|Comment by arjan tijms [ 16/Dec/13 10:16 PM ]|
This seems to have been "silently" fixed in GlassFish 4. The following unit test in the Java EE samples project shows this: https://github.com/javaee-samples/javaee7-samples/blob/master/jpa/datasourcedefinition/src/test/java/org/javaee7/jpa/datasourcedefinition/DataSourceDefinitionTest.java
This test addresses the exact use case this issue is about and puts the JDBC driver into the application archive. The test passes on a stock (embedded) GlassFish 4.
Maybe it should also be tested on a standalone GlassFish 4, but hopefully this shouldn't make any difference.
|Comment by martinandersson.com [ 23/Feb/14 11:31 AM ]|
The github example you give inject the datasource. I must use a persistence.xml file to declare the persistence unit that relies on my @DataSourceDefinition. With this requirement I can't get my application to work. Another way for me since Java EE 7 is to use the default data source, but then of course, my application still don't deploy deploy and work properly since GlassFish doesn't start his Derby database automatically. For me, I refuse to manually copy-paste jar files to the glassfish installation direction as much as I refuse to manually start the derby database. I can happily do that for a production environment, but until then, as what is my issue now, I'm using Arquillian to do real proper integration tests.
|Comment by arjan tijms [ 23/Feb/14 01:33 PM ]|
You're most likely being affected by this bug: GLASSFISH-20944
The driver seems to load, but then because of a timing issue of some sorts, or maybe a scoping issue, the JPA boot code can't locate the datasource. Very unfortunate indeed! (please vote for that issue if you think it impacts you). See also JAVAEE_SPEC-30
If you care for getting those solved, please vote for them as well
|Comment by martinandersson.com [ 23/Feb/14 03:00 PM ]|
Thank you Arjan for your feedback, you seem to be a real good spirit. Keep it up! Yeah I did vote for those other issues =)
|Comment by reza_rahman [ 23/Feb/14 05:29 PM ]|
I think this could be a pretty nice community contribution .