Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Date: Tue, 8 Mar 2011 16:44:59 +0000 (UTC)
From: "Holly Cummins (JIRA)" <jira@apache.org>
To: dev@aries.apache.org
Message-ID: 
 <173533365.5201.1299602699483.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <572960412.4122.1299583379416.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Updated: (ARIES-601) Add service ranking to re-registered XA
 data source
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/ARIES-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Holly Cummins updated ARIES-601:
--------------------------------

    Description: 
 In the blog sample we use the service property osgi.jndi.service.name to uniquely identify the datasource services. However, in the persistence.xml, we only use the jndi service name as a filter property, like: 

 
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdb)</jta-data-source>

instead of writing:

    <jta-data-source>osgi:service/jdbc/blogdb</jta-data-source>

It seems a shame to bother to specify the jndi.service.name property but then not take advantage of the shorter JNDI name, but there's a good 
reason we don't - it doesn't work. 

The datasource blueprint.xml declares two services, for DataSource and XADataSource, and then Aries helpfully auto-creates a third service, which makes an enriched wrapper of the EmbeddedXADataSource bean for lookups of the DataSource interface.

Unfortunately, once this has been done we have two services with the same JNDI service name. Anything which uses the JNDI name 
osgi:service/jdbc/blogdb, expecting a DataSource, gets a classcast exception, because an XADataSource is returned. 

A neat solution is to add a service ranking (which adds, say, 1000 to the original service ranking) to the re-registered DataSource so that it is returned in preference to the XADataSource when a short-form JNDI lookup is done.

  was:
 In the 
blog sample we use the service property osgi.jndi.service.name to uniquely identify the datasource services. However, in the persistence.xml, we only use the jndi service name as a filter property, like: 

 
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdb)</jta-data-source>

instead of writing:

    <jta-data-source>osgi:service/jdbc/blogdb</jta-data-source>

It seems a shame to bother to specify the jndi.service.name property but then not take advantage of the shorter JNDI name, but there's a good 
reason we don't - it doesn't work. 

The datasource blueprint.xml declares two services, for DataSource and XADataSource, and then Aries helpfully auto-creates a third service, which makes an enriched wrapper of the EmbeddedXADataSource bean for lookups of the DataSource interface.

Unfortunately, once this has been done we have two services with the same JNDI service name. Anything which uses the JNDI name 
osgi:service/jdbc/blogdb, expecting a DataSource, gets a classcast exception, because an XADataSource is returned. 

A neat solution is to add a service ranking (which adds, say, 1000 to the original service ranking) to the re-registered DataSource so that it is returned in preference to the XADataSource when a short-form JNDI lookup is done.


> Add service ranking to re-registered XA data source
> ---------------------------------------------------
>
>                 Key: ARIES-601
>                 URL: https://issues.apache.org/jira/browse/ARIES-601
>             Project: Aries
>          Issue Type: Improvement
>            Reporter: Holly Cummins
>            Priority: Minor
>
>  In the blog sample we use the service property osgi.jndi.service.name to uniquely identify the datasource services. However, in the persistence.xml, we only use the jndi service name as a filter property, like: 
>  
> <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/blogdb)</jta-data-source>
> instead of writing:
>     <jta-data-source>osgi:service/jdbc/blogdb</jta-data-source>
> It seems a shame to bother to specify the jndi.service.name property but then not take advantage of the shorter JNDI name, but there's a good 
> reason we don't - it doesn't work. 
> The datasource blueprint.xml declares two services, for DataSource and XADataSource, and then Aries helpfully auto-creates a third service, which makes an enriched wrapper of the EmbeddedXADataSource bean for lookups of the DataSource interface.
> Unfortunately, once this has been done we have two services with the same JNDI service name. Anything which uses the JNDI name 
> osgi:service/jdbc/blogdb, expecting a DataSource, gets a classcast exception, because an XADataSource is returned. 
> A neat solution is to add a service ranking (which adds, say, 1000 to the original service ranking) to the re-registered DataSource so that it is returned in preference to the XADataSource when a short-form JNDI lookup is done.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira