Hi Paul, Thank you for your comments. We are using felix embedded, not as the main container starting the broker. It was done so that the qpid broker is able to use plugins. We can easily make the jars manifest OSGI compliant, but it is not enough as it stands now. As Martin was saying previously, we need to modify the PluginManager, set the dependencies properly (eg so that common jar is loaded first, then broker, then modules) and finally have an Activator starting the broker which means we need to modify the startup scripts as well so that they start an OSGI framework. As Rob was mentioning we might need to do some cleanup in terms of what we export.
Cheers, Sorin On Wed, Jun 23, 2010 at 10:01 AM, Paul Fremantle <[email protected]> wrote: > My first thoughts are that we should be using Felix in an OSGi > compliant way: not calling felix specifically. > > My second thoughts are that it ought to be easy to at least bundle-ify > the QPid jars so that they fit into an OSGi model. > > The third aspect: completely OSGi-fying QPid - seems like maybe more > work and more of a requirement on users. I'd love it, but I think that > could be put in place later maybe? Of course if its really easy, then > that's even better. > > Paul > > On Tue, Jun 22, 2010 at 1:57 PM, Robert Godfrey <[email protected]> > wrote: >>> Yes, I think this would give us a more flexible product that can be >>> used in a variety of places. I don't think it would require much work. >>> >>> - Change our startup to start the felix container. >>> - Give the core broker an activator to kick start its loading as we have >>> now. >>> - Change PluginManager to simply be a helper lookup class. >>> >>> I'd be intereseted to know what the other devs think about the >>> approach, would be good to foster a community of plugins that can >>> augment the broker's functionality. >>> >>> Martin >> >> So, personally I think the problem highlighted by Danushka is one that >> we should look to solve - by using Felix in the way that we are >> currently doing, we are preventing the broker being run inside his >> application. >> >> My main concern is obviously that we preserve compatibility from a >> user experience perspective with the existing broker packaging. >> >> As to the ability to develop new plugins, my main concerns are that we >> are not yet at the point where our internal interfaces are stable - >> thus any "plugins" developed would essentially be at the developer's >> own risk. Ideally before advertising that people should be developing >> plugins we would settle on defined APIs which such plugins could use. >> >> Thoughts? >> >> Rob >> >> --------------------------------------------------------------------- >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:[email protected] >> >> > > > > -- > Paul Fremantle > Co-Founder and CTO, WSO2 > Apache Synapse PMC Chair > OASIS WS-RX TC Co-chair > > blog: http://pzf.fremantle.org > [email protected] > > "Oxygenating the Web Service Platform", www.wso2.com > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > -- Sorin S --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
