On Fri, Dec 10, 2010 at 6:56 AM, Mike Edwards <[email protected]> wrote: > 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 >> > >
Mike, The only Tuscany user I know of who uses OSGi and the JMS binding does it by having their own custom JMSResourceFactory impl. If its a problem I'd be happy to help add a new module to plug in a custom JMSResourceFactory as that seems a much better approach than adding ActiveMQ specific code to the current module. Another approach that might be worth looking at to help get started would be to use a JMS broker running as a separate process to the OSGi container. That way to start with you just have to deal with getting Tuscany running in OSGi without needing to deal with how to get JMS working in OSGi. There's an itest that shows doing that: testing/itest/jms/externalBroker. You still have the issue of loading the InitialContextFactory class, but if the approach suggested by Ramond works then it sounds like thats solvable too. ...ant
