Skip to main content

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

  • From: "lancea (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:07: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=356245#action_356245
 ] 

lancea commented on JAVAEE_SPEC-7:
----------------------------------

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

> 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