Community
Participate
Working Groups
The org.eclipse.mylar.jira.core plug-in will be bundling this, but it should come from Orbit.
Axis 1.3/1.4 can not be used in this way since it relies on callbacks, so each connector needs its own copy (see bug 167362). We should explore whether Axis2 can be used in this way.
Mik, are you talking about something like: Mylar depends on Axis, but Axis needs to access some Mylar classes? (sorry I'm not familiar with Mylar use of Axis) On this case, wouldn't Eclipse-BuddyPolicy and Eclipse-RegisterBuddy directives resolve this?
We tried, but failed to move the Axis depencency into org.eclipse.mylar. The problem with Axis is that it uses call backs (perhaps Axis2 does not, but we're not there yet). So my interpretation of what happens is that if the JIRA plug-in tries to load Axis from another plug-in that works, but then the callbacks don't work because the Axis has been loaded by another plug-ins class loader. So currently we're recommending that connectors maintain their own Axis dependencies.
Let's see if I understood: the only dependency on axis is jira.core? If so, the normal way to do is to separate axis jars on its own bundle and make jira.core depends on it. On this case, axis will be on it own classloader, and jira.core's classloader will see its classes and axis classes. The problem is that if axis needs to see jira.core's class via callbacks, it will throw some ClassNotFoundExceptions because axis classloader don't see jira.core. I had this same problem on my products, where I depends on jakarta-commons-digester which have to instantiate my own business classes. The solution: on axis bundle, declare a "Eclipse-BuddyPolicy: registered" directive on manifest (you have to insert this manually on MANIFEST.MF). On jira.core bundle, declare a "Eclipse-RegisterBuddy: <axis-bundle-id-here>" directive. This way you are saying that jira.core bundle is visible to axis's classloader. Note that these are not standardized OSGI directives (they are prefixed with "Eclipse-") and would work only on equinox. More information: http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html Let me know if this resolves you problem.
Thanks for the pointers Willian, I vaguely recall hearing about the buddy policy a while back. I'm still concerned that we don't want to force a particular version of Axis on connectors by exporting it from ..mylar.core though, because Axis 1.x and Axis2 are so different, and currently we're only approved for Axis 1.3 (1.4 has bug fixes). Shawn: since you were trying to fix the Axis dependency, could you comment on whether it would this work?
It sounds like this method could work as long as Axis was in its own Mylar project so that if there are 2 different versions, the plug-ins don't get confused and attempt to use the incorrect one. This means that Axis would not be able to reside in org.eclipse.mylar. I would still need to test this to ensure that it does work.
That's the typical Orbit story, so this bug is back to standing as first specified. I'll tentatively mark it for 2.0.
Steffen: we're approved for Axis 1.4 now. Any reason JIRA needs to move to that for the 2.0 release?
No, I am not aware of any (reported) bugs caused by Axis 1.3.
Filed Orbit bug 188654. No plans to do this for 2.0.
Removed axis jars from the XPlanner and JIRA connector. Both depend on the Axis 1.4 Orbit bundle now. In order to allow the Orbit bundle to load call backs declared in the axis properties file I added this header to the manifest of the xplanner and jira core plug-ins (see comment#4): Eclipse-RegisterBuddy: org.apache.axis
Created attachment 91285 [details] mylyn/context/zip
Adding Kathy to CC list for awareness. I'd have no idea what it would be, but would be nice to run some scenario that used bot Web Services (in WTP) axis 1.4 function and mylyn axis 1.4 function just to be sure there was no interference.
Thanks David. Now that Mylyn has been orbited I want to get an updated version into the Ganymede nightly builds as soon as possible so we can start integration testing. Axis is certainly one of the tricky bundles when it comes to class loading and it'd be good to work out any problems early in the game :). I have put this on next week's meeting agenda [1] and will post here once a Ganymede distribution with the latest Mylyn 3.0 stream is available: http://wiki.eclipse.org/Mylyn/Meetings#Next_Meeting
We already ran into an unexpected problem with the Axis dependency of the JIRA connector today: I saw class loading errors when running Mylyn on Java 6 that did not appear when running on Java 5. It turned out that the difference between Java 5 and 6 is that the latter version includes the javax.xml.soap APIs whereas Java 5 does not ship these. This is what happened: - org.apache.axis uses the javax.xml.soap.MimeHeaders class which is loaded from the javax.xml.soap bundle - the jira core plug-in declares an Axis call back that was loading the javax.xml.soap.MimeHeaders class as well - when org.eclipse.core.runtime is declared before javax.xml as a dependency in the manifest of the jira core plug-in the class is loaded from the system class loader and not from the javax.xml.soap bundle causing the class loaded in the axis bundle to be incompatible with the class loaded by the jira bundle The solution was to move the javax.xml.soap dependency in the jira core plug-in dependency "above" the org.eclipse.core.runtime dependency. David, Kathy, have you run into problems with Orbit bundles where the order of declared dependencies mattered before?
(In reply to comment #15) > > David, Kathy, have you run into problems with Orbit bundles where the order of > declared dependencies mattered before? > Sure, lots! :) Offhand, there's a couple of issues in your description. 1. I think the use of core.runtime is being discourage. Not sure why it's required in this case, but if there's something more specific to pre-req that would be good. 2. Bigger problem: if there is a chance that a package can be in both the JRE and in a plugin (as there is here in this JRE 6 case) then the plugin should "require-bundle" system.bundle ... this allows, the plugin's version of the package to replace ... or "blend in" ... with the one from the JRE. So ... javax.xml.soap should be changed to pre-req system.bundle. We've done this in several other bundles, such as xerces for it's "javax.xml" packages.
Thanks a lot for the additional information. I was wondering if bundles should prefer to consume packages provided by the JDK from the system class loader. It'd be great if the javax.xml.soap Orbit bundle could be changed accordingly so consumers wouldn't have to worry about the dependency order. Some of our core plug-ins have activators that extend Plugin which is in core.runtime so I am not sure if we can avoid that dependency entirely. What I don't fully understand, yet, is why the core.runtime bundle loader had the javax.xml.soap.MimeHeaders class. From looking at the bundles and it's re-exported dependencies there didn't seem to be any bundle using the soap package. I haven't found much documentation about consuming Orbit bundles, e.g. how to integrate Orbit bundles into the headless build or solving class loader problems. Is there a place on the wiki I haven't discovered, yet? I'd be happy to add the experiences gathered from doing this for Mylyn if that helps anyone.
(In reply to comment #17) > Thanks a lot for the additional information. I was wondering if bundles should > prefer to consume packages provided by the JDK from the system class loader. > It'd be great if the javax.xml.soap Orbit bundle could be changed accordingly > so consumers wouldn't have to worry about the dependency order. > I've opened bug 221429 so we won't forget. > Some of our core plug-ins have activators that extend Plugin which is in > core.runtime so I am not sure if we can avoid that dependency entirely. Good point ... I dont' see how to do that either. > What I > don't fully understand, yet, is why the core.runtime bundle loader had the > javax.xml.soap.MimeHeaders class. From looking at the bundles and it's > re-exported dependencies there didn't seem to be any bundle using the soap > package. It doesn't use it directly, but it pre-reqs and (unfortunately) re-exports the org.eclipse.osgi bundle. This had to be done for some compatibility reason, but it's this that automatically makes all JRE packages "visible" to plugins. > > I haven't found much documentation about consuming Orbit bundles, e.g. how to > integrate Orbit bundles into the headless build or solving class loader > problems. Is there a place on the wiki I haven't discovered, yet? I'd be happy > to add the experiences gathered from doing this for Mylyn if that helps anyone. > There's a list of things at http://wiki.eclipse.org/Orbit
