Issue Details (XML | Word | Printable)

Key: GLASSFISH-2092
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Shalini
Reporter: markuskarg
Votes: 0
Watchers: 3
Operations

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

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

Environment:

Operating System: All
Platform: All


Issuezilla Id: 2,092
Tags:
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
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.".