Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Shalini
Reporter: markuskarg
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.

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

Created: 18/Jan/07 10:07 AM   Updated: 10/Oct/12 01:42 AM
Component/s: jdbc
Affects Version/s: 9.1pe
Fix Version/s: future release

Time Tracking:
Not Specified


Operating System: All
Platform: All

Issuezilla Id: 2,092
Participants: Anissa Lam, gfbugbridge, Hong Zhang, km, marina vatkina, markuskarg, Shalini, Tim Quinn, Tom Mueller and tware

 Description  « Hide

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

tware added a comment - 18/Jan/07 12:53 PM

Changing component from entity-persistence to deployment

tware added a comment - 18/Jan/07 12:54 PM

reassigning to component owner

gfbugbridge added a comment - 19/Jan/07 11:24 AM


Hong Zhang added a comment - 30/Jan/07 11:25 AM

-> tim

Hong Zhang added a comment - 30/Jan/07 11:25 AM

-> accepted

Tim Quinn added a comment - 31/Jan/07 11:49 AM

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


marina vatkina added a comment - 31/Jan/07 01:04 PM

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.

Anissa Lam added a comment - 31/Jan/07 01:49 PM

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.

km added a comment - 01/Feb/07 06:05 PM


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.

km added a comment - 25/Feb/07 11:12 PM

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.

km added a comment - 21/Mar/07 04:57 PM

Markus, what should be done with this?

marina vatkina added a comment - 21/Mar/07 06:29 PM

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,
May be we should test and document the 1st solution (I wouldn't advise to change

Tom Mueller added a comment - 21/Jan/11 12:27 PM

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.

Hong Zhang added a comment - 10/Oct/12 01:42 AM

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.