[GLASSFISH-19451] Allow JDBC driver to be loaded from application archive Created: 15/Dec/12  Updated: 23/Feb/14

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shalini
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: datasource, ear, embedded, jdbc, war

 Description   

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.



 Comments   
Comment by Darious3 [ 20/Dec/12 ]

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 ]

Has anything happened for this yet?

Comment by arjan tijms [ 16/Dec/13 ]

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 ]

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 ]

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.

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

my applications 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 agree. This shouldn't be required. I logged issue JAVAEE_SPEC-34 for precisely this a short while ago. There's a corresponding GlassFish specific issue at GLASSFISH-20666

If you care for getting those solved, please vote for them as well

Comment by martinandersson.com [ 23/Feb/14 ]

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 ]

I think this could be a pretty nice community contribution .

Generated at Wed Aug 05 05:07:08 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.