On 8 March 2011 10:09, Holly Cummins <[email protected]> wrote: > Alasdair wrote: > > [cut for length] > >> >> > 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? > > That seems reasonable. > > (Are there any other places where we re-register services for which we > might want to support JNDI lookups? If so, we might in fact choose to make > this a global pattern.) >
No, at least not right now, there might be in the future, but we might need a different scheme, so I would wait until we have more examples before going more general. >> > >> > 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. > > This was my first thought as well, but I've had second thoughts. > Transforming the value would mean that lookups of the form > > osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use) > > would no longer work. So it would be a breaking change for the blog > sample. > > (Obviously, we could then rewrite the blog sample to use a > > osgi:service/the/name/i/hoped/i/could/use/after/transformation > > lookup, which is nicer anyway, but we can't rewrite all the code out in > the field which was copied from the blog sample and which would no longer > work.) Or you could do something like have the/name/i/hoped/i/could/use?xa=true which then is transformed into the/name/i/hoped/i/could/use. This would then only change the registration of the DataSource which isn't part of the blog code, but one of the supporting bundles for the assembly. > > It's probably better to avoid the breaking change by allowing blueprints > to opt in to short-form JNDI names for the transformed datasource by > setting the special property. Otherwise they'll have to guess the > transformed name, even to be able to do a long-form lookup like > > osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=the/name/i/hoped/i/could/use/after/transformation) > > > > 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 > > > > > > -- Alasdair Nottingham [email protected]
