1. glassfish
  2. GLASSFISH-2092

Deployer cannot bind a persistence-unit to an arbitrary JDBC data source without changing the EAR file


    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.1pe
    • Fix Version/s: future release
    • Component/s: jdbc
    • Labels:
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:


      ISVs are used to provide .msi files to Windows users. The deployer is using the
      Windows Installer Tool (as service that is part of the Windows OS) to configure
      properties found in the .msi file (for example, name of the company, etc.).
      This information gets processed by the Windows Installer Tool at time of
      installation of the programs found inside of the .msi file.

      So at least on Windows deployment is separated in stages: (a) Creation of
      an .msi archive file including binaries and configurable deployment properties,
      (b) Configuring properties using the configuration part of an installation
      tool, (c) Copying files and writing configuration values using the installation
      engine part of an installation tool. Whether this tools is called RPM,
      InstallShield or Windows Installer doesn't make a difference. Nor does it
      matter whether the OS is called Windows or Linux. The three stages are the same

      On the Java EE platform, JSR88 specifies "The Java EE Way" of these three
      stages: (a) Packaging of EJB-JARs and EARs including configurable deployment
      properties in the technical form of deployment descriptors and persistence.xml
      files, (b) Configuring the actual set of configuration values (including
      providing information missing in persistence.xml, like "which JDBC data source
      to use for this persistence unit") using a configuration tool (which, in turn
      uses a deployment driver in "offline mode"), (c) copying files on the server
      and writing configuration values into the server's proprietary configuration
      registry, using a deployment tool (which, in turn uses a deployment driver
      in "online mode").

      That's the way the story should go.

      But actually the world seems not to be as perfect, since not all people are
      using JSR88 tools to install EJB-JARs and EARs into GlassFish. Some (or: a lot
      of) people still are doing steps (b) and (c) using the browser based GUI.

      Those people actually are facing the problem that in step (b) they want to
      configure which JDBC data source a persistence unit shall be bound to.
      Unfortunately, they cannot. They have to live with the fact that each
      persistence unit is bound to jdbc/__default. If they want to change it, they
      must unpack the EAR and EJB-JAR to be able to change the persistence.xml file
      found inside of. Then, they must repack it, to make GF load and deploy it.

      This is not very convenient, since least users (1) like to unpack, edit, and
      repack their modules, and (2) like to have all of their EARs running on the
      same, single data base. Example: A company buys SAP, so they install SAP.ear.
      It must be bound to the SAP DB obviously. Then they buy a bug tracking system,
      so they install BugTrackSystem.ear. Obviously, BugTrackSystem.ear shall be
      bound to the BugTrackSystem DB. Neither does the company want to unpack both
      EARs and fiddle around in the persistence.xml files, nor does the company want
      to have BugTrackSystem.ear and SAP.ear be bound to jdbc/__default (which, by
      default, is bound to a Derby DB).

      So what is missing is a way to use the Web Based Admin GUI to say "this
      persistence unit had to be bound to that JDBC data source".

      As that is an essential link in every GF installation, I think this is a bug
      but not just some idea of a good feature.

      Also, the JPA specification contains the following:

      " jta-data-source, non-jta-data-source
      In Java EE environments, the jta-data-source and non-jta-data-source elements
      are used to specify the global JNDI name of the JTA and/or non-JTA data source
      to be used by the persistence provider. If neither is specified, the deployer
      must specify a JTA data source at deployment or a JTA data source must be
      provided by the container. "

      The GlassFish team interpreted " deployment time OR ... provided by the
      container..." is: "We, the GlassFish team, are free to decide whether we are
      providing a data source, or whether the deployer will provide one". Actually,
      from the view of an ISV or end user, this is a misinterpretation. In fact, ISVs
      and end users both would interprete it that way: "The deployer can tell which
      JDBC data source to use. If the deployer does not tell it, the server must use
      a default source.".


        No work has yet been logged on this issue.


          • Assignee:
          • Votes:
            0 Vote for this issue
            3 Start watching this issue


            • Created: