Skip to main content

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

  • From: "arjan tijms (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition
  • Date: Fri, 15 Feb 2013 21:32:53 +0000 (GMT+00:00)
  • Auto-submitted: auto-generated


    [ 
http://java.net/jira/browse/JAVAEE_SPEC-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356254#action_356254
 ] 

arjan tijms commented on JAVAEE_SPEC-7:
---------------------------------------

{quote}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. {quote}

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.

> Clarify and improve @DataSourceDefinition
> -----------------------------------------
>
>                 Key: JAVAEE_SPEC-7
>                 URL: http://java.net/jira/browse/JAVAEE_SPEC-7
>             Project: javaee-spec
>          Issue Type: Improvement
>            Reporter: arjan tijms
>            Assignee: lancea
>
> 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:
> {quote}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.{quote}
> 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:
> {quote}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.{quote}
> 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:
> {quote}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.) {quote}
> (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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

arjan tijms (JIRA) 02/15/2013

<Possible follow-up(s)>

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

lancea (JIRA) 02/15/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

arjan tijms (JIRA) 02/15/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

rmannibucau (JIRA) 02/20/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

arjan tijms (JIRA) 02/20/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

rmannibucau (JIRA) 02/22/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

Bill Shannon (JIRA) 02/25/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

Bill Shannon (JIRA) 02/27/2013

[javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition

arjan tijms (JIRA) 02/27/2013
 
 
Close
loading
Please Confirm
Close