glassfish
  1. glassfish
  2. GLASSFISH-19451

Allow JDBC driver to be loaded from application archive

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: jdbc
    • Labels:
      None

      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.

        Activity

        Hide
        Darious3 added a comment -

        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.

        Show
        Darious3 added a comment - 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.
        Hide
        Darious3 added a comment -

        Has anything happened for this yet?

        Show
        Darious3 added a comment - Has anything happened for this yet?
        Hide
        arjan tijms added a comment -

        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.

        Show
        arjan tijms added a comment - 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.
        Hide
        martinandersson.com added a comment -

        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.

        Show
        martinandersson.com added a comment - 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.
        Hide
        arjan tijms added a comment -

        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

        Show
        arjan tijms added a comment - 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
        Hide
        martinandersson.com added a comment -

        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 =)

        Show
        martinandersson.com added a comment - 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 =)
        Hide
        reza_rahman added a comment -

        I think this could be a pretty nice community contribution .

        Show
        reza_rahman added a comment - I think this could be a pretty nice community contribution .

          People

          • Assignee:
            Shalini
            Reporter:
            arjan tijms
          • Votes:
            7 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: