Unable to provision bundles to Equinox with Pax Runner 1.7.5 [PAXRUNNER-405] #415
Comments
|
Harald Wellmann commented This might be a conflict with the reference: protocol handler introduced in Pax Runner 1.7.5. Can you give on some more details:
|
|
Toni Menzel commented
|
|
Toni Menzel commented I cannot reproduce the problem described. please advice. Until then i'll close this issue. |
|
Luke Jackson commented Hi, I have the same issue as Jan, using the Osmorc OSGI plugin for IntelliJ (which Jan develops), which I have manually updated to Pax Runner 1.7.6. Hopefully the details below may help pinpoint the issue? The command line I am using (removing details of my company's proxy server): "C:\Program Files\Java\jdk1.6.0_18\bin\java" config.ini file: ################################################
##############################
##############################
##############################
|
|
Luke Jackson commented reopening with further details on issue |
|
Toni Menzel commented Thanks, Luke! We'll have a deeper look at it now. |
|
Toni Menzel commented Can you break down which of the referenced bundles is not discoverable ? I mean, there are plenty, can you tell if its a specific one ? Or happens with a single bundle (and not that many?) could also be a line-length issue in the windows shell ? Some more info would really help here, i don't have a windows box here right now ? And i guess "EDGCash" is not an open source thing ? cheers. |
|
Luke Jackson commented Hi Toni All the bundles fail to load with the same reason. The first one to fail in the log is the first one on the command line.
This is repeated for each bundle. The log ends with Equinox complaining that it cannot acquire the application service:
You're correct that "EDGCash" is not open source. However I suspect you can reproduce by running an Equinox project in IntelliJ 10.5 community edition, if you install the "osmorc" osgi plugin and replace ~/.IntelliJIdea10/system/plugins/osmorc/pax-runner.jar with the 1.7.6 version of pax runner (making sure to keep the same file name). Switching back to 1.7.3 and running the same project works fine. From Jan's previous comment it seems the regression happened in either 1.7.4 or 1.75. Let me know if I can help further. |
|
Toni Menzel commented Understood. I just made sure vanilla pax runner (when downloaded from OPS4J or Maven Central) works as expected on a Windows box. I will try to reproduce the problem with the IntelliJ Osmorc setup. |
|
Jan Thomä commented Ok, i tried with a vanilla Pax Runner 1.7.6: ./pax-run.sh --p=equinox --nologo=true --v=3.4.1 file:///Users/kork/.m2/repository/org/dom4j/com.springsource.org.dom4j/1.6.1/com.springsource.org.dom4j-1.6.1.jar file:///Users/kork/.m2/repository/org/slf4j/com.springsource.slf4j.log4j/1.5.10/com.springsource.slf4j.log4j-1.5.10.jar@nostart file:///Users/kork/.m2/repository/org/slf4j/com.springsource.slf4j.api/1.5.10/com.springsource.slf4j.api-1.5.10.jar file:///Users/kork/.m2/repository/org/objectweb/asm/com.springsource.org.objectweb.asm/1.5.3/com.springsource.org.objectweb.asm-1.5.3.jar file:///Users/kork/devel/java/maventest/abundle/target/abundle-1.0.1.jar@1 file:///Users/kork/.m2/repository/net/sourceforge/cglib/com.springsource.net.sf.cglib/2.2.0/com.springsource.net.sf.cglib-2.2.0.jar file:///Users/kork/.m2/repository/org/apache/log4j/com.springsource.org.apache.log4j/1.2.15/com.springsource.org.apache.log4j-1.2.15.jar file:///Users/kork/.m2/repository/org/antlr/com.springsource.antlr/2.7.6/com.springsource.antlr-2.7.6.jar file:///Users/kork/.m2/repository/org/osgi/org.osgi.core/4.2.0/org.osgi.core-4.2.0.jar file:///Users/kork/.m2/repository/org/apache/commons/com.springsource.org.apache.commons.collections/3.2.1/com.springsource.org.apache.commons.collections-3.2.1.jar file:///Users/kork/.m2/repository/org/jboss/javassist/com.springsource.javassist/3.9.0.GA/com.springsource.javassist-3.9.0.GA.jar file:///Users/kork/.m2/repository/org/hibernate/com.springsource.org.hibernate/3.3.2.GA/com.springsource.org.hibernate-3.3.2.GA.jar --sl=1 --bsl=5 --log=DEBUG --console --executor=inProcess --keepOriginalUrls --skipInvalidBundlesNo luck (on Mac OS X). Then just out of curiosity I removed the --keepOriginalUrls parameter. Then it worked. So somehow the --keepOriginalUrls parameter breaks it for Equinox. As far as I understand the documentation this parameter ensures that bundles are loaded from their original positions and not from the cache, which is something I need in development as otherwise I'd have to clear the runner/equinox folder before every start and this would also re-download the equinox framework. |
|
Luke Jackson commented Thanks Jan. Toni, does Jan's finding help at all? Are you now able to reproduce on your end? Jan, is there some way that I can work around this (even in a hacky way) until the issue is resolved in pax runner? I am currently blocked from developing equinox 3.7.1 (in turn required for Windows 7 64-bit development) because the versions of pax runner which support 3.7.1 are all affected by this issue. |
|
Toni Menzel commented Yes, that definitely helps. Sorry for the slow response. We are on it! |
|
Luke Jackson commented Hi Toni Just a friendly check up to see if you've managed to make any progress on this issue? Thanks Luke |
|
Sven Strohschein commented Could someone please take some time to solve this issue? The last update regarding this issue is at least four months ago and it is a blocker issue. The error is reproducable and Jan T. has already post a hint where the error could be. At the moment some IDEs can not update to a current version of PAX-Runner because it can not anymore work with Equinoxe and the old PAX-Runner version doesn't support Apache Felix 4.x... So it is very important that the IDEs can update to a current version of PAX-Runner... Issue for IntelliJ IDEA: http://youtrack.jetbrains.com/issue/IDEA-80352 |
|
Harald Wellmann commented OPS4J is an open community. If you think an issue deserves more attention, you are free to speed things up by providing a self-contained test case or by fixing it yourself. Instead of please use This provisions the bundle from the original location without creating a copy. Regarding the question of newer framework versions, Pax Runner has an option to let you specify a custom framework version, but for shortcuts like --v=3.8.0 to work, the new versions have to be hardcoded in Pax Runner and a new Pax Runner version has to be released. This is an effort that currently active OPS4J members are less inclined to take, as there is a growing number of more lightweight or more flexible and actively maintained alternatives to Pax Runner, e.g.
Anyone who thinks that Pax Runner should be kept alive, please step forward and maintain it. Otherwise, don't expect too much effort going into it. Pax Exam (the last OPS4J project with a dependency on Pax Runner, AFAIK) is dropping this dependency in its forthcoming 3.x release line, so from the current perspective, this looks very much like end of maintenance for Pax Runner. Further discussion about the future of Pax Runner is very welcome, but this is not the best place for it. Please use our mailing list |
|
TA Team commented Hi! I am not sure if I stumbled over the same problem, but at least the failure symptom is exactly the same and I am also trying to provision bundles (from Eclipse IDE workspace) to Equinox (v3.8.1, I hope) via so-called reference URLs and using the native container from pax exam v2.6. Since I am rather new to pax exam, I certainly cannot rule out that the problem is caused by my humble self. During problem investigation attempts I stumbled over a self-test called Is there something wrong in my thoughts (and thus certainly also in my initial problem), or potentially in my project set up (cf. stack trace manipulation), or would this confirm the actual problem (cf. this issue's title)? Thanks a lot, |
|
TA Team commented Hi, please note that in the meantime we implemented a workaround for this problem that allows us keeping pax exam untouched/unpatched (the credit for the idea goes to Ronald Brindl): When using so-called reference URLs in pax exam to use classes generated from IDE for OSGi component test execution, the URLs are seemingly correctly mapped to the pax exam reference url handlers etc. However, the corresponding ReferenceInputStream is not treated as expected from Equinox: only their own implementations (and pax exam one's does not inherit from it) are treated correctly. We implemented a tiny OSGi fragment bundle that configures/installs an OSGi adapter hook to map reference URLs via a special reference URL connection that inherits from the required Equinox one. This fragment bundle is placed into the same target platform folder as the osgi framework bundle (org.eclipse.osgi) and the following system properties are used for its "activation": Cu Reinhold (Füreder) |
Jan Thomä created PAXRUNNER-405
I recently upgraded to Pax Runner 1.7.5. Since then everytime I want to provision a bundle to Equinox, the bundle is not provisioned. The Error log contains several stack traces:
Provisioning to Felix works perfectly fine. Reverting back to Pax Runner 1.7.4 is the only way to make it work again.
Affects: 1.7.5
Votes: 3, Watches: 2
Referenced issues
relates to:
The text was updated successfully, but these errors were encountered: