[JAVAEE_SPEC-34] Make actual run-time availability of the default data source mandatory Created: 07/Jan/14  Updated: 23/May/15  Resolved: 23/May/15

Status: Closed
Project: javaee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: Bill Shannon
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: conventionoverconfiguration, database, datasource, ease-of-use, ease_of_development

 Description   

In Java EE 7 the concept of a default data source was added to the platform. See JAVAEE_SPEC-4

One specific request in that JIRA was to make sure the database backing this data source is actually available, without the user having to manually start a database that happens to be bundled with the application server:

From JAVAEE_SPEC-4:

To make use of this platform default data source, the user should not have to configure anything and should not have to manually start the embedded database separately from starting the application server.

For a next revision of Java EE I would like to ask to take this original request into consideration again. The intend is that just like other platform services like e.g. JNDI, JMS etc the default data source should "simply be there" (as an implementation detail actually starting the backing DB can of course be delayed to the moment of first usage or when the deployment process detects an application is actually using the default data source).

See also GLASSFISH-20666



 Comments   
Comment by Bill Shannon [ 12/Nov/14 ]

A Java EE Compatible product needs to have a default database, and it needs to be properly configured to achieve a Supported Configuration. But since the database is most likely an external service, controlling the lifecycle of that service seems outside the scope of the Java EE specification. We can't require that it be impossible to shut down the database server while the app server is running, or require that the app server shut down as soon as it notices the database server isn't running. Checking that the default database server is running when the app server starts up seems like a good idea, and probably warrants a warning if it is not, but I don't think it should be required to prevent the app server from starting.

If the database is bundled with the app server, then starting the database when the app server starts seems like a good ease of use feature, but I don't think it can be a requirement.

Comment by Bill Shannon [ 23/May/15 ]

We're not going to add this as a requirement.





[JAVAEE_SPEC-7] Clarify and improve @DataSourceDefinition Created: 21/Apr/12  Updated: 05/Apr/13  Resolved: 05/Apr/13

Status: Closed
Project: javaee-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: lancea
Resolution: Fixed Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JDBC, datasource, driver, production, transactions

 Description   

Java EE 6 introduced the @DataSourceDefinition and corresponding data-source deployment descriptor element to allow an application to define a DataSource. (see JSR 316 EE.5.17 and JSR 250 2.13)

This opens the door for creating both self-contained applications (i.e. for which an administrator does not need to setup anything before the application can be deployed and started) and applications that have a portable DataSource definition.

However, in practice it's still not entirely possible to fully use this and use this portably due to a few omissions in the spec.

One problem is that the spec does not say anything about the location of the required JDBC driver. JSR 250 does say in section 2.13:

The driver class is not required to be available at deployment but must be available at runtime prior to any attempt to access the DataSource.

In order to create a self-contained application that defines a DataSource in the java:comp, java:module or java:app JNDI namespaces, the user should be able to place the driver on the classpath corresponding to the components which can access those namespaces. E.g. WEB-INF/lib for the web module. Currently this is possible with e.g. JBoss AS 7.1, but not with GlassFish 3.1.

Another problem is that the spec is not really clear about the transactional behavior. An example from which behavior can be deduced is given in JSR 250 section 2.13:

Vendors are not required to support properties that do not normally apply to a specific data source type. For example, specifying the transactional property to be true but supplying a value for className that implements a data source class other than XADataSource may not be supported.

Since this is non-trivial functionality, a somewhat more in depth specification of the desired behavior might not be out of place.

The annotation and xml variant define attributes for pooling, but pooling is seemingly not mandated. JSR 250 calls those attributes "vendor specific". As a result, at least one vendor (JBoss) treats the annotation as a facility for testing and development only in its certified product:

Since Java EE6, the new annotation "@DataSourceDefinition" has existed to allow users to configure a data source directly from within their application. (Note that this annotation bypasses the management layer and as such it is recommended only for development and testing purposes.)

(source: https://community.jboss.org/wiki/DataSourceConfigurationInAS7)

To sum up, I would like to request the following improvements:

  • Specify all valid locations of the JDBC driver
  • Mandate possibility to use application embedded JDBC driver for application scoped datasources
  • Clarify transactional behavior
  • Mandate connection pooling

I hope that with these improvements @DataSourceDefinition/data-source can become a facility that is more likely to be used for actual production work.



 Comments   
Comment by arjan tijms [ 15/Feb/13 ]

Common Annotations made some tiny clarifications for @DataSourceDefinition in the 1.2mr: http://java.net/projects/javaee-spec/pages/CommonAnnotations1_2MR

Comment by lancea [ 15/Feb/13 ]

Yes, we made some minor clarifications to the annotation

The Java EE platform specification does not mandate that JDBC Connection Pooling must be supported (EE6.2.4.2) nor does it mandate where JDBC drivers must be installed. This annotation makes no additional requirements, it is there more for an ease of use for configuration and the driver is not required to be there until the application is executed, not at deployment time.

The available properties depend on the type of DataSource being used.

For example if you are specifying a DataSource class, the Connection Pool properties are not necessarily relevant based on the implementation so they can be ignored

Comment by arjan tijms [ 15/Feb/13 ]

The Java EE platform specification does not mandate that JDBC Connection Pooling must be supported (EE6.2.4.2) nor does it mandate where JDBC drivers must be installed.

I hope that that can be changed eventually, hence this issue

As for the JDBC driver, in case of an application scoped datasource it's important that the driver can at least be loaded from the application archive. This is specifically important for embedded databases, where the driver isn't just a driver but is actually the entire database itself (e.g. h2, derby, etc). It makes little sense that a privately scoped database that's used internally by a single application has to be installed at some location deep inside the AS installation. The vendor can still be free to provide proprietary additional locations of course.

In practice this requirement should be relatively easy to implement, as nearly all vendors that support @DataSourceDefinition already support loading the driver from the application archive. As far as I know, GlassFish is the only exception.

As for the JDBC connection pooling, the idea is that if the vendor already supports connection pooling via their proprietary datasource syntax, then it should also be supported for @DataSourceDefinition. The goal is that vendors do not degrade @DataSourceDefinition (perhaps accidentally), so that even though a standard syntax exists users are still more or less forced to use the proprietary syntax.

I understand this connection pooling might be hard to put in the spec, but merely stating that the spirit of the spec is that @DataSourceDefinition can be used for production (and not just for test/demo apps) might already be an improvement.

Comment by rmannibucau [ 20/Feb/13 ]

+ the jndi name shouldn't be ambiguous anymore. basically container resources are in a container specific jndi tree but allowing to specify "jndi name" doesn't explicitly mean you can bind in java:app/ or java:global/ (defined for EJBs not for other parts). Basically in JavaEE a datasource name should be relative (jdbc/foo for instance) but some server use absolute jndi name.

This slow down portability and should be addressed too.

Comment by arjan tijms [ 20/Feb/13 ]

the jndi name shouldn't be ambiguous anymore. basically container resources are in a container specific jndi tree but allowing to specify "jndi name" doesn't explicitly mean you can bind in java:app/ or java:global/ (defined for EJBs not for other parts).

I'm not a big JNDI expert, but if that's indeed the case it should definitely be addressed! The spec does explicitly defines that java:app and java:global among others should be supported.

EE.5.17:

The DataSource resource may be defined in any of the JNDI namespaces described in Section EE.5.2.2, “Application Component Environment Namespaces”. For example, aDataSourceresource may be defined:

  • in the java:comp namespace, for use by a single component;
  • in the java:module namespace, for use by all components in a module;
  • in the java:app namespace, for use by all components in an application;
  • in the java:global namespace, for use by all applications.

Then EE.5.2.2 does not mention that those namespaces are only defined for EJB beans, or EJB modules:

The application component’s naming environment is composed of four logical namespaces, representing naming environments with different scopes. The four namespaces are:

  • java:comp - Names in this namespace are per-component (for example, per enterprise bean). Except for components in a web module, each component gets its own java:comp namespace, not shared with any other component. Components in a web module do not have their own private component namespace. See note below.
  • java:module - Names in this namespace are shared by all components in a module (for example, all enterprise beans in a single EJB module, or all com- ponents in a web module).
  • java:app - Names in this namespace are shared by all components in all modules in a single application, where “single application” means a single deployment unit, such as a single ear file, a single module deployed standalone, etc. For example, a war file and an EJB jar file in the same ear file would both have access to resources in the java:app namespace.
  • java:global - Names in this namespace are shared by all applications de- ployed in an application server instance. Note that an application server in- stance may represent a single server, a cluster of servers, an administrative domain containing many servers, or even more. The scope of an application server instance is product-dependent, but it must be possible to deploy multiple applications to a single application server instance.

EE.5.7.1.1 gives another example of using java:app for something that is not an EJB:

It is possible to specify as part of the @Resource annotation the JNDI name of
an entry to which the resource being defined will be bound.

// The customer database, looked up in the application environment. 
@Resource(lookup=”java:app/env/customerDB”) javax.sql.DataSource customerAppDB;

EE.5.18 explicitly defines that java:app can be used for a "Managed Bean" and contrasts this to EJB:

An instance of a named Managed Bean can be obtained by looking up its name in JNDI using the same naming scheme used for EJB components:

java:app/<module-name>/<bean-name>
Comment by rmannibucau [ 22/Feb/13 ]

the main point is it is sticked to EE world so not usable from not managed beans. In other words it doesn't define a user namespace but a EE user namespace. I'm fine with this definition but it should be at least explicit.

A sample ambiguous for me:

a cdi bean starts a thread, the thread does a new MyPojo() and MyPojo does a lookup in java:app: should it work? reading the spec i don't understand it should.

Comment by Bill Shannon [ 25/Feb/13 ]

All the java: JNDI names are defined by the spec and are portable.
If you're using a JNDI name that doesn't start with java:, it's
product-specific.

Yes, it's true that the Java EE spec defines a Java EE namespace.
Are you wondering whether any of these JNDI names work in plain Java SE?
They're not required to.

Comment by Bill Shannon [ 27/Feb/13 ]

Note also that the defined way to package a JDBC driver with an application
is to package it as a Resource Adapter and include the rar file in the ear file.

Still, it seems like putting the JDBC driver in WEB-INF/lib should also work.
If it doesn't, please file a bug against GlassFish.

We need to see if there's anything in the spec that needs to be clarified in this area.

Comment by arjan tijms [ 27/Feb/13 ]

Note also that the defined way to package a JDBC driver with an application is to package it as a Resource Adapter and include the rar file in the ear file.

This might be an option for ears indeed (I've never tried it though), but as ease of use goes, just dropping it in EAR/lib is probably easier. For a web profile implementation and/or a war, a .rar is unfortunately not an option.

If it doesn't, please file a bug against GlassFish.

I filed this one a short while ago. It's at: GLASSFISH-19451

Comment by rmannibucau [ 03/Mar/13 ]

So basically using spring i have no gurantee i can acces these jndi names (not manged beans) + what does mean managed beans? Ejb, cdi, javax.annotation.ManagedBean? That's totally unclear in specs in general.

Comment by Bill Shannon [ 05/Apr/13 ]

The Java EE spec does not and will not describe what you can do in Spring.
For that, you'll need to read the Spring spec.

If there's something you still feel isn't clear in the Java EE spec, please
file a new issue. The original issue here has been addressed and I'm closing
this issue.





[GLASSFISH-20094] Undeploy on Glassfish causes connection pool to be no more usable (Grails) Created: 28/Mar/13  Updated: 25/Jun/13

Status: Open
Project: glassfish
Component/s: grails
Affects Version/s: 3.1.2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: pierre.fabier.camineo Assignee: vivekp
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish 3.1.2.2
Grails 2.2.1
Windows 7 or Debian


Tags: admin-gui, classloader, datasource, driver, grails, jdbc, jndi, postgresql

 Description   

Hi,

I'm working on a grails 2.2.1 project running on glassfish 3.1.2.2, using a jndi pooled datasource connected to a postgres 9.2 database.
When I deploy for the first time the application, I have no issues, everything works fine.

But, everytime I undeploy (or redeploy) my application, my connection pool stops working.
If I try to ping using glassfish admin console, I get this error :

Avertissement: RAR8054: Exception while creating an unpooled [test] connection for pool [ sample ], Connection could not be allocated because: No suitable driver found for jdbc:postgresql://localhost:5432/sample?loginTimeout=0&socketTimeout=0&prepareThreshold=5&unknownLength=2147483647&loglevel=0&tcpkeepalive=false
Grave: RestResponse.getResponse() donne FAILURE. endpoint = http://localhost:4848/management/domain/resources/ping-connection-pool.json ; attrs =

{id=sample}

'

I repeat : my connection pool works fine when I deploy (I have the postgresql driver in "/glassfish/lib", my connection pool is correctly configured, etc.), it's only when I undeploy that I have troubles.
This bug is highly reproductible, I even did a small grails project that reproduces the problem, you only need to have to configure a jndi datasource connected to a "sample" database (jndi/sample) on your glassfish server.

Here is the github link :
https://github.com/fabier/GlassfishJDBCGrailsPostgresql
And the war :
https://www.dropbox.com/s/cb9hmgc6lfabl5x/GlassfishJDBCGrailsPostgresql-0.1.war
and the domains.xml file:
https://www.dropbox.com/s/ljealpfp0zxj2r4/domain.xml

On grails side, my connection to the pool is configured this way:
environments {
production {
dataSource

{ dbCreate = "create-drop" jndiName = "jdbc/sample" }

}
}

I think this bug is severe, since it kills a connection pool that can be shared amongst other webapps or ears.
For information, I did a bit of research, sensing it might be some sort of class unloader associated with undeployment, I found log4j that could be linked to this problem, so I tryed :
-Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false
but it didn't help.
Last point : in fact, postgresql driver is fully unloaded, so that other connection pools using postgresql driver are not usable after an undeploy.

Please help.
Thanks.

Pierre FABIER
Ingénieur d'Etude
Parc technologique du canal
13, avenue de l'Europe
31520 Ramonville-Saint-Agne (France)
Tel: 09 74 77 14 21 - Fax: 09 59 64 78 74
www.camineo.com



 Comments   
Comment by pierre.fabier.camineo [ 28/Mar/13 ]

Link to same issue on grails ML:
http://grails.1312388.n4.nabble.com/Undeploy-on-Glassfish-causes-connection-pool-to-be-no-more-usable-td4643041.html

Comment by pierre.fabier.camineo [ 08/Apr/13 ]

Re,

I did some investigations:

  • If I use MySQL instead of PostgreSQL (after changing the driver and re-configuring the pool), I cannot reproduce this problem. So PostgreSQL is involved in this problem too.
  • If I use Tomcat instead of Glassfish, I cannot reproduce this problem. So Glassfish is involved.
  • If I do not use grails, and deploy a standard J2EE app like «petstore» (<a href="http://www.oracle.com/technetwork/java/petstore1-3-1-02-139690.html">link</a>) using PostgreSQL jndi datasource, I cannot reproduce the problem. So Grails is involved too.
  • If I use Glassfish 3.0, Glassfish 3.1 or Glassfish 3.1.2.2, I still reproduce the problem, so the version of glassfish doesn't change anything.
  • If I use PostgreSQL 9.0, PostgreSQL 9.1 or PostgreSQL 9.2, I still reproduce the problem, so the version of PostgreSQL doesn't change anything.
  • Most incredible thing I discovered (that made me fall out of my chair) : If I undeploy a grails app using a MySQL datasource on a glassfish server that declares a UNUSED connection pool to a PostgreSQL database, the MySQL pool still works, but the PostgreSQL pool doesn't !!! it shows the «No suitable driver found» error, as there was no problem prior to undeploying.

Please help me, I'm stuck with this problem, and no one seems to be able to answer me.


Pierre FABIER
Ingénieur d'Etude
Parc technologique du canal
13, avenue de l'Europe
31520 Ramonville-Saint-Agne (France)
Tel: 09 74 77 14 21 - Fax: 09 59 64 78 74

Comment by pierre.fabier.camineo [ 25/Jun/13 ]

I posted this message 3 months ago, can someone help me with this, please ?


Pierre FABIER
Ingénieur d'Etude
Parc technologique du canal
13, avenue de l'Europe
31520 Ramonville-Saint-Agne (France)
Tel: 09 74 77 14 21 - Fax: 09 59 64 78 74





[GLASSFISH-19654] Unable to specify a DataSource in an embedded EJB container Created: 08/Feb/13  Updated: 11/Feb/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: 3.1.1
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: skwirking Assignee: marina vatkina
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: datasource, ejb-container, test, testing

 Description   

There is no way to programmatically specify the datasource for an EJB container. If a module is written to make use of a JTA datasource (by declaring the following in the module's persistence.xml):

<jta-data-source>jdbc/myDS</jta-data-source>

Then it seems impossible to load this module into an embedded EJB container, because the container cannot be configured to set up a datasource, and so the module cannot find one and deployment fails.

Being able to specify datasource details in an embedded EJB container is critical for testing, where we want to use a different datasource but be sure we are testing the same artifact/jar/war file that will eventually be released.

Other embedded EJB containers use properties to achieve this:

However, the only relevant property for glassfish is
org.glassfish.ejb.embedded.glassfish.configuration.file
which could in theory be used to specify a domain.xml file with a pre-configured test datasource. Unfortunately, this property is ignored unless the following property is set
org.glassfish.ejb.embedded.glassfish.installation.root
and to set this second property requires an existing glassfish installtion - thus ruining the project portability I was trying to achieve by using embedded glassfish in the first place.

See here for the forum post I made which describes other awkward and limited workarounds:
http://stackoverflow.com/questions/14748280/how-to-define-a-test-datasource-for-an-embedded-ejb-container



 Comments   
Comment by marina vatkina [ 08/Feb/13 ]

Embeddable EJB container is designed to work either with pre-installed GlassFish, where any resource can be added using CLI or UI, or by specifying the config file with the pre-defined resources.

Changing to RFE

Comment by skwirking [ 11/Feb/13 ]

I agree that the feature to configure a datasource via EJB Container properties should be a feature request.

However, specifying the config file (domain.xml) only works if the installation root is also specified. If the installation root is not specified, the config file option is ignored.

Thus, it appears to be impossible to set up a datasource inside an EJB Container without having an existing installation of GlassFish - and for this reason I respectfully request that the issue still be marked as a 'bug'.





[GLASSFISH-19451] Allow JDBC driver to be loaded from application archive Created: 15/Dec/12  Updated: 23/Feb/14

Status: Open
Project: glassfish
Component/s: jdbc
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shalini
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: datasource, ear, embedded, jdbc, war

 Description   

As one of the few application servers, GlassFish does not allow a JDBC driver to be loaded from a .war or .ear (see http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee). Instead, the driver is required to be stored inside the GlassFish installation directory.

Especially for applications that use an embedded database and an application scoped datasource (specifically those using @DataSourceDefinition), this is not convenient. Those applications can be coded to be almost portable, with the exception that for GlassFish a jar (the JDBC driver) has to be copied from the archive to the AS installation directory.

I would like to ask for the ability to load said JDBC driver directly from an application archive such as .war and .ear.



 Comments   
Comment by Darious3 [ 20/Dec/12 ]

You can now include glassfish-resources.xml in your war, where you can define JDBC resources. These resources have a lifetime scoped to the WAR (created and destroyed when the WAR is deployed/undeployed).

This behavior really should apply to the JDBC driver as well.

Comment by Darious3 [ 04/Apr/13 ]

Has anything happened for this yet?

Comment by arjan tijms [ 16/Dec/13 ]

This seems to have been "silently" fixed in GlassFish 4. The following unit test in the Java EE samples project shows this: https://github.com/javaee-samples/javaee7-samples/blob/master/jpa/datasourcedefinition/src/test/java/org/javaee7/jpa/datasourcedefinition/DataSourceDefinitionTest.java

This test addresses the exact use case this issue is about and puts the JDBC driver into the application archive. The test passes on a stock (embedded) GlassFish 4.

Maybe it should also be tested on a standalone GlassFish 4, but hopefully this shouldn't make any difference.

Comment by martinandersson.com [ 23/Feb/14 ]

The github example you give inject the datasource. I must use a persistence.xml file to declare the persistence unit that relies on my @DataSourceDefinition. With this requirement I can't get my application to work. Another way for me since Java EE 7 is to use the default data source, but then of course, my application still don't deploy deploy and work properly since GlassFish doesn't start his Derby database automatically. For me, I refuse to manually copy-paste jar files to the glassfish installation direction as much as I refuse to manually start the derby database. I can happily do that for a production environment, but until then, as what is my issue now, I'm using Arquillian to do real proper integration tests.

Comment by arjan tijms [ 23/Feb/14 ]

I must use a persistence.xml file to declare the persistence unit that relies on my @DataSourceDefinition. With this requirement I can't get my application to work.

You're most likely being affected by this bug: GLASSFISH-20944

The driver seems to load, but then because of a timing issue of some sorts, or maybe a scoping issue, the JPA boot code can't locate the datasource. Very unfortunate indeed! (please vote for that issue if you think it impacts you). See also JAVAEE_SPEC-30

my applications still don't deploy deploy and work properly since GlassFish doesn't start his Derby database automatically. For me, I refuse to manually copy-paste jar files to the glassfish installation direction as much as I refuse to manually start the derby database.

I agree. This shouldn't be required. I logged issue JAVAEE_SPEC-34 for precisely this a short while ago. There's a corresponding GlassFish specific issue at GLASSFISH-20666

If you care for getting those solved, please vote for them as well

Comment by martinandersson.com [ 23/Feb/14 ]

Thank you Arjan for your feedback, you seem to be a real good spirit. Keep it up! Yeah I did vote for those other issues =)

Comment by reza_rahman [ 23/Feb/14 ]

I think this could be a pretty nice community contribution .





Generated at Fri Sep 04 09:15:38 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.