Ant,
Comments inline:
I'd guess that the Tuscany JMS binding __does__ already work under
OSGi, but the problem is how do you configure an OSGi container to
provided a JNDI environment.
The Tuscany JMS binding does NOT work under OSGi. I don't find this surprising since it's clearly
never until now been tested in the OSGi environment. But it isn't just a question of getting JNDI
to work.
However, the issue of getting JNDI to work under OSGi is a serious one, much
debated.
We use ActiveMQ for the testcases but the JMS binding uses just
standard JavaEE APIs and JNDI lookups so it works with any JavaEE JNDI
environment. Along with standalone ActiveMQ Tuscany also works with
Tomcat, WebSphere, JBoss, Glassfish, - or any JavaEE compliant
AppServer - and it uses the AppServer's defined JMS resources. We have
users using that capability and its function i think we should try
hard to keep working.
Agreed - but we also have users who run under OSGi - clearly so far they have either not been using
JMS or they've had to re-engineer our code.
That code in (1) would fail if ActiveMQ isn't available so it would
need to handle the class not being found or else be in a separate
module. The Tuscany JMSResourceFactory is one of the JMS binding plug
points so it could easily be a new separate module for an ActiveMQ
specific JMSResourceFactory.
I want to get something that works now. A separate module is a possibility for the future, but I
don't want to go down that road yet. Code that attempts to load the ActiveMQ class and handles any
failure sounds fine to me as a solid first step. I users want OSGi + non-ActiveMQ JMS then I am sure
they will shout for it & we can accommodate it.
I do wonder though if there are more standard ways to do JNDI in OSGi,
other enterprise OSGi things must already have a way of doing it. I
don't know anything about it but a google turns up:
http://incubator.apache.org/aries/jndiproject.html
The trouble with this is that the OSGi EEG has only recently defined their spec for JNDI under OSGi
and you're very limited wrt OSGi runtimes that implement that spec (and a host of other EEG defined
specs). Aries is one of the few. I'm not convinced that I want to tie Tuscany OSGi support to
Aries just yet.
...ant
