All, The Rampart tests now succeed with Axis2 SNAPSHOT and 1.5.2-SNAPSHOT. However, as expected, there are build failures in Sandesha2. I will restart the release process to get 1.5.2 out. Please shout if you still see an issue.
Andreas On Sun, Sep 5, 2010 at 22:24, Andreas Veithen <[email protected]> wrote: > Glean, > > I think I figured out what is going on here. Jarek's original changes > (i.e. r958696 on the trunk and r958718 on the 1.5 branch) both cause > regressions in Rampart _trunk_. Probably the tests that are failing > didn't exist in Rampart 1.5, which would explain why your conclusion > was different. These regressions were not caused by issues in the > tests themselves, but by an issue in STSClient (missing call to > ServiceClient#cleanupTransport) that I've fixed in r992868. > > I had a closer look at the CLOSE_WAIT fix, and there were indeed some > pieces missing from the trunk. Here is what I did to attempt to fix > both issues: > * I've restored Jarek's original change on the 1.5 branch (r958718). > * I've synchronized the trunk with the changes from the 1.5 branch, > i.e. the missing pieces of your CLOSE_WAIT fix and r958718. > > The builds on Hudson are in progress. In a couple of hours we will see > if the changes give the expected results. > > Probably we will again see issues in the Sandesha2 build, so we will > need some volunteers to figure out where the missing cleanupTransport > calls need to be added there. > > Andreas > > On Wed, Sep 1, 2010 at 23:17, Andreas Veithen <[email protected]> > wrote: >> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <[email protected]> wrote: >>> On 8/30/2010 5:43 PM, Andreas Veithen wrote: >>>> I also fixed (r965136) another issue on the trunk that (I believe) >>>> affected the same test cases. Maybe you are seeing that issue? >>> >>> OK, update follows... sorry for the long note! >>> >>> The summary: AbstractHTTPSender r958718 (Jarek's original change) both works >>> with Rampart and does not seem to regenerate the CLOSE_WAIT issues. I'd >>> vote >>> that we go with that one for 1.5.2. Rampart builds seem broken with 1.5.1 >>> but work with 1.5.2, so we should do a Rampart release soon after Axis2. We >>> should also test Axis2 1.5.2 with Sandesha if we haven't already (?). >>> >>> The longer version... >>> >>> Building Rampart 1.5 does not seem to be possible with Axis2 1.5.1 in any >>> configuration I've found. :( I guess the signatures of a few Xalan classes >>> changed between 2.7.0 and 2.7.1, and I can't find a way to get the >>> transitive >>> dependencies to cooperate and produce a successful build on the branch. >>> This >>> seems bad - however, I assume that the problem is really just with the >>> tests, >>> since we haven't heard reports that Rampart isn't actually working with >>> 1.5.1. >> >> Note that the issue I fixed on the trunk was that there were two >> dependencies to different versions of Xalan (with different group >> IDs). If I remember well, the issue was not always reproducible >> because the order in which the two JARs appeared on the classpath was >> not predictable. That may explain why it worked for the person who did >> the Rampart 1.5 release, but not for you. It should also be noted that >> because of the java.net repository problem, no Maven build depending >> on Axis2 <= 1.5.1 will give predictable results (unless the definition >> of the java.net repository is overridden in settings.xml). >> >>> All the following results are regarding Rampart's 1.5 branch: >>> >>> * Building with the checked-in POM, which uses Axis2 1.5.1, produces the >>> test >>> failures discussed on this thread, which are rooted in a missing method in >>> org.apache.xml.serializer.Encodings. >>> >>> * Building with Axis2 1.5.1 with all the transitive Xalan 2.7.0 dependencies >>> excluded manually and the 2.7.1 dependency added manually (essentially your >>> change above, Andreas) produces a "java.lang.IllegalAccessError: tried to >>> access class org.apache.xml.serializer.ExtendedContentHandler from class >>> org.apache.xalan.transformer.TransformerImpl" when trying to do codegen - >>> for >>> some reason this doesn't stop the build right there, but it fails as soon as >>> the generated code isn't found. >> >> It would probably require the complete list of JARs in the classpath >> to investigate that issue. I guess that since it works with >> 1.5.2-SNAPSHOT, it is not so important to find the explanation. >> >>> * Building with Axis2 1.5.2-SNAPSHOT appears to work fine, and actually >>> works >>> with either r990467 of the Axis2 1.5 branch, or with an AbstractHTTPSender >>> version modified to match r958718 (in other words, with Jarek's original >>> change). Also confirmed that this version avoids the Windows connection >>> starvation issue. >> >> There is one piece of the puzzle missing here. I reread AXIS2-4751 and >> here is what happened: Jarek simultaneously did a change for that >> issue on the trunk (r958696) and on the 1.5 branch (r958718). It was >> actually the change on the trunk that caused failures in Rampart and >> Sandesha. Since the damage to the downstream projects was quite >> massive (and not fixable by adding a call to cleanup to the broken >> test cases), I reverted r958696. Since I was assuming that r958718 was >> just a merge of the change to the branch, I also reverted this one in >> order to keep things synchronized. However, your finding that r958718 >> actually works implies that there is something else out of sync >> between the trunk and the 1.5 branch. Are we sure that the fix for the >> CLOSE_WAIT issue has been applied both to the trunk and the 1.5 >> branch? >> >>> Note that Rampart trunk builds fine for me with 1.5.2-SNAPSHOT, even without >>> Andreas' Xalan-related POM modifications. I guess Xalan 2.7.0 was getting >>> pulled in by Axis2 1.5.1 and not opensaml after all? >> >> Correct. In Axis2 1.5.1, all modules had a dependency on Xalan >> (through the parent POM), while in 1.5.2, the dependency is only >> declared for those modules that really require it. >> >>> Anyway, go back up and reread the summary + apology at the top. :) >>> >>> Thanks, >>> --Glen >>> >>> P.S. On another note, I'm not sure why Rampart depends on both >>> opensaml/opensaml/1.1 and org.opensaml/opensaml/2.2.3... are those not >>> different versions of the same thing? The build fails if you remove either, >>> so I'm wondering what's up there.... >> >> Are Axis and Axis2 two different versions of the same thing? ;-) I >> don't know much about OpenSAML, but I think that version 2 is a >> complete rewrite and uses a different package name. That is also the >> reason why in the Maven central repository, there are two different >> artifact IDs (opensaml1 and opensaml). They can really coexist as >> dependencies of the same project. >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
