javaee-spec
  1. javaee-spec
  2. JAVAEE_SPEC-7

Clarify and improve @DataSourceDefinition

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      Java EE 6 introduced the @DataSourceDefinition and corresponding data-source deployment descriptor element to allow an application to define a DataSource. (see JSR 316 EE.5.17 and JSR 250 2.13)

      This opens the door for creating both self-contained applications (i.e. for which an administrator does not need to setup anything before the application can be deployed and started) and applications that have a portable DataSource definition.

      However, in practice it's still not entirely possible to fully use this and use this portably due to a few omissions in the spec.

      One problem is that the spec does not say anything about the location of the required JDBC driver. JSR 250 does say in section 2.13:

      The driver class is not required to be available at deployment but must be available at runtime prior to any attempt to access the DataSource.

      In order to create a self-contained application that defines a DataSource in the java:comp, java:module or java:app JNDI namespaces, the user should be able to place the driver on the classpath corresponding to the components which can access those namespaces. E.g. WEB-INF/lib for the web module. Currently this is possible with e.g. JBoss AS 7.1, but not with GlassFish 3.1.

      Another problem is that the spec is not really clear about the transactional behavior. An example from which behavior can be deduced is given in JSR 250 section 2.13:

      Vendors are not required to support properties that do not normally apply to a specific data source type. For example, specifying the transactional property to be true but supplying a value for className that implements a data source class other than XADataSource may not be supported.

      Since this is non-trivial functionality, a somewhat more in depth specification of the desired behavior might not be out of place.

      The annotation and xml variant define attributes for pooling, but pooling is seemingly not mandated. JSR 250 calls those attributes "vendor specific". As a result, at least one vendor (JBoss) treats the annotation as a facility for testing and development only in its certified product:

      Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.)

      (source: https://community.jboss.org/wiki/DataSourceConfigurationInAS7)

      To sum up, I would like to request the following improvements:

      • Specify all valid locations of the JDBC driver
      • Mandate possibility to use application embedded JDBC driver for application scoped datasources
      • Clarify transactional behavior
      • Mandate connection pooling

      I hope that with these improvements @DataSourceDefinition/data-source can become a facility that is more likely to be used for actual production work.

        Activity

        Hide
        Bill Shannon added a comment -

        All the java: JNDI names are defined by the spec and are portable.
        If you're using a JNDI name that doesn't start with java:, it's
        product-specific.

        Yes, it's true that the Java EE spec defines a Java EE namespace.
        Are you wondering whether any of these JNDI names work in plain Java SE?
        They're not required to.

        Show
        Bill Shannon added a comment - All the java: JNDI names are defined by the spec and are portable. If you're using a JNDI name that doesn't start with java:, it's product-specific. Yes, it's true that the Java EE spec defines a Java EE namespace. Are you wondering whether any of these JNDI names work in plain Java SE ? They're not required to.
        Hide
        Bill Shannon added a comment -

        Note also that the defined way to package a JDBC driver with an application
        is to package it as a Resource Adapter and include the rar file in the ear file.

        Still, it seems like putting the JDBC driver in WEB-INF/lib should also work.
        If it doesn't, please file a bug against GlassFish.

        We need to see if there's anything in the spec that needs to be clarified in this area.

        Show
        Bill Shannon added a comment - Note also that the defined way to package a JDBC driver with an application is to package it as a Resource Adapter and include the rar file in the ear file. Still, it seems like putting the JDBC driver in WEB-INF/lib should also work. If it doesn't, please file a bug against GlassFish. We need to see if there's anything in the spec that needs to be clarified in this area.
        Hide
        arjan tijms added a comment -

        Note also that the defined way to package a JDBC driver with an application is to package it as a Resource Adapter and include the rar file in the ear file.

        This might be an option for ears indeed (I've never tried it though), but as ease of use goes, just dropping it in EAR/lib is probably easier. For a web profile implementation and/or a war, a .rar is unfortunately not an option.

        If it doesn't, please file a bug against GlassFish.

        I filed this one a short while ago. It's at: GLASSFISH-19451

        Show
        arjan tijms added a comment - Note also that the defined way to package a JDBC driver with an application is to package it as a Resource Adapter and include the rar file in the ear file. This might be an option for ears indeed (I've never tried it though), but as ease of use goes, just dropping it in EAR/lib is probably easier. For a web profile implementation and/or a war, a .rar is unfortunately not an option. If it doesn't, please file a bug against GlassFish. I filed this one a short while ago. It's at: GLASSFISH-19451
        Hide
        rmannibucau added a comment -

        So basically using spring i have no gurantee i can acces these jndi names (not manged beans) + what does mean managed beans? Ejb, cdi, javax.annotation.ManagedBean? That's totally unclear in specs in general.

        Show
        rmannibucau added a comment - So basically using spring i have no gurantee i can acces these jndi names (not manged beans) + what does mean managed beans? Ejb, cdi, javax.annotation.ManagedBean? That's totally unclear in specs in general.
        Hide
        Bill Shannon added a comment -

        The Java EE spec does not and will not describe what you can do in Spring.
        For that, you'll need to read the Spring spec.

        If there's something you still feel isn't clear in the Java EE spec, please
        file a new issue. The original issue here has been addressed and I'm closing
        this issue.

        Show
        Bill Shannon added a comment - The Java EE spec does not and will not describe what you can do in Spring. For that, you'll need to read the Spring spec. If there's something you still feel isn't clear in the Java EE spec, please file a new issue. The original issue here has been addressed and I'm closing this issue.

          People

          • Assignee:
            lancea
            Reporter:
            arjan tijms
          • Votes:
            3 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: