Community
Participate
Working Groups
Mylar tried to move its Axis 1.3/1.4 dependeny out of org.eclipse.mylar.jira.core. However, due to callbacks that required the dependent plug-in's classes on being in the same class loader we aborted the effort. The discussion is on bug 172264 and Eclipse-BuddyPolicy is suggested as a work-around on comment#4. I'm wondering if others have encountered this and validated this approach. I opened this bug so that we can discuss the right solution to this and similar packagings for Orbit. Mylar doesn't have a strong driver as Axis is currently only used by specific task repository connectors, connectors' versions of Axis can actually differ and if we did standardize on one it would likely be Axis 2.
My guess would be the Eclipse-BuddyPolicy might be the right approach, but as far as I know, no one has ran into this issue. I'm adding Kathy and Chris and interested parties (who know more than I do about webservices! :) Also, be aware of the types of issues raised in bug 181813. I'm not sure if the logging issues apply here, but, in short, for logging at least, it's likely inappropriate to use the buddy-registration mechanism is participatory IDE's, since there's no way to say you are the one and only "buddy" so someone else might do something contrary to your expected use. I do not know enough about how these axis callbacks are used, but if it's to register something like a host or endpoint, then I could imagine chaos resulting (again, in a participatory IDE). In the chain of logging related discussions, there's mention of next release improving the "call back registration" to better address context in participatory callbacks. In Eclipse, as in sports, there's always next year. :)
Thanks for pointers David. I'll revisit this next season :)
*** Bug 191069 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > *** Bug 191069 has been marked as a duplicate of this bug. *** > The problem with NOT using Eclipse-BuddyPolicy is that it renders the the Axis plug-in unusable as a server. The typical way to use Axis as a server is to drop it and one's own classes into a servlet container. (In my case, I'm trying to use Equinox + Jetty as the servlet container.) Axis will take care of all of the SOAP marshalling, but it needs to be able to load MY class (the actual Java implementation of the web services that I'm trying to publish) in order to have something to hook its marshalling capabilities to. And unfortunately, it needs to be able to load that class directly; it doesn't support any sort of indirect web service class implementation via a Java interface that's available to both it and my plug-in. The only feasible workaround for using Axis in server mode absent the Eclipse-BuddyPolicy is to embed it directly into my web service plug-in so that it shares my classloader and has access to my classes. That's just ugly, especially when it can be avoided with a one-line fix. (We can certainly argue about whether the Axis developers should have split server- and client-side functionality a bit so that the client-side behavior could go into a non-Eclipse-BuddyPolicy plug-in to mitigate against your IDE concerns, David, but it's kind of a moot point... :-)) I *have* successfully used the previous Axis plug-in in server mode; it had Eclipse-BuddyPolicy enabled, and as far as I could tell it worked fine.
Eclipse-BuddyPolicy is the correct thing to use here, and was designed [1] for just the sort of requirement Apache Axis has to load classes from bundles above it in the food chain, such as bundles with specific adopter-provided Axis-based Web service components. Log4J is a rather unique beastie. As I understand it, Log4J's Factory mechanism is designed to select and load "the" single Log implementation for use by the platform. If more than one Log implementation candidate is found via the buddy mechanism, then Equinox' search order [2] will pick one. It may therefore be quite important for any given assembly of Eclipse plugins (eg. WTP) that use Orbit's log4j plugin to choose very carefully from amongst a set of possible Log implementations the one that will satisfy all plugins in the assembly. Unlike Log4J's "one to one" relationship to a Log implementation, Axis has a "one to many" relationship to Web service components hosted by it. Except by fluke or a serioud lack of imagination in the selection of Web service class names, it's very unlikely any two bundles contributing Web service components (eg. service classes) based on Axis would provide identically named classes and collide. In any event, selection of bundles which register themselves as buddies to Axis and don't collide with each other is still the responsibility of whomever is assembling a bunch of Eclipse bundles above Orbit into a given tool offering. The Orbit Axis bundle MUST allow tool assemblers the freedom to register their Web services with the Axis bundle. [1] http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements [2] http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Search_Order
Thanks Chris and Mathew. A couple more question ... why do we not need this is WTP, Chris? Also, not that we have axis2 in orbit, but out of curiosity, does it use same/similar call back mechanism? Mathew (and Mik) does this have to be in the Europa distribution to be of use to you? I ask since we'd all prefer not to change anything at this late point for Europa. One thing I could do, since you experts agree its needed, is put it in now, it will be produced by Orbit "I-builds" where you could always pull it for your own servers or distributions (or, what ever you are doing). Then eventually go into another "Recommended build" later this year or next. Is that satisfactory? My only concern would be then if someone happens to put it into a Europa stack, then it's qualifier will be higher, and it be used instead ... but, if Chris isn't worried, I won't be either. Other suggestions welcome.
David, the reason WTP doesn't need to be an Axis buddy is that none of our WTP plugins include static (generated) Axis service or client components. That is, our plugins help you create Web services, but none of them *are* Web services. The only exception is the Web Services Explorer which functions as a Web service requestor (client), however, it uses entirely dynamic API - again, no generated Axis service or client components. Axis2 has the same requirement, and to a greater extent. It needs the ability to construct concrete service implementation classes, data beans, module implementations, and so forth. That said, note that we don't have an Axis2 plugin in Orbit - at least not yet. BTW, I'm not concerned strictly about adding an "Eclipse-BuddyPolicy: registered" to the Axis 1.4 plugin in Orbit since without any registered buddies there should be no effective change in bundle resource loading behavior (and I think you know how creeped out I get when we monkey with that sort of thing, especially at the 11th hour). Therefore, the bigger question is: Does anyone know if any other plugins that ship in WTP or Europa will declare an "Eclipse-RegisterBuddy: ..." on the Axis 1.4 plugin?
I'm afraid I'm not terribly clear on the schedule for Europa and WTP and how they relate to the internal IBM repackagings of Eclipse that I'll be using, but I do need it yesterday. :-)
Matthew, are any of your "Axis buddy" plugins being developed within any of the Europa projects [1]? [1] http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release#Projects
Chris - I've got nothing in Europa. I'm merely an external consumer.
David: nothing holding us up in Europa and no plans to make changes related to this. The way this works for us is that specific Mylyn connectors that like SOAP more than REST (e.g. JIRA) need Axis. Those connectors currently have to have their own version of Axis. We only have one in Eclipse CVS, and the external ones we know of have their own as well. Post Europa we will try to encourage connectors' reause of Axis via Orbit by doing so ourselves (bug 172264).
Changing severity to 'major' since the scenario Matthew has this is pretty much blocking (without them using their own bundle, that is).
I removed "1.3" from title since we do not have a 1.3 in Orbit, and no plans to.
Should be in builds > 6/19, pending review and confirmation. The tentative plan is to include this is a "Recommended 2" build, available in the next day or so.
