DO NOT REPLY [Bug 31361] - Add OS/2 launchers to tomcat

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31361


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2004-10-29 18:38 ---
Will not be done.  We don't want to maintain these, and the idea of adding a 
contrib directory to Tomcat was not liked by committers.  Feel free to add your 
scripts to our wiki.  Our FAQ also points users to the wiki for additional OS-
specific resources

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

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

[Fwd: Re: Handling HEAD request in servlet]

[Tennessee Leeuwenburg]

Hello list,
Someone who seems able to recieve mail from this list but has some 
problem sending asked me to forward the following message ::

Cheers,
-T
--- Begin Message ---
Hi tennessee 
Could u do me a favour still my tomcat memebership is not approved .So
i have an urgent problem get sloved.Can u please forward this massage
to the maling list?


I'm running on suse Linux and I have installed gsoap there.I want to
configure tomcat as my web app server for gsoap.how this possible .Is
there a already built conf module or"SO " file for this?

can any body help me on this
Thanks
Kanchana



On Thu, 06 Jan 2005 16:09:37 +1100, Tennessee Leeuwenburg
<[EMAIL PROTECTED]> wrote:
> Hi guys,
> 
> I have a problem where the default implementation of HttpServlet doesn't
> seem to be handling doHead(request, response) properly. I over-rode the
> method, and found the damndest thing happening. The line
> "response.setContentLength(length)" is just getting completely ignored.
> I can't work it out - it's like the response object is deliberately
> preventing me from setting the content-length. I tried
> setHeader("Content-Length", length) just in case but still no joy.
> 
> Help!? Please!
> -
> 
> Here's the code snippet :
> 
>FileInputStream inStream = null;
> 
>inStream = new FileInputStream(ncFile);
>int length = (int)ncFile.length();
>response.setStatus(response.SC_PARTIAL_CONTENT);
>response.setHeader("Accept-Ranges", "bytes");
>response.setContentLength(length);
>response.setHeader("Content-Length-Mimic",
> ""+(int)ncFile.length());
>response.setHeader("Impossible", "" + length);
>response.setContentType(contentType);
> 
>out.flush();
> 
> Here's what I get back via telnet :
> 
> HTTP/1.1 206 Partial Content
> Date: Thu, 06 Jan 2005 05:07:22 GMT
> Server: Apache/2.0.50 (Ubuntu) mod_jk2/2.0.4
> Set-Cookie: JSESSIONID=3D6C4C6EBE1AB1672E40C2933243BA3B; Path=/marslet
> Accept-Ranges: bytes
> Content-Length-Mimic: 36903060
> Impossible: 36903060
> Content-Type: application/x-netcdf
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

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

DO NOT REPLY [Bug 3534] - FileUpload doesn't work with Apache, mod_webapp and tomcat 4.0 RC1

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=3534





--- Additional Comments From [EMAIL PROTECTED]  2003-10-05 18:00 ---
*** Bug 5427 has been marked as a duplicate of this bug. ***

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

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

Handling HEAD request in servlet

[Tennessee Leeuwenburg]

Hi guys,
I have a problem where the default implementation of HttpServlet doesn't 
seem to be handling doHead(request, response) properly. I over-rode the 
method, and found the damndest thing happening. The line 
"response.setContentLength(length)" is just getting completely ignored. 
I can't work it out - it's like the response object is deliberately 
preventing me from setting the content-length. I tried 
setHeader("Content-Length", length) just in case but still no joy.

Help!? Please!
-
Here's the code snippet :
   FileInputStream inStream = null;
  
   inStream = new FileInputStream(ncFile);
   int length = (int)ncFile.length();
   response.setStatus(response.SC_PARTIAL_CONTENT); 
   response.setHeader("Accept-Ranges", "bytes");
   response.setContentLength(length);
   response.setHeader("Content-Length-Mimic", 
""+(int)ncFile.length());
   response.setHeader("Impossible", "" + length);
   response.setContentType(contentType);
  
   out.flush();

Here's what I get back via telnet :
HTTP/1.1 206 Partial Content
Date: Thu, 06 Jan 2005 05:07:22 GMT
Server: Apache/2.0.50 (Ubuntu) mod_jk2/2.0.4
Set-Cookie: JSESSIONID=3D6C4C6EBE1AB1672E40C2933243BA3B; Path=/marslet
Accept-Ranges: bytes
Content-Length-Mimic: 36903060
Impossible: 36903060
Content-Type: application/x-netcdf
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 12998] - HTTPS gets changed to HTTP://servername:443

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=12998





--- Additional Comments From [EMAIL PROTECTED]  2003-10-05 18:09 ---
*** Bug 5975 has been marked as a duplicate of this bug. ***

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

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

DO NOT REPLY [Bug 6709] - Images on protected areas have not "Last modified" header

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=6709





--- Additional Comments From [EMAIL PROTECTED]  2003-10-05 18:20 ---
*** Bug 7715 has been marked as a duplicate of this bug. ***

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

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

DO NOT REPLY [Bug 5191] - JspReader.skipUntil() misss overlaping partial matches

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=5191


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2002-01-22 04:26 ---
This has now been applied to the CVS HEAD, and will shortly appear in 3.3.1-B1.

Thanks for the contribution!

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

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

DO NOT REPLY [Bug 5186] - Installation Instructions for Configuring Tomcat 4.0 to Cooperate with IIS 4.0/5.0

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=5186





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

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

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 04:21 ---
FYI, I deployed the client.war and server.war (attached to this bug report by
Scott) to the Sun One Application Server 8.1 and it worked as I expected (the RD
obtained by ServerServlet in application B correctly includes /test.jsp in
application B). That's two servers so far that I have tested where it works
(Weblogic 8.1 and Sun One Application Server 8.1 2005Q1). I would imagine that
Sun got the implementation correct on their own spec? 

Mark: You stated "Relative paths are, by definition, relative to the current
request". I believe that they are relative to the root of the current
application context. This might be why the the getRequestDispatcher() method
exists in the ServletContext (and not in the request).

Remy: I do not think it is a waste of time to report bugs or to discuss spec.
compliance so that Tomcat conforms to it. My goal is the same as yours - to
improve Tomcat. Otherwise, I would not be spending all this time posting. I hope
you would welcome folks reporting bugs and encourage discussion going forward
instead of dismissing them as a waste of time.

I am moving the status to REOPENED. I hope that you will recognize that this is
a bug after all and not continue to insist that Tomcat's implementation is
correct and others (Sun, BEA etc) are incorrect.

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

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

DO NOT REPLY [Bug 32781] - attribute scheme not being recognized

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32781


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 01:47 ---
This is now fixed in CVS.

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

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java

[remm]

remm2005/01/05 16:46:37

  Modified:coyote/src/java/org/apache/coyote Request.java
  Log:
  - 32781: Fix bad initialization of the "scheme" field of the request object, 
which messes up the first request.
This should only be set by the connector.
  
  Revision  ChangesPath
  1.31  +0 -1  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
  
  Index: Request.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- Request.java  12 Aug 2004 21:46:41 -  1.30
  +++ Request.java  6 Jan 2005 00:46:37 -   1.31
  @@ -74,7 +74,6 @@
   parameters.setURLDecoder(urlDecoder);
   parameters.setHeaders(headers);
   
  -schemeMB.setString("http");
   methodMB.setString("GET");
   uriMB.setString("/");
   queryMB.setString("");
  
  
  

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965





--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 01:27 ---
The following quotes are from section SRV.14.2.5.1 (RequestDispatcher methods)
of the spec.


public void forward(ServletRequest request, ServletResponse response)
throws ServletException, IOException

Forwards a request from a servlet to another resource (servlet, JSP file, or
HTML file) on the server. This method allows one servlet to do preliminary
processing of a request and another resource to generate the response.

For a RequestDispatcher obtained via getRequestDispatcher(), the
ServletRequest object has its path elements and parameters adjusted to
match the path of the target resource.
...
The request and response parameters must be either the same objects as were
passed to the calling servlet’s service method or be subclasses of the
ServletRequestWrapper or ServletResponseWrapper classes that wrap them.



public void include(ServletRequest request, ServletResponse response)
throws ServletException, IOException

Includes the content of a resource (servlet, JSP page, HTML file) in the
response. In essence, this method enables programmatic server-side includes.

The ServletResponse object has its path elements and parameters remain
unchanged from the caller’s. The included servlet cannot change the response
status code or set headers; any attempt to make a change is ignored.

The request and response parameters must be either the same objects as were
passed to the calling servlet’s service method or be subclasses of the
ServletRequestWrapper or ServletResponseWrapper classes that wrap
them.


To address the question raised by Bill above, ie what is the "current servlet
context" consider the case of a relative path.

Relative paths are, by definition, relative to the current request. The current
request (since we are doing includes not forwards) is still the original request
(to context A). Hence the path is relative to the original request. Since it is
relative to the original request the path must be within the original servlet
context. Therefore, the "current servlet context" must be the original context
(client or context A in the discussion above).

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

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

Re: JDBCStore Downgrade (Tomcat4 vs. Tomcat 5)

[Tom Anderson]

It looks like the list stripped the image attachments.   Let me know if 
you're interested and I'll forward you the original email with the 
pictures.

~Tom
On Jan 5, 2005, at 4:59 PM, Tom Anderson wrote:
FYI,
We applied the 2 patches described in this thread with dramatic 
effects on our network bandwidth.   Our JDBCStore talks to a database 
on another machine and this graph shows how the bandwidth usage 
dropped dramatically after these patches went up last night at 17:00 
(most recent time is on the LEFT):


I beleive that green represents bytes/sec FROM the database machine 
and the blue represents bytes/sec TO the database.  The graph over the 
last week shows the same thing:


I hope this picture really illustrates the problem and demonstrates 
the worthiness of the patch.   Again, I volunteer to make the patch to 
whatever branches it's needed on.

~Tom
p.s. I hope sending a picture to the list isn't taboo... if so, sorry.
On Dec 30, 2004, at 8:53 PM, Tom Anderson wrote:
And to fix the loading of too many sessions while processing expires, 
I suggest the attached patch to only load in sessions that you KNOW 
need to be expired (I believe it's better to err in loading too few 
sessions during store expiration since they will get removed 
eventually anyways).   Here's that patch:


FYI, I am testing both patches in my development environment and they 
seem to work well and achieve what I need to go forward with Tomcat 
5.   Hopefully you will accept one or both to make Tomcat more 
robust!   Let me know if you want me to apply either or both patches 
to the HEAD (or whatever).   And I would also be willing to do doc 
patches as needed.

Thanks,
~Tom
On Dec 29, 2004, at 7:16 PM, Tom Anderson wrote:
I would like to share my experiences in upgrading from Tomcat 4 to 
Tomcat 5 and offer some suggestions for improvement (to Tomcat 5) 
based on them.  This message got a little long but I hope somebody 
in the know will find the time to read it and help me figure out how 
to rectify my problems so I can upgrade to Tomcat 5 (again).

BACKGROUND
We have been using Tomcat 4 successfully for a couple of years (or 
more?).   On some machines we have quite a few contexts running 
(approx. 75) so making sure they all work well together is 
important.We have been using the "experimental" JDBCStore 
mechanism with very good results and I have also contributed some 
patches to achieve this success.

One problem we discovered early on with Tomcat 4 was the 
JDBCStore.processExpires() being called on all of our many contexts 
at roughly the same time.   The effect was that the database would 
slow and/or crash.  Fortunately, we were able to work around this 
problem using the checkInterval settings in JDBCStore.   By 
staggering these checkIntervals to different values we could ensure 
that different contexts would hit the database at various times and 
spread the load out.   Also, in our installation, the JDBCStore 
checkInterval has been set about 15 times higher than the 
PersistentManager checkInterval because it is slower and simply 
doesn't need to be run as often (clearing out the store isn't as 
important or fast as clearing out memory).

TOMCAT 5
Recently we tried to upgrade to Tomcat 5 and discovered that our 
database was periodically choking and causing massive problems with 
Tomcat's ability to process requests.   So we have had to rollback 
to Tomcat 4.   I have spent the last several days going through the 
Tomcat 5 code to try to figure out what has been happening.

I have discovered that the checkInterval values are no longer used 
(despite what the documentation says) and are instead replaced by 
the backgroundProcessorDelay value in the Container class.   This 
means that I now only have one value to set for the equivalent of 
the 2 checkInterval values we had in Tomcat 4.   I suspect that this 
was done to decrease the number of threads necessary which seems 
like a noble goal.   But the downside is that I now am forced to run 
my JDBCStore.processExpires() much more often than I'd like (15 
times more often in my case) which is a hardship on the database.

Furthermore, in Tomcat 4 JDBCStore overrode 
StoreBase.processExpires() to only select older sessions from the 
database something like this:
	SELECT id FROM tomcat_sessions
	WHERE app = '/Standalone/localhost/acme' AND 1104288671296 > 
(lastaccess + maxinactive*1000)))
This was a good thing because each session is loaded into memory 
before deciding whether or not to expire it, so you don't want to 
load every Stored session if possible.   In my case we often have 
tens of thousands of sessions in Store so loading all those older 
sessions every 60 seconds is quite a hardship, especially when 
combined with the fact that it is running 15 times as often!

To summarize the problems:
	1. no control of the StoreBase.processExpires() interval means that 
processing expired persisted sessions is done as frequently as 
sessions in memory which is t

DO NOT REPLY [Bug 32834] - Tomcat 5.0.28 shows a Blank Page

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32834


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 01:11 ---
If you want to use a huge HTTP header (which is not a very good idea, you should
try to POST if you have lots of data), then you need to use maxHttpHeaderSize on
the connector. It's 4KB by default.

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

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 01:00 ---
Please do not bother reopening the report, unless you have more time to waste.
If you're only doing includes, the top level path will always be used. With
forwards, it's the opposite.

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

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

Re: JDBCStore Downgrade (Tomcat4 vs. Tomcat 5)

[Tom Anderson]

FYI,
We applied the 2 patches described in this thread with dramatic effects 
on our network bandwidth.   Our JDBCStore talks to a database on 
another machine and this graph shows how the bandwidth usage dropped 
dramatically after these patches went up last night at 17:00 (most 
recent time is on the LEFT):


I beleive that green represents bytes/sec FROM the database machine and 
the blue represents bytes/sec TO the database.  The graph over the last 
week shows the same thing:


I hope this picture really illustrates the problem and demonstrates the 
worthiness of the patch.   Again, I volunteer to make the patch to 
whatever branches it's needed on.

~Tom
p.s. I hope sending a picture to the list isn't taboo... if so, sorry.
On Dec 30, 2004, at 8:53 PM, Tom Anderson wrote:
And to fix the loading of too many sessions while processing expires, 
I suggest the attached patch to only load in sessions that you KNOW 
need to be expired (I believe it's better to err in loading too few 
sessions during store expiration since they will get removed 
eventually anyways).   Here's that patch:


FYI, I am testing both patches in my development environment and they 
seem to work well and achieve what I need to go forward with Tomcat 5. 
  Hopefully you will accept one or both to make Tomcat more robust!   
Let me know if you want me to apply either or both patches to the HEAD 
(or whatever).   And I would also be willing to do doc patches as 
needed.

Thanks,
~Tom
On Dec 29, 2004, at 7:16 PM, Tom Anderson wrote:
I would like to share my experiences in upgrading from Tomcat 4 to 
Tomcat 5 and offer some suggestions for improvement (to Tomcat 5) 
based on them.  This message got a little long but I hope somebody in 
the know will find the time to read it and help me figure out how to 
rectify my problems so I can upgrade to Tomcat 5 (again).

BACKGROUND
We have been using Tomcat 4 successfully for a couple of years (or 
more?).   On some machines we have quite a few contexts running 
(approx. 75) so making sure they all work well together is important. 
   We have been using the "experimental" JDBCStore mechanism with 
very good results and I have also contributed some patches to achieve 
this success.

One problem we discovered early on with Tomcat 4 was the 
JDBCStore.processExpires() being called on all of our many contexts 
at roughly the same time.   The effect was that the database would 
slow and/or crash.  Fortunately, we were able to work around this 
problem using the checkInterval settings in JDBCStore.   By 
staggering these checkIntervals to different values we could ensure 
that different contexts would hit the database at various times and 
spread the load out.   Also, in our installation, the JDBCStore 
checkInterval has been set about 15 times higher than the 
PersistentManager checkInterval because it is slower and simply 
doesn't need to be run as often (clearing out the store isn't as 
important or fast as clearing out memory).

TOMCAT 5
Recently we tried to upgrade to Tomcat 5 and discovered that our 
database was periodically choking and causing massive problems with 
Tomcat's ability to process requests.   So we have had to rollback to 
Tomcat 4.   I have spent the last several days going through the 
Tomcat 5 code to try to figure out what has been happening.

I have discovered that the checkInterval values are no longer used 
(despite what the documentation says) and are instead replaced by the 
backgroundProcessorDelay value in the Container class.   This means 
that I now only have one value to set for the equivalent of the 2 
checkInterval values we had in Tomcat 4.   I suspect that this was 
done to decrease the number of threads necessary which seems like a 
noble goal.   But the downside is that I now am forced to run my 
JDBCStore.processExpires() much more often than I'd like (15 times 
more often in my case) which is a hardship on the database.

Furthermore, in Tomcat 4 JDBCStore overrode 
StoreBase.processExpires() to only select older sessions from the 
database something like this:
	SELECT id FROM tomcat_sessions
	WHERE app = '/Standalone/localhost/acme' AND 1104288671296 > 
(lastaccess + maxinactive*1000)))
This was a good thing because each session is loaded into memory 
before deciding whether or not to expire it, so you don't want to 
load every Stored session if possible.   In my case we often have 
tens of thousands of sessions in Store so loading all those older 
sessions every 60 seconds is quite a hardship, especially when 
combined with the fact that it is running 15 times as often!

To summarize the problems:
	1. no control of the StoreBase.processExpires() interval means that 
processing expired persisted sessions is done as frequently as 
sessions in memory which is too often in a production environment
	2. the processing of Stored expires is loading all old sessions into 
memory before deciding which ones need to be removed from Store 
instead of loading older session

JNDI resources available to auth realms?

[Andrew Jaquith]

Greetings,
A while back I did some patch work on the catalina.realm.JAASRealm 
class. I learned a lot in the process.

Shortly thereafter, I wrote a (personal) JAAS LoginModule that uses a 
JDBC database as the authentication data source. It works great. One of 
the things I wished I could incorporate into the LoginModule was the 
ability to leverage Tomcat-managed JNDI resources. That way, I could 
take advantage of connection pooling, reduce the need to spray 
credentials into JAAS conf files, etc.

I tried to do it, but couldn't make it work. After many days of 
troubleshooting and debugging, I realized the source of the problem. 
JNDI resources did not seem to be available to the threads that call 
JAASRealm (or any other realms, for that matter). I noted that the 
JDBCRealm has this TODO:

  Support connection pooling (including message
  format objects) so that authenticate() does not have to 
be
  synchronized and would fix the ugly connection logic.

Making JNDI resources available to the realms would fix my problem and 
this one too; all that would be required would be some sort of 
JNDICallback that JAASCallbackHandler could use to satisfy a JNDI 
resource request by the JAAS login module. Assuming that making JNDI 
resources (read-only copies of the global + local context resources) 
available is a good idea, what's the best way to go about it? I looked 
at quite a bit of code in catalina/naming and other places; it wasn't 
very obvious how to do it.

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 00:50 ---
Let me approach this from a different angle to impress upon you that this is a
bug. What is the point of invoking a servlet in another application if one is
expected to provide all the resources (JSPs etc.) that is going to be included
by that servlet? Think about this for a second. It is very likely that someone
else wrote application B and its purpose is entirely different from application
A. The folks that wrote application B packaged their application with JSPs/HTML
files etc. that are included/forwarded to by their servlet. If I write
application A and want to invoke a servlet in application B, am I expected to
know what are all the resources included/forwarded by the servlet in application
B and in addition provide them in my application??? That is what you are
effectively saying and it makes no sense. This is a bug in Tomcat. 

Thanks to William for pointing out the spec. If the request is currently being
processed by the servlet in application B, then the current servlet context is
clearly B and not A. At the risk of repetition, it doesn't matter that the
request came to application A first. Application A passed along the request to a
servlet in application B after obtaining the servlet context for B and hence we
are in B's context now. The resources should then be looked up in application B
not application A. 

Please stop dismissing this as invalid as this is a bug (it is quite irritating
to reopen it again and again). I ran this example in another server (Weblogic
8.1) and it worked flawlessly (the resource was looked up in application B and
not application A). At the very least, leave it as REOPENED so that other folks
can provide their input. 

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

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

DO NOT REPLY [Bug 16001] - Tag.release() not invoked

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=16001


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 00:39 ---
*** Bug 32957 has been marked as a duplicate of this bug. ***

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

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

DO NOT REPLY [Bug 32957] - Problem with repeating custom tags with tag pooling turned on

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32957


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-01-06 00:39 ---
http://jakarta.apache.org/tomcat/faq/misc.html#tagbroken

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

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

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

Re: Problems checking out Tomcat 5.0 from CVS

[Ian Flanigan]

Thanks for your help.  I was able to build the TOMCAT_5_0 branch with
one change:

Index: catalina/src/share/org/apache/catalina/realm/RealmBase.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/RealmBase.java,v
retrieving revision 1.33.2.3
diff -u -r1.33.2.3 RealmBase.java
--- catalina/src/share/org/apache/catalina/realm/RealmBase.java 9 Dec
2004 13:52:59 -   1.33.2.3
+++ catalina/src/share/org/apache/catalina/realm/RealmBase.java 5 Jan
2005 23:34:52 -
@@ -1094,7 +1094,7 @@
 
 byte[] digest = null;
 // Bugzilla 32137
-synchornized(md5Helper) {
+synchronized(md5Helper) {
 digest = md5Helper.digest(valueBytes);
 }
 
This seems to be just a small syntax error.

Thanks again,

Ian Flanigan

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

DO NOT REPLY [Bug 31198] - Non-ASCII Passwords Converted to UTF-8

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31198





--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 23:50 ---
Yep. BASIC auth and non-ASCII passwords is a mess before it even gets to Tomcat.
Mozilla definitely (and I suspect IE as well) does a lossy conversion of
non-ASCII usernames and passwords before base64 encoding. There is no way I can
see of Tomcat supporting BASIC auth for non-ASCII usernames and passwords as
things currently stand.

On to FORM auth...

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

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

Re: Problems checking out Tomcat 5.0 from CVS

[Yoav Shapira]

Hi,
You can use the cvstag (IIRC, I haven't used it in ages) property.  If you
check out the right modules, build.properties.default and its dependencies will
be correct.

Yoav

--- Ian Flanigan <[EMAIL PROTECTED]> wrote:

> On Wed, 5 Jan 2005 14:10:31 -0800 (PST), Yoav Shapira <[EMAIL PROTECTED]>
> wrote:
> > 
> > You need to use the TOMCAT_5_0 CVS tag when checking out.
> 
> Okay, I know how to do that by hand, but is there a "blessed" way to
> do it with the build.xml file?  I couldn't find a related property. 
> Should I checkout all of the projects using the TOMCAT_5_0 branch, or
> only certain ones?  How will this affect the shared dependencies?
> 
> Thanks for your help,
> 
> Ian Flanigan
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


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

Re: Problems checking out Tomcat 5.0 from CVS

[Ian Flanigan]

On Wed, 5 Jan 2005 14:10:31 -0800 (PST), Yoav Shapira <[EMAIL PROTECTED]> wrote:
> 
> You need to use the TOMCAT_5_0 CVS tag when checking out.

Okay, I know how to do that by hand, but is there a "blessed" way to
do it with the build.xml file?  I couldn't find a related property. 
Should I checkout all of the projects using the TOMCAT_5_0 branch, or
only certain ones?  How will this affect the shared dependencies?

Thanks for your help,

Ian Flanigan

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

DO NOT REPLY [Bug 32957] New: - Problem with repeating custom tags with tag pooling turned on

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32957

   Summary: Problem with repeating custom tags with tag pooling
turned on
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Working with the original %CATALINA%\conf\web.xml, when I tried to declare a 
custom tag in my JSP multiple times, all the tag declarations other than the 
first one assumed the value of the first tag declaration. But when I turn the 
tag pooling off, it each tag declaration behaves distinctly.

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

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

Re: Problems checking out Tomcat 5.0 from CVS

[Yoav Shapira]

Hi,
You need to use the TOMCAT_5_0 CVS tag when checking out.  That stuff is on its
own branch.

Yoav

--- Ian Flanigan <[EMAIL PROTECTED]> wrote:

> Hi all,
> 
> I'm trying to checkout and compile the latest Tomcat 5.0 sources from
> CVS, but I seem to get the 5.5 sources instead.  I used the following
> command to get the build.xml.
> 
> $ wget http://jakarta.apache.org/tomcat/tomcat-5.0-doc/build.xml
> 
> and use the following build.properties file:
> 
> $ cat build.properties 
>  # - Proxy setup -
> # Uncomment if using a proxy server.
> #proxy.host=proxy.domain
> #proxy.port=8080
> #proxy.use=on
> 
> # - Default Base Path for Dependent Packages -
> # Replace this path with the directory path where
> # dependencies binaries should be downloaded.
> base.path=C:/Documents and Settings/flan/My
> Documents/Work/Personal/Tomcat/dependencies
> 
> The build succeeds, but when I look at the CVS version of files that I
> *know* are different in 5.0 and 5.5, I find the 5.5 version.  For
> example:
> 
> $ cat
>
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CVS/Entries
> /Authenticators.properties/1.1.1.1/Thu Jul 18 16:47:47 2002//
> /Bootstrap.java/1.21/Sat Aug 21 19:34:59 2004//
> /Catalina.java/1.35/Sat Oct 23 16:54:23 2004//
> [...]
> /HostConfig.java/1.52/Mon Jan  3 16:10:19 2005//
> [...]
> 
> What is the best way to check out the 5.0 sources?
> 
> Thanks,
> 
> Ian Flanigan
> 
> -
> 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]

Problems checking out Tomcat 5.0 from CVS

[Ian Flanigan]

Hi all,

I'm trying to checkout and compile the latest Tomcat 5.0 sources from
CVS, but I seem to get the 5.5 sources instead.  I used the following
command to get the build.xml.

$ wget http://jakarta.apache.org/tomcat/tomcat-5.0-doc/build.xml

and use the following build.properties file:

$ cat build.properties 
 # - Proxy setup -
# Uncomment if using a proxy server.
#proxy.host=proxy.domain
#proxy.port=8080
#proxy.use=on

# - Default Base Path for Dependent Packages -
# Replace this path with the directory path where
# dependencies binaries should be downloaded.
base.path=C:/Documents and Settings/flan/My
Documents/Work/Personal/Tomcat/dependencies

The build succeeds, but when I look at the CVS version of files that I
*know* are different in 5.0 and 5.5, I find the 5.5 version.  For
example:

$ cat 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CVS/Entries
/Authenticators.properties/1.1.1.1/Thu Jul 18 16:47:47 2002//
/Bootstrap.java/1.21/Sat Aug 21 19:34:59 2004//
/Catalina.java/1.35/Sat Oct 23 16:54:23 2004//
[...]
/HostConfig.java/1.52/Mon Jan  3 16:10:19 2005//
[...]

What is the best way to check out the 5.0 sources?

Thanks,

Ian Flanigan

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

DO NOT REPLY [Bug 31198] - Non-ASCII Passwords Converted to UTF-8

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=31198


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version||All
Version|4.0.6 Final |4.1.31




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 22:58 ---
Quick update:

The fix (using the filter) described in 29091 appears to resolve the issues with
the admin app (passwords are saved correctly in UTF-8) but a much trickier
problem has emerged in testing.

For BASIC auth the password is converted to bytes and base 64 encoded. The
problem appears to be the different browsers (at least IE and FireFox) make
different encoding assumptions (and neither seem to assume UTF-8) at this point
because the same username and password results in different Authorization
headers. It is looking like another i18n grey area but I will do some more work
to see if there is anything that can be done to work around this fun and games.

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

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965





--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 22:14 ---
It seems that the relevant part of the spec is:

The pathname specified may be relative, although it cannot extend outside the
current servlet context. If the path begins with a "/" it is interpreted as 
relative
to the current context root. This method returns null if the servlet container
cannot return a RequestDispatcher.


So it seems to hinge on what the "current context" is in this case.

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

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

Bug Fix - Sort of...

[Durfee, Bernard]

Hello,
 This is my first post to the list, so I am not sure of the protocol for
making contributions to the project. I had some problems getting a data
source configured in Tomcat 5. My data source factory was not being
used. After some struggle I found that I needed to put the factory name
as an attribute on the  Resource> element. So the
 ResourceParams> element seems to be ignored. 

HOWEVER! In the process of pulling out my hair to figure out what was
going on I 'fixed' the org.apache.naming.factory.ResourceFactory by
refactoring, commenting, and enhancing the exception messages to spit
out some information instead of just a one liner! These modifications
are below. I also added some comments to the code so that future
developers can figure out what the heck is going on. I would love to
contribute this to the project, I've read about 10 other threads on
various web-sites of people frustrated by the lack of error messages
related to this bug.

==
/*
 * Copyright 1999,2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * 
 *  http://www.apache.org/licenses/LICENSE-2.0
 * 
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.apache.naming.factory;

import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.Name;
import javax.naming.NamingException;
import javax.naming.RefAddr;
import javax.naming.Reference;
import javax.naming.spi.ObjectFactory;

/**
 * Object factory for Resources.
 * 
 * @author Remy Maucherat
 * @version $Revision: 1.3 $ $Date: 2004/02/27 14:58:54 $
 */
public class ResourceFactory implements ObjectFactory {

  // ---
Constructors

  // --
Constants
  private static final String DATASOURCE = "javax.sql.DataSource";

  private static final String MAIL_SESSION = "javax.mail.Session";

  private static final String DATASOURCE_FACTORY_PROPERTY =
"javax.sql.DataSource.Factory";

  private static final String MAIL_SESSION_FACTORY_PROPERTY =
"javax.mail.Session.Factory";

  private static final String MAIL_SESSION_FACTORY =
"org.apache.naming.factory.MailSessionFactory";

  // - Instance
Variables

  // - Public
Methods

  // -- ObjectFactory
Methods

  /**
   * Creates a new object using the specified factory
   * 
   * 
   *   The factory class name is determined
   *   
   * The class name is retrieved from the Reference object
   * If the class name is not found, a default factory is
created for the desired object
   * If the class name is still not found, an exception is
thrown
   *   
   *   
   *   Once the factory class name is determined, an instance is
created and used to create the desired object 
   * 
   * 
   * @param resourceRefObject The reference object describing the
DataSource
   * @param name Passed to factory
   * @param nameCtx Passed to factory
   * @param environment Passed to factory
   * @return The object instance; null if the 'referenceObject'
parameter is not an instance of Reference
   * @throws NamingException When the factory could not be created
   * @throws Exception When the factory could not create the obect
   */
  public Object getObjectInstance(Object referenceObject, Name name,
Context nameCtx, Hashtable environment)
  throws Exception {
// Make sure the Reference was passed in
if(!(referenceObject instanceof Reference)) {
  return null;
}

// Cast the incoming resource reference
Reference reference = (Reference) referenceObject;

// We need to create the factory class
final Class factoryClass;

// First check to see if a factory name has been supplied with the
reference
RefAddr factoryRefAddr = reference.get(Constants.FACTORY);
if(factoryRefAddr != null) {
  // If so, get the classname of the specified factory
  String factoryClassName = factoryRefAddr.getContent().toString();

  // Get the context class loader; may not be available
  ClassLoader tcl = Thread.currentThread().getContextClassLoader();
  if(tcl != null) {
// Use the context class loader 
try {
  factoryClass = tcl.loadClass(factoryClassName);
}
catch(ClassNotFoundException exception) {
  NamingException namingException = new NamingException("Could
not load resource factory class '"
  + fact

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 21:56 ---
There are two request dispatchers in this test case. The first is obtained as
you describe (and works correctly) but this is not the dispatcher used to
include test.jsp.

A second request dispatcher is created in the service() method of the
ServerServlet in server.war/context B. The code for this method is:

public void service(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse)
throws ServletException, IOException
{
httpServletResponse.setContentType("text/html");

RequestDispatcher dispatcher =
httpServletRequest.getRequestDispatcher(TEST_JSP);
dispatcher.include(httpServletRequest, httpServletResponse);
}

The request dispatcher is obtained from the request. Because this is an include,
the request is the original request that is associated the client/context A.
Hence this request dispatcher cannot find test.jsp which is in context B.

I would also point out that when originally investigating this bug I downloaded
the test case and stepped through it line by line in a debugger to check exactly
what was going on before closing it as invalid.

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

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

Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http LocaleToCharsetMap.java

[Bill Barker]

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 05, 2005 1:29 AM
Subject: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http
LocaleToCharsetMap.java


> remm2005/01/05 01:29:19
>
>   Removed: util/java/org/apache/tomcat/util/http
> LocaleToCharsetMap.java
>   Log:
>   - I cannot clean IP in this file. If it is needed by Tomcat 3, I think
it'll need to be added back (with
> proper attribution) to the Tomcat 3 codebase. Sorry for the trouble :(
>

Yup. Tomcat 3 does have references to it.  Fortunately, Xalan is currently
broken so Gump isn't nagging about it :).

The choices seem to be to re-add it to j-t (and have the o.a.t.u.http
package split across two jars), or to clean the references to it.  In the
first case, I'd propose removing the references to Sun, but leaving the
javadoc copy of Jason's attribution.

To clean it:  ErrorHandler is applying it to the platform Locale, which is
silly.  I'd propose adding a 'useCharset' attribute to ErrorHandler, and if
unset default to the Request charset (which is smarter).  StaticInterceptor
uses only for directory listings when its 'useCharset' attribute is set to
'locale'.  In this case, the charset could simply be an entry in the
associated ResourceBundle (since the current incarnation must look really
weird when it gets an 'Accept-Language: ar' request header :).

Personally, I can go either way on this one.

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



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

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


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

Re: Tomcat monitoring

[Peter Lin]

I believe you would have to add those to the Thread MBean. What you
see in the status servlet is what is maintained currently.

peter



On Wed, 05 Jan 2005 13:24:02 -0600, Jess Holle <[EMAIL PROTECTED]> wrote:
> I'd like to be able to monitor the maximum requests active (within a
> connector thread pool) that are used at any time (and reset this maximum).
> 
> I'd like to be able to monitor the backlog (ala acceptCount) at a given
> point in time and the maximum to date (and reset this maximum).
> 
> [I already noticed the ability to monitor the currentThreadsBusy in
> ThreadPool.]
> 
> Am I (hopefully) overlooking this in the existing MBean stack?  Or are
> these candidates for addition?
> 
> --
> Jess Holle
> 
> -
> 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]

Tomcat monitoring

[Jess Holle]

I'd like to be able to monitor the maximum requests active (within a 
connector thread pool) that are used at any time (and reset this maximum).

I'd like to be able to monitor the backlog (ala acceptCount) at a given 
point in time and the maximum to date (and reset this maximum).

[I already noticed the ability to monitor the currentThreadsBusy in 
ThreadPool.]

Am I (hopefully) overlooking this in the existing MBean stack?  Or are 
these candidates for addition?

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java

[Remy Maucherat]

Costin Manolache wrote:
Remy Maucherat wrote:
There is no "advertising clause" in this. He made it clear that the code 
is donated to ASF, under ASF license. Mentioning that the author 
developed the code while working on a book or while being paid by a 
company can't be that bad.

I don't understand why ASF is so advertising-fobic when it comes to 
authors or companies that donate code or employee time to ASF, but until 
recently strictly required advertisment for the code owner ( ASF ) not 
only in the code, but also on the web site.
I suppose you're not the one getting the cellphone calls while on 
vacation about lawyers from large companies being very unhappy about 
this comment, which is anything but clear.

The ASF also doesn't do advertisements. This comment was an advertisment.
That's the end of the discussion as far as I am concerned.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java

[Costin Manolache]

Remy Maucherat wrote:
Costin Manolache wrote:
Maybe:
* @author Jason Hunter, as part of the book "Java Servlet Programming"
* (O'Reilly). See http://www.servlets.com/book";>
* http://www.servlets.com/book for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be 
someday removed, it doesn't matter that much...

I am all in favor of giving proper attribution (author tags), but -1 on 
anything which restricts the ASF's copyright on the code (like 
advertising clauses in this case).

As a result, I have to agree with all that pointed out that the code 
should be rewritten (in this case, the encoding list must be 
reconstructed from scratch).

Rémy
There is no "advertising clause" in this. He made it clear that the code 
is donated to ASF, under ASF license. Mentioning that the author 
developed the code while working on a book or while being paid by a 
company can't be that bad.

I don't understand why ASF is so advertising-fobic when it comes to 
authors or companies that donate code or employee time to ASF, but until 
recently strictly required advertisment for the code owner ( ASF ) not 
only in the code, but also on the web site.


Costin

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

DO NOT REPLY [Bug 25965] - RequestDispatcher fails after cross context include

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=25965


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 18:47 ---
You are incorrect when you say that he is not obtaining the RD from context B.
He is. Please check the code carefully. Here is the scenario:

There are two applications deployed to Tomcat: client.war (application A) and
server.war (application B). Application A has a servlet called ClientServlet
that is mapped to "/c". Application B has a servlet called ServerServlet that is
mapped to "/serverservlet"

Here is the sequence of events:
1) Browser sends a request to http://localhost:8080/client/c.
2) Tomcat maps request to A (client.war gets the /client context root) and
invokes ClientServlet:service()
3) In ClientServlet:service(), he is getting the application context for B as
follows:
   ServletContext serverServletContext = 
 getServletContext().getContext(SERVER_CONTEXT_ROOT);
   where SERVER_CONTEXT_ROOT is "/server" (server.war gets the /server context
root). Please look up the API for the getContext() method call on the
ServletContext object. This is how one can do server-side includes of content
from servlets/resources in another application that is deployed on the same 
server.
4) He is then obtaining the request dispatcher using B's servlet context not his
own (A's) servlet context:
   RequestDispatcher requestDispatcher =
   serverServletContext.getRequestDispatcher(SERVER_SERVLET_PATH);
   where SERVER_SERVLET_PATH is "/serverservlet", the path mapped to B's
servlet. I think this is the point you are not following. He is not doing
getServletContext().getRequestDispatcher(SERVER_SERVLET_PATH) which would be
using A's servlet context. 
5) He finally does an include of B's servlet by calling:
   requestDispatcher.include(httpServletRequest, httpServletResponse);
   
   Now although the request first arrived in A, it is not A's request
exclusively. A request represents a user request to the server and can be
forwarded to another application or you can include servlets/resources from
another application. The server of course can prohibit this due to security
constraints. In Tomcat one can override the security restrictions by setting
"crossContext" to "true" in the  element for application A in
server.xml to allow servlets in A to obtain servlet contexts to other
applications (such as B). 

   With "crossContext" set to "true" for the client application (A), Tomcat
returns a servlet context to B in Step 3. It also returns a request dispatcher
to B's servlet in Step 4. The include call also works in Step 5 and B's servlet
is called correctly. However, when B's servlet gets a request dispatcher to
"/test.jsp" and does an include of it, Tomcat is looking for "/test.jsp" in
application A! THIS IS A BUG! One can verify this by creating a test.jsp file in
the root of the WAR in application A and see that it is being called instead. 
   
   Please do not rush and close this as "invalid". This is definitely a bug.
Please talk to other Tomcat developers if you must and work towards resolving 
this. 
   


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

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

DO NOT REPLY [Bug 29091] - Non-ascii characters are not handled correctly...

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=29091


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 16:23 ---
(In reply to comment #10)
> Per Mr. Ushakov's investigation and comments, I'm closing this issue.  Thanks.

Hi, 

Sorry to spoil the "party", but I reopen this bug.
This bug is marked as a duplication for #28219 (Dolar sign in password of JNDI-
Datasource disappears), thus #28219 is closed on duplication.

Maybe configuring the character encoding solves the problem with servlet 
parameter inputs, but it doesn't solve the problem of putting non ascii 
characters in tomcat 5 configuration files(I use tomcat 5.027).

To be more precise, i need to use $ sign in server.xml in order to define a 
shared folder (i.e. \\my-machine\c$\my-app\)
To make it work on tomcat 5 i had to put double dollar sign (\\my-
machine\c$$\my-app\ ) and also add Sun's tools.jar in common\lib. this is a 
workaround and not a way to solve this.

I see in forums that this problem is annoying many people. not just me. 
This problem did not occur in tomcat 4.03

Regards 
Sun House

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

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

DO NOT REPLY [Bug 32834] - Tomcat 5.0.28 shows a Blank Page

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32834


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 13:52 ---
(In reply to comment #1)
> Use the mailing list to ask for suggestions: if the request is not in the 
> access log, tomcat did not get it, so the problem may have been in your 
> network.  Can you reproduce this reliably?  If so, attach a WAR so we can do 
> the same.

Hi,
   I too face the same problem. I tried with a sample html file (i.e. attached 
one). When we access this page(http://localhost:8080/sample/Sample.html) and 
when we click the link "Click Me"(This link is there in the HTML) twice, we can 
see the same error in the second attempt. This happens if the length of the 
query string is more. The same works good in Tomcat5.0.16 and does not with 
Tomcat5.0.28.

Source of the Sample HTML file that i tried.

   

  Click Me 
   




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

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

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

[markt]

markt   2005/01/05 03:54:37

  Modified:catalina/src/share/org/apache/catalina/servlets
HTMLManagerServlet.java ManagerServlet.java
  Log:
  Fix trivial (since it is within the manager web app that should not be
  publically accessible) XSS issue.
   - Ported from TC5.
  
  Revision  ChangesPath
  1.19  +4 -2  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java
  
  Index: HTMLManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/HTMLManagerServlet.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- HTMLManagerServlet.java   26 Aug 2004 21:38:13 -  1.18
  +++ HTMLManagerServlet.java   5 Jan 2005 11:54:37 -   1.19
  @@ -34,6 +34,7 @@
   import javax.servlet.http.HttpServletResponse;
   import org.apache.catalina.Context;
   import org.apache.catalina.Host;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.ServerInfo;
   import org.apache.commons.fileupload.FileItem;
   import org.apache.commons.fileupload.DiskFileUpload;
  @@ -110,7 +111,8 @@
   message = stop(path);
   } else {
   message =
  -sm.getString("managerServlet.unknownCommand", command);
  +sm.getString("managerServlet.unknownCommand",
  + RequestUtil.filter(command));
   }
   
   list(request, response, message);
  
  
  
  1.35  +26 -14
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java
  
  Index: ManagerServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/ManagerServlet.java,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- ManagerServlet.java   26 Aug 2004 21:38:13 -  1.34
  +++ ManagerServlet.java   5 Jan 2005 11:54:37 -   1.35
  @@ -53,6 +53,7 @@
   import org.apache.catalina.UserDatabase;
   import org.apache.catalina.Wrapper;
   import org.apache.catalina.core.StandardServer;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.ServerInfo;
   import org.apache.catalina.util.StringManager;
   import org.apache.naming.resources.ProxyDirContext;
  @@ -455,7 +456,8 @@
   
   // Validate the requested context path
   if ((path == null) || path.length() == 0 || !path.startsWith("/")) {
  -writer.println(sm.getString("managerServlet.invalidPath", path));
  +writer.println(sm.getString("managerServlet.invalidPath",
  +RequestUtil.filter(path)));
   return;
   }
   String displayPath = path;
  @@ -644,7 +646,7 @@
   
   if (path == null || path.length() == 0 || !path.startsWith("/")) 
{
   writer.println(sm.getString("managerServlet.invalidPath",
  -path));
  +RequestUtil.filter(path)));
   return;
   }
   String displayPath = path;
  @@ -724,7 +726,8 @@
   log("restart: Reloading web application at '" + path + "'");
   
   if ((path == null) || (!path.startsWith("/") && path.equals(""))) {
  -writer.println(sm.getString("managerServlet.invalidPath", path));
  +writer.println(sm.getString("managerServlet.invalidPath",
  +RequestUtil.filter(path)));
   return;
   }
   String displayPath = path;
  @@ -773,7 +776,8 @@
   log("remove: Removing web application at '" + path + "'");
   
   if ((path == null) || (!path.startsWith("/") && path.equals(""))) {
  -writer.println(sm.getString("managerServlet.invalidPath", path));
  +writer.println(sm.getString("managerServlet.invalidPath",
  +RequestUtil.filter(path)));
   return;
   }
   String displayPath = path;
  @@ -783,7 +787,8 @@
   try {
   Context context = deployer.findDeployedApp(path);
   if (context == null) {
  -writer.println(sm.getString("managerServlet.noContext", 
displayPath));
  +writer.println(sm.getString("managerServlet.noContext",
  +
RequestUtil.filter(displayPath)));
   return;
   }
   // It isn't possible for the manager to remove itself
  @@ -977,7 +982,8 @@
   log("sessions: Session information for web application at '" + 
path + "'");
   
   if ((path == null) || (!path.startsWith("/") &&

Re: Doc update to remove references to nagoya and jakarta website spring clean

[Mark Thomas]

Remy Maucherat wrote:
Can you also post in a bug report with "blocker" all the diffs to the 
examples-webapps-that-we-cannot-change ? This should include the trivial 
http://issues.apache.org/bugzilla/show_bug.cgi?id=32456 as well.
Done
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 32953] - SERVLETAPI: XSS Issues

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32953





--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 12:25 ---
Created an attachment (id=13896)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=13896&action=view)
Patch for XSS issues


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

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

DO NOT REPLY [Bug 32953] New: - SERVLETAPI: XSS Issues

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32953

   Summary: SERVLETAPI: XSS Issues
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: All
Status: NEW
  Keywords: PatchAvailable
  Severity: blocker
  Priority: P1
 Component: Webapps:Examples
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


A number of XSS issues have been reported against the examples.

I will attach a patch for jakarta-servletapi-5 that fixes the reported issues
(and a few others fo a similar nature).

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

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

cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/snp snoop.jsp

[markt]

markt   2005/01/05 03:14:09

  Modified:webapps/examples/jsp/snp snoop.jsp
  Log:
  Another possible XSS issue.
  
  Revision  ChangesPath
  1.5   +1 -1  jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp
  
  Index: snoop.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- snoop.jsp 5 Jan 2005 10:34:52 -   1.4
  +++ snoop.jsp 5 Jan 2005 11:14:09 -   1.5
  @@ -21,7 +21,7 @@
   
   Content length: <%= request.getContentLength() %>
   
  -Content type: <%= request.getContentType() %>
  +Content type: <% 
out.print(util.HTMLFilter.filter(request.getContentType())); %>
   
   Server name: <%= request.getServerName() %>
   
  
  
  

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

DO NOT REPLY [Bug 32952] - Internal server problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32952


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-01-05 11:54 ---
Bugzilla is NOT a support forum.

Bugzilla is for reporting bugs, not for debugging error messages. Please use the
tomcat-user mailing list to ask questions like this.

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

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

DO NOT REPLY [Bug 32952] New: - Internal server problem

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=32952

   Summary: Internal server problem
   Product: Tomcat 4
   Version: 4.0.1 Final
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: Servlet & JSP API
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Does somebody know how to solve this problem:

Apache Tomcat/4.0.1 - HTTP Status 500 - Internal Server Error



type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server Error) 
that prevented it from fulfilling this request.

exception 

javax.servlet.ServletException: Cannot allocate servlet instance for 
path /servlet/bv.bv_question
at org.apache.catalina.servlets.InvokerServlet.serveRequest
(InvokerServlet.java:415)
at org.apache.catalina.servlets.InvokerServlet.doGet
(InvokerServlet.java:180)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke
(ApplicationDispatcher.java:679)
at org.apache.catalina.core.ApplicationDispatcher.doForward
(ApplicationDispatcher.java:431)
at org.apache.catalina.core.ApplicationDispatcher.forward
(ApplicationDispatcher.java:355)
at bv.start.forwardPage(start.java:96)
at bv.start.doGet(start.java:31)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:201)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke
(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2344)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke
(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke
(AccessLogValve.java:462)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext
(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process
(HttpProcessor.java:1011)
at org.apache.catalina.connector.http.HttpProcessor.run
(HttpProcessor.java:1106)
at java.lang.Thread.run(Thread.java:534)


root cause 

java.lang.UnsupportedClassVersionError: bv/bv_question (Unsupported major.minor 
version 8237.8195)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:539)
at java.security.SecureClassLoader.defineClass

cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/snp snoop.jsp

[markt]

markt   2005/01/05 02:34:52

  Modified:webapps/examples/jsp/snp snoop.jsp
  Log:
  Make code consistent.
  
  Revision  ChangesPath
  1.4   +1 -1  jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp
  
  Index: snoop.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- snoop.jsp 5 Jan 2005 10:25:04 -   1.3
  +++ snoop.jsp 5 Jan 2005 10:34:52 -   1.4
  @@ -7,7 +7,7 @@
   
Request Information 
   
  -JSP Request Method: <%= util.HTMLFilter.filter(request.getMethod()) %>
  +JSP Request Method: <% 
out.print(util.HTMLFilter.filter(request.getMethod())); %>
   
   Request URI: <%= request.getRequestURI() %>
   
  
  
  

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

cvs commit: jakarta-tomcat-4.0/webapps/examples/jsp/snp snoop.jsp

[markt]

markt   2005/01/05 02:25:04

  Modified:webapps/examples/jsp/snp snoop.jsp
  Log:
  Fix possible XSS issue.
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp
  
  Index: snoop.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/examples/jsp/snp/snoop.jsp,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- snoop.jsp 23 Apr 2002 15:17:26 -  1.2
  +++ snoop.jsp 5 Jan 2005 10:25:04 -   1.3
  @@ -7,7 +7,7 @@
   
Request Information 
   
  -JSP Request Method: <%= request.getMethod() %>
  +JSP Request Method: <%= util.HTMLFilter.filter(request.getMethod()) %>
   
   Request URI: <%= request.getRequestURI() %>
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapperDefault.properties

[remm]

remm2005/01/05 02:13:11

  Modified:catalina/src/share/org/apache/catalina/util
CharsetMapperDefault.properties
  Log:
  - Add the two languages I know about as HTTP default encoding.
  
  Revision  ChangesPath
  1.3   +2 -0  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapperDefault.properties
  
  Index: CharsetMapperDefault.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapperDefault.properties,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CharsetMapperDefault.properties   5 Jan 2005 09:36:46 -   1.2
  +++ CharsetMapperDefault.properties   5 Jan 2005 10:13:11 -   1.3
  @@ -0,0 +1,2 @@
  +en=ISO-8859-1
  +fr=ISO-8859-1
  
  
  

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

Re: IP issues

[Remy Maucherat]

Davanum Srinivas wrote:
+1 to rewrite the code and go past this problem.
Since the consensus was on rewriting/removing, I have done the following:
- removed the locale to encoding list (which will have to be 
reconstructed based on contributions); this opens up a relatively small 
compatibility issue with some web applications (in particluar, Servlet 
2.3 webapps assuming setLocale would magically set the encoding, and 
Servlet 2.4 webapps without proper locale to encoding declarations)

- replaced the original "algorithm" with this one:
public String getCharset(Locale locale) {
// Match full language_country_variant first, then 
language_country,
// then language only
String charset = map.getProperty(locale.toString());
if (charset == null) {
charset = map.getProperty(locale.getLanguage() + "_"
+ locale.getCountry());
if (charset == null) {
charset = map.getProperty(locale.getLanguage());
}
}
return (charset);
}

- removed the other file (LocaleToCharsetMap), which isn't used in 
Tomcat 5.x

The old tainted Tomcat 3 version is attached (LocaleToCharsetMap).
The version now used in TC 5.5 is attached as well (CharsetMapper). The 
class had been heavily rewritten by Craig already in the Tomcat 4.0 
branch, and the locale->encoding list was externalized to a file (good 
move by Craig, as usual).

This should hopefully clear the problem.
Rémy
On Wed, 5 Jan 2005 01:40:13 +0100, Oliver Zeigermann
<[EMAIL PROTECTED]> wrote:
On Tue, 4 Jan 2005 18:59:16 -0500 (EST), Henri Yandell
<[EMAIL PROTECTED]> >
If the code is legally intricate, ie) ours but not under his CLA, then it
seems quite easy for anyone to rewrite the method based on the method
signature and the JDK file.
Looking at the code it really would be hard to rewrite it - not
because it is too complicated, but because it is pretty hard to think
of another way of doing it as it is so obvious.
Oliver

/*
 *  Copyright 1999-2004 The Apache Software Foundation
 *
 *  Licensed under the Apache License, Version 2.0 (the "License");
 *  you may not use this file except in compliance with the License.
 *  You may obtain a copy of the License at
 *
 *  http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software
 *  distributed under the License is distributed on an "AS IS" BASIS,
 *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 *  See the License for the specific language governing permissions and
 *  limitations under the License.
 */

package org.apache.tomcat.util.http;

import java.util.*;

/** 
 * A mapping to determine the (somewhat arbitrarily) preferred charset for 
 * a given locale.  Supports all locales recognized in JDK 1.1.
 * 
 * @author Jason Hunter
 */
public class LocaleToCharsetMap {

  private static Hashtable map;

  static {
map = new Hashtable();

map.put("ar", "ISO-8859-6");
map.put("be", "ISO-8859-5");
map.put("bg", "ISO-8859-5");
map.put("ca", "ISO-8859-1");
map.put("cs", "ISO-8859-2");
map.put("da", "ISO-8859-1");
map.put("de", "ISO-8859-1");
map.put("el", "ISO-8859-7");
map.put("en", "ISO-8859-1");
map.put("es", "ISO-8859-1");
map.put("et", "ISO-8859-1");
map.put("fi", "ISO-8859-1");
map.put("fr", "ISO-8859-1");
map.put("hr", "ISO-8859-2");
map.put("hu", "ISO-8859-2");
map.put("is", "ISO-8859-1");
map.put("it", "ISO-8859-1");
map.put("iw", "ISO-8859-8");
map.put("ja", "Shift_JIS");
map.put("ko", "EUC-KR"); // Requires JDK 1.1.6
map.put("lt", "ISO-8859-2");
map.put("lv", "ISO-8859-2");
map.put("mk", "ISO-8859-5");
map.put("nl", "ISO-8859-1");
map.put("no", "ISO-8859-1");
map.put("pl", "ISO-8859-2");
map.put("pt", "ISO-8859-1");
map.put("ro", "ISO-8859-2");
map.put("ru", "ISO-8859-5");
map.put("sh", "ISO-8859-5");
map.put("sk", "ISO-8859-2");
map.put("sl", "ISO-8859-2");
map.put("sq", "ISO-8859-2");
map.put("sr", "ISO-8859-5");
map.put("sv", "ISO-8859-1");
map.put("tr", "ISO-8859-9");
map.put("uk", "ISO-8859-5");
map.put("zh", "GB2312");
map.put("zh_TW", "Big5");

  }

  /**
   * Gets the preferred charset for the given locale, or null if the locale
   * is not recognized.
   *
   * @param loc the locale
   * @return the preferred charset
   */
  public static String getCharset(Locale loc) {
String charset;

// Try for an full name match (may include country)
charset = (String) map.get(loc.toString());
if (charset != null) return charset;

// If a full name didn't match, try just the language
charset = (String) map.get(loc.getLanguage());
return charset;  // may be null
  }
}
/*
 * Copyright 1999,2004 The Apache Software Foundation.
 * 
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except 

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java

[Remy Maucherat]

Costin Manolache wrote:
Maybe:
* @author Jason Hunter, as part of the book "Java Servlet Programming"
* (O'Reilly). See http://www.servlets.com/book";>
* http://www.servlets.com/book for more information.
?
I think it is fair to respect the author wish for attribution.
Given that the board recomends against @author tags and they may be 
someday removed, it doesn't matter that much...
I am all in favor of giving proper attribution (author tags), but -1 on 
anything which restricts the ASF's copyright on the code (like 
advertising clauses in this case).

As a result, I have to agree with all that pointed out that the code 
should be rewritten (in this case, the encoding list must be 
reconstructed from scratch).

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapper.java

[remm]

remm2005/01/05 02:00:45

  Modified:catalina/src/share/org/apache/catalina/util
CharsetMapper.java
  Log:
  - Also match laguage_country. This seemed to have been missing.
  
  Revision  ChangesPath
  1.7   +8 -3  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
  
  Index: CharsetMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- CharsetMapper.java5 Jan 2005 09:36:46 -   1.6
  +++ CharsetMapper.java5 Jan 2005 10:00:45 -   1.7
  @@ -100,10 +100,15 @@
* @param locale The locale for which to calculate a character set
*/
   public String getCharset(Locale locale) {
  -// Match full language_country_variant first, then language only
  +// Match full language_country_variant first, then language_country, 
  +// then language only
   String charset = map.getProperty(locale.toString());
   if (charset == null) {
  -charset = map.getProperty(locale.getLanguage());
  +charset = map.getProperty(locale.getLanguage() + "_" 
  ++ locale.getCountry());
  +if (charset == null) {
  +charset = map.getProperty(locale.getLanguage());
  +}
   }
   return (charset);
   }
  
  
  

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util CharsetMapperDefault.properties CharsetMapper.java

[remm]

remm2005/01/05 01:36:46

  Modified:catalina/src/share/org/apache/catalina/util
CharsetMapperDefault.properties CharsetMapper.java
  Log:
  - Craig's version of this was quite different from the tainted version. I 
have rewritten the main "algorithm".
  - The locale -> encoding list must be cleared, and will have to be 
reconstructed again from scratch
based on others contributions. Sevlet 2.4 webapps should be ok, as they are 
supposed to use the
locale to encoding declaration in web.xml.
  
  Revision  ChangesPath
  1.2   +0 -39 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapperDefault.properties
  
<>
  
  
  1.6   +9 -22 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java
  
  Index: CharsetMapper.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CharsetMapper.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- CharsetMapper.java4 Jan 2005 22:14:42 -   1.5
  +++ CharsetMapper.java5 Jan 2005 09:36:46 -   1.6
  @@ -31,7 +31,6 @@
* it loads, or by subclassing it (to change the algorithm) and then using
* your own version for a particular web application.
*
  - * @author Jason Hunter
* @author Craig R. McClanahan
* @version $Date$ $Version$
*/
  @@ -56,9 +55,7 @@
* Construct a new CharsetMapper using the default properties resource.
*/
   public CharsetMapper() {
  -
   this(DEFAULT_RESOURCE);
  -
   }
   
   
  @@ -71,7 +68,6 @@
*  resource could not be loaded for any reason.
*/
   public CharsetMapper(String name) {
  -
   try {
   InputStream stream =
 this.getClass().getResourceAsStream(name);
  @@ -80,8 +76,6 @@
   } catch (Throwable t) {
   throw new IllegalArgumentException(t.toString());
   }
  -
  -
   }
   
   
  @@ -95,8 +89,6 @@
   private Properties map = new Properties();
   
   
  -
  -
   // --- Public Methods
   
   
  @@ -108,20 +100,15 @@
* @param locale The locale for which to calculate a character set
*/
   public String getCharset(Locale locale) {
  -
  -String charset = null;
  -
  -// First, try a full name match (language and country)
  -charset = map.getProperty(locale.toString());
  -if (charset != null)
  -return (charset);
  -
  -// Second, try to match just the language
  -charset = map.getProperty(locale.getLanguage());
  +// Match full language_country_variant first, then language only
  +String charset = map.getProperty(locale.toString());
  +if (charset == null) {
  +charset = map.getProperty(locale.getLanguage());
  +}
   return (charset);
  -
   }
   
  +
   /**
* The deployment descriptor can have a
* locale-encoding-mapping-list element which describes the
  @@ -131,8 +118,8 @@
* @param locale The locale for a character set
* @param charset The charset to be associated with the locale
*/
  -public void addCharsetMappingFromDeploymentDescriptor(String 
locale,String charset) {
  -map.put( locale, charset );
  +public void addCharsetMappingFromDeploymentDescriptor(String locale, 
String charset) {
  +map.put(locale, charset);
   }
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http LocaleToCharsetMap.java

[remm]

remm2005/01/05 01:29:19

  Removed: util/java/org/apache/tomcat/util/http
LocaleToCharsetMap.java
  Log:
  - I cannot clean IP in this file. If it is needed by Tomcat 3, I think it'll 
need to be added back (with
proper attribution) to the Tomcat 3 codebase. Sorry for the trouble :(

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

[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 36 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-05012005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-05012005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-05012005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-05012005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-05012005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 3505012005, brutus:brutus-public:3505012005
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

RE: [VOTE] JK 1.2.8 Stability

[Allistair Crossley]

+1

Not a developer, but we use JK for all our IIS5-Tomcat5.5 requests and also for 
uploading files to our server. We've seen JK broken in the past (stream 
termination, request processing errors and another recent one) all appear to 
have been fixed with 1.2.8.

Cheers, Allistair.

> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED]
> Sent: 04 January 2005 18:43
> To: Tomcat Developers List
> Subject: Re: [VOTE] JK 1.2.8 Stability
> 
> 
> Jess Holle wrote:
> > For those of us lurking waiting for the outcome of this 
> vote, it would 
> > seem to be extraordinarily slow
> >
> 
> Yes. Seems like seasons time :).
> 
> Mladen.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


 
---
QAS Ltd.
Developers of QuickAddress Software
http://www.qas.com";>www.qas.com
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---



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