You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "Holly Cummins (JIRA)" <ji...@apache.org> on 2011/03/08 12:22:59 UTC
[jira] Created: (ARIES-601) Add service ranking to re-registered XA
data source
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
[jira] Assigned: (ARIES-601) Add service ranking to re-registered
XA data source
Posted by "Alasdair Nottingham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alasdair Nottingham reassigned ARIES-601:
-----------------------------------------
Assignee: Alasdair Nottingham
> 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
> Assignee: Alasdair Nottingham
> 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
[jira] Updated: (ARIES-601) Add service ranking to re-registered XA
data source
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (ARIES-601) Add service ranking to re-registered XA
data source
Posted by "Alasdair Nottingham (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (ARIES-601) Add service ranking to re-registered XA
data source
Posted by "Holly Cummins (JIRA)" <ji...@apache.org>.
[ 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
[jira] Resolved: (ARIES-601) Add service ranking to re-registered
XA data source
Posted by "Alasdair Nottingham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ARIES-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alasdair Nottingham resolved ARIES-601.
---------------------------------------
Resolution: Fixed
Fix Version/s: 0.4
> 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