Re: [virgo-dev] Would you like to try debugging a Gemini Blueprint issue

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

I am looking at it and will give it a try. 

The issue here is that proxy interface must be stable after creation and proxy can be created prior to backing service availability. So relying on service properties is not a given. Also if there were a remote and local IHello service and all of a sudden remote went away and was replaced by a local? How will the importer deal with that?  I have to spend a little more time looking at ECF usage patterns to understand implications. 

I think it can be done with a bit of refactoring in the importer OsgiService/Collection  factory beans or by applying spring aop advice post proxy creation i.e during bean factory post processing (like spring transactions). Just want to make sure it is not destructive and overly invasive. 

Everything like this becomes a bit more problematic as soon as service dynamics come into play. :)

Regards,

Dmitry

-- 
Dmitry Sklyut

Sent with Sparrow

On Thursday, February 7, 2013 at 3:57, Glyn Normington wrote:

Hi Dmitry

Nice work!

> I will circle back with Glynn to see if there is a merit in providing ProxyCreator extension point. I think there is as demonstrated here. For example if service property xyz == true try to apply IRemote interface - but only if that IRemote interface is visible form service importer class loader. 

Sounds reasonable. Would you be interested in providing a patch as this would be a good candidate for Gemini Blueprint 2.0 which I'm hoping to release in Q1?

Regards,

Glyn

_______________________________________________

virgo-dev mailing list

virgo-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/virgo-dev