You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jeff Tulley <JT...@novell.com> on 2003/04/03 19:50:47 UTC

[Patch] Coyote losing parameters across form login (was Re: Connector issues)

here is the code, please review
3 of them are patches for existing source code.  test.zip (.txt, I
couldn't remember if the mailing list strips off zip files) is a new
junit TestCase to test my stuff in Parameters.java.  I propose that be
put in j-t-c/util/test, unless there is a better place.  I don't know if
there is a better way to submit a new directory via CVS since I cannot
"diff -u" it.

CoyoteRequest.java and Request.java fixes are very straightforward,
just doing the same sort of thing that is done in the rest of the code. 
Parameters.java is where I took an already existing (private) method,
made a copy of it, renamed and made the copy public, and then adapted it
to work with multi-valued parameters.

This seems to do the job correctly.

Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

>>> cmanolache@yahoo.com 4/2/03 8:57:09 PM >>>
Sorry for the delay.

IMO the right solution is to fix #10229 for coyote.

There are a lot of problems in the old connectors - even if mod_jk2
is not yet as stable as mod_jk1, the java side and coyote are far 
better than the old impl.

I'm +0 on fixing the MBean exception - AFAIK upgrading commons-modeler
should fix most of the problems with undeclared mbeans. The real
problem
is that the Ajp13Connector has a lot of problems and it's no longer
supported - all work is on the coyote connector, I don't know anyone
testing or supporting Ajp13.

Costin


Jeff Tulley wrote:

> There are some real problems with the Coyote Connectors right now.
> The main problem biting me (and a few others recently) is bugzilla
bug
> # 10229 - form parameters not being preserved across a login
> redirection.
> The answer given on the user list (by me also) is typically, "Use an
> non-Coyote connector".  Unfortunately that is not a good answer.
> If they move back to the deprecated AJP13Connector, they will
> experience MBean exceptions that, among other things, make the
Tomcat
> shutdown not function correctly.
> Beyond that they are stuck with not using a webserver plugin and
> instead going directly to an HTTP connector (non-Coyote).
> 
> I would propose two things:
> 1) Fix the MBean exception in the Ajp13Connector.  I can provide a
> patch for this, it is very simple.  Even though this is deprecated,
the
> reality is that people might need to use it due to bugs and/or
> unimplemented features in the Coyote connectors.  It may be their
only
> choice, and if we can make it work easily, why not?
> 2) Fix this form authentication problem in the Coyote connector.  I
> will look into this and see if it is something that I can do and
submit
> a patch for.
> 
> I actually have similar issues with the native side connector story
but
> that is for another day.
> 
> Anybody know off hand what needs to happen for item #2 above?
> 
> Jeff Tulley  (jtulley@novell.com)
> (801)861-5322
> Novell, Inc., The Leading Provider of Net Business Solutions
> http://www.novell.com 



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


Re: [Patch] Coyote losing parameters across form login (was Re: Connector issues)

Posted by Remy Maucherat <re...@apache.org>.
Jeff Tulley wrote:
> here is the code, please review
> 3 of them are patches for existing source code.  test.zip (.txt, I
> couldn't remember if the mailing list strips off zip files) is a new
> junit TestCase to test my stuff in Parameters.java.  I propose that be
> put in j-t-c/util/test, unless there is a better place.  I don't know if
> there is a better way to submit a new directory via CVS since I cannot
> "diff -u" it.
> 
> CoyoteRequest.java and Request.java fixes are very straightforward,
> just doing the same sort of thing that is done in the rest of the code. 
> Parameters.java is where I took an already existing (private) method,
> made a copy of it, renamed and made the copy public, and then adapted it
> to work with multi-valued parameters.
> 
> This seems to do the job correctly.

The attachement doesn't work for me.

Remy


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