You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pb...@apache.org> on 2008/12/01 02:42:53 UTC

Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java

It looks like you are trying 1.4. Did you mean to test that, or 1.3.10?

On Sun, Nov 30, 2008 at 4:26 PM, Martin Cooper <ma...@apache.org> wrote:
> On Sun, Nov 30, 2008 at 1:31 PM, Paul Benedict <pb...@apache.org> wrote:
>
>> See if it is running forever because the unzip failed. You should be
>> able to see the JUnit output even when it is running forever in the
>> target/surefire-reports directory. I did get the same problem you had
>> once, but just once.
>
>
> OK, I've made some progress. Some things I've found out:
>
> 1) The repeated failures to unzip that you saw are because the old download
> is not cleaned up. If the download is interrupted, the partial file is left
> around as if it was the complete download, and subsequent passes through
> that download code skip the download and try to unzip the incomplete file.
> It seems that you have to go and clean out the cargo install directory
> manually to get past this. Once I did this, I got past the download issue
> with *both* 5.5.26 and 5.5.27. FYI, on my machine, the cargo installs
> directory that needs to be cleaned out is:
>
> C:\Documents and Settings\martinc\Local Settings\Temp\cargo\installs
>
> 2) I believe I got into the corrupted zip file mess by interrupting (Ctrl-C)
> the process while it was downloading Tomcat. For whatever reason, the
> download was extremely slow the first time I tried it, and I suspect I just
> gave up too soon, leaving a partial zip file, which was then the cause of
> the subsequent problems.
>
> 3) Somewhere along the line, some Java process or another would not let go
> of the surefire output files, so that I could not delete them even after I
> thought I had got rid of all processes that could be accessing them. I found
> some other Java process in Task Manager and had to kill that manually before
> it would let go of the output files. I don't know what's up with that.
>
> 4) After getting past all of the above, I am seeing 9 test failures, which
> is basically a 404 for each of the application entry points. I'll paste one
> example below, but all 9 errors are the same except for the actual context.
>
> testStrutsBlank(org.apache.struts.apps.AppsTest)  Time elapsed: 0.781 sec
> <<< ERROR!
> com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 404 Not Found
> for http://localhost:8080/struts-blank-1.4.0-SNAPSHOT/
>    at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:347)
>    at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:384)
>    at org.apache.struts.apps.AppsTest.testStrutsBlank(AppsTest.java:71)
>
> For each of these tests, there is also an INFO message, but I don't know if
> this is important or not:
>
> INFO: Redirect requested but followRedirects is disabled
>
> --
> Martin Cooper
>
>
>
>> Paul
>>
>> On Sun, Nov 30, 2008 at 2:20 PM, Martin Cooper <ma...@apache.org> wrote:
>> > On Sat, Nov 29, 2008 at 10:55 PM, Paul Benedict <pbenedict@apache.org
>> >wrote:
>> >
>> >> No, no mirrors being used. This is straight of ibiblio.
>> >
>> >
>> > Hmm. It's not Maven doing the download, it's our code (Tomcat5xTestSetup)
>> > downloading it directly. I tried downloading from the same URL manually,
>> and
>> > both 5.5.26 and 5.5.27 have working zip files, so I don't know why 5.5.27
>> > would not work for you. I tried running the tests myself, but they never
>> > actually get far enough for me to find out. (I get "Running
>> > org.apache.struts.apps.AppsTest", and then it just sits there forever.)
>> >
>> > --
>> > Martin Cooper
>> >
>> >
>> >
>> >> Paul
>> >>
>> >> On Sat, Nov 29, 2008 at 6:15 PM, Martin Cooper <ma...@apache.org>
>> wrote:
>> >> > On Sat, Nov 29, 2008 at 3:27 PM, Paul Benedict <pb...@apache.org>
>> >> wrote:
>> >> >
>> >> >> Maven couldn't download Tomcat. As I said, I tried several times with
>> >> >> 5.5.27, and each time it aborted with a problem with the Zip file.
>> The
>> >> >> error message said "Unexpected end of ZLIB input stream"
>> >> >
>> >> >
>> >> > I don't suppose you happen to be using a Maven proxy, do you? (That
>> is,
>> >> you
>> >> > have a <mirrors> entry in your settings.xml file referencing a Maven
>> >> proxy
>> >> > server.) The reason I ask is that I literally just ran into a problem
>> >> with
>> >> > Archiva handing Maven a corrupted jar even though the original jar is
>> >> fine.
>> >> > I know it's a slim chance that you are hitting the same issue, but if
>> you
>> >> > are, and you have admin access to Archiva, then you can upload the
>> >> artifact
>> >> > manually to get around this.
>> >> >
>> >> > --
>> >> > Martin Cooper
>> >> >
>> >> >
>> >> >
>> >> >> Paul
>> >> >>
>> >> >> On Sat, Nov 29, 2008 at 4:14 PM, Martin Cooper <ma...@apache.org>
>> >> wrote:
>> >> >> > On Fri, Nov 28, 2008 at 9:52 PM, Paul Benedict <
>> pbenedict@apache.org>
>> >> >> wrote:
>> >> >> >
>> >> >> >> Yes. I could put a note in JIRA about it, but 5.5.27 would not
>> >> >> >> download successfully. I tried many times. I could only get 5.5.26
>> to
>> >> >> >> work with cargo. Any tips?
>> >> >> >
>> >> >> >
>> >> >> > Can you elaborate on "would not download"? Do you mean you couldn't
>> >> >> download
>> >> >> > Tomcat, Maven couldn't download Tomcat, Tomcat couldn't download
>> >> >> something?
>> >> >> >
>> >> >> > --
>> >> >> > Martin Cooper
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >> Paul
>> >> >> >>
>> >> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java

Posted by Paul Benedict <pb...@apache.org>.
> With respect to which tree I'm working with, I'm working with whatever
> 'current' includes. If 'current' is not what we are _currently_ releasing
> from, then you may be correct that I am trying 1.4. But that begs the
> question of why we are perpetuating releases on the 1.3 branch when we
> already have work in progress on 1.4, especially when 1.3.8 was GA. Isn't it
> time to move on?
>

Since 1.4 is a very long work in progress, I don't think it benefits
our community by withholding important bug fixes. I use both 1.4 and
1.3 on separate projects, and the soon-to-be-voted 1.3.10 contains
some important fixes.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Re: svn commit: r721644 - in /struts/struts1: branches/STRUTS_1_3_BRANCH/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java trunk/integration/apps-it/src/test/java/org/apache/struts/apps/Tomcat5xTestSetup.java

Posted by Martin Cooper <ma...@apache.org>.
On Sun, Nov 30, 2008 at 5:42 PM, Paul Benedict <pb...@apache.org> wrote:

> It looks like you are trying 1.4. Did you mean to test that, or 1.3.10?


I meant to try to figure out why you were running into problems with using
the latest GA Tomcat release. To that end, I believe I succeeded.

With respect to which tree I'm working with, I'm working with whatever
'current' includes. If 'current' is not what we are _currently_ releasing
from, then you may be correct that I am trying 1.4. But that begs the
question of why we are perpetuating releases on the 1.3 branch when we
already have work in progress on 1.4, especially when 1.3.8 was GA. Isn't it
time to move on?

--
Martin Cooper



>
> On Sun, Nov 30, 2008 at 4:26 PM, Martin Cooper <ma...@apache.org> wrote:
> > On Sun, Nov 30, 2008 at 1:31 PM, Paul Benedict <pb...@apache.org>
> wrote:
> >
> >> See if it is running forever because the unzip failed. You should be
> >> able to see the JUnit output even when it is running forever in the
> >> target/surefire-reports directory. I did get the same problem you had
> >> once, but just once.
> >
> >
> > OK, I've made some progress. Some things I've found out:
> >
> > 1) The repeated failures to unzip that you saw are because the old
> download
> > is not cleaned up. If the download is interrupted, the partial file is
> left
> > around as if it was the complete download, and subsequent passes through
> > that download code skip the download and try to unzip the incomplete
> file.
> > It seems that you have to go and clean out the cargo install directory
> > manually to get past this. Once I did this, I got past the download issue
> > with *both* 5.5.26 and 5.5.27. FYI, on my machine, the cargo installs
> > directory that needs to be cleaned out is:
> >
> > C:\Documents and Settings\martinc\Local Settings\Temp\cargo\installs
> >
> > 2) I believe I got into the corrupted zip file mess by interrupting
> (Ctrl-C)
> > the process while it was downloading Tomcat. For whatever reason, the
> > download was extremely slow the first time I tried it, and I suspect I
> just
> > gave up too soon, leaving a partial zip file, which was then the cause of
> > the subsequent problems.
> >
> > 3) Somewhere along the line, some Java process or another would not let
> go
> > of the surefire output files, so that I could not delete them even after
> I
> > thought I had got rid of all processes that could be accessing them. I
> found
> > some other Java process in Task Manager and had to kill that manually
> before
> > it would let go of the output files. I don't know what's up with that.
> >
> > 4) After getting past all of the above, I am seeing 9 test failures,
> which
> > is basically a 404 for each of the application entry points. I'll paste
> one
> > example below, but all 9 errors are the same except for the actual
> context.
> >
> > testStrutsBlank(org.apache.struts.apps.AppsTest)  Time elapsed: 0.781 sec
> > <<< ERROR!
> > com.gargoylesoftware.htmlunit.FailingHttpStatusCodeException: 404 Not
> Found
> > for http://localhost:8080/struts-blank-1.4.0-SNAPSHOT/
> >    at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:347)
> >    at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:384)
> >    at org.apache.struts.apps.AppsTest.testStrutsBlank(AppsTest.java:71)
> >
> > For each of these tests, there is also an INFO message, but I don't know
> if
> > this is important or not:
> >
> > INFO: Redirect requested but followRedirects is disabled
> >
> > --
> > Martin Cooper
> >
> >
> >
> >> Paul
> >>
> >> On Sun, Nov 30, 2008 at 2:20 PM, Martin Cooper <ma...@apache.org>
> wrote:
> >> > On Sat, Nov 29, 2008 at 10:55 PM, Paul Benedict <pbenedict@apache.org
> >> >wrote:
> >> >
> >> >> No, no mirrors being used. This is straight of ibiblio.
> >> >
> >> >
> >> > Hmm. It's not Maven doing the download, it's our code
> (Tomcat5xTestSetup)
> >> > downloading it directly. I tried downloading from the same URL
> manually,
> >> and
> >> > both 5.5.26 and 5.5.27 have working zip files, so I don't know why
> 5.5.27
> >> > would not work for you. I tried running the tests myself, but they
> never
> >> > actually get far enough for me to find out. (I get "Running
> >> > org.apache.struts.apps.AppsTest", and then it just sits there
> forever.)
> >> >
> >> > --
> >> > Martin Cooper
> >> >
> >> >
> >> >
> >> >> Paul
> >> >>
> >> >> On Sat, Nov 29, 2008 at 6:15 PM, Martin Cooper <ma...@apache.org>
> >> wrote:
> >> >> > On Sat, Nov 29, 2008 at 3:27 PM, Paul Benedict <
> pbenedict@apache.org>
> >> >> wrote:
> >> >> >
> >> >> >> Maven couldn't download Tomcat. As I said, I tried several times
> with
> >> >> >> 5.5.27, and each time it aborted with a problem with the Zip file.
> >> The
> >> >> >> error message said "Unexpected end of ZLIB input stream"
> >> >> >
> >> >> >
> >> >> > I don't suppose you happen to be using a Maven proxy, do you? (That
> >> is,
> >> >> you
> >> >> > have a <mirrors> entry in your settings.xml file referencing a
> Maven
> >> >> proxy
> >> >> > server.) The reason I ask is that I literally just ran into a
> problem
> >> >> with
> >> >> > Archiva handing Maven a corrupted jar even though the original jar
> is
> >> >> fine.
> >> >> > I know it's a slim chance that you are hitting the same issue, but
> if
> >> you
> >> >> > are, and you have admin access to Archiva, then you can upload the
> >> >> artifact
> >> >> > manually to get around this.
> >> >> >
> >> >> > --
> >> >> > Martin Cooper
> >> >> >
> >> >> >
> >> >> >
> >> >> >> Paul
> >> >> >>
> >> >> >> On Sat, Nov 29, 2008 at 4:14 PM, Martin Cooper <
> martinc@apache.org>
> >> >> wrote:
> >> >> >> > On Fri, Nov 28, 2008 at 9:52 PM, Paul Benedict <
> >> pbenedict@apache.org>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> Yes. I could put a note in JIRA about it, but 5.5.27 would not
> >> >> >> >> download successfully. I tried many times. I could only get
> 5.5.26
> >> to
> >> >> >> >> work with cargo. Any tips?
> >> >> >> >
> >> >> >> >
> >> >> >> > Can you elaborate on "would not download"? Do you mean you
> couldn't
> >> >> >> download
> >> >> >> > Tomcat, Maven couldn't download Tomcat, Tomcat couldn't download
> >> >> >> something?
> >> >> >> >
> >> >> >> > --
> >> >> >> > Martin Cooper
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >> Paul
> >> >> >> >>
> >> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>