DO NOT REPLY [Bug 10321] - Encoding problem in solaris environment (Solaris 2.6)

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

Encoding problem in solaris environment (Solaris 2.6)





--- Additional Comments From [EMAIL PROTECTED]  2002-07-03 06:09 ---
On my Solaris 2.7 box, I have no problems getting Tomcat to guess UTF-8 for 
simple examples.

For a discription of the settings, See:


Things to try:
1) If the page containing the form is a static (i.e. "foobar.html") page, then 
you might want to upgrade to 3.3.1 and take advantage of the useAcceptLanguage 
and/or useCharset attribute of StaticInterceptor.

2) If your entire site uses UTF-8, you could set the defaultEncoding="UTF-8" 
attribute on DecodeInterceptor.

3) If you don't care about portability to other servlet-containers, you could 
modify your servlet to call:
request.setAttribute("charset", "UTF-8");
before any of the parameters are processed.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute("charset", non_string) is called before request.getParameter() call.

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

ClassCastException is thrown when request.setAttribute("charset", non_string) is 
called before request.getParameter() call.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-07-03 05:27 ---
The "charset" attribute is documented at 
, where it also tells you how to change 
the name if you want to use "charset" for yourself.

Given that this particular attribute is supposed to be set by the web-app 
developer (it's the TC 3.3 version of the 2.3 setCharacterEncoding), I think 
that having a simple name is justified.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute("charset", non_string) is called before request.getParameter() call.

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

ClassCastException is thrown when request.setAttribute("charset", non_string) is 
called before request.getParameter() call.





--- Additional Comments From [EMAIL PROTECTED]  2002-07-03 05:26 ---
I'm not sure if anything in Tomcat depends on this behaviour. Anyway, you can
always work around this by using your own unique attibute identifiers. Something
like:

"domain-name.package-name.app-name.charset"

Then it won't get in the way.

Bojan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute("charset", non_string) is called before request.getParameter() call.

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

ClassCastException is thrown when request.setAttribute("charset", non_string) is 
called before request.getParameter() call.





--- Additional Comments From [EMAIL PROTECTED]  2002-07-03 05:02 ---
API doc says containers can use request attributes.  I did not know that.  I was
worrying about the conflicts of the attribute names used by application and
container. 

So, this is not a bug, but the API doc says that the attribute name should
follow the same conventions as package names; i.e. "org.apache..charset".

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[Fwd: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET]

[Sam Ruby]

I've verified this change of behavior between Tomcat 4.0.3 and Tomcat 
4.0.4, and Barry Levinson has tracked down the probable cause.

Despite the omission of the port in Host request headers by Microsoft 
.Net software (VS.NET and WSDL.EXE), Tomcat 4.0.3 was able to properly 
determine the port in calls to HTTPUtils.getRequestURL, Tomcat 4.0.4 
defaults it.

Suggestions?  Why can't Tomcat simply use socket.getPort()?

 Original Message 
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET
Date: Tue, 2 Jul 2002 15:11:38 -0400
From: "Barry Levinson" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>

some more info :

looks like HttpProcessor.java changed in tomcat exposesing this VS .net
bug :
http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/ap
ache/catalina/connector/http/HttpProcessor.java
 > Revision 1.44 / (view) - annotate - [select for diffs] , Thu Feb 28
04:23:17 2002 UTC (4 months ago) by remm
 > Branch: MAIN
 > CVS Tags: jwsdp_10_ea2_10, jwsdp_10_ea2_09, jwsdp_10_ea2_08,
jwsdp_10_ea2_07, jwsdp_10_ea2_06, jwsdp_10_ea2_05
 > Changes since 1.43: +9 -4 lines
 > Diff to previous 1.43 (colored)
 >
 > - Fix bug 6668.
 > - If no port is specified, the default port for the service is assumed.
Note: This
 >   can break broken clients, as it forces them to specify the port in the
host header.
 > - Patch submitted by Craig Setera 

VS .net seems to be "broken" in violation of rfc 2616 section 14.23 :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23

I wonder what the chances of getting MS to fix this are?  Anyone know who
to email a bug report to?

--Barry
-Original Message-
From: Barry Levinson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 2:34 PM
To: [EMAIL PROTECTED]
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET


oops : I'm running tomcat 4.0.4

When I downloaded an ran tomcat 4.0.3, of course VS .net still specifies
the incorrect Host:localhost in the HTTP header, however, tomcat responds
with the correct port in the WSDL.  in 4.0.3 tomcat must get the URL info
from a combination of the connection record, and the URL specified in HTTP
1.1.

I have an additional problem with .net when the wsdl specifies the wrong
URL.  If the URL is not correct, the session is not correctly maintained
from the returned cookie.  This is the case even if I manually change the
URL in the .net generated client stubs.

For now, I'll use < 4.0.4 tomcat.

BTW - is this list moderated?  Why do my emails seem to have a 3-6hr
delay?

--Barry

-Original Message-
From: Barry Levinson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 11:21 AM
To: [EMAIL PROTECTED]
Subject: RE: Strange bug: Axis in Tomcat 4.0.4 and .NET


 >From running tcpmon, it looks like Visual Studio .net doesn't specify the
correct URL in it's HTTP Host: line.  Instead of specifying "Host:
localhost:8081" it specifies "Host: localhost".  This is probably why the
wsdl comes back with the incorrect url.

I'm running tomcat 4.0.3.
I'll download Tomcat 4.0.2 and try it again to see if there are any
differences.

--Barry

-Original Message-
From: Sam Ruby [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 10:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Strange bug: Axis in Tomcat 4.0.4 and .NET


Arne M. Degenring wrote:
 > Hi everybody,
 >
 > I recently upgraded to Tomcat 4.0.4 and found out a problem with .NET.
 > I'm running Tomcat on port 8081. When I access a WSDL file via IE 6.0
 > at:
 >
 > http://localhost:8081/axis/services/SomeWS?wsdl
 >
 > I get back the WSDL file which contains the correct adress location:
 >
 >  location="http://localhost:8081/axis/services/SomeWS"/>
 >
 > No problem so far. BUT: When I access the same WSDL URL from the
 > Microsoft .NET platform, e.g. via .NET WebService Studio or via .NET's
 > wsdl.exe tool, the port number is missing in the WSDL's adress
 > location!!
 >
 > http://localhost/axis/services/SomeWS"/>
 >
 > .NET's generated proxy class (SubmitWSService.cs) does not work, of
 > course, because of the missing port number. This strange behaviour first
 > occured after I upgraded to Tomcat 4.0.4. No problem with 4.0.3.
 >
 > BTW: I'm using the Axis build 2002-07-01.
 >
 > Any ideas?

I'll try to reproduce.  I've verified that 2002-07-01 w/Tomcat 4.0.3
works, running wsdl.exe against
http://nagoya.apache.org:5049/axis/services/SoapInteropImport1Port?wsdl

results in

  public Import1() {
  this.Url =
"http://nagoya.apache.org:5049/axis/services/SoapInteropImport1Port";;
  }

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: servlet authentication

[Michael Bergknoff]

Looks like you're right.

Thanks,
Mike

>From: Kevin Seguin
>Subject: RE: servlet authentication
>Date: Tue, 02 Jul 2002 02:39:06 -0700
>
>i could be wrong, but i think once you call
sendError(), the response is committed and
>you cannot set any more headers.  try reversing the
order of the
>sendError()/setHeader() calls:
>
> response.setHeader("WWW-Authenticate", "BASIC
realm=\"test\"");
> response.sendError(response.SC_UNAUTHORIZED);
>
>> -Original Message-
>> From: Michael Bergknoff [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, July 01, 2002 9:02 PM
>> To: [EMAIL PROTECTED]
>> Subject: servlet authentication
>>
>>
>> To test servlet-based authentication, I have a two
>> line servlet.
>>
response.sendError(response.SC_UNAUTHORIZED);
>> response.setHeader("WWW-Authenticate",
"BASIC
>> realm=\"test\"");
>>
>> Here is the output I get:
>> $ telnet localhost 8080
>> Trying 127.0.0.1...
>> Connected to localhost.
>> Escape character is '^]'.
>> GET /myapp/servlet
>> Apache Tomcat/4.0.3 - Error
>> report
>> Apache Tomcat/4.0.3 - HTTP Status
401
>> - Unauthorizedtype
>> Status reportmessage
>> Unauthorizeddescription
This
>> request requires HTTP authentication>>
(Unauthorized).> noshade>Connection closed by foreign
>> host.
>>
>> The output contains no HTTP headers, just some
Tomcat
>> generated HTML. Is this a bug in my servlet test or
>> what?
>>
>> Thanks,
>> Mike





__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] Apache Tomcat 5.0 Proposal

[costinm]

On Tue, 2 Jul 2002, Remy Maucherat wrote:

> After trying to address the concerns raised by the proposal draft, I 
> would like to call for a vote on it, now that the discussions have died 
> down.
> 
> 
> [X] +1 I support the proposal, and will help implement it
> [ ] +0 I support the proposal
> [ ] -0 I do not support the proposal
> [ ] -1 I am against the proposal being implemented, because:
> 
> 
> 
> 
> The vote will run for one full week until July 9th. Users and other 
> contributors may vote, but only committers have binding votes.

I won't read the mail for the rest of the week ( I'll be back next Mon ).

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 9941] - Jasper in Tomcat 4.1.2 throws JasperExcepetion when comiling JSP'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://nagoya.apache.org/bugzilla/show_bug.cgi?id=9941

Jasper in Tomcat 4.1.2 throws JasperExcepetion when comiling JSP's

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[VOTE] Apache Tomcat 5.0 Proposal

[Remy Maucherat]

After trying to address the concerns raised by the proposal draft, I 
would like to call for a vote on it, now that the discussions have died 
down.


[ ] +1 I support the proposal, and will help implement it
[ ] +0 I support the proposal
[ ] -0 I do not support the proposal
[ ] -1 I am against the proposal being implemented, because:




The vote will run for one full week until July 9th. Users and other 
contributors may vote, but only committers have binding votes.

Remy




Proposal for Apache Tomcat 5.0
==



Introduction:


This document is a proposal for the next major release of Apache Tomcat, 
Apache Tomcat 5.0.

Apache Tomcat 5.0 will improve on the Apache Tomcat 3.3 and Apache
Tomcat 4.1 architectures, by making them simpler, more flexible and more 
modular, while at the same time adding support for the new Servlet API 2.4 and
JSP 2.0 specifications, currently under development by the Java Community 
Process.

The major goals for Apache Tomcat 5.0 are to:
- improve scalability, reliability and performance over previous versions
- have simpler/cleaner code, so more people can get involved
- merge of the various ideas in 3.x and 4.x
- get the community togheter
- provide maximum modularity and compliance to the standards
- make it easy to continue to maintain the existing codebases

Testing will occur to make sure the stated robustness and performance goals
are met by Tomcat 5.0.

This proposal also tries to take advantage of the lessons learned while 
optimizing and maintaining Tomcat.

Note: The development of Apache Tomcat 4.1.x will continue in parallel to the 
implementation of this proposal.



General architecture:



An improved version of Coyote 1.0, called Coyote 2.0, will be used as 
the Apache Tomcat 5.0 core.

Coyote is currently considered a connector for Tomcat 3.3 and 4.x, and is under
development in the jakarta-tomcat-connectors repository.

Coyote 1.0 includes:
- Protocol handlers for AJP 1.3, HTTP/1.1 and JNI
- Adapter for Tomcat 3.3
- Adapter for Tomcat 4.x

Extensibility capabilities will be added to Coyote, as well as JMX management
features, and if possible, addional protocol handlers (like WARP 1.0).

The Servlet API 2.4 specification will be implemented in a new version of 
Catalina, called Catalina 2.0. A new version of the Coyote adapter will be
written for it if mandated by API changes. Components which duplicate 
functionality provided by Coyote will be removed, including the old connectors.

On the JSP side, Jasper 2 will be updated to support JSP 2.0, will be renamed 
to Jasper 3, and is the proposed Jasper codebase. It provides many 
improvements over Jasper 1 included in Tomcat 3.x and Tomcat 4.0.x, including 
good tag library handling, and near zero overhead when compared to 
an equivalent hand coded servlet. Jasper 2 will also undergo additional 
optimizations.

Apache Tomcat 5.0 will be made by default of the following components:
- Coyote 2.0 - core
- Catalina 2.0 - Servlet API 2.4 implementation
- Jasper 2 - JSP 2.0 implementation

Many other configurations are also possible, and it is expected that advanced
users take advantage of it to make Tomcat better suit their needs. It is also
possible that new special purpose components, like a bare bones Servlet API 
implementation, be developed to address the embedded market.

Due to the scope of this work, this initial Proposal only plans 
the implementation and support of the default configuration described above.



Changes over Apache Tomcat 4.1.x:



A lot of the Apache Tomcat 5.0 code will be based on the Apache Tomcat 4.1.x 
codebase. Tomcat 5.0 will also be able to use the Tomcat 3.3.x code.

The following major changes and additions are proposed to the current Apche
Tomcat code, and related dependencies:

A) Removal of the org.apache.catalina.connector.*

This package is currently deprecated in Tomcat 4.1 because of 
its implementation inefficiencies, and general bad design. It is thus proposed
that it is removed in Tomcat 5.0.

B) Addition of new loader code for the commons-daemon subproject

It is proposed that, in an attempt to solve the problems with using startup 
scripts, as well as adding additional features oriented towards reliability
(including the capability to restart Tomcat automatically should the JVM
crashes or experience memory management related problems), the launcher code
which will be developed as part of commons-daemon be adopted.
This code will be based in part on the launcher code used for the Sun Web
Services Pack, and in part on the Wrapper project code (available at SF.net),
if we manage to come to an agreement with the Wrapper developers.

C) Extensions to Coyote

It is proposed that Coyote 2.0 include the following changes over Coyote 1.0:
- The current hook mechanism used in Coyote 1.0 will be extended to be 
more generic and powerful.
- It is also

cvs commit: jakarta-tomcat-4.0 PROPOSAL-5.0.txt

[remm]

remm2002/07/02 16:42:47

  Modified:.PROPOSAL-5.0.txt
  Log:
  - Add links to the specification drafts.
  
  Revision  ChangesPath
  1.4   +5 -1  jakarta-tomcat-4.0/PROPOSAL-5.0.txt
  
  Index: PROPOSAL-5.0.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/PROPOSAL-5.0.txt,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- PROPOSAL-5.0.txt  28 Jun 2002 17:47:15 -  1.3
  +++ PROPOSAL-5.0.txt  2 Jul 2002 23:42:47 -   1.4
  @@ -127,12 +127,16 @@
   limited, and shouldn't cause any major architectural changes in Catalina.
   Catalina 2.0 will also inherit from all the refactorings done in Catalina 1.1.
   
  +Servlet 2.4 Specification Draft:
  +http://jcp.org/aboutJava/communityprocess/review/jsr154/index.html
  +
   E) Implementation of the JSP 2.0 Specification
   
   Jasper 2 will be modified to support the new JSP Specification. More important
   changes will be required than for supporting the new Servlet Specification.
   
  -
  +JSP 2.0 Specification Draft:
  +http://jcp.org/aboutJava/communityprocess/review/jsr152/index.html 
   
   Resources needed:
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [4.1.6] Milestone available for testing

[Craig R. McClanahan]

On Tue, 2 Jul 2002, Chad Johnson wrote:

> Date: Tue, 2 Jul 2002 10:53:32 -0500
> From: Chad Johnson <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [4.1.6] Milestone available for testing
>
> Hey,
>   I may have missed something obvious, but if I didn't, are there plans to
> add context reset/stop/start to the new administration webapp?
>

Those facilities are all available in the Manager webapp.  Because manager
is accessed via HTTP, it is very easy to integrate these capabilities into
your development environment -- for example, 4.1.x includes custom Ant
tasks that install/reload/remove apps directly from your build.xml file,
and the deploytool that ships with the Java Web Services Developer Pack
(JWSDP)  uses them behind the scenes to
provide a GUI experience people packaging and deploying web applications.

> -Chad Johnson

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Question about patch submission

[Martin van den Bemt]

Putting the patch in bugzilla makes it easier to track and cannot get
lost that way ;-)

Mvgr,
Martin

On Wed, 2002-07-03 at 01:10, Russ Trotter wrote:
> Hey all,
> 
>   Quick question about patch submission:  I submitted a patch a week or so ago 
> and was curious if it was even received or acknowledged or anything or simply 
> diverted to /dev/null.  If it was rejected is there any protocol for the 
> submitter getting notice or anything?
> 
> thx,
> russ
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: 4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> Remy: I just fixed one serious bug in jk2/java ( the one reported by 
> David Oxley ). I think we need a 4.1.7 for that ( and possibly other
> bug fixes ). We are pretty close IMHO.
> 
> Henri: what about tagging the workspace for mod_jk1 with 1.2.0, 
> and use the same naming convention as in 4.1.x.
> 
> Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone'
> style, and mod_jk2.0.0 will be the first tagged milestone. There is
> no need for anything fancy - it's just an alpha release.
> 
> I think we should try to synchronize a bit - and maybe tag jk1.2.0 
> and jk2.0.0 at the same time with 4.1.7.  

Ok. I'll see if there are some other critical fixes that are needed to 
4.1.6. So far, I didn't get any report of serious problems (except DBCP 
issues; I'll update again to pick up the latest changes; Glenn, could 
you comment on that if you're around ?), so I'd say it looks good and 
I'll do the release (and I hope it will be beta worthy :-D).

We'll have to go do a cleanup of Bugzilla someday. Many bugs there are 
not relevant to 4.1.x, though. I'll try to update the version of those 
which are confirmed or in need of a review to be to a 4.1.x number.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10405] - ClassCastException is thrown when request.setAttribute("charset", non_string) is called before request.getParameter() call.

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

ClassCastException is thrown when request.setAttribute("charset", non_string) is 
called before request.getParameter() call.





--- Additional Comments From [EMAIL PROTECTED]  2002-07-02 23:12 ---
DecodeInterceptor expects charset to be a String. Why do need it to be an Object?

Bojan

PS. Here is that line of code:
--
charset=(String)req.getAttribute( charsetAttribute );
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Question about patch submission

[Russ Trotter]

Hey all,

  Quick question about patch submission:  I submitted a patch a week or so ago 
and was curious if it was even received or acknowledged or anything or simply 
diverted to /dev/null.  If it was rejected is there any protocol for the 
submitter getting notice or anything?

thx,
russ

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: 4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0

[Brian P. Millett]

On Tue, 2002-07-02 at 15:47, [EMAIL PROTECTED] wrote:
> Remy: I just fixed one serious bug in jk2/java ( the one reported by 
> David Oxley ). I think we need a 4.1.7 for that ( and possibly other
> bug fixes ). We are pretty close IMHO.
> 
> Henri: what about tagging the workspace for mod_jk1 with 1.2.0, 
> and use the same naming convention as in 4.1.x.
> 
> Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone'
> style, and mod_jk2.0.0 will be the first tagged milestone. There is
> no need for anything fancy - it's just an alpha release.
> 
> I think we should try to synchronize a bit - and maybe tag jk1.2.0 
> and jk2.0.0 at the same time with 4.1.7.  

For what it is worth, here are two patches (not pretty) to get the
tomcat 4.1.6-LE-jdk1.4 to compile with the struts-1.1-b1.  Don't know if
you want this for 4.1 final.

--- jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/build.xml~  Fri Jun
28 11:03:48 2002
+++ jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/build.xml   Sat Jun 29
17:27:13 2002
@@ -22,6 +22,7 @@
 
 
 
+
   
 
 
@@ -140,6 +141,7 @@
   
   
 
+
 
 
 


AND:
---
jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java~
  Fri Jun 28 11:03:48 2002
+++
jakarta-tomcat-4.1.6-LE-jdk14-src/webapps/admin/WEB-INF/classes/org/apache/webapp/admin/AttributeTag.java
   Sat Jun 29 17:07:50 2002
@@ -70,8 +70,7 @@
 import javax.servlet.jsp.JspWriter;
 import javax.servlet.jsp.PageContext;
 import javax.servlet.jsp.tagext.TagSupport;
-import org.apache.struts.util.PropertyUtils;
-
+import org.apache.commons.beanutils.PropertyUtils;
 
 /**
  * Custom tag that retrieves a JMX MBean attribute value, and writes it

 
-- 
Brian Millett
Enterprise Consulting Group   "Shifts in paradigms
(314) 205-9030   often cause nose bleeds."
[EMAIL PROTECTED]   Greg Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

4.1.7 / mod_jk 1.2.0 / mod_jk 2.0.0

[costinm]

Remy: I just fixed one serious bug in jk2/java ( the one reported by 
David Oxley ). I think we need a 4.1.7 for that ( and possibly other
bug fixes ). We are pretty close IMHO.

Henri: what about tagging the workspace for mod_jk1 with 1.2.0, 
and use the same naming convention as in 4.1.x.

Nacho, Mladen: same thing for mod_jk2 - we should use the 'milestone'
style, and mod_jk2.0.0 will be the first tagged milestone. There is
no need for anything fancy - it's just an alpha release.

I think we should try to synchronize a bit - and maybe tag jk1.2.0 
and jk2.0.0 at the same time with 4.1.7.  


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10425] New: - Null Pointer Exception on all requests to tomcat after start

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

Null Pointer Exception on all requests to tomcat after start

   Summary: Null Pointer Exception on all requests to tomcat after
start
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote HTTP/1.1
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Quite often when i start Tomcat I make a http request to the server and on the 
server side the following exception prints out.  On the client side the 
browser just sits awaiting a response from Tomcat till it times out.  This 
occurs till the server is restarted, it does not recover from the error.

Exception on the console:
java.lang.NullPointerException
at java.io.Writer.write(Writer.java:126)
at java.io.PrintWriter.newLine(PrintWriter.java:254)
at java.io.PrintWriter.println(PrintWriter.java:405)
at java.io.PrintWriter.println(PrintWriter.java:516)
at org.apache.catalina.logger.LoggerBase.log(LoggerBase.java:262)
at org.apache.catalina.connector.http.HttpProcessor.log
(HttpProcessor.java:421)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1026)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1107)
at java.lang.Thread.run(Thread.java:536)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10423] New: - Premature packet header end

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

Premature packet header end

   Summary: Premature packet header end
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
   URL: http://www.challenger.com
OS/Version: Linux
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


This seems similiar to bug#3509 but here is my story. I'm using tomcat 4.0.3 
final, apache 1.3.26, redhat linux 7.3.

In my 'apache_log__mm_dd' log file I get this error/warning (at the bottom 
of this)

>From my research I really couldn't find much. One comment somewhere in bugzilla 
said this wasn't a bug, just a warning. (I can't find that same message)

My site works from what I can determine from my testing, I just want to make 
sure that my customers aren't seeing any sort of errors when viewing the static 
and java servlet pages.

Thanks!

...
2002-07-02 15:14:11 WarpEngine[www.challenger.com]: Mapping request
2002-07-02 15:14:11 WarpHost[www.challenger.com]: Mapping request for Host
2002-07-02 15:14:26 WarpEngine[www.challenger.com]: Mapping request
2002-07-02 15:14:26 WarpHost[www.challenger.com]: Mapping request for Host
2002-07-02 15:16:23 [org.apache.catalina.connector.warp.WarpConnector] 
Connection from 10.10.10.2/10.10.10.2:33437 to 10.10.10.2/10.10.10.2:8008
2002-07-02 15:16:23 
[org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings 
(0)
2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConnector] 
Connection from 10.10.10.2/10.10.10.2:33438 to 10.10.10.2/10.10.10.2:8008
2002-07-02 15:16:24 [org.apache.catalina.connector.warp.WarpConnector] 
Connection from 10.10.10.2/10.10.10.2:33439 to 10.10.10.2/10.10.10.2:8008
2002-07-02 15:16:24 
[org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings 
(0)
2002-07-02 15:16:24 
[org.apache.catalina.connector.warp.WarpConfigurationHandler] Filter mappings 
(0)
2002-07-02 15:16:40 [org.apache.catalina.connector.warp.WarpConnection] 
Exception on socket
java.io.IOException: Premature packet header end
at org.apache.catalina.connector.warp.WarpConnection.recv
(WarpConnection.java:237)
at org.apache.catalina.connector.warp.WarpRequestHandler.handle
(WarpRequestHandler.java:112)
at org.apache.catalina.connector.warp.WarpConnection.run
(WarpConnection.java:194)
at java.lang.Thread.run(Thread.java:479)

2002-07-02 15:16:42 [org.apache.catalina.connector.warp.WarpConnection] 
Exception on socket
java.io.IOException: Premature packet header end
at org.apache.catalina.connector.warp.WarpConnection.recv
(WarpConnection.java:237)
at org.apache.catalina.connector.warp.WarpRequestHandler.handle
(WarpRequestHandler.java:112)
at org.apache.catalina.connector.warp.WarpConnection.run
(WarpConnection.java:194)
at java.lang.Thread.run(Thread.java:479)

2002-07-02 15:16:44 [org.apache.catalina.connector.warp.WarpConnection] 
Exception on socket
java.io.IOException: Premature packet header end
at org.apache.catalina.connector.warp.WarpConnection.recv
(WarpConnection.java:237)
at org.apache.catalina.connector.warp.WarpRequestHandler.handle
(WarpRequestHandler.java:112)
at org.apache.catalina.connector.warp.WarpConnection.run
(WarpConnection.java:194)
at java.lang.Thread.run(Thread.java:479)

2002-07-02 15:26:24 WarpEngine[www.challenger.com]: Mapping request
2002-07-02 15:26:24 WarpHost[www.challenger.com]: Mapping request for Host
2002-07-02 15:26:25 WarpEngine[www.challenger.com]: Mapping request
2002-07-02 15:26:25 WarpHost[www.challenger.com]: Mapping request for Host
2002-07-02 15:52:29 WarpEngine[www.challenger.com]: Mapping request
2002-07-02 15:52:29 WarpHost[www.challenger.com]: Mapping request for Host

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java

[costin]

costin  2002/07/02 13:00:16

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  No comment...
  
  Revision  ChangesPath
  1.18  +1 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ChannelSocket.java2 Jul 2002 19:58:27 -   1.17
  +++ ChannelSocket.java2 Jul 2002 20:00:15 -   1.18
  @@ -209,7 +209,7 @@
   tp.setDaemon( b );
   }
   
  -public void getDaemon() {
  +public boolean getDaemon() {
   return tp.getDaemon();
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java

[costin]

costin  2002/07/02 12:58:27

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
   jk/java/org/apache/jk/server JkMain.java
  Log:
  Add support for the daemon setting.
  
  Minor fix in JkMain
  
  Revision  ChangesPath
  1.17  +11 -0 
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- ChannelSocket.java2 Jul 2002 16:57:30 -   1.16
  +++ ChannelSocket.java2 Jul 2002 19:58:27 -   1.17
  @@ -201,6 +201,17 @@
   public int getInstanceId() {
   return port-startPort;
   }
  +
  +/** If set to false, the thread pool will be created in
  + *  non-daemon mode, and will prevent main from exiting
  + */
  +public void setDaemon( boolean b ) {
  +tp.setDaemon( b );
  +}
  +
  +public void getDaemon() {
  +return tp.getDaemon();
  +}
   
   /*   */
   ServerSocket sSocket;
  
  
  
  1.27  +1 -0  
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java
  
  Index: JkMain.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkMain.java,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- JkMain.java   5 Jun 2002 21:24:29 -   1.26
  +++ JkMain.java   2 Jul 2002 19:58:27 -   1.27
  @@ -208,6 +208,7 @@
   // XXX use IntrospectionUtil to find myself
   this.guessHome();
   }
  +home=wEnv.getJkHome();
   if( home != null ) {
   File hF=new File(home);
   File conf=new File( home, "conf" );
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

[costin]

costin  2002/07/02 12:57:49

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
  Log:
  Allow customization of thread.setDaemon().
  
  Previous versions of TP set all the threads in non-daemon mode, but
  this can create restart problems in some cases. However non-daemon mode
  is usefull in some cases
  
  Revision  ChangesPath
  1.3   +19 -4 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ThreadPool.java   22 Apr 2002 18:55:56 -  1.2
  +++ ThreadPool.java   2 Jul 2002 19:57:49 -   1.3
  @@ -125,6 +125,9 @@
*/
   protected boolean stopThePool;
   
  +/* Flag to control if the main thread is 'daemon' */
  +protected boolean isDaemon=true;
  +
   static int debug=0;
   
   /**
  @@ -176,6 +179,18 @@
   return maxSpareThreads;
   }
   
  +/** The default is true - the created threads will be
  + *  in daemon mode. If set to false, the control thread
  + *  will not be daemon - and will keep the process alive.
  + */
  +public void setDaemon( boolean b ) {
  +isDaemon=b;
  +}
  +
  +public boolean getDaemon() {
  +return isDaemon;
  +}
  +
   //
   // You may wonder what you see here ... basically I am trying
   // to maintain a stack of threads. This way locality in time
  @@ -395,7 +410,7 @@
   shouldTerminate = false;
   this.p = p;
   t = new Thread(this);
  -t.setDaemon(true);
  +t.setDaemon(p.getDaemon() );
t.setName( "MonitorRunnable" );
   t.start();
   }
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java

[costin]

costin  2002/07/02 12:56:24

  Modified:util/java/org/apache/tomcat/util/mx DynamicMBeanProxy.java
  Log:
  Few changes to delay the introspection until it is neede.
  
  Revision  ChangesPath
  1.3   +10 -2 
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java
  
  Index: DynamicMBeanProxy.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/mx/DynamicMBeanProxy.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- DynamicMBeanProxy.java6 Jun 2002 22:17:00 -   1.2
  +++ DynamicMBeanProxy.java2 Jul 2002 19:56:24 -   1.3
  @@ -79,7 +79,7 @@
   Object real;
   String name;
   
  -Method methods[];
  +Method methods[]=null;
   
   Hashtable attMap=new Hashtable();
   
  @@ -166,7 +166,10 @@
*/
   public void setReal( Object realBean ) {
   real=realBean;
  +}
   
  +private void init() {
  +if( methods!=null ) return;
   methods = real.getClass().getMethods();
   for (int j = 0; j < methods.length; ++j) {
   String name=methods[j].getName();
  @@ -213,7 +216,6 @@
   continue;
   invokeAttMap.put( name, methods[j]);
   }
  -
   }
   }
   
  @@ -226,6 +228,9 @@
*   
*/
   public MBeanInfo getMBeanInfo() {
  +if( methods==null ) {
  +init();
  +}
   try {
   MBeanAttributeInfo attributes[]=new MBeanAttributeInfo[attMap.size()];
   
  @@ -272,6 +277,7 @@
   public Object getAttribute(String attribute)
   throws AttributeNotFoundException, MBeanException, ReflectionException
   {
  +if( methods==null ) init();
   Method m=(Method)getAttMap.get( attribute );
   if( m==null ) throw new AttributeNotFoundException(attribute);
   
  @@ -291,6 +297,7 @@
   public void setAttribute(Attribute attribute)
   throws AttributeNotFoundException, InvalidAttributeValueException, 
MBeanException, ReflectionException
   {
  +if( methods==null ) init();
   Method m=(Method)setAttMap.get( attribute.getName() );
   if( m==null ) throw new AttributeNotFoundException(attribute.getName());
   
  @@ -316,6 +323,7 @@
   public Object invoke(String method, Object[] arguments, String[] params)
   throws MBeanException, ReflectionException
   {
  +if( methods==null ) init();
   Method m=(Method)invokeAttMap.get( method );
   if( m==null ) return null;
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/conf tomcat-jk2.manifest

[costin]

costin  2002/07/02 12:45:50

  Modified:jk   build.xml
  Added:   jk/conf  tomcat-jk2.manifest
  Log:
  Added a manifest for tomcat-jk2. It sets a minimal classpath and starts JkMain
  
  Revision  ChangesPath
  1.45  +1 -2  jakarta-tomcat-connectors/jk/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/build.xml,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- build.xml 23 Jun 2002 19:04:48 -  1.44
  +++ build.xml 2 Jul 2002 19:45:49 -   1.45
  @@ -99,8 +99,6 @@

   

  -



  @@ -190,6 +188,7 @@
   


   
   
  
  
  
  1.1  jakarta-tomcat-connectors/jk/conf/tomcat-jk2.manifest
  
  Index: tomcat-jk2.manifest
  ===
  Main-Class: org.apache.jk.server.JkMain
  Class-Path: tomcat-util.jar workers.jar ../classes/ commons-logging.jar log4j.jar
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [DOCS] Tyrex-Tomcat HOWTO

[David Haraburda]

Thanks for fixing up my XML typos.

I guess I personally don't really care where the Tyrex HOWTO goes.. Tyrex is a bit
different though, so it may belong somewhere
else.  Only one comment:  you put my Tyrex stuff under "Tyrex Connection Pool and
Castor ORM with mysql", and this is an inaccurate title.  Tyrex is more than
connection pooling, and it doesn't have anything to do with (at least the example
doesn't) Castor ORM.  Also, I didn't really mean for it to serve as an example for
MySQL, because I didnt actaully test that config.

That's my $0.02 about it :-)

Thanks,

David

Les Hughes wrote:

> David / All,
>
> Had problems rendering your doc so I've patched it onto the end of mine and
> cleaned up the XML so that it styles up OK. Here it is.
>
> Comments?
>
> Les
>
> PS I will stop moaning about getting this committed, I promise... :-)
>
> > -Original Message-
> > From: Les Hughes [mailto:[EMAIL PROTECTED]]
> > Sent: 02 July 2002 13:29
> > To: 'Tomcat Developers List'
> > Subject: RE: [DOCS] Tyrex-Tomcat HOWTO
> >
> >
> > Hi all,
> >
> > Could we add this into the JNDI Datasources HOWTO that I
> > wrote the other
> > week (I dont think this has been committed yet BTW)
> >
> > If someone can commit my HOWTO, I'll merge the two together
> > and submit a
> > patch this afternoon.
> >
> > Hope this is OK
> >
> > Les
> >
> >
> >
> > > -Original Message-
> > > From: David Haraburda [mailto:[EMAIL PROTECTED]]
> > > Sent: 28 June 2002 20:05
> > > To: [EMAIL PROTECTED]
> > > Subject: [DOCS] Tyrex-Tomcat HOWTO
> > >
> > >
> > > Hi all,
> > >
> > > Here is a short HOWTO I've written on how to use Tyrex 1.0
> > with Tomcat
> > > 4.1 (which goes along with the patch I submitted, which was just
> > > recently committed).  I've added the appropriate XML tags, using the
> > > other HOWTOs as examples, so very little modification should
> > > be needed.
> > > Feedback on the content however, is greatly appreciated. :-)
> > >
> > > Thanks,
> > >
> > > David
> > >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>   
>  Name: jndi-datasource-examples-howto.xml
>jndi-datasource-examples-howto.xmlType: XML Document (text/xml)
>  Encoding: quoted-printable
>
>   
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 7588] - Session cannot be established if there are multiple session cookies

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

Session cannot be established if there are multiple session cookies





--- Additional Comments From [EMAIL PROTECTED]  2002-07-02 17:23 ---
This is a Bug, that manifests itself in Bug #10419. Only the first cookie with 
a session-id is taken from the response, but it is not checked, whether this 
is a valid session within that context.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10419] New: - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions

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

Session-ID grabbing from Request accepts invalid session cookies in presense of valid 
URL sessions

   Summary: Session-ID grabbing from Request accepts invalid session
cookies in presense of valid URL sessions
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
   URL: http://www.freiheit.com/users/hzeller/SessionBugDemonstr
ation.java
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


[ Applies to current 4.1 CVS as well ] 
There is a bug in the way, the session id is grabbed 
from the request. If there is more than one session id in the request 
-- in the URL and a Cookie, for instance -- the session id found in the 
cookie _always_ wins. This is a problem, if the browsers sends an 
invalidated cookie and you choose to use URL-encoding in a later session: 
even if the session id from the URL (via encodeURL(), that works only 
after fixing Bug #1) is valid, the application always gets the old 
and invalid session from the cookie instead of the valid session from the 
URL. 
 
The expected behaviour of course is: give preference to valid session 
id's if we get more than one session id. 
 
The current session id grabbing-from-http-request algorithm is as follows 
(from HttpProcessor.java) 
 
1. get the session ID from the URL, if any. 
 [HttpProcessor.parseRequest()] 
 
2. go through the cookies. If there is _any_ 
   jsessionid - grab the _first one_ and 
   override the jsession-id found in the 
   URL unconditionally. And set 
  request.setRequestedSessionCookie(true); 
  request.setRequestedSessionURL(false); 
   even if the jsession id found in the 
   cookie is the _same_ as found in the URL, 
   in that case it should be 
   setRequestedSessionURL(true). 
 [HttpProcessor.parseHeaders()] 
- 
 
However, it should be something like: 
- 
1. get the jsessionid from the URL, if any. 
   if found there, setRequestedSessionURL(true) 
   else setRequestedSessionURL(false) 
2. go through the cookies. 
   FOREACH jsessionid found in the cookies: 
 IF the sessionid found is valid in that context 
IF   found session id equals id already in request 
   setRequestedSessionCookie(true) 
ELSE  (* see below) 
   override the session id in request with the cookie-value 
   setRequestedSessionCookie(true) 
   setRequestedSessionURL(false) 
ENDIF 
BREAK FOREACH 
  ELSE IF we have not found any session id before 
   (either from URL or a previous cookie) 
   // set at least some session id 
   set the session id from the cookie 
   setRequestedSessionCookie(true) 
   END FOREACH 
- 
This makes sure, that we find the valid session id, if there is more than 
one session. 
 
 
   I'd even suggest to give a higher priority to the 
   URL encoded session: if the session id found in the URL is _valid_, 
   then ignore any valid session id in the cookies unless it is the same. 
   This enables to have two independant web-application instances in the 
   same browser: one with cookie, and one with URL-encoding (otherwise this 
   mode only works with two applications both with URL-encoding). 
   This behaviour can be implemented by adding 
   -- 
 IF not request.isRequestedSessionIdValid() 
   -- 
   at the point denoted with (*) above. 
 
 
In an attempt to fix this bug myself, I found, that at that stage it is 
not yet possible to check whether isRequestedSessionIdValid() 
[ implementation in HttpRequestBase ], since the context is not yet set 
in the HttpProcessor.process() stage -- so we don't have 
the manager and cannot check the session ID in that context for validity. 
The context is set much later in the processing in 
StandardHostMapper.map() after having gone through several 
valves/Pipelines. 
Since I don't know the internals of the tomcat (yet) I have no quick fix 
at hand, but for you guys its probably no big deal. Or give me an hint - 
then I'll fix it myself. 
 
To demonstrate this and the previously posted bug, I've written a small 
servlet, that goes 
through several steps to create two sessions; one as cookie, one with URL 
rewriting - just follow the instructions the servlet gives. 
Note, that Bug #2 can only be checked thoroughly if Bug #1 has been fixed; 
otherwise Bug #1 does not do URL-encoding in the first place.

--
To unsubscribe, e-mail:   

Re: PROPOSAL: 5.0 configuration

[costinm]

On Tue, 2 Jul 2002, Remy Maucherat wrote:

> [EMAIL PROTECTED] wrote:
> > The basic idea is to use a 2-layer configuration mechansim, 
> > with a pluggable repository for preferene storage and 
> > JMX-based component configuration.
> 
> That seems like a very good idea to me. In Tomcat 4.1, there's currently 
> a big difference configuration-wise when you embed Tomcat when compared 
> to when you run it standalone; I think this is a problem.
> Another problem of the current config mechanism is that it is hardcoded 
> for the digester, and is therefore is limited. The mechanisms to save 
> back the configuration are also hackish and limited.

Saving the configuration is what got me started. Beeing able to integrate
configuration for multiple 'domains' ( tomcat, jk, logging, etc ) was
the other big itch.

> +1. This looks like a welcome step forward, and is well worth the effort.
> 
> I don't see anything in the proposal which mentions removing the current 
> configuration mechanisms; would you leave it there for compatibility ?

I think learned something in the last years :-) 

No, I plan to minimize the changes ( hopefully none will be required in 
existing code ), and I'll certainly not touch the existing config 
mechanism.

Tomcat already follow the right patterns ( i.e. beans, setters, etc ),
and all components are also JMX enabled now - so no changes in tomcat
are needed.

This will happen in util, as a new package - most likely an API based 
on util.prefs and an implementation based on code in jk2. When ready
I'll first enable jk to use it, then probably I'll have to make few
minor changes in Startup/Main. 

An intersting point - JMX has a nice notification mechanism. There are
few problems - the attribute change notification is optional - but
since we 'instrument' using modeler and dynamic mbeans we can intercept
all the config changes done directly by JMX and persist them too. 

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [PATCH] Re: SSI Servlet has big problems

[Bill Barker]

You're right. It should have been "-r TOMCAT_4_1_2" (which checks out fine
for me).

- Original Message -
From: "Dan Sandberg" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, July 01, 2002 6:06 PM
Subject: Re: [PATCH] Re: SSI Servlet has big problems


> Hi Bill.
>
> Didn't have any luck with that either (see below).  Does it work for
> you? Any idea what the message about the CVS locks means / how to fix it?
>
> Yeah, I see what you mean re: files in the attic.  I'm curious how
> things looked before I started changing things, to better understand
> what caused this code collision...
>
> -Dan
>
> Here's what I got when I tried to do the -r thing:
>
> [dan@oogie tmp]$ echo $CVSROOT
> :ext:[EMAIL PROTECTED]:/home/cvs
>
> [dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0
> Protocol error: uncounted data discarded
>
> Bill Barker wrote:
>
> >"-r tomcat_4_1_2" should work.  You could also "add" the files back from
the
> >Attic, since it's a completely different directory.
> >- Original Message -
> >From: "Dan Sandberg" <[EMAIL PROTECTED]>
> >To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> >Sent: Monday, July 01, 2002 4:25 PM
> >Subject: Re: [PATCH] Re: SSI Servlet has big problems
> >
> >
> >
> >
> >>I'm trying to checkout an old version of tomcat with the following
> >>
> >>
> >command:
> >
> >
> >>[dan@oogie tmp]$ cvs co -D "4 months ago" jakarta-tomcat-4.0
> >>
> >>And I'm getting the following error:
> >>
> >>Core dumped; preserving /tmp/cvs-serv41751 on server.
> >>CVS locks may need cleaning up.
> >>
> >>My version is (on Linux):
> >>
> >> >[dan@oogie tmp]$ cvs --version
> >> >
> >> >Concurrent Versions System (CVS) 1.11.1p1 (client/server)
> >>
> >>I tried the same thing on Solaris, and had the same problem.
> >>
> >>Any idea?  Am I doing something stupid?
> >>
> >>-Dan
> >>
> >>Dan Sandberg wrote:
> >>
> >>
> >>
> >>>Yes, let's merge them together.  How do I get to the code that you
> >>>fixed?  Were the test cases in CVS?
> >>>
> >>>I'd say lets get all the test cases setup, and see where my code fails
> >>>your tests.  Then we can use your code wherever functionality is
> >>>
> >>>
> >missing.
> >
> >
> >>>I thought I had checked out the head revision.  Did I make a mistake
> >>>with the cvs check out command?
> >>>
> >>>-Dan
> >>>
> >>>Paul Speed wrote:
> >>>
> >>>
> >>>
> (Resending from my older address in hopes that it will help avoid
> some confusion.)
> 
> Hmmm...
> 
> This is what I get for ignoring the list for a while. ;)
> 
> Note: I completely rewrote the SSI support in 4.x HEAD and had Bip
> apply the patches (Amy also did some patching) for exactly the same
> reasons you originally mention.  I did this around Oct/Nov 2001.  On
> most of the 4.0 bug reports for SSI (which I agree was a bad
> implementation on that branch) I commented that my changes should
> probably have been back-ported from head.
> 
> I even had test cases for all of the SSI commands, including the
> conditionals which I added support for.
> 
> My only guess is that you were looking at an older version when
finding
> the problem.  My rewrite solved all of these problems and was
> completely compatible with all mod_include commands except for the
> regex stuff.
> 
> Of course, now it seems that my version has been completely blown
> away.  Which is unfortunate since that means we lose conditionals...
> and possibly some of the more esoteric nesting behavior that I copied
> from Apache (I haven't tested this yet.)
> 
> It's too bad that SSI on head was blown away for changes to an older
> version.  Any chance we can nicely merge the two good versions into
> one more good version?
> 
> -Paul Speed
> 
> 
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >>
> >>
> >
> >
> >
> >>For additional commands, e-mail:
> >>
> >>
> >
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail:

> >For additional commands, e-mail:

> >
> >
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10418] New: - logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken

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

logic whether  URL needs to be encoded in HttpServletResponse.encodeURL() broken

   Summary: logic whether  URL needs to be encoded in
HttpServletResponse.encodeURL() broken
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
   URL: http://www.freiheit.com/users/hzeller/SessionBugDemonstr
ation.java
OS/Version: Linux
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


[ This applies to current 4.1 CVS as well ] 
The logic to determine whether a URL needs to be encoded in  
HttpServletResponse.encodeURL() is broken. In  
HttpServletResponseBase.isEncodeable(String location), it  
decides, that the URL needn't be encoded in the URL, if the  
current ID comes from the cookie; see code-snippet from  
HttpServletResponseBase:  
---  
if (hreq.isRequestedSessionIdFromCookie()) {  
return (false);  
}  
--  
  
However, this does not take into account, that the session ID we got  
might have been from some previous session that already is invalidated,  
i.e. is not valid. In this case isRequestedSessionIdFromCookie() will  
return true, but this does not say anything if future (valid) sessions  
will come through the cookie.  
  
The fix is easy: So the only way to check this correctly is:  
-  
   if (hreq.isRequestedSessionIdFromCookie()  
   && hreq.isRequestedSessionIdValid()) {  
 return (false);  
   }  
-

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java

[costin]

costin  2002/07/02 09:57:31

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
   jk/java/org/apache/jk/server JkCoyoteHandler.java
  Log:
  Added a bit of code to display the time spent in jk and request.
  
  I had it in my workspace, better to check it in so it doesn't get lost.
  
  Revision  ChangesPath
  1.16  +2 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- ChannelSocket.java5 Jun 2002 21:22:40 -   1.15
  +++ ChannelSocket.java2 Jul 2002 16:57:30 -   1.16
  @@ -471,7 +471,8 @@
   log.warn("Closing ajp connection " + status );
   break;
   }
  -
  +ep.setLong( MsgContext.TIMER_RECEIVED, System.currentTimeMillis());
  +
   ep.setType( 0 );
   status= this.invoke( recv, ep );
   if( status!= JkHandler.OK ) {
  
  
  
  1.25  +39 -8 
jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java
  
  Index: JkCoyoteHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- JkCoyoteHandler.java  21 Jun 2002 23:41:16 -  1.24
  +++ JkCoyoteHandler.java  2 Jul 2002 16:57:30 -   1.25
  @@ -83,6 +83,10 @@
   {
   protected static org.apache.commons.logging.Log log 
   = org.apache.commons.logging.LogFactory.getLog(JkCoyoteHandler.class);
  +// Set debug on this logger to see the container request time
  +private static org.apache.commons.logging.Log logTime=
  +org.apache.commons.logging.LogFactory.getLog( "org.apache.jk.REQ_TIME" );
  +
   int headersMsgNote;
   int c2bConvertersNote;
   int utfC2bNote;
  @@ -185,8 +189,8 @@
   
   int len=chunk.getLength();
   byte buf[]=msg.getBuffer();
  -// 3 - hardcoded, byte[] marshalling overhead 
  -int chunkSize=buf.length - msg.getHeaderLength() - 3;
  +// 4 - hardcoded, byte[] marshalling overhead 
  +int chunkSize=buf.length - msg.getHeaderLength() - 4;
   int off=0;
   while( len > 0 ) {
   int thisTime=len;
  @@ -224,6 +228,9 @@
   public int invoke( Msg msg, MsgContext ep ) 
   throws IOException
   {
  +if( logTime.isDebugEnabled() ) 
  +ep.setLong( MsgContext.TIMER_PRE_REQUEST, 
System.currentTimeMillis());
  +
   org.apache.coyote.Request req=(org.apache.coyote.Request)ep.getRequest();
   org.apache.coyote.Response res=req.getResponse();
   res.setHook( this );
  @@ -241,7 +248,7 @@
   
   res.setNote( epNote, ep );
   ep.setStatus( JK_STATUS_HEAD );
  -
  +
   try {
   adapter.service( req, res );
   } catch( Exception ex ) {
  @@ -301,6 +308,7 @@
   public void action(ActionCode actionCode, Object param) {
   try {
   if( actionCode==ActionCode.ACTION_COMMIT ) {
  +if( log.isDebugEnabled() ) log.debug("COMMIT " );
   org.apache.coyote.Response res=(org.apache.coyote.Response)param;
   
   if(  res.isCommitted() ) {
  @@ -312,15 +320,17 @@
   } else if( actionCode==ActionCode.ACTION_RESET ) {
   if( log.isInfoEnabled() )
   log.info("RESET " );
  +
   } else if( actionCode==ActionCode.ACTION_CLIENT_FLUSH ) {
  +if( log.isDebugEnabled() ) log.debug("CLIENT_FLUSH " );
   org.apache.coyote.Response res=(org.apache.coyote.Response)param;
   MsgContext ep=(MsgContext)res.getNote( epNote );
   ep.setType( JkHandler.HANDLE_FLUSH );
   ep.getSource().invoke( null, ep );
  +
   } else if( actionCode==ActionCode.ACTION_CLOSE ) {
  -if( log.isDebugEnabled() ) {
  -log.debug("CLOSE " );
  -}
  +if( log.isDebugEnabled() ) log.debug("CLOSE " );
  +
   org.apache.coyote.Response res=(org.apache.coyote.Response)param;
   MsgContext ep=(MsgContext)res.getNote( epNote );
   if( ep.getStatus()== JK_STATUS_CLOSED ) {
  @@ -343,12 +353,16 @@
   ep.getSource().invoke( msg, ep );
   
   ep.setStatus(JK_STATUS_CLOSED );
  +
  +if( logTime.isDebugEnabled() ) 
  + 

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common MsgAjp.java

[costin]

costin  2002/07/02 09:55:03

  Modified:jk/java/org/apache/jk/common MsgAjp.java
  Log:
  Fix for 10018, use the same size for the buffer as in jk1.
  
  Revision  ChangesPath
  1.12  +2 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java
  
  Index: MsgAjp.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- MsgAjp.java   20 Jun 2002 18:47:48 -  1.11
  +++ MsgAjp.java   2 Jul 2002 16:55:03 -   1.12
  @@ -92,7 +92,8 @@
   private static org.apache.commons.logging.Log log=
   org.apache.commons.logging.LogFactory.getLog( MsgAjp.class );
   
  -private byte buf[]=new byte[8300];
  +// that's the original buffer size in ajp13 - otherwise we'll get 
interoperability problems.
  +private byte buf[]=new byte[8*1024]; 
   // The current read or write position in the buffer
   private int pos;
   /**
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_msg.h

[costin]

costin  2002/07/02 09:53:59

  Modified:jk/native2/include jk_msg.h
  Log:
  Change back the max message size to what we had in jk1.
  
  Without this we run into problems when jk2 talks with jk1.
  
  Revision  ChangesPath
  1.13  +1 -1  jakarta-tomcat-connectors/jk/native2/include/jk_msg.h
  
  Index: jk_msg.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_msg.h,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- jk_msg.h  11 Jun 2002 21:46:38 -  1.12
  +++ jk_msg.h  2 Jul 2002 16:53:59 -   1.13
  @@ -77,7 +77,7 @@
   struct jk_ws_service;
   struct jk_logger;
   
  -#define DEF_BUFFER_SZ (8300)
  +#define DEF_BUFFER_SZ (8*1024)
   #define AJP13_MAX_SEND_BODY_SZ  (DEF_BUFFER_SZ - 6)
   
   /**
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

[costin]

costin  2002/07/02 09:53:15

  Modified:jk/native2/common jk_channel_socket.c
  Log:
  Minor fix - unix doesn't know about ioctlsocket.
  
  For 5.0 we should deprecate the old 'backward compat' components
  and use only APR.
  
  Revision  ChangesPath
  1.37  +4 -2  jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c
  
  Index: jk_channel_socket.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_socket.c,v
  retrieving revision 1.36
  retrieving revision 1.37
  diff -u -r1.36 -r1.37
  --- jk_channel_socket.c   27 Jun 2002 17:16:28 -  1.36
  +++ jk_channel_socket.c   2 Jul 2002 16:53:15 -   1.37
  @@ -285,10 +285,12 @@
   /* convert from seconds to ms */
   int set = ntimeout * 1000;
   u_long zero = 0;
  -if (ioctlsocket(sock, FIONBIO, &zero) == SOCKET_ERROR) {
   #ifdef WIN32
  +if (ioctlsocket(sock, FIONBIO, &zero) == SOCKET_ERROR) {
   errno = WSAGetLastError() - WSABASEERR;
  -#endif /* WIN32 */
  +#else
  +if (ioctl(sock, FIONBIO, &zero) != 0) {
  +#endif
   env->l->jkLog(env, env->l, JK_LOG_ERROR,
 "channelSocket.open() ioctlcocket failed %s:%d %d %s \n",
  socketInfo->host, socketInfo->port, errno, strerror( 
errno ) );
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

[costin]

costin  2002/07/02 09:51:08

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Add more info to the message.
  
  Revision  ChangesPath
  1.27  +3 -2  jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_ajp_common.c   25 Jun 2002 07:08:03 -  1.26
  +++ jk_ajp_common.c   2 Jul 2002 16:51:08 -   1.27
  @@ -684,7 +684,8 @@
   msglen += (head[3] & 0xFF);
   
   if(msglen > jk_b_get_size(msg)) {
  -jk_log(l, JK_LOG_ERROR, "ajp_connection_tcp_get_message: Error - Wrong 
message size\n");
  +jk_log(l, JK_LOG_ERROR, "ajp_connection_tcp_get_message: Error - Wrong 
message size %d %d\n",
  +   msglen, jk_b_get_size(msg));
   return JK_FALSE;
   }
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [4.1.6] New milestone release soon

[costinm]

Got it.

I'll check in, please test again.

Costin

On Tue, 2 Jul 2002, David Oxley wrote:

> Costin,
> 
> I'm using RedHat 7.3, Apache 2.1.39, TC 4.1.6, mod_jk1, CoyoteJK2.
> I build a new mod_jk.so everytime I get a new Tomcat. So it is definetley
> recent.
> 
> I'm not sure what additional information to provide that hasn't already been
> detailed in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018.
> 
> Dave.
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: 01 July 2002 23:54
> > To: Tomcat Developers List
> > Subject: RE: [4.1.6] New milestone release soon
> > 
> > On Mon, 1 Jul 2002, David Oxley wrote:
> > 
> > > Costin,
> > >
> > > This problem still happens with 4.1.6.
> > 
> > Ok, I need more details then.
> > 
> > Are you sure the mod_jk is recent ?  Are you using mod_jk or mod_jk2 ( on
> > apache side )?
> > Any stack traces or message ?
> > 
> > As I said, I'm doing large uploads/downloads currently, and it works
> > fine.
> > 
> > Costin
> > 
> > 
> > >
> > > Dave.
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > > Sent: 26 June 2002 16:57
> > > > To: Tomcat Developers List
> > > > Subject: RE: [4.1.6] New milestone release soon
> > > >
> > > > On Wed, 26 Jun 2002, David Oxley wrote:
> > > >
> > > > > Remy,
> > > > >
> > > > > Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource
> > (might
> > > > apply
> > > > > to dynamic content as well as static) that's bigger than 8k.
> > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018
> > > >
> > > > Are you using a nightly ? I fixed the bug few days ago, I'm
> > > > constantly doing large posts with jk2 in my day job.
> > > >
> > > > Please let me know ASAP if you still have this problem !
> > > >
> > > > Costin
> > > >
> > > >
> > > > >
> > > > > Dave.
> > > > >
> > > > > > -Original Message-
> > > > > > From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> > > > > > Sent: 26 June 2002 12:14
> > > > > > To: Tomcat Developers List
> > > > > > Subject: [4.1.6] New milestone release soon
> > > > > >
> > > > > > There are only a few issues remaining:
> > > > > > - Updating JNDI resources with the admin webapp is not dynamic
> > (for
> > > > > > reasons currently beyond my understanding). Doing a stop/start on
> > the
> > > > > > context allows to pick up the changes, so the bug is only minor.
> > > > > > - Nacho's IIS issues with JK 2.
> > > > > > - Costin's bug with Jasper 2.
> > > > > >
> > > > > > None of these are showstoppers IMO, but it would be best to have
> > them
> > > > > > fixed before the release is tagged (the objective being to get
> > back to
> > > > > > beta status). By friday maybe ?
> > > > > >
> > > > > > Remy
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:    > > > > > [EMAIL PROTECTED]>
> > > > > > For additional commands, e-mail:  > > > > > [EMAIL PROTECTED]>
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:    > > > [EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:  > > > [EMAIL PROTECTED]>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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]>
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

A couple of possible data-race bugs

[Robert W O'callahan]

I'm working on a tool for finding datarace bugs in Java programs. Roughly,
we find places where data shared between threads is being accessed without
locking or other synchronization. I found a couple of things in Tomcat
(4.0.4 final, still present in CVS) that look like lurking problems:

The first one is minor: in
org.apache.catalina.connector.http.HttpConnector.start(), curProcessors is
checked without holding the processors lock. So, between start() checking
curProcessors < maxProcessors and creating a new processor, the
HttpConnector thread might get a bunch of connections and create its own
processors up to maxProcessors, and so start() will create processor number
"maxProcessors+1".

In org.apache.catalina.core.StandardWrapper, the countAllocated field is
updated without any locking. If increments or decrements to countAllocated
occur simultaneously in different threads, updates can be lost, leading to
countAllocated having an incorrect value. It seems that an incorrect value
could cause problems in unload(), where the loop that waits for
countAllocated to go <= 0 might either terminate early or never terminate
at all.

I'd appreciate any feedback on whether my understanding of the code is
correct and whether these are real problems.

Thanks,
Robert O'Callahan IBM TJ Watson Research Staff Member
Office: Hawthorne 1N-J20Phone: (914) 784-7911
"The first to present his case seems right, till another comes forward
and questions him." -- Proverbs 18:17



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [4.1.6] Milestone available for testing

[Chad Johnson]

Hey,
  I may have missed something obvious, but if I didn't, are there plans to
add context reset/stop/start to the new administration webapp?

-Chad Johnson

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Cc: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Friday, June 28, 2002 2:10 PM
Subject: [4.1.6] Milestone available for testing


> Hightlights in this test release include:
> - fix for a memory leak in the request dispatcher
> - many fixes and refactorings in Jasper 2
> - admin webapp improvements
> - other misc fixes
>
> See the release notes for the list of changes.
>
> Downloads:
> http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.6/
>
> Remy
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10410] New: - Adding 1 element results in multiple displayed in admin webapp

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

Adding 1  element results in multiple displayed in admin webapp

   Summary: Adding 1  element results in multiple
displayed in admin webapp
   Product: Tomcat 4
   Version: 4.1.6
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When using the Admin web-app to add  elements, the webapp 
would "add" 3 elements for every 1 that I configured. I checked in server.xml, 
and only 1  was added, as well as a spurious  element 
(spurious because I was linking to a global )

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk2 shuts down

[Mladen Turk]

> 
> Good work!!, are you volunteering to be the release manager? :)
>

What is this? A man hunt :)

> In any case +1!!!

Would, but have no idea what the RM should do :)

1. We still need to update the docs before any release (just look at the
Tomcat Users list).
2. Didn't do any tests with the 1.3
3. Unix builds (all that I have is a RH 7.3 under VMware)

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10407] New: - Tomcat Memory Management

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

Tomcat Memory Management

   Summary: Tomcat Memory Management
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Product:Java Web Application
Operating system:   Windows NT/2000 server, Linux, FreeBSD
Web Server: IIS, Apache etc
Application server: Tomcat 3.2.4 and above
Database server:MySQL 3.23.49, MS-SQL, Oracle etc
Java Architecture:  JSP (presentation) + Java Bean (Business logic)

We are currently hosting our web application using Tomcat 4 with IIS 5 
on Windows 2000 server. We have also supplied our product to some of our 
customers who are hosting it on Linux using Tomcat 3.2.4 also. We have been 
facing the following problem for quite some time now. As more and more people 
are visiting and browsing the site, the Java.exe/Tomcat.exe size keeps growing 
and finally we end up with "Out of memory" error. Even if we leave the server 
inactive for hours, the memory doesn't get released and the only option is to 
restart the Tomcat server. We have posted this problem in many forums and in 
the Tomcat bug database also (both 3.* and 4). But we didn't get any solutions 
and also we were told that the problem could lie with our application. 
So, we decided to conduct a test with Tomcat example JSP pages, so as 
to see whether the memory is getting released properly with them at least. The 
memory.jsp contains the following code and all the example pages used had the 
same code embedded to find out the memory usage.

memory.jsp:
<%
try
{
out.println("Total Memory " + Runtime.getRuntime
().totalMemory()/1000 +" KB");
out.println("Memory in Use "+((Runtime.getRuntime().totalMemory()-
Runtime.getRuntime().freeMemory())/1000) +" KB");
out.println("Thread Count " + Thread.activeCount() + "");
}
catch(Exception ex)
{
   out.println(ex);
}
%>


Following is the result of the test done on Tomcat 4.03 as standalone server.


NameTotal memoryUsed memory Threads 
memory.jsp  4026274422
examples/jsp/num/numguess.jsp   4026346422
examples/jsp/num/numguess.jsp?guess=4026370422
examples/jsp/dates/date.jsp 4435305422
examples/jsp/snp/snoop.jsp· 4435337422
examples/jsp/include/include.jsp4435395322
examples/jsp/forward/forward.jsp4599385022
examples/jsp/plugin/plugin.jsp  4599417622
examples/jsp/simpletag/foo.jsp  4730271222
memory.jsp  4730297722
After 30 mins (session timeout) 
memory.jsp  4730318222

We felt, as in our application, the memory used by Tomcat doesn't get 
released fully even for 
Tomcat example JSP pages. We have repeated the same test many times, restarting 
Tomcat, deleting work folder, clearing browser cache every time. We have even 
tried the same after restarting the machine. The pattern is exactly the same 
barring variations of few bytes here and there. 
We repeated the same test on Tomcat 3.2.4 and the results were 
similar. Only the figures were different. Then, we decided to conduct the same 
test using JRun 3.1, so as to see whether the memory is getting released 
properly with it at least.

Following is the result of the test done on JRun 3.1 as standalone server.


NameTotal memoryUsed memory Threads 

memory.jsp  285924512
examples/jsp/num/numguess.jsp   373121884
examples/jsp/num/numguess.jsp?guess=373123394
examples/jsp/dates/date.jsp 387021504
examples/jsp/snp/snoop.jsp· 387024724
examples/jsp/include/include.jsp387020104
examples/jsp/forward/forward.jsp387022734
examples/jsp/plugin/plugin.jsp  387020064
examples/jsp/simpletag/foo.jsp  
memory.jsp  387020634
After 30 mins (session timeout) 

DO NOT REPLY [Bug 10406] New: - Tomcat Memory Management

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

Tomcat Memory Management

   Summary: Tomcat Memory Management
   Product: Tomcat 3
   Version: 3.2.3 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Product:Java Web Application
Operating system:   Windows NT/2000 server, Linux, FreeBSD
Web Server: IIS, Apache etc
Application server: Tomcat 3.2.4 and above
Database server:MySQL 3.23.49, MS-SQL, Oracle etc
Java Architecture:  JSP (presentation) + Java Bean (Business logic)

We are currently hosting our web application using Tomcat 4 with IIS 5 
on Windows 2000 server. We have also supplied our product to some of our 
customers who are hosting it on Linux using Tomcat 3.2.4 also. We have been 
facing the following problem for quite some time now. As more and more people 
are visiting and browsing the site, the Java.exe/Tomcat.exe size keeps growing 
and finally we end up with "Out of memory" error. Even if we leave the server 
inactive for hours, the memory doesn't get released and the only option is to 
restart the Tomcat server. We have posted this problem in many forums and in 
the Tomcat bug database also (both 3.* and 4). But we didn't get any solutions 
and also we were told that the problem could lie with our application. 
So, we decided to conduct a test with Tomcat example JSP pages, so as 
to see whether the memory is getting released properly with them at least. The 
memory.jsp contains the following code and all the example pages used had the 
same code embedded to find out the memory usage.

memory.jsp:
<%
try
{
out.println("Total Memory " + Runtime.getRuntime
().totalMemory()/1000 +" KB");
out.println("Memory in Use "+((Runtime.getRuntime().totalMemory()-
Runtime.getRuntime().freeMemory())/1000) +" KB");
out.println("Thread Count " + Thread.activeCount() + "");
}
catch(Exception ex)
{
   out.println(ex);
}
%>


Following is the result of the test done on Tomcat 4.03 as standalone server.


NameTotal memoryUsed memory Threads 
memory.jsp  4026274422
examples/jsp/num/numguess.jsp   4026346422
examples/jsp/num/numguess.jsp?guess=4026370422
examples/jsp/dates/date.jsp 4435305422
examples/jsp/snp/snoop.jsp· 4435337422
examples/jsp/include/include.jsp4435395322
examples/jsp/forward/forward.jsp4599385022
examples/jsp/plugin/plugin.jsp  4599417622
examples/jsp/simpletag/foo.jsp  4730271222
memory.jsp  4730297722
After 30 mins (session timeout) 
memory.jsp  4730318222

We felt, as in our application, the memory used by Tomcat doesn't get 
released fully even for 
Tomcat example JSP pages. We have repeated the same test many times, restarting 
Tomcat, deleting work folder, clearing browser cache every time. We have even 
tried the same after restarting the machine. The pattern is exactly the same 
barring variations of few bytes here and there. 
We repeated the same test on Tomcat 3.2.4 and the results were 
similar. Only the figures were different. Then, we decided to conduct the same 
test using JRun 3.1, so as to see whether the memory is getting released 
properly with it at least.

Following is the result of the test done on JRun 3.1 as standalone server.


NameTotal memoryUsed memory Threads 

memory.jsp  285924512
examples/jsp/num/numguess.jsp   373121884
examples/jsp/num/numguess.jsp?guess=373123394
examples/jsp/dates/date.jsp 387021504
examples/jsp/snp/snoop.jsp· 387024724
examples/jsp/include/include.jsp387020104
examples/jsp/forward/forward.jsp387022734
examples/jsp/plugin/plugin.jsp  387020064
examples/jsp/simpletag/foo.jsp  
memory.jsp  387020634
After 30 mins (session timeout) 

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

[marcsaeg]

marcsaeg2002/07/02 06:52:40

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
BufferedServletOutputStream.java
  Log:
  If an invalid character is sent through BufferedServletOutputStream it will
  cause an infinite loop on the error page because the same invalid character
  will put into the error page which will then be sent through the BSOS which
  will cause another exception to the error page which will start the whole
  over again.
  
  NOTE:  I know that TC3.2.x has been obsoleted, but I came across this one
  change that I made locally after the 3.2.4 release and figured I'd get into
  CVS before it got lost on my local machine.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.14.2.4  +5 -5  
jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletOutputStream.java
  
  Index: BufferedServletOutputStream.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletOutputStream.java,v
  retrieving revision 1.14.2.3
  retrieving revision 1.14.2.4
  diff -u -r1.14.2.3 -r1.14.2.4
  --- BufferedServletOutputStream.java  22 Jun 2001 19:57:06 -  1.14.2.3
  +++ BufferedServletOutputStream.java  2 Jul 2002 13:52:39 -   1.14.2.4
  @@ -215,9 +215,9 @@
// streams properly encode their output.
//
if ((c & 0xff00) != 0) {// high order byte must be zero
  - String errMsg = sm.getString(
  +String errMsg = sm.getString(
   "servletOutputStreamImpl.fmt.not_iso8859_1", 
  - new Object[] {new Character(c)});
  + new Object[] {Integer.toHexString((int)c)});
throw new IOException(errMsg);
}
write(c);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [DOCS] Tyrex-Tomcat HOWTO

[Les Hughes]

David / All,

Had problems rendering your doc so I've patched it onto the end of mine and
cleaned up the XML so that it styles up OK. Here it is.

Comments?

Les

PS I will stop moaning about getting this committed, I promise... :-)



> -Original Message-
> From: Les Hughes [mailto:[EMAIL PROTECTED]]
> Sent: 02 July 2002 13:29
> To: 'Tomcat Developers List'
> Subject: RE: [DOCS] Tyrex-Tomcat HOWTO
> 
> 
> Hi all,
> 
> Could we add this into the JNDI Datasources HOWTO that I 
> wrote the other
> week (I dont think this has been committed yet BTW)
> 
> If someone can commit my HOWTO, I'll merge the two together 
> and submit a
> patch this afternoon.
> 
> Hope this is OK
> 
> Les
> 
> 
> 
> > -Original Message-
> > From: David Haraburda [mailto:[EMAIL PROTECTED]]
> > Sent: 28 June 2002 20:05
> > To: [EMAIL PROTECTED]
> > Subject: [DOCS] Tyrex-Tomcat HOWTO
> > 
> > 
> > Hi all,
> > 
> > Here is a short HOWTO I've written on how to use Tyrex 1.0 
> with Tomcat
> > 4.1 (which goes along with the patch I submitted, which was just
> > recently committed).  I've added the appropriate XML tags, using the
> > other HOWTOs as examples, so very little modification should 
> > be needed.
> > Feedback on the content however, is greatly appreciated. :-)
> > 
> > Thanks,
> > 
> > David
> > 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 




jndi-datasource-examples-howto.xml
Description: Binary data

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 10405] New: - ClassCastException is thrown when request.setAttribute("charset", non_string) is called before request.getParameter() call.

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

ClassCastException is thrown when request.setAttribute("charset", non_string) is 
called before request.getParameter() call.

   Summary: ClassCastException is thrown when
request.setAttribute("charset", non_string) is called
before request.getParameter() call.
   Product: Tomcat 3
   Version: 3.3.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Here is a simple Servlet that reproduce the problem.
---
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;

public class Attr extends HttpServlet {
public void doGet(HttpServletRequest request,
  HttpServletResponse response)
throws IOException, ServletException
{
request.setAttribute("charset", new Object());
request.getParameter("blah");
}
}


java.lang.ClassCastException: java.lang.Object
at
org.apache.tomcat.modules.mappers.DecodeInterceptor.getInfo(DecodeInterceptor.java:581)
at org.apache.tomcat.core.Request.getCharEncoding(Request.java:483)
at org.apache.tomcat.core.Request.getCharacterEncoding(Request.java:470)
at org.apache.tomcat.core.Request.handleQueryParameters(Request.java:451)
at
org.apache.tomcat.facade.HttpServletRequestFacade.getParameter(HttpServletRequestFacade.java:277)
at Attr.doGet(Attr.java:12)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at javax.servlet.http.HttpServlet.service(HttpServlet.java)
at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:574)
at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
at org.apache.tomcat.core.Handler.service(Handler.java:235)
at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:485)
at 
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:917)
at org.apache.tomcat.core.ContextManager.service(ContextManager.java:833)
at
org.apache.tomcat.modules.server.Http10Interceptor.processConnection(Http10Interceptor.java:176)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:494)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk2 shuts down

[Ignacio J. Ortega]

> Right now we have the Apache2/WIN32 and IIS tested and working.
> What about other platforms, and how about some beta?

Good work!!, are you volunteering to be the release manager? :)

In any case +1!!!

Saludos ,
Ignacio J. Ortega

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [DOCS] Tyrex-Tomcat HOWTO

[Les Hughes]

Hi all,

Could we add this into the JNDI Datasources HOWTO that I wrote the other
week (I dont think this has been committed yet BTW)

If someone can commit my HOWTO, I'll merge the two together and submit a
patch this afternoon.

Hope this is OK

Les



> -Original Message-
> From: David Haraburda [mailto:[EMAIL PROTECTED]]
> Sent: 28 June 2002 20:05
> To: [EMAIL PROTECTED]
> Subject: [DOCS] Tyrex-Tomcat HOWTO
> 
> 
> Hi all,
> 
> Here is a short HOWTO I've written on how to use Tyrex 1.0 with Tomcat
> 4.1 (which goes along with the patch I submitted, which was just
> recently committed).  I've added the appropriate XML tags, using the
> other HOWTOs as examples, so very little modification should 
> be needed.
> Feedback on the content however, is greatly appreciated. :-)
> 
> Thanks,
> 
> David
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

mod_jk2 shuts down

[Mladen Turk]

Hi,

Finaly been able to gracefully shutdown the isapi_redirector without the
need to reboot the machine!

The reason were the ghost threads left attaching in other and detaching
jvm in another.

Right now we have the Apache2/WIN32 and IIS tested and working.
What about other platforms, and how about some beta?

MT. 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_jni.c

[mturk]

mturk   2002/07/02 05:08:25

  Modified:jk/native2/common jk_channel_jni.c
  Log:
  Call the vm detach on 'afterRequest' and on
  channel destoy.
  
  Revision  ChangesPath
  1.31  +5 -1  jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c
  
  Index: jk_channel_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_channel_jni.c,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- jk_channel_jni.c  29 Jun 2002 18:31:00 -  1.30
  +++ jk_channel_jni.c  2 Jul 2002 12:08:25 -   1.31
  @@ -329,6 +329,10 @@
   (*jniEnv)->DeleteGlobalRef( jniEnv, epData->jniJavaContext );
   }
   
  +jniCh->vm->detach( env, jniCh->vm );
  +env->l->jkLog(env, env->l, JK_LOG_INFO,
  +  "channel_jni.close() ok\n" ); 
  +
   endpoint->channelData=NULL;
   return JK_OK;
   
  @@ -522,7 +526,7 @@
   if( we==NULL || we->vm==NULL ) {
   return JK_OK;
   }
  -/* we->vm->detach( env, we->vm );  */
  +we->vm->detach( env, we->vm );
   
   if( worker->mbean->debug > 0 )
   env->l->jkLog(env, env->l, JK_LOG_INFO, 
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_worker_jni.c

[mturk]

mturk   2002/07/02 05:06:46

  Modified:jk/native2/common jk_worker_jni.c
  Log:
  Disable the call ro the DestoryJavaVM.
  This call should be invoked when the TomcatStarter
  or something else signals that there will be no more calls.
  
  Revision  ChangesPath
  1.23  +7 -2  jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c
  
  Index: jk_worker_jni.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_worker_jni.c,v
  retrieving revision 1.22
  retrieving revision 1.23
  diff -u -r1.22 -r1.23
  --- jk_worker_jni.c   1 Jul 2002 23:11:42 -   1.22
  +++ jk_worker_jni.c   2 Jul 2002 12:06:46 -   1.23
  @@ -378,13 +378,18 @@
   
   env->l->jkLog(env, env->l, JK_LOG_INFO,
 "jni.destroy() calling main()...\n");
  -
  +
   (*jniEnv)->CallStaticVoidMethod(jniEnv,
   jniWorker->jk_java_bridge_class,
   jniWorker->jk_main_method,
   jargs,stdout_name,stderr_name);
  -
  +#if 0
  +/* XXX  Need to fix the TomcatStarter not calling jkSetAttribute
  + *  and call the destroy JVM on that event.
  + *  Perhaps the DestroyJavaVM is not needed at all.
  + */
   vm->destroy(env, vm);
  +#endif
   }
   env->l->jkLog(env, env->l, JK_LOG_INFO, "jni.destroy() done\n");
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_logger_win32.c

[mturk]

mturk   2002/07/02 05:04:40

  Modified:jk/native2/common jk_logger_win32.c
  Log:
  Fix the Run-Time Check Failrue #3 -
  The variable 'rc' is being used without being defined.
  This solves the IIS startup for debug build.
  
  Revision  ChangesPath
  1.7   +1 -1  jakarta-tomcat-connectors/jk/native2/common/jk_logger_win32.c
  
  Index: jk_logger_win32.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/common/jk_logger_win32.c,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- jk_logger_win32.c 10 Jun 2002 21:55:06 -  1.6
  +++ jk_logger_win32.c 2 Jul 2002 12:04:40 -   1.7
  @@ -137,7 +137,7 @@
const char *fmt,
va_list args)
   {
  -int rc;
  +int rc = 0;
   if(l->level <= level) {
   char buf[HUGE_BUFFER_SIZE];
   char *f = (char *)(file + strlen(file) - 1);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [4.1.6] New milestone release soon

[David Oxley]

Costin,

I'm using RedHat 7.3, Apache 2.1.39, TC 4.1.6, mod_jk1, CoyoteJK2.
I build a new mod_jk.so everytime I get a new Tomcat. So it is definetley
recent.

I'm not sure what additional information to provide that hasn't already been
detailed in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018.

Dave.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 01 July 2002 23:54
> To: Tomcat Developers List
> Subject: RE: [4.1.6] New milestone release soon
> 
> On Mon, 1 Jul 2002, David Oxley wrote:
> 
> > Costin,
> >
> > This problem still happens with 4.1.6.
> 
> Ok, I need more details then.
> 
> Are you sure the mod_jk is recent ?  Are you using mod_jk or mod_jk2 ( on
> apache side )?
> Any stack traces or message ?
> 
> As I said, I'm doing large uploads/downloads currently, and it works
> fine.
> 
> Costin
> 
> 
> >
> > Dave.
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: 26 June 2002 16:57
> > > To: Tomcat Developers List
> > > Subject: RE: [4.1.6] New milestone release soon
> > >
> > > On Wed, 26 Jun 2002, David Oxley wrote:
> > >
> > > > Remy,
> > > >
> > > > Bug 10018 is pretty serious. Coyote-JK2 won't serve a resource
> (might
> > > apply
> > > > to dynamic content as well as static) that's bigger than 8k.
> > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10018
> > >
> > > Are you using a nightly ? I fixed the bug few days ago, I'm
> > > constantly doing large posts with jk2 in my day job.
> > >
> > > Please let me know ASAP if you still have this problem !
> > >
> > > Costin
> > >
> > >
> > > >
> > > > Dave.
> > > >
> > > > > -Original Message-
> > > > > From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
> > > > > Sent: 26 June 2002 12:14
> > > > > To: Tomcat Developers List
> > > > > Subject: [4.1.6] New milestone release soon
> > > > >
> > > > > There are only a few issues remaining:
> > > > > - Updating JNDI resources with the admin webapp is not dynamic
> (for
> > > > > reasons currently beyond my understanding). Doing a stop/start on
> the
> > > > > context allows to pick up the changes, so the bug is only minor.
> > > > > - Nacho's IIS issues with JK 2.
> > > > > - Costin's bug with Jasper 2.
> > > > >
> > > > > None of these are showstoppers IMO, but it would be best to have
> them
> > > > > fixed before the release is tagged (the objective being to get
> back to
> > > > > beta status). By friday maybe ?
> > > > >
> > > > > Remy
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:    > > > > [EMAIL PROTECTED]>
> > > > > For additional commands, e-mail:  > > > > [EMAIL PROTECTED]>
> > > >
> > > > --
> > > > To unsubscribe, e-mail:    > > [EMAIL PROTECTED]>
> > > > For additional commands, e-mail:  > > [EMAIL PROTECTED]>
> > > >
> > > >
> > >
> > >
> > > --
> > > 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]>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: servlet authentication

[Kevin Seguin]

i could be wrong, but i think once you call sendError(), the response is committed and 
you cannot set any more headers.  try reversing the order of the 
sendError()/setHeader() calls:

 response.setHeader("WWW-Authenticate", "BASIC realm=\"test\"");
 response.sendError(response.SC_UNAUTHORIZED);

> -Original Message-
> From: Michael Bergknoff [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 01, 2002 9:02 PM
> To: [EMAIL PROTECTED]
> Subject: servlet authentication
> 
> 
> To test servlet-based authentication, I have a two
> line servlet.
> response.sendError(response.SC_UNAUTHORIZED);
> response.setHeader("WWW-Authenticate", "BASIC
> realm=\"test\"");
> 
> Here is the output I get:
> $ telnet localhost 8080
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /myapp/servlet
> Apache Tomcat/4.0.3 - Error
> report
> Apache Tomcat/4.0.3 - HTTP Status 401
> - Unauthorizedtype
> Status reportmessage
> Unauthorizeddescription This
> request requires HTTP authentication
> (Unauthorized). noshade>Connection closed by foreign
> host.
> 
> The output contains no HTTP headers, just some Tomcat
> generated HTML. Is this a bug in my servlet test or
> what?
> 
> Thanks,
> Mike
> 
> 
> __
> Do You Yahoo!?
> Sign up for SBC Yahoo! Dial - First Month Free
> http://sbc.yahoo.com
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: PROPOSAL: 5.0 configuration

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
> The basic idea is to use a 2-layer configuration mechansim, 
> with a pluggable repository for preferene storage and 
> JMX-based component configuration.
> 
> For config storage, we should be able to use:
> - current XML files ( with few minor changes in the 3-4 classes
> that deal with reading config )
> - JNDI - for config stored in a directory service ( ldap,
> active directory, nds, etc). 
> - JDK1.4 preference API, if running in JDK1.4 ( that means
> registry on windows, well-defined xml files on unix ).
> - registry - using jk2 native calls
> - if tomcat is embeded in another application, the application-specific
> config repository.
> 
> 
> The config layer will be similar with the JDK1.4 preferences (which
> we can't use directly - we still have to support older versions ),
> and will be mostly independent of tomcat ( eventually move to 
> commons - but after we get it stable and to do what we need in tomcat).
> 
> There are few big benefits in this:
> - better scalability ( with directory services, in case of large site ).
> - consistent configuration with the applications embeding tomcat.
> - consistent configuration with the OS ( i.e. registry can be used
> on windows, etc ).
> - simpler API for configuration ( the XmlMapper/Digester are still
> a bit tricky, and is very difficult to make changes )
> - allow us to capture what the user directly changes - the current
> mechanism for saving will just read all the properties from all beans.
> - we'll be able to use a single config storage/format for all 
> components ( instead of server.xml, policy, jk2.properites, user.xml,etc)
> 
> The implementation will actually use the same mechanism as today -
> except that instead of reading the XML file and using XmlMapper/Digester,
> we'll get the data from the repository. 

That seems like a very good idea to me. In Tomcat 4.1, there's currently 
a big difference configuration-wise when you embed Tomcat when compared 
to when you run it standalone; I think this is a problem.
Another problem of the current config mechanism is that it is hardcoded 
for the digester, and is therefore is limited. The mechanisms to save 
back the configuration are also hackish and limited.

> In addition, any change will be made via the configurator and JMX,
> and will be recorded and saved ( with a bit of work it is even
> possible to save the xml files preserving the comments and with
> the same structure, and only what is modified will be written ).
> 
> 
> 
> The second layer will be based on the JMX patterns - and will not require
> any change in the current code. The configurator will just set
> the attributes and create the components - using either direct
> introspection or JMX.
> 
> As more components will be JMX-instrumented, we should be able to use
> the new configuration to setup those components as well ( log4j for
> example ) - without any special change in the code.
> 
> There is nothing very new in this proposal - having pluggable config
> has been a goal since tomcat3.0, and the proposal itself will change
> very little as code. A basic implementation of this model is already
> part of mod_jk2 ( in jk_config.c - the java version will follow,
> if we agree on this proposal :-).
> 
> Both layers will be based on existing standards and common patterns.
> JMX ( and the current java bean patterns ) are clearly the best way to 
> configure components, and JNDI/prefs provide an excelent API
> for storing config data ( and XML can use that easily )

+1. This looks like a welcome step forward, and is well worth the effort.

I don't see anything in the proposal which mentions removing the current 
configuration mechanisms; would you leave it there for compatibility ?

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-tomcat-connectors/jk/native/iis README

[GOMEZ Henri]

Who could update the iplanet README ?

-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Monday, July 01, 2002 9:34 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat-connectors/jk/native/iis README
>
>
>nacho   2002/07/01 12:33:59
>
>  Modified:jk/native/iis README
>  Log:
>  * More on build i_r.dll from command line.
>  
>  Revision  ChangesPath
>  1.2   +21 -3 jakarta-tomcat-connectors/jk/native/iis/README
>  
>  Index: README
>  ===
>  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/README,v
>  retrieving revision 1.1
>  retrieving revision 1.2
>  diff -u -r1.1 -r1.2
>  --- README   1 Jul 2002 11:08:35 -   1.1
>  +++ README   1 Jul 2002 19:33:59 -   1.2
>  @@ -8,8 +8,26 @@
>   REQUIREMENT
>   ---
>   
>  -MS VC 6.0 (+ update, latest service pack is sp5)
>  -MS PLATFORM SDK
>  +* MS VC 6.0 (+ update, latest service pack is sp5)
>  +  isapi_redirector.dll can be built using the command line 
>tools, or 
>  +  from within the Visual Studio IDE Workbench. The command 
>line build 
>  +  requires the environment to reflect the PATH, INCLUDE, 
>LIB and other 
>  +  variables that can be configured with the vcvars32 batch file: 
>  +  
>  +  "c:\Program Files\DevStudio\VC\Bin\vcvars32.bat"
>  +
>  +* MS PLATFORM SDK
>  +  Visual C++ 6.0 builds require an updated Microsoft 
>Windows Platform SDK 
>  +  
(http://www.microsoft.com/msdownload/platformsdk/sdkupdate/) to enable 
  +  some isapi_redirector.dll features. For command line builds,
  +  the Platform SDK environment is prepared by the setenv batch file:
  +  
  +  "c:\Program Files\Microsoft Platform SDK\setenv.bat"
  +
  +  Note that the Windows Platform SDK is only needed if you want authenticate 
  +  using IIS to compile a isapi_redirector.dll.. 
  +
  +
   
   BUILDING
   
  @@ -17,7 +35,7 @@
   The steps that you need to take are:
   
  1. Change directory to the isapi redirector plugins source directory.
  -
  +   
  2. Execute the following command:
 MSDEV isapi.dsp /MAKE ALL
 If msdev is not in your path, enter the full path to msdev.exe
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk 1.2.0

[GOMEZ Henri]

Good news :)

Some updates in documentation (workers.properties need updates)
and I think we could tag jtc mod_jk_1_2_0


-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .) 
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-Original Message-
>From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, July 02, 2002 12:52 AM
>To: Tomcat Dev List
>Subject: RE: [PROPOSAL] removing outdated makefile/buildfile for mod_jk
>1.2.0
>
>
>If you're referring to statically linking mod_jk into Apache 
>1.3.x, then
>I can confirm that it works just fine. I've been running that
>configuration for quite some time now.
>
>Bojan
>
>On Mon, 2002-07-01 at 18:53, GOMEZ Henri wrote:
>> Ok, I'll remove them so, and will update the build documentation
>> (in xdocs).
>> 
>> BTW, who could tell us more about mod_jk 1.2.x static build ?
>> 
>> -
>> Henri Gomez ___[_]
>> EMAIL : [EMAIL PROTECTED](. .) 
>> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>> 
>> 
>> 
>> >-Original Message-
>> >From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
>> >Sent: Saturday, June 29, 2002 5:19 AM
>> >To: Tomcat Dev List
>> >Subject: Re: [PROPOSAL] removing outdated 
>makefile/buildfile for mod_jk
>> >1.2.0
>> >
>> >
>> >As long as configure/make works I'm +1.
>> >
>> >Bojan
>> >
>> >On Fri, 2002-06-28 at 22:39, GOMEZ Henri wrote:
>> >> Hi,
>> >> 
>> >> What about removing all the outdated 
>> >> makefile and build.platform.sh 
>> >> present in jk/native now that we
>> >> have a working configure/makefile or
>> >> ant/jkant ?
>> >> 
>> >> 
>> >> 
>> >> -
>> >> Henri Gomez ___[_]
>> >> EMAIL : [EMAIL PROTECTED](. .) 
>> >> PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
>> >> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 
>> >> 
>> >> 
>> >> --
>> >> To unsubscribe, e-mail:   
>> >
>> >> For additional commands, e-mail: 
>> >
>> >> 
>> >
>> >
>> >
>> >--
>> >To unsubscribe, e-mail:   
>> 
>> For additional commands, e-mail: 
>
>> 
>> 
>> --
>> To 
>unsubscribe, e-mail:   
>
>> For 
>additional commands, e-mail: 
>
>> 
>
>
>
>--
>To 
>unsubscribe, e-mail:   
>
>For 
>additional commands, e-mail: 
>
>
>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: