Community
Participate
Working Groups
Build Identifier: 3.5.1.R35x_v20090827 We are having issues while using GlassFish on Equinox. It seems Equinox is not able to find a consistent bundle space, but Felix 3.0 (yet to be released) is able to find it. I have documented the steps in the "Steps to reproduce." To easily reproduce the issue, I have made available a GlassFish installation with necessary configuration. Just download the binary and run it. Thank you. Reproducible: Always Steps to Reproduce: 1. Download glassfish from http://tinyurl.com/37uvdpn 2. Unzip glassfishv3.zip When you unzip, the layout would look like this: glassfishv3/ glassfish/ modules/ [This contains all OSGi bundles] osgi/ felix/ [contains felix jar] equinox/ org.eclipse.osgi_3.5.1.R35x_v20090827.jar configuration/ config.ini debugoptions.properties Edit config.ini and adjust the path of osgi.debug properties file. 3. Start GlassFish: (You must use JDK 1.6) ------------------------------------------ java -DGlassFish_Platform=Equinox -jar glassfishv3/glassfish/modules/glassfish.jar If you have turned on resolver debug option, you shall notice that a bundle with symbolic name com.sun.xml.ws does not get resolved and that's the issue. The diag command does not lead to any conclusion or I don't understand how to interpret its outcome. 4. On a separate console, telnet to equinox: telnet localhost 6667 > bundle com.sun.xml.ws > diag <bundle id> Additional Notes: ------------------ Equinox cache location: It is created glassfishv3/glassfish/domains/domain1/osgi-cache/equinox/. rm this directory in case you want to clean the cache during subsequent restart. How to use different equinox version: To use a different equinox version, first delete org.eclipse.osgi_3.5.1.R35x_v20090827.jar from above location and copy the appropriate jar to the location.
I have only looked into this briefly, but it appears that we are running into a timeout trying to find the best combination to use for the resolution result. Perhaps we would find one if the resolution was allowed to continue but perhaps not. I will need to investigate more. Or as Richard says, start using the felix resolver ;-)
(In reply to comment #1) > I have only looked into this briefly, but it appears that we are running into a > timeout trying to find the best combination to use for the resolution result. > Perhaps we would find one if the resolution was allowed to continue but perhaps > not. I will need to investigate more. I look forward to your comments. The sooner the better. We do want GlassFish to work on Equinox all the time without requiring any special configuration.
(In reply to comment #2) > I look forward to your comments. The sooner the better. We do want GlassFish to > work on Equinox all the time without requiring any special configuration. It looks like you have bundles that import a number of packages that are exported by the system bundle on Java SE 1.6. These bundles do not use any versions when importing the package. The resolver prefers to use the packages exported by the system bundle because it is already resolved over the packages (with higher versions) that are exported by other bundles. If your bundles need the higher versions of the packages then I suggest you import the packages with proper version ranges to force them to get resolved to the correct version exported by your bundles. I don't expect a quick fix will be available in the framework to fix this. We need to evaluate either improving the equinox algorithm or look into sharing the resolver algorithm with felix.
I forgot to mention that in this particular configuration the equinox algorithm has to exhaust the complete set of permutations to figure out that the last permutation will give us a no conflict result. This is pretty much the worst case scenario with the current algorithm. We could reverse the order we permutate but that has just as likely of a chance to cause other cases to take a long time. This would cause us to prefer the exports from your bundles over the system bundle.
(In reply to comment #3) > (In reply to comment #2) > > I look forward to your comments. The sooner the better. We do want GlassFish to > > work on Equinox all the time without requiring any special configuration. > > It looks like you have bundles that import a number of packages that are > exported by the system bundle on Java SE 1.6. These bundles do not use any > versions when importing the package. The resolver prefers to use the packages > exported by the system bundle because it is already resolved over the packages > (with higher versions) that are exported by other bundles. If your bundles > need the higher versions of the packages then I suggest you import the packages > with proper version ranges to force them to get resolved to the correct version > exported by your bundles. > > I don't expect a quick fix will be available in the framework to fix this. We > need to evaluate either improving the equinox algorithm or look into sharing > the resolver algorithm with felix. Three things: 1. I expected a framework as good as Equinox to provide me far better information that silently giving up and then causing random class loading failures. I have turned on debug level in general and debug level of resolver, but there is not much information spit out by Equinox. 2. Is there a property that controls the resolver time-out? I would like to set it to maximum possible value to see if it eventually finds a consistent class space or not. 3. We have actually tried to improve the bundle metadata. We had identified a few bundles which did not import with proper versions and fixed them. Even then Equinox fails. Since it is not clear which bundles are causing Equinox to give up, it is pretty difficult to identify the rogue bundles. I am hoping Equinox developers being more familiar with their code may be able to identify those bundles. Since the bundles with improved metadata have already been committed, to reproduce one just has to download glassfish from: http://download.java.net/maven/glassfish/org/glassfish/distributions/glassfish/3.1-SNAPSHOT/glassfish-3.1-SNAPSHOT.zip unzip, copy an equinox jar to glassfish/osgi/equinox/ and run: java -DGlassFish_Platform=Equinox -jar glassfish/modules/glassfish.jar We would like GlassFish to be runnable on top of Equinox.
The problematic imports seem to be ones for javax.* You have lots of bundles that export their own version of these packages. If I remove them from the system.packages property in the config.ini then things seem to resolve better: javax.annotation javax.xml.stream javax.jws javax.xml.bind javax.xml.bind.annotation javax.xml.bind.annotation.adapters javax.xml.bind.attachment javax.xml.bind.helpers javax.xml.bind.util javax.xml.crypto.dsig.spec javax.xml.soap javax.xml.ws javax.xml.ws.handler javax.xml.ws.handler.soap javax.xml.ws.http javax.xml.ws.soap javax.xml.ws.spi javax.xml.ws.wsaddressing This eliminates all the combinations because (I think) you want to really use the exports from your bundles and not the ones from the VM. There are likely other cases where you have duplicate exports of packages also exported by the system bundle. The packages above were the ones that I found you had one or more import-package statements with no version specified, allowing it to resolve to either the system.bundle export or the versioned one from one of your bundles.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
We have since moved to using the Felix resolver in Equinox. If this is still causing issues on the latest releases of Equinox please re-open.
