You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/04/17 15:01:27 UTC
Test build for Tomcat 4.next available
Many components have been rewritten for the next release of Tomcat,
including Jasper (this new version is called Jasper 2).
Jasper 2 is not currently included in the nightly builds (the old Japser
is), so I have packaged a CVS build which includes it.
Jasper 2 passes Watchdog, and is able to run a Struts based webapp (the
admin webapp of Tomcat), but otherwise needs some real-world testing.
The build (which can be considered alpha quality) can be downloaded at:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/test1/
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Test build for Tomcat 4.next available
Posted by Remy Maucherat <re...@apache.org>.
> On Thu, 18 Apr 2002, Remy Maucherat wrote:
>
> > What is the problem with "4.1" ? The differences with 4.0 should be
minimal.
> > If it's a mapping bug, one difference is that the protocol handler has
to
> > fill out the decodedURI field of the request. Since it's part of the
HTTP
> > and URI specs, I moved it in the protocol handler.
> > If it's a problem for you, I can move the code back in the adapter.
>
> Well, it's not a problem if I know about it :-)
> Thanks, I'll change that and see if it works.
I already moved the decoding code back in the adapter. It doesn't make any
difference and there's no reason to force the protocol handler to do that.
Try it and let me know if it works.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Test build for Tomcat 4.next available
Posted by co...@covalent.net.
On Thu, 18 Apr 2002, Remy Maucherat wrote:
> What is the problem with "4.1" ? The differences with 4.0 should be minimal.
> If it's a mapping bug, one difference is that the protocol handler has to
> fill out the decodedURI field of the request. Since it's part of the HTTP
> and URI specs, I moved it in the protocol handler.
> If it's a problem for you, I can move the code back in the adapter.
Well, it's not a problem if I know about it :-)
Thanks, I'll change that and see if it works.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Test build for Tomcat 4.next available
Posted by Remy Maucherat <re...@apache.org>.
> On Wed, 17 Apr 2002, Remy Maucherat wrote:
>
> > The build (which can be considered alpha quality) can be downloaded at:
> > http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/test1/
>
> Hi Remy - something is strange in coyote/jk2 - I get:
> "No Context configured to process this request"
>
> Everything is fine with 4.0.
>
> BTW, curently coyote-jk2 is using jk2.properties for 'advanced' config,
> the one in j-t-c/jk/config should work fine ( but you may have to
> remove some of the channels )
What is the problem with "4.1" ? The differences with 4.0 should be minimal.
If it's a mapping bug, one difference is that the protocol handler has to
fill out the decodedURI field of the request. Since it's part of the HTTP
and URI specs, I moved it in the protocol handler.
If it's a problem for you, I can move the code back in the adapter.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Test build for Tomcat 4.next available
Posted by co...@covalent.net.
On Wed, 17 Apr 2002, Remy Maucherat wrote:
> The build (which can be considered alpha quality) can be downloaded at:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/nightly/test1/
Hi Remy - something is strange in coyote/jk2 - I get:
"No Context configured to process this request"
Everything is fine with 4.0.
BTW, curently coyote-jk2 is using jk2.properties for 'advanced' config,
the one in j-t-c/jk/config should work fine ( but you may have to
remove some of the channels )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>