Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Asyncproxy and Java 7

On 2/20/2015 7:41 AM, Dario Foresti wrote:


In April 2014, Scott Lewis wrote:

"We arrange some set of features (maybe exactly what we have now, maybe not...I'm not sure) so that *both* versions of asyncproxy are installed into consumer's runtimes (Eclipse, other p2 users, or others...e.g. Karaf). Why do this? My thinking is this: This way, at framework startup time if both 1.0 and 2.0 versions of async proxy are present, and the java version being used is < J8, then the asyncproxy 1.0 version will resolve and be wired to, while if the java version is >= j8 then the 2.0 version will be used/wired. If my thinking is right on this, then this would mean that J8 users of ECF would have to do absolutely nothing to use this new CompletableFutures with async proxies....if they ran using j8 then the async proxy use of CF would/will 'just work'."

Now I'm using remote OSGI on a framework running on a java 7 environment. I can't use java 8 because the destination system of the product will be an IBM Power8 with Linux and for now a java 8 JVM is not available for this system. When the OSGI framework starts ( on a test system with Windows 7, Eclipse Luna and Java-SE1.7 execution environment ), in console I have this error message:

org.osgi.framework.BundleException: Could not resolve module: org.eclipse.ecf.remoteservice.asyncproxy [1248]
  Unresolved requirement: Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=1.8))"

It seems like the system always loads the 2.0 version of asyncproxy bundle (that require a J8 environment) instead of the right 1.0 version for J7. 
So, only for my tests it seems that the Scott Lewis solution based on Require-Capability filters and multiple version bundles does not work properly. But it is possible that i'm doing something wrong.

Anyone can help me? 
And, if the solution really does not work, what can i do for load and wire the correct version of asyncproxy bundle?

Any help will be very appreciate.

Sure.   First question:  how are you starting/running/debugging things?   If you are running one of the example product configs (e.g. TimeService.*.product from within Eclipse, there's a known problem with PDE that I'm trying to find a reliable work-around for:

The behavior seems to be that when the Eclipse generates a launch config from running/debugging the .product config it *always* uses the highest version (i.e. 2.0.0 of asyncproxy) when there are multiple versions of a bundle present in the target (as is the case with the ECF remoteservice SDK installed into Eclipse).    In this case, it should rather select the 1.0.0 version of asyncproxy, because of the Require-Capability constraint you quote above (2.0.0 requires java8, 1.0.0 =< j7).   I suspect the reason for this is that PDE doesn't yet look at Require-Capability constraints (probably because I don't think p2 does yet either [1]) and so doesn't pay attention to the 1.8 constraint when selecting bundles for the launch config.  Anyway, I'm trying to think of ways to word around this in the next ECF release, but haven't got a solution yet.

If this is what's happening (.product config -> .launch config selecting wrong version), then one work around that you can do yourself is to generate the launch config, get the error above on start, and then go to the Run.../Debug... entry for that generated launch config, go to the plugins tab, and unselect the 2.0.0 version and select the 1.0.0 version from the list on the plugins tab.   This is inconvenient, I know, especially since if you have to change the product config, then you will need to re-generate the .launch (as I do for the examples), change the selected version again...etc.   But it does work.

If you are *not* using the example product configs, however (you have your own product config and/or features), this does point to a different/better solution for you.   In that case, in your product config and/or feature that includes the asyncproxy bundle, you can specify the *exact version* of the async proxy to use (i.e. 1.0.0.v20140410-1838).  Then, when PDE generated the launch config, it will use the correct one.   I understand this is somewhat brittle, because if we update the qualifier in a new version you will have to update your product and/or feature to reference a new version, but I can say that this version has been in place for nine months without change, and I don't know of/expect any bugs, so I expect it to be relatively stable.

If I'm misunderstanding/misinterpreting what you are doing to launch please let me know.   If you are doing something else/different from what I described above, then there may be other ways to prevent this from happening.

I've opened an ECF bug [2] to track pursuing a work-around for this.  

Thanks for speaking up.  

Scott


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=313553
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=460466


Back to the top