[
https://issues.apache.org/jira/browse/ARIES-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alasdair Nottingham updated ARIES-601:
--------------------------------------
Component/s: Transaction
> 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
> Components: Transaction
> Reporter: Holly Cummins
> Assignee: Alasdair Nottingham
> Priority: Minor
> Fix For: 0.4
>
>
> 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
