Alasdair Nottingham
On 7 Mar 2011, at 15:18, Holly Cummins <[email protected]> wrote: > Hi Brian, > > Thanks for the response. I've added some comments below: > > [cut for length] > > >> The dataSource blueprint.xml file is meant to be the equivalent of the >> configuration that you would provide to an application server when >> configuring data sources, i.e. this is the way that the data source is >> configured to use a particular jndi name. This name is then copied to > the >> data source that the application uses (see below). > > My concern is that copying the JNDI name to the data source that the > application uses doesn't have the intended effect, because the datasource > can't actually be looked up using that JNDI name. So instead of providing > the equivalent of the configuration you'd provide to the application > server, you provide a broken-ish configuration. It depends, if you wanted the XADataSource it would work just fine, although that isn't really helpful here. > > In order to disambiguate between the javax.sql.DataSource and the > javax.sql.XADataSource which both have the same osgi.jndi.service.name > property, a full OSGi service lookup is required: > > osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use) > > If we can't use the osgi.jndi.service.name to infer a usable JNDI name, we > should perhaps use some other, arbitary, property in the sample. Otherwise > the samples are misleading. > >>>> 2. In my testing, I found that just registering the >> EmbeddedXADataSource >>> >>>> as a javax.sql.DataSource service and not registering any services > for >>> the >>>> XADataSource worked quite well. However, I assume there's a reason > we >>>> didn't write the sample this way. :) What's the service under the >>>> XADataSource interface used for? The service isn't referenced in the >>> blog >>>> persistence.xml, so I'm assuming that the blog persistence unit > never >>> sees >>>> it. >> >> This may work fine for the blog sample, but if you have an application > that >> needs to participate in XA transactions then you need to provide an >> XADataSource so that the transaction wrappers bundle can detect it and >> create a DataSource capable of enlisting in XA transactions for the >> application to use. > > I guess what I was struggling to understand was why an > EmbeddedXADataSource wasn't able to participate in XA transactions. I > understand now that - despite its name - the EmbeddedXADataSource isn't > capable of the full XA support we need and that it needs to be wrapped in > a fuller featured datasource. That's the piece I was missing. > I would phrase this differently, the XADataSource does all the XA stuff we need, but not in the way we need it. The Client needs a DataSource that does implicit transactions, not one that does explicit ones. > I do think we need some improvement in this area. One option is just to > replace the misleading use of osgi.jndi.service.name in the sample with > another property which can be still used as a filter but doesn't suggest > the datasources can be looked up by friendly JNDI names. An alternative > (thanks Tim!), if we do want to enable the 'short-form' JNDI names, is > that we set a property something like 'aries.jndi.service.name' on the > javax.sql.XADataSource. When Aries registers the javax.sql.DataSource, it > could turn the 'aries.jndi.service.name' into the > 'osgi.jndi.service.name'. This would enable the short-form JNDI lookup > while avoiding the name clash. I don't like using aries.jndi.service.name here because it has a global scope, how about aries.jdbc.jndi.service.name? > > I'll raise a JIRA either to rewrite the sample or provide support for > datasource lookups of the form > > osgi:service/the/name/i/hoped/i/could/use > > with an extra property. > > Do people have a preference between these two options? Or any other > thoughts? I'd like to keep the use of osgi.jndi.service.name, even if we just create some transformation. We could also transform the value as well as the service property name. > > > [cut for length] > > Holly > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > >
