Re: RE: [ANN] Servlet and JSP APIs have moved to subversion

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: Re: [ANN] Servlet and JSP APIs have moved to subversion

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: RE: [ANN] Servlet and JSP APIs have moved to subversion

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: Re: [ANN] Servlet and JSP APIs have moved to subversion

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: Francisco Pradas Garcia está ausente de la oficina.

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: DO NOT REPLY [Bug 36518] -

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

Re: Small refactoring in Http11Processor

[Costin Manolache]

Bill Barker wrote:

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, September 08, 2005 10:56 PM
Subject: Small refactoring in Http11Processor




Hi,

I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e.  the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.

I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.

Please review and let me know if it's ok to commit the change.




It seems that the only thing this patch does is to allow you to exclude
jmx.jar, so it's usefulness seems very minimal :).  TC 3.3 & 4.1 already run
very happily with the current code without JMX enabled.


True, it allows a smaller package. TC3.3 and 4.1 don't register the 
connector, so no JMX-related code is called, but it still requires 
jmx.jar to be around.






Something better would be a refactor that would remove the duplicated code
between Http11Processor and Http11AprProcessor (which one doesn't do :).


Yes, I've been thinking about this too :-), and also InternalAprBuffer 
and maybe add conditional compilation for the apr. But I didn't want to 
make the diff too big and risky.





Of course, none of this is enough for me to veto your scratching an itch :).



Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)




I agree with Mladen that this would work better if you could wait a couple
of weeks until we are up on SVN.


Ok, sounds good, I need to clean up the code anyway ( well, there are 
2-3 classes only and some build.xml ).



Costin


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

Re: DO NOT REPLY [Bug 36518] -

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

REMOVE THE MAILING LIST FROM YOUR SUPPORT EMAIL ADDRESSSSSS Re: DO NOT REPLY [Bug 36518] New: -

[Wade Chandler]

--- [EMAIL PROTECTED] wrote:

> We heartily thank you for your support & interest in
> our offerings. We appreciate & value your mails. We
> will soon contact you to take this further, as
> appropriate.
> 
> Thank you,
> 
> mie consultants inc.
> 
> 
> 
>
-
> 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: DO NOT REPLY [Bug 36518] New: -

[support]

We heartily thank you for your support & interest in our offerings. We 
appreciate & value your mails. We will soon contact you to take this further, 
as appropriate.

Thank you,

mie consultants inc.



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

DO NOT REPLY [Bug 36582] - Eclipse JDT compiler bug in 5.5.11

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36582





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 23:28 ---
New releases of JDT will be integrated as they are released. We only accept bug
reports on Tomcat in Tomcat's bugzilla.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36582] - Eclipse JDT compiler bug in 5.5.11

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36582





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 23:02 ---
INVALID?  What do you mean invalid?  Are you saying this is not a compiler bug?
It is not a bug in the Jasper code, but you ship that compiler with Tomcat and
it does not compile Java 5 corectly. 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36582] - Eclipse JDT compiler bug in 5.5.11

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36582


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 22:41 ---
Don't use autoboxing then.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36582] New: - Eclipse JDT compiler bug in 5.5.11

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36582

   Summary: Eclipse JDT compiler bug in 5.5.11
   Product: Tomcat 5
   Version: 5.5.11
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The latest IBM Eclipse JDT compiler that handles Java 5 and is included with
Tomcat 5.5.11 behaves differently than Sun's compiler. It doesn't seem to
implement autoboxing correctly with the conditional operator.  

method call in example code:  int getMinAge() //returns an int.

This line in a jsp
<%= type.getMinAge() < 0 ? "" : type.getMinAge() %>

becomes this line in the servlet version
out.print( type.getMinAge() < 0 ? "" : type.getMinAge() );


Sun's Java 5 compiler will compile the code above, IBM's won't.

Compile error:
An error occurred at line: 184 in the jsp file: /jsp/createConstraint.jsp
Generated servlet error:
Incompatible conditional operand types String and int



The following test class compiles and runs with Sun's 1.5. 
autoboxing converts the int to Integer 
==

import java.io.*;

public class TernaryTest{

   static int getInt(){return 0;}

   public static void main(String[] args) throws Exception{
  PrintStream ps = new PrintStream("test.out");
  ps.println("");
  ps.println(getInt() < 0 ? "x" : getInt());
  ps.close();

  Object obj = (getInt() < 0 ? "x" : getInt());
  System.out.println("obj = " + obj);
   }
}

==

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36578] - How to use a truststore other than cacerts

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36578





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 20:34 ---
(In reply to comment #1)
> See the entry for 'truststoreFile' at:
>  http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html#Configuration

I think you are referring to server.xml which has truststore attributes. But I 
am talking about my client deployer. I doubt if my client deployer (for 
deploying, undeploying, list etc using deployer package from command-line) 
will read the server.xml . In some cases these clients may be on different 
hosts than the one where Tomcat server is running on.

If I have misunderstood, please can you elaborate ?

Regards

Atanu Mukherjee

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36578] - How to use a truststore other than cacerts

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36578


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: Small refactoring in Http11Processor

[Bill Barker]

- Original Message -
From: "Costin Manolache" <[EMAIL PROTECTED]>
To: 
Sent: Thursday, September 08, 2005 10:56 PM
Subject: Small refactoring in Http11Processor


> Hi,
>
> I have a small patch, spliting the JMX-dependent code in
> Http11Processor, i.e.  the few lines of code dealing with the
> registration of the thread pool and per thread data - and moving all
> non-jmx code in a separate base class.
>
> I know Tomcat5 is heavily dependent on JMX, but the connector can be
> used in other containers, or it can be used standalone. This small
> change won't affect any functionality on tomcat - all methods are used
> only for intialization anyway, not in the critical path.
>
> Please review and let me know if it's ok to commit the change.
>

It seems that the only thing this patch does is to allow you to exclude
jmx.jar, so it's usefulness seems very minimal :).  TC 3.3 & 4.1 already run
very happily with the current code without JMX enabled.

Something better would be a refactor that would remove the duplicated code
between Http11Processor and Http11AprProcessor (which one doesn't do :).

Of course, none of this is enough for me to veto your scratching an itch :).

> Also, I would like to add another directory under j-t-c, with a build
> file and few classes for a 'mini' experiment - i.e. using the connector
> standalone, as a minimal http server, and also a target to build a
> minimal servlet container as a single self-contained jar. We don't have
> a sandbox, and j-t-c seems closest to that :-)
>

I agree with Mladen that this would work better if you could wait a couple
of weeks until we are up on SVN.

> Costin
>



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

DO NOT REPLY [Bug 36580] New: - Bad setting in uriworkermap.properties

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36580

   Summary: Bad setting in uriworkermap.properties
   Product: Tomcat 5
   Version: 5.5.9
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The uriworkermap.properties file installed has the line:
/servlet-examples/*=ajp13w

But based on the webapps installed by Tomcat, it should be:
/servlets-examples/*=ajp13w

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36578] - How to use a truststore other than cacerts

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36578


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 20:07 ---
See the entry for 'truststoreFile' at:
 http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html#Configuration

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36569] - Redirects produce illegal URL's

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36569





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 18:21 ---

On further examination, I think what you are right in essence ... the real
problem is that acegi is providing an invalid URL to Tomcat.

This raises the question, however, about whether sendRedirect shouldn't check
it's input and provide an informative error message so that errors like this are
caught early rather than much later.

Also, the resulting access after the invalid location is used could provide a
better message.  The GET message that begins the transaction looks somehting
like this:

   GET http://host.domain.tld/usrl?arg1=first second&arg2=foo HTTP/1.1

Tomcat interprets this as meaning that the protocol is "second&arg2=foo".  What
should really happen is that Tomcat should generate a 505 invalid request.

Changing the error checking is more important than it might appear to be due to
the widespread use of acegi.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36578] New: - How to use a truststore other than cacerts

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36578

   Summary: How to use a truststore other than cacerts
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hi. I would like to use a truststore file other than the JDK's cacerts when I 
use the deployer utility for command-line deploy/undeploy/start/stop/list etc 
over HTTPS.

I do not find any documentation for doing that. Perhaps there is a JVM 
argument that I need to specify. Something like  -
Djavax.net.ssl.TrustStore=/home/tomcat55/etc/trust.jks.

The example above is a fictitious one. That does not work. It is for making my 
objective clear. Can you please point me in the right direction ? If there is 
a JVM argument for this, what is it ?

Regards

Atanu Mukherjee

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 17:37 ---
(In reply to comment #71)
> Guys please .. Remy already said way back in #40 that he would look into 
> allowing this to be configurable :)

I don't really see anything that says the real issue will be addressed.  An out
of the box Tomcat has to be configured not to have a bug?  Plus, he said he
would look into it and all this and that and that's fine, but no where does it
reflect he believes there is an issue, and right now a bug caused by an
uninformed decision remains.  One, how do you synchronize calls with jsp:useBean
with scope of session?  Where else is session accessed in the Tomcat code
without synchronizing that developers should be aware of?  Is JSESSIONID stored
in the session as well and where is it accessed?  We need to make sure that
access is synchronized.  If we are going to talk about specifications and
responsibilities lets talk about them, but logically and truthfully.  There is
more to this issue than can be addressed by: "It's the developers
responsibility.".  Do we need to file bugs for all of the other issues if this
is going to remain invalid?  I say that must be the case if this is to remain
invalid.

Personally I don't like the idea that "this was done as an experiment"...
written in one of the comments above... in a system said to be "production
quality" (Tomcat home page).  The point is this: if it were an experiment it
should have used an option to turn it on, but should not have been a default by
any means.  If a system has an apparent flaw that reduces it's stability and
reliability and  especially when it can be solved with a couple of lines of
code.a patch is a no brainer.  This entire issue makes Tomcat currently
invalid as there are sections of standard usage which can not be safe guarded
against concurrency issues.  If I have an issue where customers can get kicked
out of the site after being logged in and the client asks me to fix itI
can't without changing the entire application, and by that I mean not using
jsp:useBean calls in my JSP pages without wrapping them with other calls, so
what's the point of using the tags in JSP if they can't be safe guarded without
more work.  I thought the point of the tags, EL, and other things is to make
development quicker and to provide short cuts.

My opinion:

1) Before a decision was made to change the synchronization of something which
was currently synchronized when documentation for the underlying implementation
explains there are issues with not synchronizing should not have only been
discussed as to whether it was safe, logical, and correct, but should have been
proved.

2) If it were to be an experiment, then it should have used an option to turn it
on, and the default been the more correct implementation for the given 
situation.

3) When a problem is identified in a piece of software being promoted as
production ready it should be handled.  Not shaken off as INVALID.  Where is the
proof that unsychronized reads don't have issues.  Examine the HashMap source
code and write a few tests.  You'll see with the bouncing index that a valid
value can exist in the Map for a given key and that Entry not be located because
null is returned.  Thus a program relying on a session variable to be set will
not be able to retrieve that session variable and take an entirely different
path because of thisit's very simplejust read the code:
public Object get(Object key) {
Object k = maskNull(key);
int hash = hash(k);
int i = indexFor(hash, table.length);
Entry e = table[i]; 
while (true) {
if (e == null)
return e;
if (e.hash == hash && eq(k, e.key)) 
return e.value;
e = e.next;
}
}

between the time i is set from a call to indexFor if table is resized with all
values null or all items are transfered and the given index for i is null then
null is returned as soon as we step into the while loop.  What that means is: If
between the time i is set from indexFor and the HashMap is resized because of a
write then there is a concurrency issue which affects the consistency of the
application.

How can this issue be worked around currently using Tags?  If we need to file
bugs on all the other places please let us know.  If you would like some help
with the other issues I would be willing to help, but my feelings are this
should be changed back for the time being and we need a new release based on the
latest release with only this change to the source.  In the mean time all the
other issues can be worked on as all of that w

Iso Demirkaya/CH/BALOISE ist außer Haus. Ferien!

[iso . demirkaya]

Ich werde ab  09.09.2005 nicht im Büro sein. Ich kehre zurück am
10.09.2005.

Ferien. Bin zurück am 19. September 2005. In dringenden Fällen wenden Sie
sich bitte an Till Schober 032 626 08 27 oder Roland Käser 032 626 08 24.


Disclaimer: The contents of this email and any attachment thereto are
intended exclusively for the attention of the addressee(s).
The email and any such attachment(s) may contain information that is
confidential and protected on the strength of professional,
official or business secrecy laws and regulations or contractual
obligations. Should you have received this email by mistake,
you may neither make use of nor divulge the contents of the email or of any
attachment thereto. In such a case,
please inform the email's sender and delete the message and all attachments
without delay from your systems.
You can find our e-mail disclaimer statement in other languages under
http://www.baloise.ch/disclaimer


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

DO NOT REPLY [Bug 36574] New: - Broken PDF document in online docware

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36574

   Summary: Broken PDF document in online docware
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
   URL: http://jakarta.apache.org/tomcat/tomcat-5.5-
doc/architecture/startup.html
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Hope this is the right place to report ...

On the page
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/architecture/startup.html there
is a link "UML sequence diagram of the startup procedure is available here"
pointing to
.
That PDF document is broken. When trying to open with Adobe Reader 7.0.1 on
Windows 2000 it says "An unrecognized token .P35.76 was found". When trying with
xpdf or acroread on Linux I get similar results; the document cannot be viewed.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 15:16 ---
Guys please .. Remy already said way back in #40 that he would look into 
allowing this to be configurable :)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 15:12 ---
(In reply to comment #67)
> (In reply to comment #66)
> > http://java.sun.com/j2se/javadoc/writingapispecs/index.html#top-level
> 
> That reference is invalid in the context of this bug report.  I read it to be 
> a
> hyperthetical example of what to put inside javadoc information.
> 
> Nothing concrete to under pin all Java programming design.

I think what leon is trying to say is that 'this is what should be done'.

So either - the documentation for HTTPsession has a problem, that it is missing
the information regarding it not being thread safe - or the implementation
in TC is wrong.

According to what I have read here, it has been decided that TC says that 
HTTPsession
is NOT threadsafe, meaning that all developers who use HTTPsession will
- should they call 'put' - need to ensure that they sync the session - otherwise
nasty things can happen.

This means that the documentation should definitely be changed to warn 
developers,
and that all 3rd party projects fix their code so that it does not crash/ hang 
tomcat 5.0 .

(I haven't had a proper look to check if the synced puts in 5.5 are enough to 
stop the
loops)...

IMHO - Anyone who doesn't care whether or not the data is consistent - really
doesn't need the data, and shouldn't bother calling the routine.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 14:49 ---
(In reply to comment #65)
> Leon,
> 
> Can you publish your TC+HashMap finding you based your comment #55 ?

It's a simple program, which actually shows the bug (on synchronized put/remove
and unsychronized get). I am to stupid to program the writers to stop as soon as
the loop occurs, so they fix the problem some time after it occurs (thats why a
long loop instead of infinite loop). 

After each execution the reader measures how long the execution lasted. If the
execution lasted longer then 5 seconds it cries. The mid time of the execution
is 0.05 milliseconds. So we can safely assume, that executions which last 5
seconds or more aren't normal. In fact I had it all night running with 714 "too
long executions", longest of them being 70 seconds. If I add synchronized(map)
in the getAttribute method of the Storage class it doesn't occure anymore.






-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 14:39 ---
Created an attachment (id=16347)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16347&action=view)
bug reproduction

eclipse ready project. 
to start: 
jar -xf synchtest.jar
cd synchtest
java -cp classes leon.synch.StartTest

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 13:28 ---
(In reply to comment #66)
> http://java.sun.com/j2se/javadoc/writingapispecs/index.html#top-level

That reference is invalid in the context of this bug report.  I read it to be a
hyperthetical example of what to put inside javadoc information.

Nothing concrete to under pin all Java programming design.


My comments fallback to what is written (and not written) into the documentation
for the HashMap implementation that TC has elected to use for the job.  It does
not say you call get() while you are also doing a put() (when the put() may
cause internal re-arangement), it explicitly warns you of this problem and as we
have no way knowing if the put will cause a rearrangment to achieve TCs goal of
robustness we have to synchronize our usage.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 13:10 ---
(In reply to comment #65)
> all).  Where within the reference is that implicit thread-safe notion stated ?

http://java.sun.com/j2se/javadoc/writingapispecs/index.html#top-level


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 12:55 ---
(In reply to comment #64)
> Another question:
> 
> http://java.sun.com/j2se/javadoc/writingdoccomments/index.html
> 
> According to sun's javadoc principals (above link)
> #  The Java Platform API Specification is a contract between callers and
> implementations.

Leon,

Can you publish your TC+HashMap finding you based your comment #55 ?


I've always tried to program for the worst case scenario, assume thread-unsafe
unless otherwise stated.  Probably my 'C' language background thinking here.  So
it interests me to hear this stated in reverse for Java (not a bad thing at
all).  Where within the reference is that implicit thread-safe notion stated ?


Is a HashMap really needed for session attributes, exactly how many attributes
does an average application have set ?  Replacing the collection with a bespoke
TC internal class based on something as silly as a linked list or fixed hash
bucket redirect into linked list should serve most users well.

Then making the exact collection implementation class a configurable item so
those users that would benifit from a safe HashMap for scalabilty of key count
would be happy to fix their performance with a config change.


It would please me greatly to see a more proper collection class for the job
with a safe write operation whilst allowing simultenous mutiple reads.  But
trying to bend the HashMap API into something its not is wrong.

Java Moto #1: "You program to interfaces"


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 12:26 ---
Another question:

http://java.sun.com/j2se/javadoc/writingdoccomments/index.html

According to sun's javadoc principals (above link)
#  The Java Platform API Specification is a contract between callers and
implementations.

The Specification describes all aspects of the behavior of each method on which
a caller can rely. It does not describe implementation details, such as whether
the method is native or synchronized. The specification should describe
(textually) the thread-safety guarantees provided by a given object. In the
absence of explicit indication to the contrary, all objects are assumed to be
"thread-safe" (i.e., it is permissible for multiple threads to access them
concurrently). It is recognized that current specifications don't always live up
to this ideal.

Since the javadoc of the HTTPSession
(http://java.sun.com/j2ee/1.4/docs/api/index.html) doesn't mention anything
about session being not thread-safe, should not the developer be able to rely on
the fact that the implementation is thread safe?







-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36569] - Redirects produce illegal URL's

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36569





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 12:06 ---
sendRedirect takes a URL as a parameter. If you don't give more details, I'll
close as INVALID.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36540] - pooled cluster replication does not seem ensure synchronized replication in tomcat 5.5.11

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36540


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 10:48 ---
I did some further testing, and my test case works as expected with tomcat 5.5.9
without the cluster fix pack (Bug 34389) So you have a regression there, which
should be fixed. Anyway, this bug isn't INVALID, it's either a bug, or a
WONTFIX, so I reopen it. But you should really fix that, since many load
balancers don't support tomcat's sticky sessions.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 10:14 ---
(In reply to comment #62)
> (In reply to comment #61)
> 
> java.util.ConcurrentHashMap

You meant java.util.concurrent.ConcurrentHashMap, didn't you? 
Too bad it has been introduced in java 5.0


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.

[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://issues.apache.org/bugzilla/show_bug.cgi?id=36541





--- Additional Comments From [EMAIL PROTECTED]  2005-09-09 10:05 ---
(In reply to comment #61)

java.util.ConcurrentHashMap

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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