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

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

yoavs   2003/12/16 18:42:26

  Modified:webapps/docs changelog.xml
  Log:
  Started changelog for 5.0.17.
It's probably easier if either:
- only one guy does it (so he knows what needs to be in the changelog)
- everyone updates the changelog when making a change
As the second is too messy and generates too much mail, I think it's the 
RM's duty to do the first item :) This is really boring, of course, but 
at least it's manageable this way.

Rémy



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

DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to

[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=25547

default errorpage is displayed instead of the one forwarded to

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 07:23 ---
This is invalid: you set a standard attribute, which will cause the error
processing to think Jasper did it. As a result, the response will be reset once
again, and the standard report for the exception you set in the attribute will
be displayed.

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

DO NOT REPLY [Bug 25528] - WebappClassloader does not register with RMI codebase cache

[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=25528

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 09:06 ---
OK thanx will do. I will keep an eye on tomcat 4.1 patch and recommend our 
clients to upgrade to that version. Until then, we will use current patch.

thanx for the quick response (no support for bugs in tomcat, that's what i keep 
hearing. try to get this addressed to the right people for weblogic ;-)

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

tomcat simulator

[Anirban . Dutta]

Hi,
I am developing a Web based CustomerCare application using Tomcat 3.2. I
have used XML and jsp for displaying the content in IE5, Netscape. I'm
running the tomcat server on WinNT.
I've used java classes(jdk 1.3) to send any request from the browser to our
application server (orbix3.3.4 - iona implementation) and vice versa. That
is when a user asks for any data to retrieve(clicking a button on browser)
the jsp page calls a function in a java class and the java program in turn
calls a corresponding function in orbix server running on SOLARIS. The
Application Server program then fetches the record from DB and sends a
sequence(structure array ) to the java program...the java function then
form a xml string and send it to jsp for displaying it in the browser.
Now we want to simulate a process to test the load of tomcat server. Would
anyone please tell me whether there is any tool available to test a
situation, wherein n number of browsers are opened and the users ask for
records simultaneously. We just want to do a stress testing of tomcat
server.
I'm totally new in this tomcat, web application area...really don't know
much of this jsp, tomcat technology...would appriciate for any kind of
suggestion/help

Anirban



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

DO NOT REPLY [Bug 25584] New: - UTF-8 character encoding problem with HTTP get

[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=25584

UTF-8 character encoding problem with HTTP get

   Summary: UTF-8 character encoding problem with HTTP get
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


UTF-8 charaters are lost (encoded wrongly) when sending back a page by GET. 
When I changed the method of the form to POST it works perfectly.

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

DO NOT REPLY [Bug 25584] - UTF-8 character encoding problem with HTTP get

[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=25584

UTF-8 character encoding problem with HTTP get





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 10:00 ---
I have tried it in IE6

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

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

[Tim Funk]

I prefer only the RM updating changelog.

-Tim

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

yoavs   2003/12/16 18:42:26

  Modified:webapps/docs changelog.xml
  Log:
  Started changelog for 5.0.17.


It's probably easier if either:
- only one guy does it (so he knows what needs to be in the changelog)
- everyone updates the changelog when making a change
As the second is too messy and generates too much mail, I think it's the 
RM's duty to do the first item :) This is really boring, of course, but 
at least it's manageable this way.


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

DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to

[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=25547

default errorpage is displayed instead of the one forwarded to





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 14:30 ---
The servlet code was taken from Phil Hanna's book JSP 2.0, The Complete 
Reference. (ControllerServlet Page 675)

I think that the advantage was to allow servlets to use the errorpage of jsp.

If that's an invalid use of error page, what would be a valid way to display 
errors caught by servlets?

Thanks

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

DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to

[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=25547

default errorpage is displayed instead of the one forwarded to





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 14:38 ---
Have you tried creating your own, error page entry in your apps web.xml file?


500
/server_error.html


404
/file_not_found.html


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

DO NOT REPLY [Bug 25593] New: - allowLinking attribute value is not preserved or ignored after context is reloaded

[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=25593

allowLinking attribute value is not preserved or ignored after context is reloaded

   Summary: allowLinking attribute value is not preserved or ignored
after context is reloaded
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]




I have a link in "myapp/WEB-INF/classes/com" that points to a directory 
located on an NFS share. After tomcat starts up "myapp" works perfectly fine. 
After the application gets reloaded (either my the manager or because of the 
class file change) tomcat stops floowing the links for the application 
generating ClassNotFound exceptions.

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

Errorpage for Servlets

[Reinhard Moosauer]

Hi,

Jean-Pierre Pelletier submitted this bug (already closed):

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25547
(default errorpage is displayed instead of the one forwarded to)

I am also using the technique he describes. (In Tomcat 4.1)
Seems like this will work no more in Tomcat 5

My question: Is there a portable way to use the same errorpage for servlets 
and JSPs? 

I can think of these solutions:

1. use another attribute instead of "javax.servlet.jsp.jspException" and get 
it back in the errorpage

2. Simply use "exception" as the attribute name.

thanks in advance for some tips,


Reinhard

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

Karma for servletapi-5

[Shapira, Yoav]

Hi,
I was going to fix bug 22290 last night when to my surprise I found out
I didn't have karma for the jakarta-servletapi-5 component.  I would
like karma there please ;)   Thanks,

Yoav Shapira
Millennium ChemInformatics





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

RE: Errorpage for Servlets

[Shapira, Yoav]

Howdy,

>My question: Is there a portable way to use the same errorpage for
servlets
>and JSPs?

How about mapping the error page in web.xml and throwing the mapped
exception type?  It's very simple and clean.

Yoav Shapira

>
>I can think of these solutions:
>
>1. use another attribute instead of "javax.servlet.jsp.jspException"
and
>get
>it back in the errorpage
>
>2. Simply use "exception" as the attribute name.
>
>thanks in advance for some tips,
>
>
>Reinhard
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

DO NOT REPLY [Bug 25596] New: - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload

   Summary: application briefly unavailable when using manager to
reload
   Product: Tomcat 5
   Version: 5.0.16
  Platform: Other
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When reloading a web application in production. Tomcat reports that the 
application is unavailable for a brief period of time. the reason for 
reloading the application is the jsp pages are precompiled and the application 
reloadable property is set to false. So on every migration we are forced to 
reload the application which leads to the problem described above. 
When using reloadable propery in development this doesn't happen even after 
recompiling all class files. Some of the pages on the server are pretty 
complex pages that requires a lot of users input and when the application is 
unavailable all the user's work is simply lost and they have to start over 
again. 
there are no error messages in the log files and no complains, the application 
uses struts and the reloading is using the Ant tasks shipped with Tomcat. 

Please advice what is the best configuration, may be reloadable is not so bad 
after all. 
P.S. the application doesn't take this long to load we are talking about 
couple of seconds at the most.

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

DO NOT REPLY [Bug 25596] - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 17:44 ---
This is a known bug/regression over TC 4, see this thread for more info:

http://marc.theaimsgroup.com/?t=10710407064&r=1&w=2

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

Important information about jakarta-servletapi-*

[Mark Roth]

Hi everyone,

I've seen a few requests to fix items in the jakarta-servletapi-* 
workspaces and wanted to clear up any confusion there might be.

Changes to examples in these workspaces are fine.

However, ANY changes to the core APIs (including even simple javadocs 
changes) CANNOT be done outside of the JCP process.  This applies to 
both Servlet and JSP APIs.

To make any changes to these APIs, you must propose the change through 
the spec aliases, which appear on the front covers of the corresponding 
specifications:

Servlet: [EMAIL PROTECTED]
JSP: [EMAIL PROTECTED]
Your change request will be considered by the specification leads and 
potentially debated by the expert group.  Changes to the APIs can only 
be done in a maintenance release of the specification, or in the next 
revision of the specification.  The Servlet 2.4 and JSP 2.0 
specifications have both been finalized for this release of Tomcat and 
are very unlikely to change in any substantial way until the next release.

Please understand that Tomcat is only one of many containers that are 
implementing the Servlet and JSP specifications, and the APIs must match 
identically on all containers.

Please don't hesitate to contact me if you have any questions on this 
matter.

Thank you for your cooperation.

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25597] New: - ArrayIndexOutOfBoundsException

[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=25597

ArrayIndexOutOfBoundsException

   Summary: ArrayIndexOutOfBoundsException
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Sun
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Before upgrading to tomcat 4.1.27, thsi worked fine. Now I get this exception: 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 14
at org.apache.jasper.JspC.locateUriRoot(JspC.java:628)
at org.apache.jasper.JspC.execute(JspC.java:759)
at org.apache.jasper.JspC.main(JspC.java:823)
Is there any issues with tomcat 4 and jspc?

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

Re: Understanding jakarta-tomcat-4.0 cvs source base / jasper

[Jeff Tulley]

Kin-man,
   Thank you, that is exactly the answer I was looking for.  That makes
things a lot more clear.  I would suggest removing the j-t-4.0/jasper
directory then, since 4.0.x seems done with.

>The source for Jasper in Tomcat 4.1.29 is from j-t-j/jasper2 with
>Tomcat_4_branch tag.  The head branch is for Tomcat 5.

>A lot of bugs filed against Tomcat 4.1.x has been fixed in Tomcat 5.
>Unfortunately I don't have cycles to apply the fixes to 4.1.x.  It
would
>be great if someone can do that, and I can help and/or anser questions
if
>needed.

>The branch jakarta-tomcat-4.0/jasper was used for Tomcat 4.0.x
releases,
>and I don't think we are making new releases for Tomcat 4.0.x.

>-Kin-man

>> Quick question - Does the jasper that ships with Tomcat 4.1.29 come
from
>> the source code in jakarta-tomcat-4.0/jasper, or is it from the
>> jakarta-tomcat-jasper CVS module?
> 
>> I am looking at some bugs in Bugzilla against Jasper, where they
>> complain about something in j-t-4.0/jasper/src/(some class), and the
bug
>> is fixed in j-t-j/jasper2/src   I do not know whether to mark the
bug as
>> fixed or investigate further.
>> 
>> If the answer turns out that the source code in j-t-4/jasper is NOT
>> being used, what is there against removing it to avoid confusion?


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

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

Re: Important information about jakarta-servletapi-*

[Tim Funk]

Does this mean that any bug submitted with a criticism (or patch) against 
jakarta-servletapi-* can be marked as WONTFIX with a advisory for the 
requestor to notify [EMAIL PROTECTED] or 
[EMAIL PROTECTED] ? (I know there is at least one bug in this 
category)

-Tim

Mark Roth wrote:
Hi everyone,

I've seen a few requests to fix items in the jakarta-servletapi-* 
workspaces and wanted to clear up any confusion there might be.

Changes to examples in these workspaces are fine.

However, ANY changes to the core APIs (including even simple javadocs 
changes) CANNOT be done outside of the JCP process.  This applies to 
both Servlet and JSP APIs.

To make any changes to these APIs, you must propose the change through 
the spec aliases, which appear on the front covers of the corresponding 
specifications:

Servlet: [EMAIL PROTECTED]
JSP: [EMAIL PROTECTED]
Your change request will be considered by the specification leads and 
potentially debated by the expert group.  Changes to the APIs can only 
be done in a maintenance release of the specification, or in the next 
revision of the specification.  The Servlet 2.4 and JSP 2.0 
specifications have both been finalized for this release of Tomcat and 
are very unlikely to change in any substantial way until the next release.

Please understand that Tomcat is only one of many containers that are 
implementing the Servlet and JSP specifications, and the APIs must match 
identically on all containers.



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

RE: Important information about jakarta-servletapi-*

[Shapira, Yoav]

Howdy,
Thanks for the clarification Mark, and for beating me to the question
Tim ;)

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Tim Funk [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, December 17, 2003 1:09 PM
>To: Tomcat Developers List
>Subject: Re: Important information about jakarta-servletapi-*
>
>Does this mean that any bug submitted with a criticism (or patch)
against
>jakarta-servletapi-* can be marked as WONTFIX with a advisory for the
>requestor to notify [EMAIL PROTECTED] or
>[EMAIL PROTECTED] ? (I know there is at least one bug in
this
>category)
>
>-Tim
>
>Mark Roth wrote:
>> Hi everyone,
>>
>> I've seen a few requests to fix items in the jakarta-servletapi-*
>> workspaces and wanted to clear up any confusion there might be.
>>
>> Changes to examples in these workspaces are fine.
>>
>> However, ANY changes to the core APIs (including even simple javadocs
>> changes) CANNOT be done outside of the JCP process.  This applies to
>> both Servlet and JSP APIs.
>>
>> To make any changes to these APIs, you must propose the change
through
>> the spec aliases, which appear on the front covers of the
corresponding
>> specifications:
>>
>> Servlet: [EMAIL PROTECTED]
>> JSP: [EMAIL PROTECTED]
>>
>> Your change request will be considered by the specification leads and
>> potentially debated by the expert group.  Changes to the APIs can
only
>> be done in a maintenance release of the specification, or in the next
>> revision of the specification.  The Servlet 2.4 and JSP 2.0
>> specifications have both been finalized for this release of Tomcat
and
>> are very unlikely to change in any substantial way until the next
>release.
>>
>> Please understand that Tomcat is only one of many containers that are
>> implementing the Servlet and JSP specifications, and the APIs must
match
>> identically on all containers.
>>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: Important information about jakarta-servletapi-*

[Mark Roth]

Hi Tim,

Tim Funk wrote:
Does this mean that any bug submitted with a criticism (or patch) 
against jakarta-servletapi-* can be marked as WONTFIX with a advisory 
for the requestor to notify [EMAIL PROTECTED] or 
[EMAIL PROTECTED] ? (I know there is at least one bug in 
this category)
If the bug fix results in a change to the externally-visible portions of 
an API class (javax.*), the change MUST go through the JCP.  The best 
way to get such an issue considered is through the mail aliases I 
mentioned in the previous email.

Fixing bugs in the implementation of such classes resulting in NO change 
to the external interface (e.g. signature of public/protected methods or 
javadocs) is okay.

Additions, removals and changes to other portions of this workspace, 
such as the sample applications, are entirely okay.

I'll leave it up to the Tomcat team to decide how to handle the 
paperwork (e.g. whether to mark bugs as WONTFIX or not).  Your 
suggestion sounds reasonable to me.

It's probably a good idea to outline these rules in a README.txt file in 
the workspace as well.

Hope this helps.

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Important information about jakarta-servletapi-*

[Mark Roth]

Hi Yoav,

Shapira, Yoav wrote:
Howdy,
Thanks for the clarification Mark, and for beating me to the question
Tim ;)
No problem!

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25596] - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 19:19 ---
Actually, even on TC 4.1.29 I was getting this problem, and one of the main 
reason to upgrade was to avoid this from happening, thought that it might have 
been fixed. I was wrong according to the new implementation TC 5 is even worse 
form that prospective.
I would appreciate if somebody would point out where the code for this 
behaviour is located I would like to patch it myself if I can.

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

DO NOT REPLY [Bug 25596] - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 19:28 ---
In TC 4 when I reload a context through the manager, any requests to that
context don't come back until the context has been reloaded.  I wonder why it's
different for you?

Anyway, let me post what Remy said about fixing this issue:

"To solve the recurrent bugs and problems caused by reload and simplify 
the code, reload was replaced with the stop/start sequence. So 
unfortunately the side effect is that this cannot work anymore, and we 
need a more generic mechanism to 'wait'."

I'm not sure exactly where to look but I would start with the Manager webapp and
see where it ties into the container.  From there, you'll have to look at how
requests get processed and see if there's a way to get new requests to a context
to block if a context is reloading.

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

DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to

[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=25547

default errorpage is displayed instead of the one forwarded to

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 19:31 ---
I removed the forward to the error page and added this to the web.xml
   
  java.lang.Throwable
  /ErrorPage.jsp
   
   
  500
  /ErrorPage.jsp


It still display the default error page (It does use the file specified when it 
is a .html)

Here is a reference where they talk about forwarding to an error page
http://www.jguru.com/faq/view.jsp?EID=1347
http://www.jguru.com/faq/printableview.jsp?EID=1347

You might have to consider supporting forwarding to an error page
1) for backward compatibility because it was a recommended method of doing 
things in some books for example

2) There seems to be no ways for a servlet to have the servlet container 
properly invoke an .jsp error page on its behalf.

Thanks

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

DO NOT REPLY [Bug 25599] New: - Cannot change the Java VM option in the Configure Tomcat utility

[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=25599

Cannot change the Java VM option in the Configure Tomcat utility

   Summary: Cannot change the Java VM option in the Configure Tomcat
utility
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Native:Integration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm running Tomcat 5 on a Windows XP system with at least 6 different JDKs.  I
have my JAVA_HOME environment variable set to reference the default instance,
the one I use most often.  During the initial installation, the Tomcat installer
asked me to point to the location of the JDK I wanted Tomcat to use, and it
pre-populated the field with the value of the JAVA_HOME variable.  This was
fine, so I left the value alone and continued the installation.  When I checked
the values in the Configure Tomcat tool, I saw that the Java VM option read
simply "java" rather than the value I had seen during installation.  If I try to
change this value, and point to a specific Java executable from a specific JDK
version, Tomcat will not start up.  The process dies almost as soon as I run it,
and it will not come back until I go into the Windows Registry and return the
Java VM value to just "java".   I can find no other way to specify which Java
version Tomcat uses after installation, and I can't verify that it is using the
one I selected during installation.

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

RE: Important information about jakarta-servletapi-*

[Mark Thomas]

Mark,

One final question. The javadoc bugs I was looking at were of the following 
types:
 - @returns used rather than @return
 - @seealso used rather than @see
 - etc

Is it permitted to make changes to fix these? There were no changes to the 
actual text of the javadoc.

Thanks,

Mark

On Wednesday, December 17, 2003 6:22 PM, Mark Roth [SMTP:[EMAIL PROTECTED] 
wrote:
> Hi Yoav,
>
> Shapira, Yoav wrote:
> > Howdy,
> > Thanks for the clarification Mark, and for beating me to the question
> > Tim ;)
>
> No problem!
>
> ---
> Mark Roth, Java Software
> JSP 2.0 Co-Specification Lead
> Sun Microsystems, 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]

DO NOT REPLY [Bug 25600] New: - sessionDestroyed method (in HttpSessionListener) is being called twice

[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=25600

sessionDestroyed method (in HttpSessionListener) is being called twice

   Summary: sessionDestroyed method (in HttpSessionListener) is
being called twice
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have an application running on Tomcat 4.1.27, who uses an HttpSessionListener 
to intercept session invalidations. It runs OK, according with the 2.3 servlet 
spec, which says that the sessionDestroyed method must be called AFTER the 
session is already invalidated. (I had a lot of pain to build a logic that 
could overcome this behavior). Well, today, I moved the same application to 
Tomcat 5.0.16 and - for my surprise - the sessionDestroyed is now called BEFORE 
the session is invalidated... I KNOW that this is the correct behavior 
according to 2.4 servlet spec, and I fixed my listener to work with it. 

The problem now, is that the sessionDestroyed method is being called TWICE: one 
BEFORE the session is invalidated and another AFTER the session is already 
invalidated, in THE SAME INVALIDATION PROCESS !  And more: it only happens when 
the session expires - after timeout is reached. It does NOT happen when I 
explicity invalidate the session, with "session.invalidate()". My listener is 
full of logs and that's the only reason I could figure this out

I just want to know if this is the correct behavior for the 2.4 servlet spec, 
or if it's a bug... I can overcome this too, but I think that if there's 
something wrong, it must fixed...

Thanks,
Roberto (Ironman)

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

DO NOT REPLY [Bug 25599] - Cannot change the Java VM option in the Configure Tomcat utility

[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=25599

Cannot change the Java VM option in the Configure Tomcat utility





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 20:25 ---
Further testing reveals that Tomcat will always use the JVM referenced in the
Windows registry, regardless of the choice made during installation.  In my
case, this was C:\Program Files\Java\j2re1.4.2_02 -- it was installed along with
the Java 1.4.2 SDK.  If this JVM instance does not exist on the Windows
filesystem, the installer will still act like everything is okay -- asking if
you want Tomcat to use the JDK referenced by your JAVA_HOME environment variable
-- but when installation is complete, Tomcat *will not run*.  Tomcat needs to
actually use the JDK that the user specifies during or after installation, and
it needs to be able to run even if the silly JRE is not installed under
C:\Program Files.

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

Re: Important information about jakarta-servletapi-*

[Mark Roth]

Hi Mark,

Mark Thomas wrote:
Mark,

One final question. The javadoc bugs I was looking at were of the following 
types:
 - @returns used rather than @return
 - @seealso used rather than @see
 - etc
Yuck.  :)  It's unfortunate we didn't catch those earlier.  I'm 
definitely interested in a list of any such bugs in the JSP APIs and I'm 
sure Yutaka is too, for Servlet.  Please send a summary of any such 
errors to the spec aliases and we'll be sure to catch them in the next 
revision of the specs.

Is it permitted to make changes to fix these? There were no changes to the 
actual text of the javadoc.
Unfortunately, the answer is no, even though it seems rather silly.  The 
reason is that the specifications themselves have an auto-generated copy 
of the javadocs in PDF format, and the assertion list for the TCK is 
generated, in part, based on the javadoc tags.  Converting an incorrect 
@returns to a correct @return would make both the spec PDF and assertion 
list get out of sync with the API workspace.  There are other 
side-effects as well.

Thanks in advance for the summary to the specification aliases!

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/webapps/docs cluster-howto.xml

[fhanik]

fhanik  2003/12/17 13:00:40

  Modified:webapps/docs cluster-howto.xml
  Log:
  added a little note about sync vs async replication. Sync replication is truly 
working on redhat,
  somehow windows is giving me problems with NIO when writing the ACK back to the 
channel
  
  Revision  ChangesPath
  1.2   +42 -29jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml
  
  Index: cluster-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/cluster-howto.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- cluster-howto.xml 15 Oct 2003 01:57:59 -  1.1
  +++ cluster-howto.xml 17 Dec 2003 21:00:40 -  1.2
  @@ -4,7 +4,7 @@
   ]>
   
   
  -&project; 
  +&project;
   
   
   Filip Hanik
  @@ -24,7 +24,7 @@
   Uncomment the Valve(ReplicationValve) element in server.xml
   If your Tomcat instances are running on the same machine, make sure the 
tcpListenPort
   attribute is unique for each instance.
  -Make sure your web.xml has the  
element
  +Make sure your web.xml has the  
element
   
   Then all you have to do is start Tomcat, I suggest using http://balance.sourceforge.net";>Balance
  as a load balancer. Apache/mod_jk will also do or hardware of course
  @@ -43,8 +43,8 @@
   
   
   In this release of session replication, Tomcat performs an all-to-all 
replication of session state.
  -   
  -   This is an algorithm that is only efficient when the clusters are small. For 
large clusters, the next 
  +
  +   This is an algorithm that is only efficient when the clusters are small. For 
large clusters, the next
  release will support a primary-secondary session replication where the session 
will only be stored at one
  or maybe two backup servers.
  In order to keep the network traffic down in an all-to-all environment, you can 
split your cluster
  @@ -63,7 +63,7 @@
   
   
   What is important to mention here, is that session replication is only the 
beginning of clustering.
  -   Another popular concept used to implement clusters is farming, ie, you deploy 
your apps only to one 
  +   Another popular concept used to implement clusters is farming, ie, you deploy 
your apps only to one
  server, and the cluster will distribute the deployments across the entire 
cluster.
  This is all capabilities that can go into the next release.
   In the next section will go deeper into how session replication works and how to 
configure it.
  @@ -74,7 +74,7 @@
   To make it easy to understand how clustering works, I'm gonna take you through a 
series of scenarios.
  In the scenario I only plan to use two tomcat instances TomcatA and 
TomcatB.
  We will cover the following sequence of events:
  -   
  +
   
   TomcatA starts up
   TomcatB starts up
  @@ -105,12 +105,12 @@
   
   When TomcatB starts up, it follows the same sequence as TomcatA did with 
one exception.
   The cluster is started and will establish a membership (TomcatA,TomcatB).
  -TomcatB will now request the session state from a server that already 
exists in the cluster, 
  -in this case TomcatA. TomcatA responds to the request, and before TomcatB 
starts listening 
  +TomcatB will now request the session state from a server that already 
exists in the cluster,
  +in this case TomcatA. TomcatA responds to the request, and before TomcatB 
starts listening
   for HTTP requests, the state has been transferred from TomcatA to TomcatB.
  -In case TomcatA doesn't respond, TomcatB will time out after 60 seconds, 
and issue a log 
  -entry. The session state gets transferred for each web application that has 
distributable in 
  -its web.xml. Note: To use session replication efficiently, all your tomcat 
instances should be 
  +In case TomcatA doesn't respond, TomcatB will time out after 60 seconds, 
and issue a log
  +entry. The session state gets transferred for each web application that has 
distributable in
  +its web.xml. Note: To use session replication efficiently, all your tomcat 
instances should be
   configured the same.
   
   
  @@ -124,17 +124,17 @@
   the request returns to the user, back through the valve pipeline.
   For each request the entire session is replicated, this allows code that 
modifies attributes
   in the session without calling setAttribute or removeAttribute to be 
replicated.
  -a useDirtyFlag configuration parameter can be used to optimize the number 
of times 
  -a session is replicated.
  +a useDirtyFlag configuration parameter can be used to optimize the number 
of times
  +a session is replicated.
   
   
   
   TomcatA crashes
   
  -When TomcatA crashes, TomcatB receives a notification that To

DO NOT REPLY [Bug 25584] - UTF-8 character encoding problem with HTTP get

[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=25584

UTF-8 character encoding problem with HTTP get

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:35 ---
Please look at the connector documentation, and in particular the uriEncoding
attribute.

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

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

[Remy Maucherat]

Tim Funk wrote:
I prefer only the RM updating changelog.
Or we would need to disable commit messages for changelog.xml ;-)

Rémy



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

DO NOT REPLY [Bug 25603] New: - HTTPS Connector ignores truststoreFile attribute

[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=25603

HTTPS Connector ignores truststoreFile attribute

   Summary: HTTPS Connector ignores truststoreFile attribute
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When setting up a Connector to create an SSL listen socket over HTTPS, the
truststoreFile attribute of the Connector element is ignored by Tomcat 5. 
Regardless of the file path set in the attribute, Tomcat will only recognize the
certificate authority trust store located in
%JAVA_HOME%\jre\lib\security\cacerts.  Setting an alternate location for the
trust store, as suggested in the Tomcat 5 documentation, has no effect.

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

DO NOT REPLY [Bug 25547] - default errorpage is displayed instead of the one forwarded to

[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=25547

default errorpage is displayed instead of the one forwarded to

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:44 ---
I think you are mistaken about this issue. Please do not reopen the report, and
use tomcat-user to debug your setup instead, as this looks like configuration
issues.

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

DO NOT REPLY [Bug 25596] - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:46 ---
This works as intended, and this will not be implemented. I belive "waiting" is
actually a bad feature. More robust failover mechanisms should be used instead.

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

DO NOT REPLY [Bug 25593] - allowLinking attribute value is not preserved or ignored after context is reloaded

[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=25593

allowLinking attribute value is not preserved or ignored after context is reloaded

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Normal



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:51 ---
I'll try to look into it, but I'd like to point out this is not a major issue
even if it's valid. As a workaround, simply redeploy the webapp, which is not
very different from a reload anyway.

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

DO NOT REPLY [Bug 25596] - application briefly unavailable when using manager to reload

[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=25596

application briefly unavailable when using manager to reload





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:52 ---
This works as intended, and this will not be implemented. I belive "waiting" is
actually a bad feature. More robust failover mechanisms should be used instead.

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

DO NOT REPLY [Bug 6649] - jakarta-servletapi-4 build using java 1.4 javadoc errors

[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=6649

jakarta-servletapi-4 build using java 1.4 javadoc errors

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||REMIND



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:54 ---
The tomcat team can't actually fix this. See

http://marc.theaimsgroup.com/?t=10716840481&r=1&w=2

for an explanation of why. I am resolving this as REMIND so we can follow it 
up later.

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

DO NOT REPLY [Bug 25600] - sessionDestroyed method (in HttpSessionListener) is being called twice

[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=25600

sessionDestroyed method (in HttpSessionListener) is being called twice

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:56 ---
Please don't whine, we didn't introduce this bug on purpose just to annoy you,
and the issue has been fixed already. The patch can be applied easily if you
need it.


  Index: StandardManager.java
  ===
  RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- StandardManager.java  29 Nov 2003 18:06:35 -  1.15
  +++ StandardManager.java  5 Dec 2003 09:28:55 -   1.16
  @@ -813,13 +813,7 @@
   for (int i = 0; i < sessions.length; i++) {
   StandardSession session = (StandardSession) sessions[i];
   if (!session.isValid()) {
  -try {
  -expiredSessions++;
  -session.expire();
  -} catch (Throwable t) {
  -log.error(sm.getString
  -  ("standardManager.expireException"), t);
  -}
  +expiredSessions++;
   }
   }
   long timeEnd = System.currentTimeMillis();


*** This bug has been marked as a duplicate of 25234 ***

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

DO NOT REPLY [Bug 25234] - HttpSessionListener called twice on session expiration

[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=25234

HttpSessionListener called twice on session expiration

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 21:56 ---
*** Bug 25600 has been marked as a duplicate of this bug. ***

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets CGIServlet.java

[markt]

markt   2003/12/17 14:06:34

  Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  - Port fix
  - Bug 5759. CGI servlet does not support extension mapping.
  
  Revision  ChangesPath
  1.15  +13 -8 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
  
  Index: CGIServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- CGIServlet.java   12 Dec 2003 22:52:20 -  1.14
  +++ CGIServlet.java   17 Dec 2003 22:06:34 -  1.15
  @@ -804,8 +804,13 @@
*/
   protected void setupFromRequest(HttpServletRequest req) {
   this.contextPath = req.getContextPath();
  -this.pathInfo = req.getPathInfo();
   this.servletPath = req.getServletPath();
  +this.pathInfo = req.getPathInfo();
  +// If getPathInfo() returns null, must be using extension mapping
  +// In this case, pathInfo should be same as servletPath
  +if (this.pathInfo == null) {
  +this.pathInfo = this.servletPath;
  +}
   }
   
   
  
  
  

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

DO NOT REPLY [Bug 5759] - CGI servlet mapping by extension *.cgi does not work

[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=5759

CGI servlet mapping by extension *.cgi does not work

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:08 ---
This has been fixed in CVS and will be available in the next releases of TC4 & 
TC5.

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs class-loader-howto.xml

[markt]

markt   2003/12/17 14:28:19

  Modified:webapps/tomcat-docs class-loader-howto.xml
  Log:
  - Bug 10627. Small path error in class loader how to.
  - Provided by Andrew Conrad.
  
  Revision  ChangesPath
  1.11  +2 -2  jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml
  
  Index: class-loader-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/class-loader-howto.xml,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- class-loader-howto.xml13 Sep 2003 14:57:54 -  1.10
  +++ class-loader-howto.xml17 Dec 2003 22:28:19 -  1.11
  @@ -167,8 +167,8 @@
   in which case you should put them in the Common
   class loader instead).  All unpacked classes and resources in
   $CATALINA_HOME/shared/classes, as well as classes and
  -resources in JAR files under $CATALINA_HOME/lib, are
  -made visible through this class loader.  By default, that includes
  +resources in JAR files under $CATALINA_HOME/shared/lib,
  +are made visible through this class loader.  By default, that includes
   the following:
   
   jasper-compiler.jar - The page compiler classes required
  
  
  

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

DO NOT REPLY [Bug 10627] - incorrect documentation for class-loader-howto.xml

[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=10627

incorrect documentation for class-loader-howto.xml

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:29 ---
You rpatch has been applied to CVS and will be included in the next release of 
TC4.
Many thanks.

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

DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name

[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=20463

Jasper2 ant task generate invalid package name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|Jasper 2|Jasper
Product|Tomcat 4|Tomcat 5
 Resolution|WONTFIX |
Version|4.1.24  |5.0.16



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:32 ---
I get the same behavior with the attached test updated for tomcat 5.0.16.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardContext.java

[remm]

remm2003/12/17 14:39:27

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Set all common resources attributes on start (incl allowLinking).
  - Bug 25593.
  
  Revision  ChangesPath
  1.103 +13 -1 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.102
  retrieving revision 1.103
  diff -u -r1.102 -r1.103
  --- StandardContext.java  27 Nov 2003 00:37:29 -  1.102
  +++ StandardContext.java  17 Dec 2003 22:39:27 -  1.103
  @@ -3847,8 +3847,20 @@
   try {
   ProxyDirContext proxyDirContext =
   new ProxyDirContext(env, webappResources);
  +if (webappResources instanceof FileDirContext) {
  +filesystemBased = true;
  +((FileDirContext) webappResources).setCaseSensitive
  +(isCaseSensitive());
  +((FileDirContext) webappResources).setAllowLinking
  +(isAllowLinking());
  +}
   if (webappResources instanceof BaseDirContext) {
   ((BaseDirContext) webappResources).setDocBase(getBasePath());
  +((BaseDirContext) webappResources).setCached
  +(isCachingAllowed());
  +((BaseDirContext) webappResources).setCacheTTL(getCacheTTL());
  +((BaseDirContext) webappResources).setCacheMaxSize
  +(getCacheMaxSize());
   ((BaseDirContext) webappResources).allocate();
   }
   // Register the cache in JMX
  
  
  

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

DO NOT REPLY [Bug 25593] - allowLinking attribute value is not preserved or ignored after context is reloaded

[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=25593

allowLinking attribute value is not preserved or ignored after context is reloaded

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:39 ---
This is now fixed.

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

DO NOT REPLY [Bug 17716] - setenv.bat File Not found

[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=17716

setenv.bat File Not found

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:41 ---
Setenv is no longer included in the distribution and as AFAIK is no longer 
referred to in the documnetation.

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

DO NOT REPLY [Bug 25603] - HTTPS Connector ignores truststoreFile attribute

[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=25603

HTTPS Connector ignores truststoreFile attribute





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 22:50 ---
I think the implementation for configuring the truststore is missing, except for
is type.

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

DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name

[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=20463

Jasper2 ant task generate invalid package name





--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 23:25 ---
Created an attachment (id=9616)
modified bug demo jar for tomcat5

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

DO NOT REPLY [Bug 20463] - Jasper2 ant task generate invalid package name

[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=20463

Jasper2 ant task generate invalid package name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-12-17 23:39 ---
Note that the supplied jar contains java files generated by tomcat 4, but if you
do an "ant clean" and then an "ant", everyting works as expected.

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

jk2 .. uncomfortably silent ?

[NAIK,ROSHAN (HP-Cupertino,ex1)]

Wonder why questions on jk2 often never get a response. 
Are the relevant developers not active on this list ? 

Even cc-ing the developers who are credited in the relevant source code
doesnt help !!

--Roshan

> -Original Message-
> From: NAIK,ROSHAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 15, 2003 3:48 PM
> To: 'Tomcat Developers List'
> Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> Subject: mod_jk2 .. is 0 a valid child_id ?
> 
> 
> mod_jk2 creates this error long entry each time apache starts up...
> 
> 
> [Mon Dec 15 15:20:17 2003] [error] mod_jk child init 1 0
> 
> 
> The relevant code printing the error is in function 
> jk2_child_init() in
> mod_jk2.c
> 
> static void jk2_child_init(apr_pool_t *pconf, server_rec *s)
> {
>  //...
> 
> if( workerEnv->childId <= 0 ) 
> env->l->jkLog(env, env->l, JK_LOG_ERROR, "mod_jk 
> child init %d
> %d\n",
>   workerEnv->was_initialized, 
> workerEnv->childId );
> }
>  //...
> }
> 
> 
> Here 0 is assumed to be invalud childID. But other parts of 
> the code (in the
> 
> same function) seem to find the childID>=0 to be fine 
> 
> if (workerEnv->childId >= 0) {
> workerEnv->childGeneration =
> ap_scoreboard_image->parent[workerEnv->childId].generation;
> ++ap_scoreboard_image->parent[workerEnv->childId].generation;
> }
> 
> ...
> 
> /* Restore the process generation */
> if (workerEnv->childId >= 0) {
> ap_scoreboard_image->parent[workerEnv->childId].generation =
> workerEnv->childGeneration;
> }
> 
> 
> I am not too clear about the logic ...however it seems like 
> something is 
> not right if thar error is being printed each time apache comes up.
> 
> -- Roshan 
> 
> -
> 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: jk2 .. uncomfortably silent ?

[Martin Gainty]

Tomcat is a child process (ProcessID=0) to HTTP Server
What is your specific concern?
-Martin
- Original Message - 
From: "NAIK,ROSHAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 17, 2003 7:58 PM
Subject: jk2 .. uncomfortably silent ?


> Wonder why questions on jk2 often never get a response. 
> Are the relevant developers not active on this list ? 
> 
> Even cc-ing the developers who are credited in the relevant source code
> doesnt help !!
> 
> --Roshan
> 
> > -Original Message-
> > From: NAIK,ROSHAN (HP-Cupertino,ex1) [mailto:[EMAIL PROTECTED]
> > Sent: Monday, December 15, 2003 3:48 PM
> > To: 'Tomcat Developers List'
> > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
> > Subject: mod_jk2 .. is 0 a valid child_id ?
> > 
> > 
> > mod_jk2 creates this error long entry each time apache starts up...
> > 
> > 
> > [Mon Dec 15 15:20:17 2003] [error] mod_jk child init 1 0
> > 
> > 
> > The relevant code printing the error is in function 
> > jk2_child_init() in
> > mod_jk2.c
> > 
> > static void jk2_child_init(apr_pool_t *pconf, server_rec *s)
> > {
> >  //...
> > 
> > if( workerEnv->childId <= 0 ) 
> > env->l->jkLog(env, env->l, JK_LOG_ERROR, "mod_jk 
> > child init %d
> > %d\n",
> >   workerEnv->was_initialized, 
> > workerEnv->childId );
> > }
> >  //...
> > }
> > 
> > 
> > Here 0 is assumed to be invalud childID. But other parts of 
> > the code (in the
> > 
> > same function) seem to find the childID>=0 to be fine 
> > 
> > if (workerEnv->childId >= 0) {
> > workerEnv->childGeneration =
> > ap_scoreboard_image->parent[workerEnv->childId].generation;
> > ++ap_scoreboard_image->parent[workerEnv->childId].generation;
> > }
> > 
> > ...
> > 
> > /* Restore the process generation */
> > if (workerEnv->childId >= 0) {
> > ap_scoreboard_image->parent[workerEnv->childId].generation =
> > workerEnv->childGeneration;
> > }
> > 
> > 
> > I am not too clear about the logic ...however it seems like 
> > something is 
> > not right if thar error is being printed each time apache comes up.
> > 
> > -- Roshan 
> > 
> > -
> > 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]
> 
> 

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

DO NOT REPLY [Bug 25610] New: - avadocs of TLV.validate() need

[bugzilla]

javadocs of TLV.validate() need to be clarified to match the spec

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=25610

avadocs of TLV.validate() need
javadocs of TLV.validate() need to be clarified to match the spec

   Summary: avadocs of TLV.validate() need
javadocs of TLV.validate() need to be clarified to match
the spec
   Product: Tomcat 5
   Version: 5.0.16
  Platform: All
   URL: http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/jsp/
tagext/TagLibraryValidator.html#validate(java.lang.Strin
g,%20java.lang.String,%20javax.servlet.jsp.tagext.PageDa
ta)
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Excerpts from http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15703 : 


--- Additional Comments From Jan Luehe 2003-12-15 17:54 ---

JSP.13.9.6 mentions that the "uri" parameter in TLV.validate()
corresponds to the taglib's uri in the XML view.

The javadocs of TLV.validate() describe the "uri" param as follows:

 @param uri the tag library's unique identifier
 
The JSP spec lead confirmed that the javadocs of TLV.validate() need
to be clarified to match the spec.

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

DO NOT REPLY [Bug 15703] - Illegal scope attribute without var in "fmt:setLocale" tag

[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=15703

Illegal scope attribute without var in "fmt:setLocale" tag

[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||25610
 Status|NEW |ASSIGNED
  Component|Jasper  |Standard Taglib
Product|Tomcat 5|Taglibs
Version|5.0.16  |1.1



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 03:25 ---
Moved bug back to Jakarta Standard (and create a new Tomcat bug for the javadoc
issue).

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

DO NOT REPLY [Bug 25610] - avadocs of TLV.validate() need

[bugzilla]

javadocs of TLV.validate() need to be clarified to match the spec

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=25610

avadocs of TLV.validate() need
javadocs of TLV.validate() need to be clarified to match the spec

[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||15703
  nThis||

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

DO NOT REPLY [Bug 25610] - javadocs of TLV.validate() need

[bugzilla]

javadocs of TLV.validate() need to be clarified to match the spec

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=25610

javadocs of TLV.validate() need
javadocs of TLV.validate() need to be clarified to match the spec

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|avadocs of TLV.validate()   |javadocs of TLV.validate()
   |need|need
   |javadocs of TLV.validate()  |javadocs of TLV.validate()
   |need to be clarified to |need to be clarified to
   |match the spec  |match the spec

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

DO NOT REPLY [Bug 15703] - Illegal scope attribute without var in "fmt:setLocale" tag

[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=15703

Illegal scope attribute without var in "fmt:setLocale" tag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW

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

cvs commit: jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/tcp Jdk13ReplicationListener.java ReplicationListener.java ReplicationTransmitter.java SimpleTcpCluster.java SocketSender.java TcpReplicationThread.java

[fhanik]

fhanik  2003/12/17 20:20:15

  Modified:modules/cluster/src/share/org/apache/catalina/cluster/io
ObjectReader.java
   modules/cluster/src/share/org/apache/catalina/cluster/mcast
McastService.java McastServiceImpl.java
   modules/cluster/src/share/org/apache/catalina/cluster/tcp
ReplicationListener.java
ReplicationTransmitter.java SimpleTcpCluster.java
SocketSender.java TcpReplicationThread.java
  Added:   modules/cluster/src/share/org/apache/catalina/cluster/io
Jdk13ObjectReader.java
   modules/cluster/src/share/org/apache/catalina/cluster/tcp
Jdk13ReplicationListener.java
  Log:
  adding in a regular io cluster listener to be used with JDK1.3
  
  Revision  ChangesPath
  1.2   +14 -17
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/ObjectReader.java
  
  Index: ObjectReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/ObjectReader.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ObjectReader.java 19 Feb 2003 20:32:10 -  1.1
  +++ ObjectReader.java 18 Dec 2003 04:20:14 -  1.2
  @@ -102,25 +102,22 @@
   return this.channel;
   }
   
  -public boolean append(byte[] data,int off,int len) {
  +public int append(byte[] data,int off,int len) {
   boolean result = false;
   buffer.append(data,off,len);
  -if ( buffer.doesPackageExist() ) {
  +int pkgCnt = 0;
  +boolean pkgExists = buffer.doesPackageExist();
  +while ( pkgExists ) {
   byte[] b = buffer.extractPackage(true);
   callback.messageDataReceived(b);
  -result = true;
  +pkgCnt++;
  +pkgExists = buffer.doesPackageExist();
   }//end if
  -return result;
  +return pkgCnt;
   }
   
  -public boolean execute() {
  -boolean result = false;
  -if ( buffer.doesPackageExist() ) {
  -byte[] data = buffer.extractPackage(true);
  -callback.messageDataReceived(data);
  -result = true;
  -}//end if
  -return result;
  +public int execute() {
  +return append(new byte[0],0,0);
   }
   
   public int write(ByteBuffer buf)
  @@ -131,4 +128,4 @@
   
   
   
  -}
  \ No newline at end of file
  +}
  
  
  
  1.1  
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/Jdk13ObjectReader.java
  
  Index: Jdk13ObjectReader.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/io/Jdk13ObjectReader.java,v
 1.1 2003/12/18 04:20:14 fhanik Exp $
   * $Revision: 1.1 $
   * $Date: 2003/12/18 04:20:14 $
   *
   * 
   *
   * 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 acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIM

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse JSSESocketFactory.java

[billbarker]

billbarker2003/12/17 21:19:47

  Modified:util/java/org/apache/tomcat/util/net/jsse
JSSESocketFactory.java
  Log:
  Adding a 'truststoreType' attribute, and making the trustStorePassword default to 
the keystorePass.
  
  Sort of fix for bug #25603.
  
  Revision  ChangesPath
  1.12  +19 -1 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
  
  Index: JSSESocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/jsse/JSSESocketFactory.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- JSSESocketFactory.java6 Oct 2003 00:08:19 -   1.11
  +++ JSSESocketFactory.java18 Dec 2003 05:19:47 -  1.12
  @@ -102,6 +102,8 @@
   private static final String defaultKeystoreFile
   = System.getProperty("user.home") + "/.keystore";
   private static final String defaultKeyPass = "changeit";
  +static org.apache.commons.logging.Log log =
  +org.apache.commons.logging.LogFactory.getLog(JSSESocketFactory.class);
   
   protected boolean initialized;
   protected boolean clientAuth = false;
  @@ -269,12 +271,28 @@
   if(trustStoreFile == null) {
   trustStoreFile = System.getProperty("javax.net.ssl.trustStore");
   }
  +if(log.isDebugEnabled()) {
  +log.debug("Truststore = " + trustStoreFile);
  +}
   String trustStorePassword = (String)attributes.get("truststorePass");
   if( trustStorePassword == null) {
   trustStorePassword = 
System.getProperty("javax.net.ssl.trustStorePassword");
   }
  +if( trustStorePassword == null ) {
  +trustStorePassword = getKeystorePassword();
  +}
  +if(log.isDebugEnabled()) {
  +log.debug("TrustPass = " + trustStorePassword);
  +}
  +String truststoreType = (String)attributes.get("truststoreType");
  +if(truststoreType == null) {
  +truststoreType = keystoreType;
  +}
  +if(log.isDebugEnabled()) {
  +log.debug("trustType = " + truststoreType);
  +}
   if (trustStoreFile != null && trustStorePassword != null){
  -trustStore = getStore(keystoreType, trustStoreFile,
  +trustStore = getStore(truststoreType, trustStoreFile,
 trustStorePassword);
   }
   
  
  
  

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

DO NOT REPLY [Bug 25603] - HTTPS Connector ignores truststoreFile attribute

[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=25603

HTTPS Connector ignores truststoreFile attribute

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 05:27 ---
I'm marking as FIXED, since now the code matches the docs.  However, it should 
work fine in 5.0.16 as long as you explicity configure the truststorePass on 
the Connector.

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

cvs commit: jakarta-tomcat-catalina/webapps/docs ssl-howto.xml

[billbarker]

billbarker2003/12/17 21:31:48

  Modified:webapps/docs ssl-howto.xml
  Log:
  updating the SSL docs to match the code.
  
  Revision  ChangesPath
  1.10  +2 -1  jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml
  
  Index: ssl-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/ssl-howto.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- ssl-howto.xml 11 Oct 2003 08:52:41 -  1.9
  +++ ssl-howto.xml 18 Dec 2003 05:31:48 -  1.10
  @@ -376,7 +376,8 @@
 
 
  truststorePass
  -   The password to access the TrustStore.
  +   The password to access the TrustStore.  This defaults to the value
  +   of keystorePass.
 
 
  truststoreType
  
  
  

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