On Fri, Dec 10, 2010 at 10:13 AM, ant elder <[email protected]> wrote: > On Fri, Dec 10, 2010 at 10:00 AM, Mike Edwards > <[email protected]> wrote: >>> 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 >>> >> Ant, >> >> Perhaps you're right and ultimately we shall need to create a whole new >> module binding-jms-runtime-osgi (or something like that). >> >> However, I'm not sure that we yet know what needs to be in that module - >> we're just getting this working under OSGi for the first time and I can't >> predict what might need tweaking/changing. >> >> So for the moment, I'll commit an initial set of changes that do get things >> working under OSGi while still getting us a clean build when not running >> under OSGi. We can iterate away from that. >> The amount of changed code is not large. >> >> >> Yours, Mike. >> > > Ok fine, i'll help by putting that into a separate ActiveMQ specific > module then. > > ...ant >
I've added a new module, binding-jms-runtime-activemq, which has a new ActiveMQ specific JMSResourceFactory impl that overrides the JMS binding default one when both modules are used. Would you use that for adding the ActiveMQ specific code? ...ant
