Re: Tomcat Sessions problem

[Remy Maucherat]

Cristina Lopez wrote:
Hello,

My name is Christina and I am developing to an application Web in Java with
Tomcat 4.1 under Linux for my company. For days I have been detecting a
mistake on the sessions in Tomcat. I detect that when there is connected one
more user simultaneously, a user could see information of session of another
user. This application can have between 50 and 300 people connected at the
same moment. 

I have investigated about it seeing the plans that Tomcat generates, and I
see that it generates the new session for each user well that is connected
but at the time of adding to the session the data of the user, Tomcat it
takes the last session created and it is there adding to all the values of
session of all the users, replacing those values by so many users connected
then. This way, the data of the user correspond to another user.
To that it must? Has Tomcat bug of sessions? I have read in forums of
Internet that is a subject common in Tomcat. It would be thankful to them
put an article in Jakarta page of the problem and like solving it.
I do not understand this message. Please try to use shorter sentences, 
it's easier.

You should be using TC 4.1.24+ to avoid a race condition problem in the 
session recycling code, which could cause what you apparently see.

Remy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat Sessions problem

[Cristina Lopez]

Hello,

 

My name is Christina and I am developing to an application Web in Java with
Tomcat 4.1 under Linux for my company. For days I have been detecting a
mistake on the sessions in Tomcat. I detect that when there is connected one
more user simultaneously, a user could see information of session of another
user. This application can have between 50 and 300 people connected at the
same moment. 

 

I have investigated about it seeing the plans that Tomcat generates, and I
see that it generates the new session for each user well that is connected
but at the time of adding to the session the data of the user, Tomcat it
takes the last session created and it is there adding to all the values of
session of all the users, replacing those values by so many users connected
then. This way, the data of the user correspond to another user.

 

To that it must? Has Tomcat bug of sessions? I have read in forums of
Internet that is a subject common in Tomcat. It would be thankful to them
put an article in Jakarta page of the problem and like solving it.

 

Thank you very much for your help,

 

Christina.

 

 

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters BufferedInputFilter.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

luehe   2003/10/17 11:45:40

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java
  Added:   http11/src/java/org/apache/coyote/http11/filters
BufferedInputFilter.java
  Log:
  In case the server needs to reinitiate SSL handshake (with client auth
  enabled), consume request body and buffer it, so that it does not
  interfere with client's handshake messages.
  
  Many thanks to Bill Barker for helping me with this!
This patch is sort of rocket science, but seems good :)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Doubt

[erlis]

When you want you use a bean you need to specify only the package name
in the class attribute, in your case example.WEB_INF.classes wasn't your
package name you should try with UserInfoBean if that bean have no
package...  ()

In the case your bean was in a package like com.company.Bean you then
specify that package structure like this


Sincerely
Erlis Vidal Santos

> -Original Message-
> From: PUTHAMODOM, RAJESH [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 17, 2003 9:26 AM
> To: '[EMAIL PROTECTED]'
> Subject: Doubt
> 
> Hi
> 
> 
> I have developed a JSP Page, HTML and a Bean. I have put the JSP Page
in
> the
> C:\jakarta-tomcat-4.1.27\jakarta-tomcat-4.1.27\webapps\examples
Directory
> and the HTML in the same dir. I have put the Bean class in
> C:\jakarta-tomcat-4.1.27\jakarta-tomcat-4.1.27\webapps\examples\WEB-
> INF\clas
> ses directory.
> 
> 
> I MY bean , the Path is like this package examples.WEB_INF.classes;
> 
> and In mY JSP
> 
> 
> 
> 
> But it does not find the Class. Please let me know how do i do?
> 
> Thanks
> 
> Rajesh
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Doubt

[PUTHAMODOM, RAJESH]

Hi


I have developed a JSP Page, HTML and a Bean. I have put the JSP Page in the
C:\jakarta-tomcat-4.1.27\jakarta-tomcat-4.1.27\webapps\examples Directory
and the HTML in the same dir. I have put the Bean class in
C:\jakarta-tomcat-4.1.27\jakarta-tomcat-4.1.27\webapps\examples\WEB-INF\clas
ses directory.


I MY bean , the Path is like this package examples.WEB_INF.classes;

and In mY JSP 




But it does not find the Class. Please let me know how do i do?

Thanks

Rajesh



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jk2 evolution plan

[Glenn Nielsen]

+1

I can help out.

This is a significant change for a minor revision to 2.0.4,
perhaps we should bump it to 2.1 or even 3.0?
Glenn

Henri Gomez wrote:
Ok, about everybody seems to agree on using apr for jk2
(still waiting Nacho for IIS).
APR side will be to :

- Update doc to indicate that APR is mandatory

- Remove #idef APR

- Use APR for all OS operation and sus will save us from
  handling all the #include for all the diverses IO operation
  (it's really a pain).
- For now still use_jk pool, but the version using apr_tools.

- Make socket use apr_socket for compatibility.

JK to JK2 fonctionnalities backport :

- Check features added in jk and not present in jk2 (ie cping/cpong).
  There was also some specific lb workers settings which should be
  studied.
- After this works, make a 2.0.4 release and start extensive
  testing.
On the channel side I added a new method, hasinput which should help
use determine if there is something to do on 'stream connections'.
For instance, it's used in jk/jk2 by the cping/cpong stage when
connectTimeout, prepostTimeout and replyTimeout are set.
And no the who's who ;)

I'd like to know who could works on jk2 evolution.

BTW, where could we find today the jk/jk2 documentation which is
regenerated each day  ?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java

[luehe]

luehe   2003/10/17 11:47:43

  Modified:catalina/src/share/org/apache/catalina/authenticator
SSLAuthenticator.java
  Log:
  In case the server needs to reinitiate SSL handshake (with client auth
  enabled), consume request body and buffer it, so that it does not
  interfere with client's handshake messages.
  
  Many thanks to Bill Barker for helping me with this!
  
  Revision  ChangesPath
  1.9   +4 -11 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java
  
  Index: SSLAuthenticator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- SSLAuthenticator.java 2 Sep 2003 21:22:04 -   1.8
  +++ SSLAuthenticator.java 17 Oct 2003 18:47:43 -  1.9
  @@ -147,13 +147,6 @@
   if (debug >= 1)
   log(" Looking up certificates");
   
  -if ("POST".equalsIgnoreCase(((HttpServletRequest) 
request.getRequest()).getMethod())) {
  -// Causes POST of  application/x-www-form-urlencoded to be read,
  -// removing data from socket so that a cert exchange can happen if 
needed.
  -// A more general solution for all POSTs is coming 01-Nov-2002 bobh
  -((HttpServletRequest) request.getRequest()).getParameterMap();
  -}
  -
   X509Certificate certs[] = (X509Certificate[])
   request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
   if ((certs == null) || (certs.length < 1)) {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters BufferedInputFilter.java

[luehe]

luehe   2003/10/17 11:45:40

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java
  Added:   http11/src/java/org/apache/coyote/http11/filters
BufferedInputFilter.java
  Log:
  In case the server needs to reinitiate SSL handshake (with client auth
  enabled), consume request body and buffer it, so that it does not
  interfere with client's handshake messages.
  
  Many thanks to Bill Barker for helping me with this!
  
  Revision  ChangesPath
  1.21  +8 -2  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Constants.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- Constants.java6 Oct 2003 08:46:04 -   1.20
  +++ Constants.java17 Oct 2003 18:45:40 -  1.21
  @@ -201,7 +201,7 @@
   
   
   /**
  - * Indetity filters (input and output).
  + * Identity filters (input and output).
*/
   public static final int IDENTITY_FILTER = 0;
   
  @@ -219,9 +219,15 @@
   
   
   /**
  - * GZIP filters (input and output).
  + * GZIP filter (output).
*/
   public static final int GZIP_FILTER = 3;
  +
  +
  +/**
  + * Buffered filter (input)
  + */
  +public static final int BUFFERED_FILTER = 3;
   
   
   /**
  
  
  
  1.84  +12 -1 
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.83
  retrieving revision 1.84
  diff -u -r1.83 -r1.84
  --- Http11Processor.java  14 Oct 2003 21:35:21 -  1.83
  +++ Http11Processor.java  17 Oct 2003 18:45:40 -  1.84
  @@ -81,6 +81,7 @@
   import org.apache.coyote.http11.filters.IdentityOutputFilter;
   import org.apache.coyote.http11.filters.VoidInputFilter;
   import org.apache.coyote.http11.filters.VoidOutputFilter;
  +import org.apache.coyote.http11.filters.BufferedInputFilter;
   import org.apache.regexp.RE;
   import org.apache.regexp.RESyntaxException;
   import org.apache.tomcat.util.buf.Ascii;
  @@ -997,7 +998,14 @@
   request.localAddr().setString(localAddr);
   
   } else if (actionCode == ActionCode.ACTION_REQ_SSL_CERTIFICATE) {
  -if( sslSupport != null) { 
  +if( sslSupport != null) {
  +/*
  + * Consume and buffer the request body, so that it does not
  + * interfere with the client's handshake messages
  + */
  +InputFilter[] inputFilters = inputBuffer.getFilters();
  +inputBuffer.addActiveFilter
  +(inputFilters[Constants.BUFFERED_FILTER]);
   try {
   Object sslO = sslSupport.getPeerCertificateChain(true);
   if( sslO != null) {
  @@ -1478,6 +1486,9 @@
   // Create and add the void filters.
   inputBuffer.addFilter(new VoidInputFilter());
   outputBuffer.addFilter(new VoidOutputFilter());
  +
  +// Create and add buffered input filter
  +inputBuffer.addFilter(new BufferedInputFilter());
   
   // Create and add the chunked filters.
   //inputBuffer.addFilter(new GzipInputFilter());
  
  
  
  1.1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/BufferedInputFilter.java
  
  Index: BufferedInputFilter.java
  ===
  /*
   * 
   * 
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this 

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 18:19 ---
OK I'll take your word for it. I'll log this at bugzilla.mozilla.org and let
them think about it. 

Thanks for the information. 

Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23898] New: - Tag doesn't get reused by the TagPool if the tag returns SKIP_PAGE

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23898

Tag doesn't get reused by the TagPool if the tag returns SKIP_PAGE

   Summary: Tag doesn't get reused by the TagPool if the tag returns
SKIP_PAGE
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If tag pool is enabled and the tag returns SKIP_PAGE at the end of doEndTag 
return is called immediately which doesn't give a chance for reuse to be 
called. 
i am not sure about how the other tags on the same page would perform in a 
situation like this.
Also if doEndTag throws an exception there is no way for the reuse to be 
called.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 18:08 ---
No, it's a Mozilla bug: Tomcat doesn't include a if-modified-since, and it is a
secure connection, so it is wrong to cache this. BTW, if this is not a secure
connection, Tomcat should set the appropriate cache control headers.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 17:58 ---
Yes that is the problem. I've been tricked by the cache again. Caching is the
one of my biggest sources of wasted time in looking for bugs that aren't there. 

In the upgrade from TC4 to TC5, the URL of the FORM-based login page is hidden,
so I am not surprised by Mozilla's behaviour. I do not think Mozilla is buggy -
it is more likely a feature. :)

I was also caught out because I am using struts so much and the struts servlet
puts the non-cache headers in automatically if you configure it to do so.
Obviously these are not going to be taken care of in the HTML login page. 

So a refresh is all that is required. Or for anyone else reading this
afterwards, the following headers in the HTML (where the expiry date is in the
past) (check the source HTML if you can't see this):





Adasm

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23895] - JspC ant task can't compile JSPs not ending in .jsp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23895

JspC ant task can't compile JSPs not ending in .jsp





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 17:37 ---
i have not read the spec, so i can't comment that. but in tomcat, you can set a
different extension for JSPs by remapping the jsp servlet to that extension in
the web.xml file.

given that you can have different extensions for JSPs, i don't see how this
change is non-portable, regardless of what the spec says.

and with JspC, you can compile JSPs that don't end in .jsp, you just can't do it
easily through ant. which is what this small patch attempts to fix.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23895] - JspC ant task can't compile JSPs not ending in .jsp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23895

JspC ant task can't compile JSPs not ending in .jsp

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 17:15 ---
The assumption that all JSP pages have .jsp suffices is guaranteed by the spec. 
The proposed extension is non-portable.  How can you tell the container that
those pages are JSP pages if they are not precompiled by JSPC?

Note that in Tomcat 5, you can specify any page as being a JSP page by the use
of jsp-config element in web.xml.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23895] - JspC ant task can't compile JSPs not ending in .jsp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23895

JspC ant task can't compile JSPs not ending in .jsp





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 16:59 ---
the patch adds a setExtension(String) method to JspC, so in ant you can add an
attribute "extension" to the jasper2 task, specifying the file extension of your
JSPs.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23895] - JspC ant task can't compile JSPs not ending in .jsp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23895

JspC ant task can't compile JSPs not ending in .jsp





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 16:57 ---
Created an attachment (id=8610)
add setter method for extensions

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Remy Maucherat]

Craig R. McClanahan wrote:

Remy Maucherat wrote:

Hi,

I'd like to make a small proposal to do property replacement. Included 
are changes that should be made in the digester, and that I'll post on 
commons-dev if I have approval.

- Add a get/setProperty to Container. This would allow a property 
inheritance across containers, similar to Tomcat 3.3 features as 
described by Bill.

- Add the two introspectionUtil replaceProperties methods to the 
digester, along with a way to set the array of PropertySource globally 
for a digester instance. The replaceProperties will be called 
automagically if the standard set properties rule is added to an 
element, and will check all attributes for possible property replacement.
This sounds like a good addition to Digester.  I would prefer to also 
have replacement enabled by a boolean property on the Digester instance 
(default=false), so that we don't mess up people using Digester to parse 
things that happen to have "${ ... }" in the attribute values or element 
bodies.
I was thinking about that. This sounds reasonable.

- Additionally, we could add the "set all properties" rule to 
digester, which would attempt to call a setProperty method on an 
object to set properties which have no designated setter. I'm mixed on 
this: we need something like that for the Connector, but this is a 
very specific situation, and may be abused in the general case.
I'm dubious on this one as well, but will look at the details of what 
you'd propose.
I think I'll forget about it in the general case.

- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)
Agree that this code is about as hackish as you can get, but at least it 
sorta worked :-).
Yes, it worked good :) I added more hacks myself in there to make the 
saved XML look a bit less nasty :)
Scary code :-D

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Craig R. McClanahan]

Remy Maucherat wrote:

Hi,

I'd like to make a small proposal to do property replacement. Included 
are changes that should be made in the digester, and that I'll post on 
commons-dev if I have approval.

- Add a get/setProperty to Container. This would allow a property 
inheritance across containers, similar to Tomcat 3.3 features as 
described by Bill.

- Add the two introspectionUtil replaceProperties methods to the 
digester, along with a way to set the array of PropertySource globally 
for a digester instance. The replaceProperties will be called 
automagically if the standard set properties rule is added to an 
element, and will check all attributes for possible property replacement.


This sounds like a good addition to Digester.  I would prefer to also 
have replacement enabled by a boolean property on the Digester instance 
(default=false), so that we don't mess up people using Digester to parse 
things that happen to have "${ ... }" in the attribute values or element 
bodies.

- Additionally, we could add the "set all properties" rule to 
digester, which would attempt to call a setProperty method on an 
object to set properties which have no designated setter. I'm mixed on 
this: we need something like that for the Connector, but this is a 
very specific situation, and may be abused in the general case.
I'm dubious on this one as well, but will look at the details of what 
you'd propose.

- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)
Agree that this code is about as hackish as you can get, but at least it 
sorta worked :-).

Comments ?

Remy
Craig



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392

When tag pooling is enabled, release() is not called on tag instances

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 16:44 ---
Please refer to Craig's comments.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 13392] - When tag pooling is enabled, release() is not called on tag instances

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13392

When tag pooling is enabled, release() is not called on tag instances

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 16:35 ---
According to the specification the release method should be called before the 
tag is garbage collected. But the truth is when a programmer writes the code 
for a tag, he/she is expecting that it will be garbage collected at the end of 
the page. The tag pooling disable this behaviour which puts everybody in a 
tight spot. Still all tag handlers including the JSTL doesn't release the 
resources after they are done with them. I reviewed the guidlines posted on 
jakarta for creating tag library. But here is an example for your Remy, I have 
a page that uploads a file and creates a huge number of objects to be inserted 
into the database, it is like Access mapping of fields feature. At the end of 
the page with TagLibraries I am left with 20 MB of ram held in memory because 
both Struts Iterator tag and JSTL ForEachTag doesn't set the items collection 
to null until the release. Now i have to wait for the next iteration for this 
page to be called and still I will end up with 20 MB in memory. According to 
the guidelines these 20MB will never be released or garbage collected because 
the initial state of the tag will only be reinitialized in the doStartTag. 

I think there were too much discussion about this issue and I think 
practically every tag developer expects the release to be called at the end of 
the page. Disabling Tag Pooling is not an option for precompiled pages because 
JSPC Ant Task implementation returns a hardcoded true for the isPooling 
method. So now where can somebody go to fix this issue.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23895] New: - JspC ant task can't compile JSPs not ending in .jsp

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23895

JspC ant task can't compile JSPs not ending in .jsp

   Summary: JspC ant task can't compile JSPs not ending in .jsp
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Given a web app, whose location is set by uriroot, JspC will assume that all
JSPs are files ending in .jsp

there doesn't seem to be anyway in ant to change this behavior.

i have an extremely simple patch that exposes the extensions Vector to ant, so
you can set the extension.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23518] - Strange Perfomance Issue, tomcat slowes down my code by factor more than 10

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23518

Strange Perfomance Issue, tomcat slowes down my code by factor more than 10

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 16:10 ---
Was my failt. But it was such a strange issue, and I was surprised, nobody had 
recognized it before. Thought maybe I'm the only java user on earth ;(

So, to close this issue:
My fault was to symlink all the jboss-client-jars to my WEB-INF/lib-directory, 
but when I copy them to $TOMCAT_HOME/shared/lib/ instead, it works! :)
And the speed is like jetty.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Florent BENOIT]

   Hi,

I thought that when you said "in a non hackish and flexible fashion" it 
will for delegating the save-to-xml feature to an helper class and that 
I can contribute to this task.
Maybe I have misunderstand your sentence and I apologize. So I will let 
my patched class as I have no other choice.

Regards,

Florent

Remy Maucherat wrote:

Florent BENOIT wrote:

Henri Gomez wrote:
   Hello,
As I had already said in a previous mail, I'm interesting in the 
customisation of the save-to-XML feature. If it can be more flexible 
in order to specify our own save instead of supplying a patched 
StandardServer class (We can not extend extended the class as it's a 
final class. And I understand that it's can be a final class)

So, maybe I can contribute on a helper class, but I have some questions.
The helper class will be for the method storeConfig() or for 
storeServer() ? Because the name of the config file will remain the 
same name in the same place.
But it's true that the helper class must allow the best flexibility 
so maybe it would be for storeConfig.

So, the Helper class can be on the form StoreConfigHelper with a 
constructor which take a Server Object.
The storeConfig() method of StandardServer will call : 
storeConfigHelper.store(server)
All the stuff concerning exceptions, persistables, skippables could 
be in this helper class. Or it can be arguments for the constructor 
of the helper class.
StandardServer will also have a method for setting the helper class.
So there is a need of an interface. My next question is : Can we 
authorize the default StoreConfigHelper class to be extended and by 
allowing the fact that storeListener, storeContext, etc will be 
protected and not private.
Or if we have only choice by implementing a class of the 
StoreConfigHelper interface.

My last question is about the name and the package of these classes.
The helper class must go on the util package or stay in the core 
package.
The interface must go on root package where there are a lot of 
interfaces ?
Do you have advice for the name of these classes or architecture for 
this helper class.

I'm very interesting by having an helper class for customize the 
save-to-xml without having to patch StandardServer class
Regards,


To which I replied that I'm against hacking any more on the shaky code 
we have, which is *bad*.

I didn't change my mind, and I didn't forget about your previous posts 
wither. No need to post again verbatim, IMO.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Tim Funk]

If the admin is using the properties functionality, will they also be using 
the admin webapp to make config changes? (I think not)

-Tim

Remy Maucherat wrote:

Hi,
- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Benchmarking gcj-built Tomcat

[Gary Benson]

Costin Manolache wrote:
> My benchmarks ( > 1 yr ago ) showed GCJ-based tomcat to be as fast
> as the IBM JDK1.3 ( the fastest VM at that time ). There were small
> differences under different loads - but the garbage collector seemed
> like the biggest factor ( GCJ performed worse on JSP pages where
> more objects were created if I remember correctly ).

Do you still have the benchmark code around?  I'd love to see it...

> The amazing thing was the startup time - almost 0 ( it felt more
> like apache :-).

It does start up fast :)  The compiler we're using has a funky
experimental optimiser (the same as used in the fast free eclipse
project), and the startup became perhaps twice as fast when I switched
from gcj 3.3.  It compiles JSPs pretty fast too.  That's one reason
why I'd like to benchmark it.

> BTW - GCJ is not a virtual machine and doesn't have a JIT - it is a
> ahead-of-time compiler, just like C and C++ compilers.

This may have been true a while back, but it isn't now -- gcj can
interpret bytecode just like any other JVM.  In my Tomcat package this
is exactly what it does when executing servlets (everything else is
built to native code).  You're right in that doesn't have a JIT
though.

> The biggest problem at that time was dynamic class loading. GCJ has
> a small interpretor and could load servlets - but the difference in
> performance between precompiled code and interpretor was
> significant.

It probably still is, though not as bad.  But it's not such a big
problem as it seems, as most of the calls that a given servlet makes
will be to native-compiled methods.

Gary

[ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Remy Maucherat]

Florent BENOIT wrote:
Henri Gomez wrote:
   Hello,
As I had already said in a previous mail, I'm interesting in the 
customisation of the save-to-XML feature. If it can be more flexible in 
order to specify our own save instead of supplying a patched 
StandardServer class (We can not extend extended the class as it's a 
final class. And I understand that it's can be a final class)

So, maybe I can contribute on a helper class, but I have some questions.
The helper class will be for the method storeConfig() or for 
storeServer() ? Because the name of the config file will remain the same 
name in the same place.
But it's true that the helper class must allow the best flexibility so 
maybe it would be for storeConfig.

So, the Helper class can be on the form StoreConfigHelper with a 
constructor which take a Server Object.
The storeConfig() method of StandardServer will call : 
storeConfigHelper.store(server)
All the stuff concerning exceptions, persistables, skippables could be 
in this helper class. Or it can be arguments for the constructor of the 
helper class.
StandardServer will also have a method for setting the helper class.
So there is a need of an interface. My next question is : Can we 
authorize the default StoreConfigHelper class to be extended and by 
allowing the fact that storeListener, storeContext, etc will be 
protected and not private.
Or if we have only choice by implementing a class of the 
StoreConfigHelper interface.

My last question is about the name and the package of these classes.
The helper class must go on the util package or stay in the core package.
The interface must go on root package where there are a lot of interfaces ?
Do you have advice for the name of these classes or architecture for 
this helper class.

I'm very interesting by having an helper class for customize the 
save-to-xml without having to patch StandardServer class
Regards,
To which I replied that I'm against hacking any more on the shaky code 
we have, which is *bad*.

I didn't change my mind, and I didn't forget about your previous posts 
wither. No need to post again verbatim, IMO.

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Florent BENOIT]

Henri Gomez wrote:

Remy Maucherat wrote:

Hi,

I'd like to make a small proposal to do property replacement. 
Included are changes that should be made in the digester, and that 
I'll post on commons-dev if I have approval.

- Add a get/setProperty to Container. This would allow a property 
inheritance across containers, similar to Tomcat 3.3 features as 
described by Bill.

- Add the two introspectionUtil replaceProperties methods to the 
digester, along with a way to set the array of PropertySource 
globally for a digester instance. The replaceProperties will be 
called automagically if the standard set properties rule is added to 
an element, and will check all attributes for possible property 
replacement.

- Additionally, we could add the "set all properties" rule to 
digester, which would attempt to call a setProperty method on an 
object to set properties which have no designated setter. I'm mixed 
on this: we need something like that for the Connector, but this is a 
very specific situation, and may be abused in the general case.

- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)

+1

The save could be implemented by saving all the discovered properties
to an another xml file which will be load at next start time ?
   Hello,

As I had already said in a previous mail, I'm interesting in the 
customisation of the save-to-XML feature. If it can be more flexible in 
order to specify our own save instead of supplying a patched 
StandardServer class (We can not extend extended the class as it's a 
final class. And I understand that it's can be a final class)

So, maybe I can contribute on a helper class, but I have some questions.
The helper class will be for the method storeConfig() or for 
storeServer() ? Because the name of the config file will remain the same 
name in the same place.
But it's true that the helper class must allow the best flexibility so 
maybe it would be for storeConfig.

So, the Helper class can be on the form StoreConfigHelper with a 
constructor which take a Server Object.
The storeConfig() method of StandardServer will call : 
storeConfigHelper.store(server)
All the stuff concerning exceptions, persistables, skippables could be 
in this helper class. Or it can be arguments for the constructor of the 
helper class.
StandardServer will also have a method for setting the helper class.
So there is a need of an interface. My next question is : Can we 
authorize the default StoreConfigHelper class to be extended and by 
allowing the fact that storeListener, storeContext, etc will be 
protected and not private.
Or if we have only choice by implementing a class of the 
StoreConfigHelper interface.

My last question is about the name and the package of these classes.
The helper class must go on the util package or stay in the core package.
The interface must go on root package where there are a lot of interfaces ?
Do you have advice for the name of these classes or architecture for 
this helper class.

I'm very interesting by having an helper class for customize the 
save-to-xml without having to patch StandardServer class
Regards,

Florent

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Remy Maucherat]

Henri Gomez wrote:
+1

The save could be implemented by saving all the discovered properties
to an another xml file which will be load at next start time ?
That won't work: the save-to-XML blindly introspects the objects and 
saves the results.

Actually, I think we have found a neat feature addition for Tomcat.next: 
abstract the configuration storage and make it R/W. JNDI DirContext 
could be the API, but it's not a perfect fit (we'd need a naming scheme).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [5.0] Property replacement

[Henri Gomez]

Remy Maucherat wrote:

Hi,

I'd like to make a small proposal to do property replacement. Included 
are changes that should be made in the digester, and that I'll post on 
commons-dev if I have approval.

- Add a get/setProperty to Container. This would allow a property 
inheritance across containers, similar to Tomcat 3.3 features as 
described by Bill.

- Add the two introspectionUtil replaceProperties methods to the 
digester, along with a way to set the array of PropertySource globally 
for a digester instance. The replaceProperties will be called 
automagically if the standard set properties rule is added to an 
element, and will check all attributes for possible property replacement.

- Additionally, we could add the "set all properties" rule to digester, 
which would attempt to call a setProperty method on an object to set 
properties which have no designated setter. I'm mixed on this: we need 
something like that for the Connector, but this is a very specific 
situation, and may be abused in the general case.

- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)

+1

The save could be implemented by saving all the discovered properties
to an another xml file which will be load at next start time ?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23891] New: - Need isap_redirector.dll (FOR IIS) for all versions of Tomcat

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23891

Need isap_redirector.dll (FOR IIS) for all versions of Tomcat

   Summary: Need isap_redirector.dll (FOR IIS) for all versions of
Tomcat
   Product: Tomcat 5
   Version: 5.0.0
  Platform: PC
OS/Version: Windows NT/2K
Status: UNCONFIRMED
  Severity: Blocker
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I know that this product is supposed to be cross platform and windows 
operating system is only 1 aspect of the whole spectrum for the apache 
developers.

I saw to my dismay that the isapi_redirector.dll was dependent on the version 
of the Apache Tomcat and not on thewindows.  I had an isapi_redirector.dll for 
a particular version of Tomcat 4.0.5 and that did not work with version tomcat 
5.x.

the version of 4.1.x has gui interface with IE/web browser and that is lacking 
in the 4.0.x version of tomcat. i want to use the latest version because it 
can do a lot of good things for the users like me.

is that a lot of difficulty for the developers to give the 
isapi_redirector.dll for the particular version of the build when they release 
TomCat apache.

This is a suggestion.  I am sorry to create  a bug like this.  pl. feel free 
to reclassify the severity/class as needed.

regards
Ravi.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[5.0] Property replacement

[Remy Maucherat]

Hi,

I'd like to make a small proposal to do property replacement. Included 
are changes that should be made in the digester, and that I'll post on 
commons-dev if I have approval.

- Add a get/setProperty to Container. This would allow a property 
inheritance across containers, similar to Tomcat 3.3 features as 
described by Bill.

- Add the two introspectionUtil replaceProperties methods to the 
digester, along with a way to set the array of PropertySource globally 
for a digester instance. The replaceProperties will be called 
automagically if the standard set properties rule is added to an 
element, and will check all attributes for possible property replacement.

- Additionally, we could add the "set all properties" rule to digester, 
which would attempt to call a setProperty method on an object to set 
properties which have no designated setter. I'm mixed on this: we need 
something like that for the Connector, but this is a very specific 
situation, and may be abused in the general case.

- Note: The properties used will not be saved when using save-to-XML 
from the admin. If anyone has an idea on how to make it work, let me 
know ;-) (anyway, save-to-XML should probably be rewritten in a non 
hackish and flexible fashion, but this can wait)

Comments ?

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

conf/web.xml still uses the servlet 2.3 DTD format?

[Petr Jiricka]

Hello list,

I noticed that Tomcat 5.0.12 still has the Servlet 2.3 DD in conf/web.xml:

http://java.sun.com/dtd/web-app_2_3.dtd";>
Are there any plans to upgrade it to web-app_2_4.xsd ?

Thanks
Petr


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup SetAllPropertiesRule.java

[remm]

remm2003/10/17 07:42:51

  Modified:catalina/src/share/org/apache/catalina/startup
SetAllPropertiesRule.java
  Log:
  - Add system property replacement to this (which will apply to the connector),
as an experiment.
  - The best would be to add a souped up version of this to the digester, as
well as add some get/setProperty on the container interface. The only problem
is that it can't be saved back to XML (since the stuff needs to be transparently
replaced). I'll post a "proposal" about that.
  
  Revision  ChangesPath
  1.2   +16 -3 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/SetAllPropertiesRule.java
  
  Index: SetAllPropertiesRule.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/SetAllPropertiesRule.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SetAllPropertiesRule.java 28 Jul 2003 11:14:48 -  1.1
  +++ SetAllPropertiesRule.java 17 Oct 2003 14:42:51 -  1.2
  @@ -99,9 +99,22 @@
   name = attributes.getQName(i);
   }
   String value = attributes.getValue(i);
  +value = IntrospectionUtils.replaceProperties
  +(value, new SystemPropertyPropertyResource());
   IntrospectionUtils.setProperty(digester.peek(), name, value);
   }
   
  +}
  +
  +
  +// - SystemPropertyPropertyResource Inner Class
  +
  +
  +protected class SystemPropertyPropertyResource
  +implements IntrospectionUtils.PropertySource {
  +public String getProperty(String key) {
  +return System.getProperty(key);
  +}
   }
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20073] - no object DCH for MIME type text/plain

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073

no object DCH for MIME type text/plain

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|Other   |Medium



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 14:15 ---
Came across this problem with own code invoking JavaMail, using Tomcat 4.1.24 on Mac 
OS X, 
using smtp to localhost sendmail.  Same code, jars, environment, etc. works correctly 
on Tomcat 
4.1.24 and 4.1.18 on Linux and Solaris.

Verified that mail.jar (including the 'mailcap' meta-inf file) is on classpath, and 
classes from the jar 
are being loaded.  For example, you can explicitly load 
com.sun.mail.handlers.text_plain before 
attempting to use the JavaMail package, to no avail.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 12:34 ---
Mozilla is buggy: its cache handling is invalid (hint: hit refresh after logging
in). Please do not reopen the report unless you can prove bad behavior on the
Tomcat side (ex: bad redirects, bad session handling).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 10:22 ---
Created an attachment (id=8606)
test.war

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 10:20 ---
Created an attachment (id=8605)
deployment descriptor

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23887] New: - FORM-based login with SSL broken in Mozilla (but not IE6)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23887

FORM-based login with SSL broken in Mozilla (but not IE6)

   Summary: FORM-based login with SSL broken in Mozilla (but not
IE6)
   Product: Tomcat 5
   Version: 5.0.12
  Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I cannot log in to an SSL-encrypted page with Mozilla. 

Tomcat just redisplays the login page continually and then perhaps after 5, 10
or 30 login attempts, it succeeds. 

Sometimes, at undefined times as far as my testing goes, it throws a status 400
'invalid direct reference to j_security_check' error.

I will attach a simple WAR to demonstrate. The web.xml is configured to work
with the TC memory realm. 

I will also attach just the web.xml for people who only want to do a quick check.

Best regards,
Adam

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23882] - JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23882

JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 10:05 ---
Sorry, it was my fault.

Never copy code from a swing app to a JSP, because you will not see the message 
box with the exception message if tomcat runs as a service :-) ! D'oh !

Everything fine now ! And I was so sure.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23885] New: - JAAS Realm property misspelling

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23885

JAAS Realm property misspelling

   Summary: JAAS Realm property misspelling
   Product: Tomcat 4
   Version: 4.1.27
  Platform: All
OS/Version: All
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


org.apache.catalina.realm.JAASRealm uses the 
property "jaasRealm.authenticateSuccess", that it tries to get from 
org/apache/catalina/realm/LocalStrings.properties

But in the properties file, the property is 
spelled "jaasRealm.authenticatedSuccess" (with an extra 'd').

Because of this the following log entry will show up when using JAASRealm
2003-10-17 10:54:56 JAASRealm[/]: Cannot find message associated with key 
jaasRealm.authenticateSuccess

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23881] - SingleSignOn and FormAuthenticator in embedded tomcat

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23881

SingleSignOn and FormAuthenticator in embedded tomcat





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 09:08 ---
also the register method in AuthenticatorBase creates a new cookie for 
SingleSignOn - i guess should check against an already existing cookie (using 
lookup) - and just call method associate in case this one exists. this solves a 
potential memory leak and the logout issue (register is called after every 
successful authenticate with the container realm).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf CharChunk.java

[remm]

remm2003/10/17 01:08:31

  Modified:util/java/org/apache/tomcat/util/buf CharChunk.java
  Log:
  - Apply Bill's trick.
  
  Revision  ChangesPath
  1.10  +1 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java
  
  Index: CharChunk.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/CharChunk.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- CharChunk.java16 Oct 2003 23:53:03 -  1.9
  +++ CharChunk.java17 Oct 2003 08:08:31 -  1.10
  @@ -294,7 +294,7 @@
   // Optimize on a common case.
   // If the source is going to fill up all the space in buffer, may
   // as well write it directly to the output, and avoid an extra copy
  -if ( len == limit && end == 0) {
  +if ( len == limit && end == start) {
   out.realWriteChars( src, off, len );
   return;
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23882] - JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23882

JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec





--- Additional Comments From [EMAIL PROTECTED]  2003-10-17 08:07 ---
> Each of the following two calls make it block, too:
> out.println (inputStream.getClass().getName() );

Well that is dubious. Jasper has no chance blocking either #getClass or #getName. 
Maybe #println 
blocks, then ? Anyway, whenever a java program allegedly "hangs" or "blocks" please 
send a thread 
dump. On Windows you get one by pressing 'CTRL-Break'. The dump is written to stderr, 
whatever 
that is in Windows ...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 23882] New: - JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23882

JSP.getServletContext().getResourceAsStream behaves not according to Servlet-Spec

   Summary: JSP.getServletContext().getResourceAsStream behaves not
according to Servlet-Spec
   Product: Tomcat 4
   Version: 4.1.24
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In a JSP the call to 
this.getServletContext().getResourceAsStream (".\SomeFileName")
should return null according to the description of the servlet api: 
javax.servlet.ServlectContext.getResourceAsStream says "... This method returns 
null if no resource exists at the specified path." (Taken from the API-Doc with 
Tomcat 4.1.24).

But it's not NULL:
  this.getServletContext().getResourceAsStream (".\SomeFileName")
  if (inputStream == null)
 out.println ("Is NULL");   //Never happens.

It returns a valid inputstream, which blocks at the first read. Each of the 
following two calls make it block, too:
out.println (inputStream.available() );
out.println (inputStream.getClass().getName() );
So there's no chance to find out what is returned.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]