DO NOT REPLY [Bug 25639] New: - CGIServlet only runs perl code

[bugzilla]

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

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

CGIServlet only runs perl code

   Summary: CGIServlet only runs perl code
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlets:CGI
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


line 1572 explicitly appends the string "perl " to the beginning of each CGI
command making it impossible to run non perl programs as CGIs.

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

DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available

[bugzilla]

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

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

include (PageContext) does not throw IOException if resource not available





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 01:36 ---
It doesn't look like the patch will work for the case of a mapped Servlet 
(e.g. a pre-compiled JSP).  There is no reason to expect that there will be a 
physical resource on the other end of the request.

I like the WONTFIX personally, since it is cleanest.  Otherwise, maybe having 
DefaultServlet throw a FileNotFound exception if it is being included.

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

DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available

[bugzilla]

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

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

include (PageContext) does not throw IOException if resource not available





--- Additional Comments From [EMAIL PROTECTED]  2003-12-19 01:04 ---
The patch looks OK.

However, be aware that this part of spec has been updated in JSP 2.0, so that
the  behavior of PageContext.include now follows that of
javax.servlet.RequestDispatcher.include.  So if this is fixed in TC4, it would
behave differently from TC5.

I wouldn't mind if this bug is resolved to WONTFIX, just to keep the same
behavior in both versions of TC.

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

RE: jk2 .. uncomfortably silent ?

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

> Tomcat is a child process (ProcessID=0) to HTTP Server
> What is your specific concern?
> -Martin


My specific concern is mentioned in the message below.. i have pasted
the relevant sections of code there. 
--Roshan


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

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

DO NOT REPLY [Bug 3865] - 403 response code .

[bugzilla]

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

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

403 response code .

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 23:08 ---
*** Bug 11208 has been marked as a duplicate of this bug. ***

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

DO NOT REPLY [Bug 11208] - form-based authentication failed to use the proper error page

[bugzilla]

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

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

form-based authentication failed to use the proper error page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 23:08 ---


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

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

DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available

[bugzilla]

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

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

include (PageContext) does not throw IOException if resource not available





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 22:59 ---
Created an attachment (id=9636)
Proposed patch for TC4 to fix this bug

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

DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available

[bugzilla]

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

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

include (PageContext) does not throw IOException if resource not available





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 22:59 ---
I have a proposed patch for this. I am not 100% sure about this patch so I 
would be grateful if one of the committers with more knowledge of jasper than 
I reviewed the patch before it gets committed.

I will attach the patch shortly.

Thanks.

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

Re: 5.next + 4.1.x future

[David Rees]

Costin Manolache wrote:
Jan-Henrik Haukeland wrote:
Remy Maucherat <[EMAIL PROTECTED]> writes:
My opinion is that NIO is going to be really useless.
Eh, hello!? Oh, okay if it's not important that Tomcat scale and
perform well it may be useless. But, really, before NIO it was
hopeless to try and write a scalable and fast tcp server application
in Java. Tomcat's current connection handling with blocing all over
the place and "thundering herd" problem doesn't scale or work very
well under heavy load.
Only thing you can save is the static servlet - but for that you are 
better off using a real server or a cache.
But as Remy mentioned:

Static content is handled with a regular (well, almost) servlet, and 
all those requests have to go through the filter pipeline (ie, user 
components). This is the exact same problem when having Apache serve
 static files.
So unless you break the spec, you still will need to spawn a thread to 
process static content through the filter pipeline.

If that happens to be OK for your application, then you are right, 
better to use a real server or cache in front of your application (like 
Squid www.squid-cache.org).

-Dave

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

DO NOT REPLY [Bug 25634] New: - failed to connect endpoint errno=61 Unknown error

[bugzilla]

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

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

failed to connect endpoint errno=61 Unknown error

   Summary: failed to connect endpoint errno=61 Unknown error
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have configured multiple Tomcat instances with IIS 5.1 using the 
isapi_redirector2.dll. The load balancing appears to be working, however I am 
receiving error messages in my jk2.log that I cannot decipher. I have 
configured two instances with ports 8011 and 8013. Following are the error 
messages from the jk2.log. Any advice would be appreciated. Thanks.

[Wed Dec 17 15:45:42 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8011 61 Unknown error 
[Wed Dec 17 15:45:42 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8011
[Wed Dec 17 15:45:42 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:45:42 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8011 1 1
[Wed Dec 17 15:45:42 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8011
[Wed Dec 17 15:45:43 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8013 61 Unknown error 
[Wed Dec 17 15:45:43 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8013
[Wed Dec 17 15:45:43 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:45:43 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8013 1 1
[Wed Dec 17 15:45:43 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8013
[Wed Dec 17 15:45:44 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8011 61 Unknown error 
[Wed Dec 17 15:45:44 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8011
[Wed Dec 17 15:45:44 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:45:44 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8011 1 1
[Wed Dec 17 15:45:44 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8011
[Wed Dec 17 15:45:45 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8013 61 Unknown error 
[Wed Dec 17 15:45:45 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8013
[Wed Dec 17 15:45:45 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:45:45 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8013 1 1
[Wed Dec 17 15:45:45 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8013
[Wed Dec 17 15:45:46 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8011 61 Unknown error 
[Wed Dec 17 15:45:46 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8011
[Wed Dec 17 15:45:46 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:45:46 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8011 1 1
[Wed Dec 17 15:45:46 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8011
[Wed Dec 17 15:45:46 2003] (error ) [jk_worker_lb.c (353)]  lb_worker.service
() all workers in error or disabled state
[Wed Dec 17 15:46:19 2003] (error ) [jk_channel_socket.c (335)]  
channelSocket.open() connect failed localhost:8013 61 Unknown error 
[Wed Dec 17 15:46:19 2003] (error ) [jk_worker_ajp13.c (247)]  ajp13.connect() 
failed ajp13:localhost:8013
[Wed Dec 17 15:46:19 2003] (error ) [jk_worker_ajp13.c (322)]  ajp13.service() 
failed to connect endpoint errno=61 Unknown error
[Wed Dec 17 15:46:19 2003] (error ) [jk_worker_ajp13.c (512)]  ajp13.service() 
Error  forwarding ajp13:localhost:8013 1 1
[Wed Dec 17 15:46:19 2003] (error ) [jk_worker_lb.c (407)]  lb.service() 
worker failed 12 for ajp13:localhost:8013
[Wed Dec 17 15:46:20 2003] (error ) [jk_channel_socket.c (335)]  
channelS

DO NOT REPLY [Bug 25617] - jspWriter.println(obj) where obj is null string.. not prints "null" literal

[bugzilla]

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

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

jspWriter.println(obj) where obj is null string..   not prints "null" literal

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 18:53 ---
The response for the following test:

<%! String myString = null; %>
<%! Object myObject = myString; %>

myString is <% out.println(myString); %>

myObject is <% out.println(myObject); %>


is

myString is null
myObject is null

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

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

[bugzilla]

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

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

no object DCH for MIME type text/plain





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 18:52 ---
In fact, there is another possible cause for this problem depending on the platform:

on Mac OS X (server), the existence of a different version of "activation.jar" in 
/Library/Java/
Extensions will cause this error, and no amount of catalina.policy manipulation will 
clear it up.  The 
solution is to remove /Library/Java/Extensions/activation.jar .  (Not sure if this 
causes other 
problems on the system, haven't run into any yet.)

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

RE: Intro/question possible buglet with Content-Type and Charsets - now more of an RFC

[Greg . Cope]

Hi All,

(We may be barking up the wrong tree here, so if so please point me in the
right direction)

This is still causing us issues - as IE fails to parse a charset when it is
tacked on to Content-Type: application/vnd.ms-excel

It would appear that the charset is being tacked onto the Content-Type in
setContentType method of
catalina/src/share/org/apache/catalina/connector/ResponseBase.java in the
event of it not being supplied in the Content-Type (it looks for a ';')

The encoding can never be null as it is extracted from the locale in the
setLocale method below it.

I understand this to mean that the charset will always be tacked on
irrespective of the Type.

However;

I cannot find an explicit reference to not defining a charset for binary
Types, but I cannot see why you would want to.

HTTP 1.1 implies that there is a default charset for text Types (makes
sense)(http://www.w3.org/Protocols/rfc2068/rfc2068)

'When no explicit charset parameter is provided by the sender, media
subtypes of the "text" type are defined to have a default charset value of
"ISO-8859-1"' 

Which I understand that it is fair enough to add it to text/* Types.

RFC 1341 (http://www.faqs.org/rfcs/rfc1341.html) states that:

'2.a.  A "text" Content-Type value, which can be used to represent  textual
information  in  a  number  of character  sets  and  formatted  text
description languages in a standardized manner.'

But no mention of Charsets in Application types:

'2.c.  An "application" Content-Type value, which can be used  to transmit
application data or binary data, and hence,  among  other  uses,  to
implement  an electronic mail file transfer service.

What I would suggest is a little if wrapper to only add a default if the
Content-Type is text/

A sudo code below (not tested)

###
catalina/src/share/org/apache/catalina/connector/ResponseBase.java

 public void setContentType(String type) {

if (isCommitted())
return;

if (included)
return; // Ignore any call from an included servlet

this.contentType = type;
if (type.indexOf(';') >= 0) {
encoding = RequestUtil.parseCharacterEncoding(type);
if (encoding == null)
encoding = "ISO-8859-1";
} else {
if (encoding != null && type.startsWith('text/'))
this.contentType = type + ";charset=" + encoding;
}

}

Regards,

Greg


> -Original Message-
> From: Tim Funk [mailto:[EMAIL PROTECTED]
> Sent: 16 December 2003 18:09
> To: Tomcat Developers List
> Subject: Re: Intro/question possible buglet with Content-Type and
> Charsets .
> 
> 
> Yeah, nagoya.apache.org seems down. Hopefully it will be back 
> soon. The bug 
> has good detail of what and how to fix.
> 
> -Tim
> 
> [EMAIL PROTECTED] wrote:
> 
> > Thanks Tim,
> > 
> > Having a little trouble getting anything from bugzilla, 
> nagoya.apache.org
> > seems to be having a little trouble!
> > 
> > Looking in the archives for this id, I see that someone has 
> a 4.1.29 patch
> > and a complied class, but cannot see either email address 
> or content via the
> > archive.
> > 
> > Ho hum
> > 
> > Thanks for the pointer.
> > 
> > Greg
> > 
> > 
> > 
> > 
> >>-Original Message-
> >>From: Tim Funk [mailto:[EMAIL PROTECTED]
> >>Sent: 16 December 2003 12:31
> >>To: Tomcat Developers List
> >>Subject: Re: Intro/question possible buglet with Content-Type and
> >>Charsets.
> >>
> >>
> >>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24970
> >>
> >>[EMAIL PROTECTED] wrote:
> >>
> >>>Hi All,
> >>>
> >>>Quick intro, and then a question;
> >>>
> >>>We use tomcat to host java web applications at our 
> >>
> >>location.  My client
> >>
> >>>requires us to follow very strict rules for deploying 
> >>
> >>software, that means
> >>
> >>>it can be a documentation intensive process (evidence 
> >>
> >>gathering/ IQP's etc
> >>
> >>>).  So we rarely upgrade as it is quite allot of 
> >>
> >>work. Luckily
> >>
> >>>tomcat is excellent and rarely needs upgrading or patching.
> >>>
> >>>Now the question;
> >>>
> >>>Tomcat 4.1.29 seems to insist on added charset to the 
> >>
> >>content type, even if
> >>
> >>>a Content-Type has been set using response.setContentType 
> or similar
> >>>(without a charset).  Tomcat 5 seems to do something 
> >>
> >>similar judging from
> >>
> >>http://www.mail-archive.com/[EMAIL PROTECTED]/msg4
> >>9015.html but
> >>
> >>>I think it fails to check if the Content type is a text one 
> >>
> >>(HTML) and adds
> >>
> >>>it for any content type, which would appear not to be right IMHO.
> >>>
> >>>Without wishing to appear rude :-) I need to change this 
> >>
> >>behaviour and
> >>
> >>>remove the insertion of the charset for non text based 
> >>
> >>Content-Types  eg:
> >>
> >>>application/vnd.ms-excel
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands

DO NOT REPLY [Bug 25629] - jsp include tag

[bugzilla]

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

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

jsp include tag

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 16:30 ---
There should be more errors in the logs files. Please use tomcat-user to debug
until it is proven this is a tomcat bug.

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

DO NOT REPLY [Bug 25629] New: - jsp include tag

[bugzilla]

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

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

jsp include tag

   Summary: jsp include tag
   Product: Tomcat 5
   Version: 5.0.16
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I currently have a webapp running under tomcat 4.1.29 and everything works fine.
I create an instance of the same application on my new tomcat 5.0.16 server and 
the initial index.jsp page throws the following exception.

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

exception 

javax.servlet.ServletException: 
org.apache.jasper.runtime.JspRuntimeLibrary.include
(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;
Ljava/lang/String;Ljavax/servlet/jsp/JspWriter;Z)V
org.apache.jasper.runtime.PageContextImpl.doHandlePageException
(PageContextImpl.java:867)
org.apache.jasper.runtime.PageContextImpl.handlePageException
(PageContextImpl.java:800)
avbase.winairweb.jsp.Index_jsp._jspService(Unknown Source)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)


The only tag in this index page is this one


Which works perfectly under the previous version of tomcat.

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

DO NOT REPLY [Bug 25628] New: - NPE is thrown when jar containing tld file is not found in WEB-INF/lib

[bugzilla]

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

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

NPE is thrown when jar containing tld file is not found in WEB-INF/lib

   Summary: NPE is thrown when jar containing tld file is not found
in WEB-INF/lib
   Product: Tomcat 4
   Version: 4.1.27
  Platform: All
OS/Version: All
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Jasper 2's implementation is such that it expects the jar files containing the 
tld files in WEB-INF/lib of a web application. If the jar file containing the 
tld is not present WEB-INF/lib directory, it throws NullPointerException (and 
hence JasperException). Below given is the stacktrace 

C:\DRIVE_E\advent1\jakarta\tomcat4.x\jakarta-tomcat-4.1.27-LE-jdk14>java org.
apache.jasper.JspC -v9 -d . webapps\wcfphase1\sa
ravanan\test.jsp
2003-12-18 09:14:27 - uriRoot implicitly set to "C:
\DRIVE_E\advent1\jakarta\tomcat4.x\jakarta-tomcat-4.1.27-LE-jdk14\webapps\
wcfphase1"
2003-12-18 09:14:28 - ERROR-the file '\saravanan\test.jsp' generated the 
following general exception: java.lang.NullPointerEx
ception
error:org.apache.jasper.JasperException: Error compiling \saravanan\test.jsp
at org.apache.jasper.JspC.processFile(JspC.java:596)
at org.apache.jasper.JspC.execute(JspC.java:801)
at org.apache.jasper.JspC.main(JspC.java:823)

It should give a proper message stating the tld file referred in not found.

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

DO NOT REPLY [Bug 25625] - Security Restrictions don't apply to initial page

[bugzilla]

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

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

Security Restrictions don't apply to initial page





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 15:07 ---
Tomcat 4 issues an external redirect of welcome files so after the redirect is
performed, the security constraint may be applied.

Tomcat5 does an internal forwards. (Which is also legal according to the spec)

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

DO NOT REPLY [Bug 25625] - Security Restrictions don't apply to initial page

[bugzilla]

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

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

Security Restrictions don't apply to initial page





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 14:58 ---
O.K, I thought it was a bug, because in tomcat 4 it works flawlessly

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

DO NOT REPLY [Bug 23802] - Bug Workaround: Custom 401 error page fails WWW-Authenticate 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://nagoya.apache.org/bugzilla/show_bug.cgi?id=23802

Bug Workaround: Custom 401 error page fails WWW-Authenticate header





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 14:48 ---
Hi,

I'm having the same problem with JBoss 3.2.2 (with Tomcat 4.1.27).

Julien Dubois.

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

DO NOT REPLY [Bug 25625] - Security Restrictions don't apply to initial page

[bugzilla]

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

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

Security Restrictions don't apply to initial page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 14:38 ---
Security constraints are defined on the incoming URL. The incoming URL is not
/common/* so the contraint doesn't apply.

Side note: it is not recommended to use paths with / in it as welcome files. 
BAD: /common/examplePage.jsp
GOOD: examplePage.jsp

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

DO NOT REPLY [Bug 25625] New: - Security Restrictions don't apply to initial page

[bugzilla]

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

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

Security Restrictions don't apply to initial page

   Summary: Security Restrictions don't apply to initial page
   Product: Tomcat 5
   Version: 5.0.16
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In Tomcat 5, if you restrict a directory in web.xml, so no user can access
without login:


 
  common
  /common/*
  POST
  GET
 
 
  general
 
 
  NONE
 


and you define your welcome file in that directory


/common/examplePage.jsp

when you access to your application (Ex: localhost:8080/myApp) it access
directly to examplePage (forgetting the access restriction) BUT if you access
the file directly, the access restriction works
(localhost:8080/myApp/common/examplePage.jsp redirects to your login page)

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

RE: 5.next + 4.1.x future

[Shapira, Yoav]

Howdy,
Your name seems familiar... Ah yes, the log4j TRACE discussion.

Anyways, your suggestion is interesting.  It seems like it'd be a lot of work, so it 
should only be done if the benefit is significant.  What would you estimate the 
throughput increase over the current implementation would be (for a "NIO-able" 
servlet)?

Yoav Shapira
Millennium ChemInformatics


>-Original Message-
>From: Endre Stølsvik [mailto:[EMAIL PROTECTED]
>Sent: Thursday, December 18, 2003 4:48 AM
>To: Tomcat Developers List
>Subject: Re: 5.next + 4.1.x future
>
>[ a little late here, but hey.. ]
>
>On Fri, 12 Dec 2003, David Rees wrote:
>
>| On Fri, December 12, 2003 at 2:12 pm, Adam Fisk wrote:
>| >
>| > I'd be happy to send my data to the group if people are interested.
>| > Aside from memory, I was surprised to find that the effect on CPU was
>| > negligible (not much of a benefit from no context-switching between
>| > threads) -- CPU was virtually the same in both cases.  So, the scaling
>| > benefits on Windows basically come from not having to allocate more
>| > memory to new threads.  I'm unfortunately not as familiar with the
>| > Tomcat code as I'd like to be, but I assume it makes intelligent use of
>| > thread pooling, which may even the memory benefits of NIO negligible.
>| > At the same time, though, NIO may remove some of the constraints
>| > introduced by thread pooling, possibly allowing Tomcat to handle
>heavier
>| > loads without blowing up.  An optimized NIO server would if anything
>| > out-perform a blocking server, but maybe by not that much.
>|
>| On current Linux systems, once you start getting 500+ processes/threads
>| active on a typical machine, you will find that context switching starts
>| taking up a significant amount of system time, especially if you decide
>to
>| run any system moniting tools (like ps, or top).  This is better with the
>| upcoming 2.6 kernels, but still doesn't scale to thousands of active
>| threads very well.
>|
>| However, given that you need a thread anyway to server any dynamic
>| content, I don't see NIO helping that much for your typical web
>| application.  I could see NIO helping scale the serving of static content
>| which would be useful where people are using Tomcat standalone.  Maybe
>| someone can prove me wrong.  ;-)
>
>I've also been wondering about NIO for some time, and whether a Servlet
>Container ever could benefit from it.
>
>What about this idea: if you have two types of threads, one set of Servlet
>threads, and then one (or more) threads that do all the IO, and a set of
>-memory buffers- inbetween, what would you get?
>
>See, the thing is about caching - and letting the Servlet distance itself
>from the client. The normal case is that the output stream is more or less
>"directly attached" to the client. But if you do this other thing, having
>a memory buffer inbetween, the servlet thread could do its stash, and
>exit, immediately. Hopefully it could do several such operations within
>-one- context switch, instead of having to IO block "on every byte
>output". (Btw: i do realize that the Servlet spec allows for a buffer on
>the output stream:  this is something slightly different: a forced
>total-buffering of the servlet's output)
>
>So, one could tag servlets with "NIO-able" true/false. NIO-able are
>servlets that typically don't produce more than 10k of data (or something
>like that), and that doesn't need to "hang onto the client", typically a
>servlet outputting and flushing (thus, "sending") one byte a second while
>it does the heavy database query.
>  Thus, if a servlet needs this direct link to the client, or produces
>very large "result sets", it can't be "NIOed", in the first case because
>it -needs- this direct link between the server thread and the client, and
>in the second case because the memory-buffer requirement would be to
>heavy.
>
>If one have loads of memory, this idea could potentially speed up
>processing a bit by not spening an excessive amount of CPU time in context
>switches. One have to realize that the clients' line-speed (and slowstart
>on the TCP stack) often will lead to a servlet having to spend multiple
>context switches before being able to exit due to the blocking of the IO -
>this could be totally eliminated in many cases using this aproach of
>dividing a dynamic page generation into two totally distinct steps: the
>generation of the page, and the sending of that resulting page over the
>network.
>
>The connector architecture in earlier tomcats used to not be able to queue
>requests; if no worker thread was available, it immediately returned a
>"server full" response. I then advocated an approach of having a set of
>worker threads (a limited set), and a line of incoming requests (that then
>might have a higher number of "slots" than the number of available
>workers), and then a dispatcher that stands inbetween. I believe that
>something along the same lines have been implemented now.  This suggestion
>here is s

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

[bugzilla]

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

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

UTF-8 character encoding problem with HTTP get

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 13:49 ---
Setting uriEncoding to UTF-8 in config resolved the problem, however it was 
not necessary in Tomcat 4.0. The bug appeared when we moved to 5.0 from 4.0. 
Thank you!

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

DO NOT REPLY [Bug 25615] - WebApp Classloader can't load GenericPrincipal

[bugzilla]

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

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

WebApp Classloader can't load GenericPrincipal





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 12:33 ---
Well, as I understand I'm encouraged to implement the interface Principal in a 
custom class. Is Tomcat allowing me to do so? I mean - does Tomcat rely on 
GenericPrincipal?

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

DO NOT REPLY [Bug 25615] - WebApp Classloader can't load GenericPrincipal

[bugzilla]

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

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

WebApp Classloader can't load GenericPrincipal

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 12:07 ---
Please follow up with tomcat-user for more detail if needed

GenericPrincipal lives in the server's classloader. Webapps do not have access
to any of the classes in the server classloader. To allow access, you can add
the attribute privileged="true" to your Context declaration - but this does open
security holes since it allows the webapp to access catalina internals.

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

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

[bugzilla]

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

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

sessionDestroyed method (in HttpSessionListener) is being called twice





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 11:13 ---
I didn't mean to sound rude or anything else, guys... It happens that English 
is not my "mother language" - I use it only for business and technically... So, 
I don't use to worry about diplomacy while I'm writing - I just go straight to 
the point. I'm old enough to know that we must treat people the way we want to 
be treated, but this is something that I do in my natural language only...

Well, as I said before, I can overcome that "triggering twice" problem of 
Tomcat, but I wanted to know WHAT was happening... Now I do...:D

And since I don't have the needed patience to apply patches, I'll wait until 
the next release (or sub-release) of Tomcat... Could you PLEASE tell me when 
the "5.0.17" sub-release will be available - with this tiny problem fixed ?

Thanks for the attention,
Roberto

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

problem in .tld pickup from a jar

[A Misra]

Hi,

I am facing some problem in .tld pickup from a jar(in
WEB-INF/lib). This may be a bug or my poor
understanding of the jsp specifications. Any
pointer/clarification will be highly appreciated.


Scenario - 1


Two tlds placed under META-INF directory and
META-INF/subdirectory respectively (with separate
uri's)

(a.jar)
 -- META-INF
  -- someNotDef.tld (uri - abc)
  -- subDir
   -- someNotDef.tld (uri - xyz)

This jar is not mapped in the web.xml.

Both the tlds's are read and i get the expected output
from the jsp.


Scenario - 2


A single taglib is placed as someDef.tld under
META-INF dir of the jar.

This jar is mapped in the web.xml.

Now the parser is looking just for the taglib.tld in
the META-INF directory and i get the following
stack-trace

org.apache.jasper.JasperException: Unable to read TLD
"META-INF/taglib.tld" from JAR file
"file:/home/ambrish/tools/jakarta-tomcat-5.0.4/webapps/tld_pick_dh/WEB-INF/lib/notDef.jar":
java.lang.NullPointerException
at
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:94)
at
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:365)
at
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:216)
at
org.apache.jasper.compiler.TagLibraryInfoImpl.(TagLibraryInfoImpl.java:203)
at
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:456)
at
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:517)
at
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1567)
at
org.apache.jasper.compiler.Parser.parse(Parser.java:174)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:254)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:154)
at
org.apache.jasper.compiler.ParserController.parse(ParserController.java:140)
at
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:250)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:458)
at
org.apache.jasper.compiler.Compiler.compile(Compiler.java:444)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:603)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:300)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:293)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:286)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:205)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:177)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:562)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:203)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:637)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:488)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:568)
   

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

[bugzilla]

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

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

WebappClassloader does not register with RMI codebase cache





--- Additional Comments From [EMAIL PROTECTED]  2003-12-18 10:08 ---
Invalid bug?

I think that this bug is invalid as it suggests that the WebappClassLoader 
should “register with the RMI codebase cache”. However, registering every 
WebappClassLoader as a codebase loader will simply cause the getClassAnnitation
(Class) method in sun.rmi.server.LoaderHandler to return the default codebase, 
which is the value of the “java.rmi.server.codebase” system property. This will 
disable the RMI server to dynamically load classes from the web application if 
needed, which might be OK in some situations where the server already has 
access to required classes but should not be considered a valid solution for a 
multi-purpose Container. Moreover, what will happen if running on a JVM not 
provided by Sun? 

I would really appreciate if one of the TC developers (or someone with deeper 
RMI knowledge than me) could comment this.

Thanks,
Daniel

PS: I too have been experiencing performance problems when calling remote 
objects using RMI from within a web application, however, the patch that was 
committed by Remy last week solved my problems (Thanks a lot! :D ). I’d really 
appreciate if this patch was applied for TC4.1 as well (i.e., available in the 
next release).

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

Re: 5.next + 4.1.x future

[Endre Stølsvik]

[ a little late here, but hey.. ]

On Fri, 12 Dec 2003, David Rees wrote:

| On Fri, December 12, 2003 at 2:12 pm, Adam Fisk wrote:
| >
| > I'd be happy to send my data to the group if people are interested.
| > Aside from memory, I was surprised to find that the effect on CPU was
| > negligible (not much of a benefit from no context-switching between
| > threads) -- CPU was virtually the same in both cases.  So, the scaling
| > benefits on Windows basically come from not having to allocate more
| > memory to new threads.  I'm unfortunately not as familiar with the
| > Tomcat code as I'd like to be, but I assume it makes intelligent use of
| > thread pooling, which may even the memory benefits of NIO negligible.
| > At the same time, though, NIO may remove some of the constraints
| > introduced by thread pooling, possibly allowing Tomcat to handle heavier
| > loads without blowing up.  An optimized NIO server would if anything
| > out-perform a blocking server, but maybe by not that much.
|
| On current Linux systems, once you start getting 500+ processes/threads
| active on a typical machine, you will find that context switching starts
| taking up a significant amount of system time, especially if you decide to
| run any system moniting tools (like ps, or top).  This is better with the
| upcoming 2.6 kernels, but still doesn't scale to thousands of active
| threads very well.
|
| However, given that you need a thread anyway to server any dynamic
| content, I don't see NIO helping that much for your typical web
| application.  I could see NIO helping scale the serving of static content
| which would be useful where people are using Tomcat standalone.  Maybe
| someone can prove me wrong.  ;-)

I've also been wondering about NIO for some time, and whether a Servlet
Container ever could benefit from it.

What about this idea: if you have two types of threads, one set of Servlet
threads, and then one (or more) threads that do all the IO, and a set of
-memory buffers- inbetween, what would you get?

See, the thing is about caching - and letting the Servlet distance itself
from the client. The normal case is that the output stream is more or less
"directly attached" to the client. But if you do this other thing, having
a memory buffer inbetween, the servlet thread could do its stash, and
exit, immediately. Hopefully it could do several such operations within
-one- context switch, instead of having to IO block "on every byte
output". (Btw: i do realize that the Servlet spec allows for a buffer on
the output stream:  this is something slightly different: a forced
total-buffering of the servlet's output)

So, one could tag servlets with "NIO-able" true/false. NIO-able are
servlets that typically don't produce more than 10k of data (or something
like that), and that doesn't need to "hang onto the client", typically a
servlet outputting and flushing (thus, "sending") one byte a second while
it does the heavy database query.
  Thus, if a servlet needs this direct link to the client, or produces
very large "result sets", it can't be "NIOed", in the first case because
it -needs- this direct link between the server thread and the client, and
in the second case because the memory-buffer requirement would be to
heavy.

If one have loads of memory, this idea could potentially speed up
processing a bit by not spening an excessive amount of CPU time in context
switches. One have to realize that the clients' line-speed (and slowstart
on the TCP stack) often will lead to a servlet having to spend multiple
context switches before being able to exit due to the blocking of the IO -
this could be totally eliminated in many cases using this aproach of
dividing a dynamic page generation into two totally distinct steps: the
generation of the page, and the sending of that resulting page over the
network.

The connector architecture in earlier tomcats used to not be able to queue
requests; if no worker thread was available, it immediately returned a
"server full" response. I then advocated an approach of having a set of
worker threads (a limited set), and a line of incoming requests (that then
might have a higher number of "slots" than the number of available
workers), and then a dispatcher that stands inbetween. I believe that
something along the same lines have been implemented now.  This suggestion
here is something along the same lines - the whole idea is to reduce the
real CPU time spent in context switches - a context switch isn't just the
registers and memory maps, it is also flushing of the CPU's Lx caches!

-- 
Mvh,
Endre Stølsvik   M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS -  http://www.coretrek.com/
CoreTrek corporate portal / EIP -  http://www.corelets.com/

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

DO NOT REPLY [Bug 25617] New: - jspWriter.println(obj) where obj is null string.. not prints "null" literal

[bugzilla]

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

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

jspWriter.println(obj) where obj is null string..   not prints "null" literal

   Summary: jspWriter.println(obj) where obj is null string..   not
prints "null" literal
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


jspWriter.println(obj); where this Obj is a null String Object, prints empty
String not a "null" literal as per specs ..

public abstract void print(java.lang.String s)
Print a string. If the argument is null then the string “null” is printed.
Otherwise,
the string’s characters are converted into bytes according to the platform’s
default character encoding, and these bytes are written in exactly the
manner of the java.io.Writer.write(int) method.

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

DO NOT REPLY [Bug 25615] New: - WebApp Classloader can't load GenericPrincipal

[bugzilla]

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

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

WebApp Classloader can't load GenericPrincipal

   Summary: WebApp Classloader can't load GenericPrincipal
   Product: Tomcat 4
   Version: Unknown
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We use a custom Realm (MyRealm) with a custom Principal Class MyPrincipal.
MyPrincipal extends org.apache.catalina.realm.GenericPrincipal and additionally
implements a custom Interface MyId.
Thus, we placed myJar.jar (the jar containing both classes) in the server/lib 
directory.
The authentication works, the WebApp call to request.getUserPrincipal() returns 
an object that is of class MyPrincipal (confirmed via 
myPrincipalInstance.getClass() ).
We then try to cast myPrincipalInstance to the Interface MyId which causes
a class cast exception.
Exploring the error reveals that the WebApp class loader could not load the 
class org.apache.catalina.realm.GenericPrincipal .
We tried the following workarounds:
1. Modify the class MyPrincipal not to extend 
org.apache.catalina.realm.GenericPrincipal, but implement the two interfaces 
java.security.Principal und MyId -> this causes a complete failure of Tomcat's 
authentication.
2. Place the jar myJar.jar in the common/lib dir -> Tomcat isn't able to load 
the class MyRealm on startup.

I assume custom Principal are supposed to work in Tomcat.
Am I doing wrong?

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