qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: QPID-2705: New Plug-in Architecture for the Java Broker
Date Fri, 02 Jul 2010 13:37:37 GMT
Hi Marnie,

My immediate approach was to have a new plug-in management mechanism as I
could see that it was not possible to have Felix running inside Equinox. I
am having a deeper look at whats going wrong here. I will keep this thread
updated. Even though my non-OSGi plug-in manager runs fine in my
application, not tested for all possible scenarios, though.

Thanks,
Danushka

On Fri, Jul 2, 2010 at 6:52 PM, Marnie McCormack <
marnie.mccormack@googlemail.com> wrote:

> Hi Danuska,
>
> What would be really helpful here would be to get stack trace/logs/details
> on what happens when you tried to use Felix inside Equinox ? Its not
> currently clear why this doesn't work so hard to comment on what we need to
> do next.
>
> Currently the plugin manager uses Felix as a registry of factories, rather
> than write our own factory manager. Felix also handles dependency resolver
> and the manifest for the plug-ins.
>
> If we can help you get Felix running I think that'd might be the best way
> to
> go ?
>
> There's definitely some refactoring required on the plug in interfaces
> though.
>
> Regards,
> Marnie
>
> On Wed, Jun 30, 2010 at 11:19 AM, Danushka Menikkumbura <
> danushka.menikkumbura@gmail.com> wrote:
>
> > Hi Andrew,
> >
> > I spent fair amount of time looking at how to hookup one OSGi runtime
> with
> > another but could not find anything. I am more than happy if that is
> > possible because I am doing something that I am not intended to do.
> Please
> > let me know if you think there is a better approach.
> >
> > Thanks,
> > Danushka
> >
> > 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.
> > >
> >
> > --
> >  Danushka Menikkumbura
> > Apache Axis2 PMC Member
> >
> > Apache Qpid - World Domination through Advanced Message Queueing ;
> > http://qpid.apache.org
> >
> > phone : +94 77 364 1754
> > personal blog : http://danushka-menikkumbura.blogspot.com/
> > <http://danushka-menikkumbura.blogspot.com/>technical blog :
> > http://danushkastechythoughts.blogspot.com/
> >  <http://danushkastechythoughts.blogspot.com/>twitter :
> > http://twitter.com/danushkamenik
> > <http://twitter.com/danushkamenik>linkedin :
> > http://lk.linkedin.com/in/danushka
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message