axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <>
Subject Re: Build failures in Rampart 1.5?
Date Mon, 06 Sep 2010 18:13:33 GMT

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.


On Sun, Sep 5, 2010 at 22:24, Andreas Veithen <> 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 <> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <> 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 repository problem, no Maven build depending
>> on Axis2 <= 1.5.1 will give predictable results (unless the definition
>> of the 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:
For additional commands, e-mail:

View raw message