Skip to main content

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

  • From: "rmannibucau (JIRA)" <jira-no-reply@...>
  • To: issues@...
  • Subject: [javaee-spec issues] [JIRA] Commented: (JAVAEE_SPEC-7) Clarify and improve @DataSourceDefinition
  • Date: Wed, 20 Feb 2013 14:52: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=356609#action_356609
 ] 

rmannibucau commented on JAVAEE_SPEC-7:
---------------------------------------

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

> 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