On Fri, Dec 10, 2010 at 9:08 AM, Mike Edwards <[email protected]> wrote: > On 09/12/2010 19:02, Mike Edwards wrote: >> >> On 09/12/2010 17:37, Raymond Feng wrote: >>> >>> Hi, >>> >>> Maybe you can try this: >>> >>> ServiceDiscovery.getServiceDeclaration("/" >>> >>> +contextFactoryClassName+".class").loadClass(contextFactoryClassName).getClassLoader(); >>> >>> getServiceDeclaration() finds the OSGi entry for the class file. >>> >>> Thanks, >>> Raymond >> >> Raymond, >> >> Thanks for the suggestion, which I take to be a way of getting away from >> making the >> binding-jms-runtime module formally depend on the ActiveMQ InitialContext >> class. >> >> I then assume that the code would have to go fetch the >> contectFactoryClassName by reading the >> properties file itself (ie the same one that the InitialContext JNDI code >> reads when it creates the >> InitialContext)? It does not do this today, but clearly it could be made >> to do this. >> >> One other question is how efficient this approach would be - since the >> ActiveMQ >> InitialContextFactory class is NOT defined as a META-IF/services service, >> does this mean that the >> getServiceDeclaration() method above would necessarily go search ALL of >> the bundles loaded, or is it >> cleverer than that? >> >> >> Yours, Mike. > > Raymond, > > An update. > > The code above does not work. It does not find the InitialContextFactory. > > I think this is simply because the InitialContextFactory is not declared in > META-INF/services. The loading process for this stuff does not follow that > pattern. > > > Yours, Mike. >
If we find that, after suitable experimentation with the various suggestions here, we have to have ActiveMQ specific code then having it in an ActiveMQ specific module would seem to follow the pattern we've used for other extensions. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
