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
        tware added a comment -

        Changing component from entity-persistence to deployment

        Show
        tware added a comment - Changing component from entity-persistence to deployment
        Hide
        tware added a comment -

        reassigning to component owner

        Show
        tware added a comment - reassigning to component owner
        Hide
        gfbugbridge added a comment -

        <BT6515334>

        Show
        gfbugbridge added a comment - <BT6515334>
        Hide
        Hong Zhang added a comment -

        -> tim

        Show
        Hong Zhang added a comment - -> tim
        Hide
        Hong Zhang added a comment -

        -> accepted

        Show
        Hong Zhang added a comment - -> accepted
        Hide
        Tim Quinn added a comment -

        Although the description mentions deployment and deployer in several places, at
        its heart this issue is requesting a change in the admin GUI.

        Reassigning.

        Show
        Tim Quinn added a comment - Although the description mentions deployment and deployer in several places, at its heart this issue is requesting a change in the admin GUI. Reassigning.
        Hide
        marina vatkina added a comment -

        I'm not sure which component is responsible for providing the functionality, but
        this option should be available via 'asadmin' as well, and the result need to
        end up in the PU descriptor. What can complicate the situation, is that a PU is
        not a component, and can be part of a library jar that is not exploded.

        Show
        marina vatkina added a comment - I'm not sure which component is responsible for providing the functionality, but this option should be available via 'asadmin' as well, and the result need to end up in the PU descriptor. What can complicate the situation, is that a PU is not a component, and can be part of a library jar that is not exploded.
        Hide
        Anissa Lam added a comment -

        GUI cannot provide such a feature without support from backend.
        >>> 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".

        This requires more than 1 subcomponent to work together. I am assigning this to
        Kedar who can decide whats the first step to solve this issue.

        Show
        Anissa Lam added a comment - GUI cannot provide such a feature without support from backend. >>> 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". This requires more than 1 subcomponent to work together. I am assigning this to Kedar who can decide whats the first step to solve this issue.
        Hide
        km added a comment -

        Markus,

        This seems to be (what my friend calls) a red ball.

        If I am understanding you
        correctly, the resource that a persistence unit (PU) needs is implicitly mapped
        onto "jdbc/__default", unless <jta-data-source> is provided in the PU's xml.

        If that's correct, then what Marina suggests is that we provide a capability
        on the admin tools to essentially modify the persistence.xml on deployment.
        Well, that is simply not consistent. We don't modify any of the deployment
        descriptors during deployment using admin console or admin CLI.

        AFAIU, jdbc/__default is a global resource defined out-of-the-box in GlassFish
        and it points to an embedded "Java DB" database (Actually, I don't know why
        it points to sun-appserv-samples!). All applications can use this datasource.

        If you want jta-data-source to actually point to a "database" of your choice,
        can't you

        • define a connection pool pointing to that database,
        • change the pool-name on jdbc/__default to point to that pool?

        (Both these options are available on the Web Admin Console or admin CLI).

        Your application remains portable and you don't have to change persistence.xml
        at all.

        Will that not work to satisfy the situation you describe?

        Another approach would be to use application server vendor specific data-source
        mapping. I don't know if that's available for persistence units, though.

        Please let me know.

        Show
        km added a comment - Markus, This seems to be (what my friend calls) a red ball. If I am understanding you correctly, the resource that a persistence unit (PU) needs is implicitly mapped onto "jdbc/__default", unless <jta-data-source> is provided in the PU's xml. If that's correct, then what Marina suggests is that we provide a capability on the admin tools to essentially modify the persistence.xml on deployment. Well, that is simply not consistent. We don't modify any of the deployment descriptors during deployment using admin console or admin CLI. AFAIU, jdbc/__default is a global resource defined out-of-the-box in GlassFish and it points to an embedded "Java DB" database (Actually, I don't know why it points to sun-appserv-samples!). All applications can use this datasource. If you want jta-data-source to actually point to a "database" of your choice, can't you define a connection pool pointing to that database, change the pool-name on jdbc/__default to point to that pool? (Both these options are available on the Web Admin Console or admin CLI). Your application remains portable and you don't have to change persistence.xml at all. Will that not work to satisfy the situation you describe? Another approach would be to use application server vendor specific data-source mapping. I don't know if that's available for persistence units, though. Please let me know.
        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.
        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
        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
        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
        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.

          People

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

            Dates

            • Created:
              Updated: