You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2010/09/01 03:00:45 UTC
Re: Build failures in Rampart 1.5?
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. 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.
* 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.
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?
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....
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> 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 <an...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> 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 <an...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> 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 <an...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> 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 <an...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> 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 <an...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
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 <an...@gmail.com> wrote:
> On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: Build failures in Rampart 1.5?
Posted by Andreas Veithen <an...@gmail.com>.
On Wed, Sep 1, 2010 at 03:00, Glen Daniels <gl...@thoughtcraft.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org