On 30 June 2010 03:42, Danushka Menikkumbura <danushka.menikkumb...@gmail.com> wrote: > Devs, > > Any other idea on this?. Please provide your feedback. > > Thanks, > Danushka > > > Hi Sorin, >> >> I am not saying OSGi does not fit into the broker. Undoubtedly we should >> OSGi-fy the broker at some point. That will add modularity, multiple version >> support, hot deployment/update, etc into the broker. What I am saying is >> that the way OSGi is used in the current plug-in architecture does not add >> any value from an OSGi point of view. We have rather used the service >> registry facility in OSGi to register and look up services (i.e. plug-in >> factories in this case).
Hi Danushka, I think I agree with Sorin here. I don't think we gain anything by moving away from the OSGi plugin architecture we have now - it has been in place for a long time, and works well. As far as I can see, we would just end up rewriting much of the functionality that Felix provides for us already, which seems like a waste of resources, unless there is another benefir I haven't seen. I agree that *some* further refactoring of the plugin interfaces would be nice - perhaps making them paramaterised by their configuration class, and using generics a little better in the factories and activators, such that we could have a single parent abstract factory, activator and plugin that would be extended. I will comment separately on the issue you raised about re-factoring (QPID-2705), but perhaps if you gave more details on the issue you mentioned in your message of 22 June 2010 10:34 (PluginManager OSGi Framework) we could start to work towards getting Felix running inside another OSGi framework. I can see no technical reason why an OSGi BundleContext cannot be loaded as a child of another BundleContext, i.e. Felix embedde4d inside Equinox or Spring dm or whatever. Do you have a stack trace or some more logs that you could attach to a new JIRA? Cheers, Andrew. -- -- andrew d kennedy ? edinburgh : +44 7941 197 134 --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
