DO NOT REPLY [Bug 25615] New: - WebApp Classloader can't load GenericPrincipal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25615. 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]
DO NOT REPLY [Bug 25617] New: - jspWriter.println(obj) where obj is null string.. not prints null literal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25617. 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]
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 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 25528] - WebappClassloader does not register with RMI codebase cache
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25528. 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]
problem in .tld pickup from a jar
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 25600] - sessionDestroyed method (in HttpSessionListener) is being called twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25600. 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]
DO NOT REPLY [Bug 25615] - WebApp Classloader can't load GenericPrincipal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25615. 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 25615] - WebApp Classloader can't load GenericPrincipal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25615. 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 25584] - UTF-8 character encoding problem with HTTP get
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25584. 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]
RE: 5.next + 4.1.x future
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 something along the same lines - the whole idea is to reduce the real CPU time spent in context switches - a context
DO NOT REPLY [Bug 25625] New: - Security Restrictions don't apply to initial page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25625. 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: security-constraint web-resource-collection web-resource-namecommon/web-resource-name url-pattern/common/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection auth-constraint role-namegeneral/role-name /auth-constraint user-data-constraint transport-guaranteeNONE/transport-guarantee /user-data-constraint /security-constraint and you define your welcome file in that directory welcome-file-list welcome-file/common/examplePage.jsp/welcome-file /welcome-file-list 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]
DO NOT REPLY [Bug 25625] - Security Restrictions don't apply to initial page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25625. 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: welcome-file/common/examplePage.jsp/welcome-file GOOD: welcome-fileexamplePage.jsp/welcome-file - 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23802. 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25625. 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 25625] - Security Restrictions don't apply to initial page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25625. 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 25628] New: - NPE is thrown when jar containing tld file is not found in WEB-INF/lib
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25628. 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-jdk14java 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 25629] New: - jsp include tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25629. 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 jsp:include page=/css/StyleSheet.jsp flush=true/ 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 25629] - jsp include tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25629. 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]
RE: Intro/question possible buglet with Content-Type and Charsets - now more of an RFC
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, e-mail: [EMAIL PROTECTED]
-
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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20073. 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]
DO NOT REPLY [Bug 25617] - jspWriter.println(obj) where obj is null string.. not prints null literal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25617. 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); % br/ myObject is % out.println(myObject); % br/ is myString is null myObject is null - 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25634. 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)]
Re: 5.next + 4.1.x future
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 8200] - include (PageContext) does not throw IOException if resource not available
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8200. 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]
DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8200. 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 11208] - form-based authentication failed to use the proper error page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11208. 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 3865] - 403 response code .
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3865. 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]
RE: jk2 .. uncomfortably silent ?
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 8200] - include (PageContext) does not throw IOException if resource not available
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8200. 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]
DO NOT REPLY [Bug 8200] - include (PageContext) does not throw IOException if resource not available
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8200. 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 25639] New: - CGIServlet only runs perl code
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25639. 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]
