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 Sun, 05 Sep 2010 20:24:02 GMT

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.


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