glassfish
  1. glassfish
  2. GLASSFISH-2092

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

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      2,092

      Description

      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
      always.

      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:

      "6.2.1.5 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 "...at 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.".

        Activity

        Hide
        Hong Zhang added a comment -

        Reassign to JDBC team to see if it makes sense to provide this support through deploy command.

        And retarget to future release as it's not a must for GlassFish 4.0.

        Show
        Hong Zhang added a comment - Reassign to JDBC team to see if it makes sense to provide this support through deploy command. And retarget to future release as it's not a must for GlassFish 4.0.
        Hide
        Tom Mueller added a comment -

        This is a deployment issue at its heart. The capability needs to be provided via the asadmin and GUI interfaces, but it is the deployment logic that needs to support this capability.

        Show
        Tom Mueller added a comment - This is a deployment issue at its heart. The capability needs to be provided via the asadmin and GUI interfaces, but it is the deployment logic that needs to support this capability.
        Hide
        marina vatkina added a comment -

        Kedar, you are right, but unfortunately the spec says that there should be a way
        to specify the datasource at deployment. This can be done either by the user via
        specifying some predefined name for the datasource (like jdbc/PU1DS) that is
        retargeted to the actual datasource of choice at the necessary points of time.
        Another option would be to either modify the existing persistence.xml on the fly
        or add something like sun-persistence.xml for overrides (which is even worse).
        This second option becomes even more complicated as persistence.xml can be
        placed into the EAR's /lib directory, and we won't even unpack it on deployment,
        right?
        May be we should test and document the 1st solution (I wouldn't advise to change
        jdbc/__default).

        Show
        marina vatkina added a comment - Kedar, you are right, but unfortunately the spec says that there should be a way to specify the datasource at deployment. This can be done either by the user via specifying some predefined name for the datasource (like jdbc/PU1DS) that is retargeted to the actual datasource of choice at the necessary points of time. Another option would be to either modify the existing persistence.xml on the fly or add something like sun-persistence.xml for overrides (which is even worse). This second option becomes even more complicated as persistence.xml can be placed into the EAR's /lib directory, and we won't even unpack it on deployment, right? May be we should test and document the 1st solution (I wouldn't advise to change jdbc/__default).
        Hide
        km added a comment -

        Markus, what should be done with this?

        Show
        km added a comment - Markus, what should be done with this?
        Hide
        km added a comment -

        Is this a must for GlassFish V2? I tend to make this a P4 as I don't think it
        is a priority for V2 release.

        Show
        km added a comment - Is this a must for GlassFish V2? I tend to make this a P4 as I don't think it is a priority for V2 release.

          People

          • Assignee:
            Shalini
            Reporter:
            markuskarg
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: