[
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
