Re: Null pointer in manager web app. Tomcat 6.0.14
On Sun, 27 Jan 2008 16:01:28 -0800 Hassan Schroeder wrote: Aside from the fact that putting Context elements in server.xml is strongly discouraged Various people tend to claim the same thing on this list. I'm pretty sure there is a functionality which could not be achieved otherwise, although I could not remember which one at this very moment. I've been doing conf/Catalina/HOST/CONTEXT.xml stuff for some time and reverted back to the Contexts defined in server.xml . I want the automatic reloads/deployment completely disabled and it might have been something related with it. having a docBase == appBase is totally wrong, and /will/ cause ugly problems. Context path= docBase=/home/USER/web-root It doesn't cause any problems. And has been working since the early 6.0.x releases. Some problems might appear if you have some sort of automatic deployment/reloading. My post is actually a bug report. Not a question. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Null pointer in manager web app. Tomcat 6.0.14
On Mon, 28 Jan 2008 20:16:14 + Mark Thomas wrote: Delian Krustev wrote: I'm pretty sure there is a functionality which could not be achieved otherwise, although I could not remember which one at this very moment. No, there isn't. If there is, that is a bug that needs to be fixed. It doesn't cause any problems. And has been working since the early 6.0.x releases. Some problems might appear if you have some sort of automatic deployment/reloading. appBase == docBase is unsupported. Period. The servlet spec allows (might even be requires I don't recall off-hand) any directory to treated as a webapp so as soon as you have an WAR exploded into the appBase you end up with multiple contexts which will cause problems. I don't see a conflict here. Have you looked at the configuration I've posted ? workDir=work/Catalina/USER/DOMAIN Wars are expanded in the work dir, which is not anywhere under the appBase Additionally: unpackWARs=false deployXML=false deployOnStartup=false autoDeploy=false You need to fix your configuration. appBase in my case is completely irrelevant. I could point it to anywhere and it won't make any difference. Well, I'm not sure I'll find the time to experiment with the contexts in separate files especially when it did not work for me. I'm sorry I haven't filed a bug report then. I'd prefer to spend more time with my 12 days old daughter than chasing tomcat bugs ;) Those NPEs have been fixed in svn and will be in the next release. Here we go. Thank you :-) BTW, Mark. Still haven't received a reply from you on the Juli CVE issue. Have you received my message, stating the fix is not sufficient ? Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Null pointer in manager web app. Tomcat 6.0.14
On Mon, 28 Jan 2008 22:01:37 + Mark Thomas wrote: With your specific configuration you might be OK but appBase==docBase is something that usually always cause pain. Yes, *usually*. And I'm aware of this ;) My main concern is making sure that people reading this thread in the archives don't go away thinking that appBase==docBase is ever a good idea. People tend to omit the docs. Taking care for random zealots pasting configuration from mailings lists might be a waste of time though. I replied a few hours after you sent the message asking you for more info. Looks like it didn't get through. I'll re-send it. I got it this time and will look at it. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Null pointer in manager web app. Tomcat 6.0.14
Hi, This seems to happen when there is a broken WAR inside a vhost. Other vhosts work fine at the same time. 2008-01-27 23:21:07.556049500 INFO: HTMLManager: list: Listing contexts for virtual host 'DOMAIN' 2008-01-27 23:21:07.556050500 Jan 27, 2008 11:21:07 PM org.apache.catalina.core.StandardWrapperValve invoke 2008-01-27 23:21:07.556052500 SEVERE: Servlet.service() for servlet HTMLManager threw exception 2008-01-27 23:21:07.556053500 java.lang.NullPointerException 2008-01-27 23:21:07.556054500 at org.apache.catalina.manager.HTMLManagerServlet.list(HTMLManagerServlet.java:437) 2008-01-27 23:21:07.556068500 at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:136) 2008-01-27 23:21:07.556070500 at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) 2008-01-27 23:21:07.556071500 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) 2008-01-27 23:21:07.556072500 at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source) 2008-01-27 23:21:07.556073500 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 2008-01-27 23:21:07.556079500 at java.lang.reflect.Method.invoke(Method.java:597) 2008-01-27 23:21:07.556080500 at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) 2008-01-27 23:21:07.556082500 at java.security.AccessController.doPrivileged(Native Method) 2008-01-27 23:21:07.556083500 at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) 2008-01-27 23:21:07.556091500 at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) 2008-01-27 23:21:07.556093500 at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) 2008-01-27 23:21:07.556094500 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) 2008-01-27 23:21:07.556096500 at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) 2008-01-27 23:21:07.556102500 at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) 2008-01-27 23:21:07.556103500 at java.security.AccessController.doPrivileged(Native Method) 2008-01-27 23:21:07.556104500 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) 2008-01-27 23:21:07.556106500 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) 2008-01-27 23:21:07.556112500 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) 2008-01-27 23:21:07.556113500 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525) 2008-01-27 23:21:07.556115500 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) 2008-01-27 23:21:07.556116500 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2008-01-27 23:21:07.556150500 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2008-01-27 23:21:07.556151500 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) 2008-01-27 23:21:07.556153500 at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) 2008-01-27 23:21:07.556154500 at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) 2008-01-27 23:21:07.556160500 at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) 2008-01-27 23:21:07.556161500 at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) 2008-01-27 23:21:07.556163500 at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) 2008-01-27 23:21:07.556164500 at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) 2008-01-27 23:21:07.556170500 at java.lang.Thread.run(Thread.java:619) It is Tomcat 6.0.14 started with its security manager enabled. The host configuration is as follows: Host deployXML=false deployOnStartup=false autoDeploy=false unpackWARs=false appBase=/home/USER/web-root workDir=work/Catalina/USER/DOMAIN name=DOMAIN Aliaswww.DOMAIN/Alias Context path= docBase=/home/USER/web-root privileged=false / Context path=/BROKENWAR docBase=/home/USER/web-root/BROKENWAR.war privileged=false / Context path=/MANAGER docBase=/home/tomcat/default/webapps/manager privileged=true / /Host Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Tue, 08 Jan 2008 21:10:31 + Mark Thomas wrote: All I can suggest is start Tomcat with remote debugging enabled and when you see the error, connect, debug you way through a request and see if you can see what the security settings are and try and confirm that they match the policy file. I'll try to do this . Meanwhile, I've also seen something similar with the AJP connector. I'm pasting from the beginning of the stack traces. Sorry it's so long but it might give you some clue. This is the first stack trace after the container startup. Jan 9, 2008 9:15:25 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet action threw exception java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END at java.nio.charset.CharsetEncoder.throwIllegalStateException(CharsetEncoder.java:951) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:537) at sun.nio.cs.StreamEncoder.flushLeftoverChar(StreamEncoder.java:223) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:282) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216) at java.io.PrintWriter.close(PrintWriter.java:295) at astarot.web.CompressionServletResponseWrapper.finishResponse(CompressionServletResponseWrapper.java:99) at astarot.web.CompressionFilter.doFilter(CompressionFilter.java:170) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at astarot.web.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:218) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Mon, 07 Jan 2008 20:59:28 + Mark Thomas wrote: Not right now. Could you provide the full debug stack trace again please. We should at least see a different problem now the code has been changed. Here it goes: SEVERE: Servlet.service() for servlet jsp threw exception java.security.AccessControlException: org/apache/coyote/http11/Constants at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:419) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1588) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934) at org.apache.coyote.Response.action(Response.java:183) at org.apache.coyote.Response.sendHeaders(Response.java:379) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288) at org.apache.catalina.connector.CoyoteWriter.flush(CoyoteWriter.java:95) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:175) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:956) at org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:609) at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:808) at org.apache.jasper.runtime.PageContextImpl.access$1100(PageContextImpl.java:71) at org.apache.jasper.runtime.PageContextImpl$12.run(PageContextImpl.java:766) at java.security.AccessController.doPrivileged(Native Method) at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:764) at org.apache.jsp.WEB_002dINF.view.page_jsp._jspService(page_jsp.java:438) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:65) at org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:80) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:284) at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1069) at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:455) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244)
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 27 Dec 2007 16:04:29 +0200 Delian Krustev wrote: I'll monitor the container for the next several restarts. The problem appeared once again on the next tomcat restart. Any other ideas ? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 13 Dec 2007 21:54:22 + Mark Thomas wrote: Snapshot build of trunk available from: http://people.apache.org/~markt/dev/ This is the current 6.0.x trunk with the security manager optimisation reverted for the org.apache.coyote.* packages. *HEALTH WARNING* This is a snapshot for testing of this issue only. It is not a formal release. Thanks for the build Mark, and sorry for the delay of this reply. Could you please provide the patch also? I could not afford to move this instance to 6.0-trunk. I'll do the build myself and probably touch only the modified classes. Thank you -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 27 Dec 2007 11:12:28 + Mark Thomas wrote: I have uploaded it here. http://people.apache.org/~markt/dev/remove-sm-opt.patch Thanks OK. Let us know the results. I did a build with your patch and replaced just lib/tomcat-coyote.jar . The exception did not show this time. I'll monitor the container for the next several restarts. Regards -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Tue, 11 Dec 2007 22:35:20 + Mark Thomas wrote: Are you happy to mod the code and build a patched version yourself or do you want some help? I can build a binary with the patch for you to test if you wish. I've not built Tomcat from source before, so I'll take advantage of the help you're offering. Thank you. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Wed, 05 Dec 2007 22:13:00 + Mark Thomas wrote: Did it happen straight away or did it work for a while and then fail? Dec 3, 2007 10:14:24 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 152362 ms .. Dec 3, 2007 10:17:22 PM org.apache.catalina.core.ApplicationDispatcher invoke SEVERE: Servlet.service() for servlet jsp threw exception java.security.AccessControlException: org/apache/coyote/Constants I've tried it about 3 minutes after the restart. I am beginning to think that http://svn.apache.org/viewvc?view=revrev=505593 introduced a subtle timing issue. If Tomcat internal code causes Constants to be loaded, everything is fine. If the webapp code causes Constants to be loaded, it fails. It goes live straight away, so I suppose some request from user web application might have already been served. I've been observing this problem for quite a while, and it has been there all the time. The HTTP connector stays unused because of this problem. You might be right - may be the last time it did not appear because my test was done prior to a request to an application that triggers it. The fix would be to revert to the (System.getSecurityManager() != null) test. I'd be glad to test the patch. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Hundreds of Instances
Really? From your other message, you make it look like Java is taking something like 1GB of memory. Sure, the JVM adds some overhead to the heap size you configured, but it shouldn't be more than 5% or 10%... nothing like 200%. It could be more that 200% depending on the heap size and other parameters. I tried JProfiler sometime ago, and it worked fine. Too bad it's not free software. I'll look for others. I'd recommend forgetting about the profiler, enabling JMX, attach to the JVM and see which type of memory is excessively used. Furthermore if the swapping is a problem you'd better limit the memory available to the JVM. IMHO this could not be done via VM parameters. Use ulimit instead. This way out of memory errors will start to appear(instead of swapping) with the needed memory type shown in the exception. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 29 Nov 2007 07:51:07 + Mark Thomas wrote: It should show more information. If there is something subtle going on with the permissions then it should make it easier to figure out. Well, here we go. The problem appeared once again after the next restart. I've hidden the username and the domain since they are irrelevant anyway. This happens with all the users, apps and URLs once the problem appears. It seem that the files under the work directory need: java.lang.RuntimePermission accessClassInPackage.org.apache.coyote and it is not granted each time. Sorry for the long stack trace. access: access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.coyote) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:313) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1512) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:273) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557) at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934) at org.apache.coyote.Response.action(Response.java:181) at org.apache.coyote.http11.InternalOutputBuffer.doWrite(InternalOutputBuffer.java:563) at org.apache.coyote.Response.doWrite(Response.java:560) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:353) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:325) at org.apache.tomcat.util.buf.IntermediateOutputStream.write(C2BConverter.java:242) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:190) at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:196) at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:81) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:438) at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:143) at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:119) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:326) at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:342) at org.apache.jsp.WEB_002dINF.view.page_jsp._jspService(page_jsp.java:351) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:393) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at sun.reflect.GeneratedMethodAccessor324.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:244) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:517) at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:276) at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:162) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:283) at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:56) at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:189) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:654) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:445) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:379) at
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
On Thu, 29 Nov 2007 07:51:07 + Mark Thomas wrote: It should show more information. If there is something subtle going on with the permissions then it should make it easier to figure out. The container has been restarted today. Oddly enough the exception does not show now. I'll keep the option -Djava.security.debug=access,failure and will post more information if this happens again. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Hi Mark,
On Tue, 27 Nov 2007 18:21:20 + Mark Thomas wrote:
Can you run the faulty instance with:
-Djava.security.debug=access,failure
and report the failure message.
I thought on this, but the exception looks pretty self explanatory.
I'll try it anyway, in case anything new comes up. The machine is used in
production so this will be applied on the next tomcat restart(might be
several days from now).
If you can reproduce this at will then
-Djava.security.debug=all
would be better but it will generate lots of log data
I have also seen problems with policy files where I have had to use
${file.separator} rather than / but that was with java.io.FilePermission on
Windows rather than in the codebase.
Cheers
--
Delian
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AccessControlException in Coyote Http11Processor (Tomcat 6.0.14). Bug in Coyote ?
Hi all,
I'm running several similarly configured Tomcat containers all using
security manager.
On one of the instances I'm getting the following exception from the HTTP
connector:
Nov 26, 2007 7:42:19 PM org.apache.catalina.connector.CoyoteAdapter service
SEVERE: An exception or error occurred in the container during the request
processing
java.security.AccessControlException: org/apache/coyote/Constants
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.sendHeaders(Response.java:379)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:273)
at org.apache.catalina.connector.Response.finishResponse(Response.java:486)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:287)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Nov 26, 2007 7:42:19 PM org.apache.coyote.http11.Http11Processor process
SEVERE: Error finishing response
java.security.AccessControlException: org/apache/coyote/Constants
at
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1557)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:934)
at org.apache.coyote.Response.action(Response.java:181)
at
org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:379)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
At the same time the AJP connector works fine.
The security policy is a bit looser than the one distributed with tomcat 6.0.14:
start catalina.policy
grant codeBase file:${java.home}/lib/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/jre/lib/ext/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/../lib/- {
permission java.security.AllPermission;
};
grant codeBase file:${java.home}/lib/ext/- {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/commons-daemon.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/bin/bootstrap.jar {
permission java.security.AllPermission;
};
grant codeBase file:${catalina.home}/lib/- {
permission java.security.AllPermission;
};
grant {
permission java.util.PropertyPermission *, read;
permission java.lang.RuntimePermission getAttribute;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.jasper.runtime;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.jasper.runtime.*;
permission java.net.SocketPermission *:1-, connect;
permission java.net.SocketPermission localhost:1-, connect;
permission java.io.FilePermission ${catalina.home}/lib/-, read;
permission java.io.FilePermission ${java.home}/-, read;
permission java.lang.RuntimePermission accessDeclaredMembers;
permission java.lang.RuntimePermission getClassLoader;
permission java.lang.RuntimePermission getProtectionDomain;
permission java.lang.reflect.ReflectPermission suppressAccessChecks;
permission ognl.OgnlInvokePermission *;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.collections;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.pool.impl;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.dbcp;
permission java.lang.RuntimePermission
accessClassInPackage.org.apache.tomcat.dbcp.pool;
};
end catalina.policy
catalina.properties is unmodified .
The connectors are configured like this:
Connector
port=8080
protocol=HTTP/1.1
maxThreads=150
connectionTimeout=2
redirectPort=443 /
Connector port=8009
enableLookups=false
redirectPort=443
protocol=AJP/1.3
backlog=100
connectionTimeout=5000
maxThreads=300 /
My guess is that either this is a bug in the Coyote HTTP connector
Re: How to initialize variables when tomcat load a webservice?
On Tue, 27 Nov 2007 13:18:47 +0100 Tomás Tormo wrote: I'm developing a webservice wich has to initialize some variables when it is loaded by tomcat (just because otherwise it is too slow). Can this be done? Has the client to initialize the class by means of the constructor or is tomcat the one that will initialize it? You need to define a listener and handle the context initialized event. This should give you enough tips for searching :-) P.S. this looks like a general java web apps programming question, not a tomcat one. Cheers Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat becomes non-response for ~30 seconds
On Tue, 27 Nov 2007 10:58:24 -0800 (PST) jnedzel wrote: We're having an intermittent problem with Tomcat becoming non-responsive for a while (between 30 seconds and several minutes) and then recovering without any intervention. There are no error messages in the Tomcat logs. Any ideas what might be causing this or where to look? We're running Tomcat 5.5.20 on linux. Try running the VM with the -verbosegc option. May be the garbage collector and the memory settings need some tuning. You can also read about JMX and jconsole. They might prove to be helpful. Cheers -- Delian - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
