Issue1489
Created on 2009-10-19.15:08:50 by amak, last changed 2010-11-09.13:11:05 by rafanunes.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | Remove |
JythonServlet.java | amak, 2009-10-19.15:10:04 | A jython servlet which recreates the issue. | ||
web.xml | amak, 2009-10-19.15:11:06 | web.xml file for the attached jython servlet. |
Messages | |||
---|---|---|---|
msg5232 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.15:08:48 | |
I'm finding unusual behaviour running a jython servlet on Tomcat 6. The bizarre thing is that the behaviour only occurs when Tomcat is run as a Windows service. It does NOT occur when Tomcat 6 is run from the command line. This problem was originally seen by a user running modjy, but I've written a minimal servlet which recreates the problem without modjy. See attached source file. When the jython servlet has an __init__ method, i.e. like so class jyServlet(HttpServlet): def __init__(self): HttpServlet.__init__(self) def service(self, request, response): response.getWriter().write('Hello World!') then the servlet crashes on Tomcat 6 with the following stacktrace Traceback (most recent call last): File "<string>", line 4, in __init__ RuntimeError: maximum recursion depth exceeded org.python.core.PyException.fillInStackTrace(PyException.java:70) java.lang.Throwable.<init>(Throwable.java:181) java.lang.Exception.<init>(Exception.java:29) java.lang.RuntimeException.<init>(RuntimeException.java:32) org.python.core.PyException.<init>(PyException.java:46) org.python.core.PyException.<init>(PyException.java:43) org.python.core.PyException.<init>(PyException.java:61) org.python.core.Py.RuntimeError(Py.java:124) org.python.core.Py.JavaError(Py.java:450) org.python.core.PyTableCode.call(PyTableCode.java:168) org.python.core.PyBaseCode.call(PyBaseCode.java:297) org.python.core.PyBaseCode.call(PyBaseCode.java:191) org.python.core.PyFunction.__call__(PyFunction.java:385) org.python.core.PyMethod.__call__(PyMethod.java:215) org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221) org.python.core.PyMethod.__call__(PyMethod.java:206) org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:1097) org.python.core.PyType.invoke_new_(PyType.java:444) org.python.core.PyType.type___call__(PyType.java:1397) org.python.core.PyType.__call__(PyType.java:1388) org.python.core.PyObject.__call__(PyObject.java:381) JythonServlet.init(JythonServlet.java:38) javax.servlet.GenericServlet.init(GenericServlet.java:212) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859) org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:574) org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1527) java.lang.Thread.run(Thread.java:619) When the __init__ method is dropped, i.e. it is defined like so class jyServlet(HttpServlet): def service(self, request, response): response.getWriter().write('Hello World!') Then a different problem occurs: here is the traceback (with > 1000 lines snipped for brevity) java.lang.StackOverflowError java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) org.python.core.PyStringMap.__finditem__(PyStringMap.java:55) org.python.core.PyType.lookup_where(PyType.java:1059) org.python.core.PyType.lookup(PyType.java:1048) org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:93) [> 1000 identical lines snipped] org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:93) |
|||
msg5233 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.15:13:26 | |
Thinking that this may be a memory related issue, I tried increasing the memory allocation of the Tomcat 6 Windows service to 1024M. There was no difference in behaviour, i.e. the bug still appears. |
|||
msg5234 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.15:14:03 | |
Another thing that I tried was to compile the attached java class with both JDK 5 and JDK 6 compilers. This made no difference. |
|||
msg5235 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.15:14:58 | |
Another thing that I tried was to run the Tomcat 6 Windows service with both the client and server JVMs from a JDK 6 JRE. This made no difference. |
|||
msg5236 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.15:31:46 | |
Should also mention that all of my testing so far has been on Windows Server 2003. |
|||
msg5237 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-19.16:48:52 | |
I have started a discussion on the Tomcat-users mailing list about this. http://www.nabble.com/What-is-the-difference-between-running-Tomcat-6-as-a-Windows-Service--vs.-running-from-the-command-line--td25960450.html |
|||
msg5272 (view) | Author: Marcin Kasperski (Mekk) | Date: 2009-10-27.17:18:28 | |
I am observing very similar problem while trying to run minimalist pylons application on BEA weblogic (10.3, tested under Linux). Below there is my backtrace (thrown while I try to deploy my .war file). I put it here, as I suspect the problem may be related. Notes: - the same .war deploys and works properly on tomcat6 (on the same Ubuntu machine), - I had to use weblogic.xml with <prefer-web-inf-classes>true to convince weblogic to use jython2.5.1, not the bundled old version Traceback (most recent call last): File "/opt/jython2.5.1/Lib/modjy/modjy.py", line 43, in __init__ HttpServlet.__init__(self) RuntimeError: maximum recursion depth exceeded at org.python.core.PyException.fillInStackTrace(PyException.java:70) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.python.core.PyException.<init>(PyException.java:46) at org.python.core.PyException.<init>(PyException.java:43) at org.python.core.PyException.<init>(PyException.java:61) at org.python.core.Py.RuntimeError(Py.java:124) at org.python.core.Py.JavaError(Py.java:450) at org.python.core.PyTableCode.call(PyTableCode.java:168) at org.python.core.PyBaseCode.call(PyBaseCode.java:297) at org.python.core.PyBaseCode.call(PyBaseCode.java:191) at org.python.core.PyFunction.__call__(PyFunction.java:385) at org.python.core.PyMethod.__call__(PyMethod.java:215) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221) at org.python.core.PyMethod.__call__(PyMethod.java:206) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:10 97) at org.python.core.PyType.invoke_new_(PyType.java:444) at org.python.core.PyType.type___call__(PyType.java:1397) at org.python.core.PyType.__call__(PyType.java:1388) at org.python.core.PyObject.__call__(PyObject.java:381) at com.xhaus.modjy.ModjyJServlet.init(ModjyJServlet.java:103) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubS ecurityHelper.java:283) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu bject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityH elper.java:64) at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLife cycleHelper.java:58) at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper .java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl .java:521) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServ letContext.java:1893) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(Web AppServletContext.java:1870) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppSe rvletContext.java:1790) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContex t.java:2999) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1 371) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:468) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModule Driver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleLis tenerInvoker.java:117) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModule sFlow.java:27) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java: 635) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.jav a:212) at weblogic.application.internal.SingleModuleDeployment.activate(SingleModu leDeployment.java:16) at weblogic.application.internal.DeploymentStateChecker.activate(Deployment StateChecker.java:162) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppCo ntainerInvoker.java:79) at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDepl oyment.java:184) at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServer Lifecycle(BasicDeployment.java:361) at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(Deplo ymentAdapter.java:51) at weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploymen tAdapter.java:196) at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTra nsition.java:30) at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps (ConfiguredDeployments.java:233) at weblogic.management.deploy.internal.ConfiguredDeployments.activate(Confi guredDeployments.java:169) at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Configu redDeployments.java:123) at weblogic.management.deploy.internal.DeploymentServerService.resume(Deplo ymentServerService.java:173) at weblogic.management.deploy.internal.DeploymentServerService.start(Deploy mentServerService.java:89) at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) I tried increasing the java stack, up to -Xss48m, wi |
|||
msg5274 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-27.17:44:46 | |
Changing the title to reflect new report. |
|||
msg5275 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-27.17:46:16 | |
Marcin, In order to determine if this is a modjy specific problem, or a general jython problem, please can you run the jython servlet (attached to this bug) in your servlet container, and report the results? The attached servlet illustrates the same problem on Tomcat, and does not use modjy. |
|||
msg5283 (view) | Author: Marcin Kasperski (Mekk) | Date: 2009-10-28.11:13:52 | |
Yes, your example also crashes: ####<Oct 28, 2009 12:08:15 PM CET> <Error> <HTTP> <cauchy> <examplesServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1256728095905> <BEA-101216> <Servlet: "jyservlet" failed to preload on startup in Web application: "runtime". Traceback (most recent call last): File "<string>", line 4, in __init__ RuntimeError: maximum recursion depth exceeded at org.python.core.PyException.fillInStackTrace(PyException.java:70) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.python.core.PyException.<init>(PyException.java:46) at org.python.core.PyException.<init>(PyException.java:43) at org.python.core.PyException.<init>(PyException.java:61) at org.python.core.Py.RuntimeError(Py.java:124) at org.python.core.Py.JavaError(Py.java:450) at org.python.core.PyTableCode.call(PyTableCode.java:168) at org.python.core.PyBaseCode.call(PyBaseCode.java:297) at org.python.core.PyBaseCode.call(PyBaseCode.java:191) at org.python.core.PyFunction.__call__(PyFunction.java:385) at org.python.core.PyMethod.__call__(PyMethod.java:215) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221) at org.python.core.PyMethod.__call__(PyMethod.java:206) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:10 97) at org.python.core.PyType.invoke_new_(PyType.java:444) at org.python.core.PyType.type___call__(PyType.java:1397) at org.python.core.PyType.__call__(PyType.java:1388) at org.python.core.PyObject.__call__(PyObject.java:381) at JythonServlet.init(JythonServlet.java:40) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubS ecurityHelper.java:283) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu bject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityH elper.java:64) at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLife cycleHelper.java:58) at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper .java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl .java:521) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServ letContext.java:1893) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(Web AppServletContext.java:1870) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppSe rvletContext.java:1790) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContex t.java:2999) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1 371) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:468) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModule Driver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleLis tenerInvoker.java:117) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:204) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModule sFlow.java:27) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java: 635) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.jav a:212) at weblogic.application.internal.SingleModuleDeployment.activate(SingleModu leDeployment.java:16) at weblogic.application.internal.DeploymentStateChecker.activate(Deployment StateChecker.java:162) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppCo ntainerInvoker.java:79) at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDepl oyment.java:184) at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServer Lifecycle(BasicDeployment.java:361) at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(Deplo ymentAdapter.java:51) at weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploymen tAdapter.java:196) at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTra nsition.java:30) at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps (ConfiguredDeployments.java:233) at weblogic.management.deploy.internal.ConfiguredDeployments.activate(Confi guredDeployments.java:169) at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Configu redDeployments.java:123) at weblogic.management.deploy.internal.DeploymentServerService.resume(Deplo ymentServerService.java:173) at weblogic.management.deploy.internal.DeploymentServerService.start(Deploy mentServerService.java:89) at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) |
|||
msg5284 (view) | Author: Marcin Kasperski (Mekk) | Date: 2009-10-28.11:23:25 | |
BTW, I really have no idea about jython internals, but after glazing at this backtrace for some time I get the feeling that we may have some "error while handling an error" case here I am just considering the idea of swithing includeJavaStackInExceptions to false and checking whether it helps. |
|||
msg5285 (view) | Author: Marcin Kasperski (Mekk) | Date: 2009-10-28.11:29:12 | |
No - it did not help. I have no further ideas, so let me know if you would like me to test something. Here is the backtrace (for your sample) with python.options.includeJavaStackInExceptions = false: Traceback (most recent call last): File "<string>", line 4, in __init__ RuntimeError: maximum recursion depth exceeded at org.python.core.PyTableCode.call(PyTableCode.java:183) at org.python.core.PyBaseCode.call(PyBaseCode.java:297) at org.python.core.PyBaseCode.call(PyBaseCode.java:191) at org.python.core.PyFunction.__call__(PyFunction.java:385) at org.python.core.PyMethod.__call__(PyMethod.java:215) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:221) at org.python.core.PyMethod.__call__(PyMethod.java:206) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:10 97) at org.python.core.PyType.invoke_new_(PyType.java:444) at org.python.core.PyType.type___call__(PyType.java:1397) at org.python.core.PyType.__call__(PyType.java:1388) at org.python.core.PyObject.__call__(PyObject.java:381) at JythonServlet.init(JythonServlet.java:40) at javax.servlet.GenericServlet.init(GenericServlet.java:242) at weblogic.servlet.internal.StubSecurityHelper$ServletInitAction.run(StubS ecurityHelper.java:283) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu bject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.StubSecurityHelper.createServlet(StubSecurityH elper.java:64) at weblogic.servlet.internal.StubLifecycleHelper.createOneInstance(StubLife cycleHelper.java:58) at weblogic.servlet.internal.StubLifecycleHelper.<init>(StubLifecycleHelper .java:48) at weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl .java:521) at weblogic.servlet.internal.WebAppServletContext.preloadServlet(WebAppServ letContext.java:1893) at weblogic.servlet.internal.WebAppServletContext.loadServletsOnStartup(Web AppServletContext.java:1870) at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppSe rvletContext.java:1790) at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContex t.java:3000) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1 371) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:471) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:205) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModule Driver.java:201) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleLis tenerInvoker.java:118) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateD river.java:205) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDr iver.java:60) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModule sFlow.java:28) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java: 636) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriv er.java:37) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.jav a:212) at weblogic.application.internal.SingleModuleDeployment.activate(SingleModu leDeployment.java:16) at weblogic.application.internal.DeploymentStateChecker.activate(Deployment StateChecker.java:162) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppCo ntainerInvoker.java:79) at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDepl oyment.java:184) at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServer Lifecycle(BasicDeployment.java:361) at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(Deplo ymentAdapter.java:52) at weblogic.management.deploy.internal.DeploymentAdapter.activate(Deploymen tAdapter.java:196) at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTra nsition.java:31) at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps (ConfiguredDeployments.java:233) at weblogic.management.deploy.internal.ConfiguredDeployments.activate(Confi guredDeployments.java:170) at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(Configu redDeployments.java:124) at weblogic.management.deploy.internal.DeploymentServerService.resume(Deplo ymentServerService.java:174) at weblogic.management.deploy.internal.DeploymentServerService.start(Deploy mentServerService.java:90) at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) |
|||
msg5290 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-28.21:10:32 | |
Thanks for the report Marcin. I can see from your report that this is a general jython issue. More in a follow-up message. |
|||
msg5291 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-28.21:19:37 | |
I have narrowed the problem down a single line of code, from PyReflectedConstructor.java line 98, namely // ======= // If the declaring class is a pure Java type but we're instantiating a Python proxy, // grab the proxy version of the constructor to instantiate the proper type if ((declaringClass == null || !PyProxy.class.isAssignableFrom(declaringClass)) && !(self.getType() instanceof PyJavaType)) { // The following line return PyType.fromClass(javaClass).lookup("__init__").__call__(self, args, keywords); } // ======= Breaking that line up and tracing through its execution, I can see that it goes into infinite recursion. When I arrange the code like this // ======= if ((declaringClass == null || !PyProxy.class.isAssignableFrom(declaringClass)) && !(self.getType() instanceof PyJavaType)) { // Stage 0 PyType pyType = PyType.fromClass(javaClass); // Stage 1 PyObject initMeth = pyType.lookup("__init__"); // Stage 2 PyObject methResult = initMeth.__call__(self, args, keywords); // Stage 3 - Never reached return methResult; } // ======= Then stage 3 is never reached, in this particular circumstance. Meaning that the call after stage 2, the line containing "initMeth.__call__()" somehow results in a recursive call to the same piece of code, resulting in infinite recursion, which blows the stack. This explains the appearance of more than 1000 copies of the following line in the stack traces org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:93) Why this is happening, I do not know. The bottom of the stack trace looks like this //===== org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:98) org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:98) org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:98) org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:98) org.python.core.PyObject.__call__(PyObject.java:342) org.python.core.PyMethod.instancemethod___call__(PyMethod.java:220) org.python.core.PyMethod.__call__(PyMethod.java:211) org.python.core.PyMethod.__call__(PyMethod.java:206) org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:1057) org.python.core.PyType.type___call__(PyType.java:1486) org.python.core.PyType.__call__(PyType.java:1469) org.python.core.PyObject.__call__(PyObject.java:368) JythonServlet.init(JythonServlet.java:38) javax.servlet.GenericServlet.init(GenericServlet.java:212) //===== I have a feeling that this may be caused by class-loading issues, relating to security permissions. Any other jython devs have input why this might be happening? |
|||
msg5293 (view) | Author: Alan Kennedy (amak) | Date: 2009-10-28.21:29:59 | |
Sorry, the above reference to line 98 should be to line 93: I moved the line in question with my debug refactoring. |
|||
msg5313 (view) | Author: Greg (gturnquist) | Date: 2009-11-18.00:02:30 | |
I don't think this issue is confined to Tomcat. I'm pretty sure it has to do with class loading. I was trying to use Spring Security/Spring LDAP inside Jython to code ldap support for Spring Python, and ran into a strange error (http://forum.springsource.org/showthread.php?t=50707), that appears to only be solved by Thread.currentThread().setContextClassLoader(<one of the classes from spring>). When doing so, I get: RuntimeError: maximum recursion depth exceeded I don't have any stack trace to offer. Is there a flag to getting a more detailed backtrace? Anyway, my source code using Spring Security/Spring LDAP from inside jython: """ Copyright 2006-2008 SpringSource (http://springsource.com), All Rights Reserved Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. """ import logging import re import sys from springpython.security import AuthenticationException from springpython.security import AuthenticationServiceException from springpython.security import BadCredentialsException from springpython.security import DisabledException from springpython.security import UsernameNotFoundException from springpython.security.providers import AuthenticationProvider from springpython.security.providers import UsernamePasswordAuthenticationToken from springpython.security.providers.dao import AbstractUserDetailsAuthenticationProvider from springpython.security.providers.encoding import LdapShaPasswordEncoder print "You are in Jython!" import java import org.springframework.security.ldap.DefaultSpringSecurityContextSource import org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator import org.springframework.security.providers.ldap.authenticator.BindAuthenticator import org.springframework.security.providers.ldap.authenticator.PasswordComparisonAuthenticator import org.springframework.security.providers.UsernamePasswordAuthenticationToken from jarray import array print "Using Spring Security to do our LDAP dirty work!" print "Current thread's class loader %s" % java.lang.Thread.currentThread().getContextClassLoader() class DefaultSpringSecurityContextSource(object): def __init__(self, url): self._context = org.springframework.security.ldap.DefaultSpringSecurityContextSource(url) java.lang.Thread.currentThread().setContextClassLoader(self._context.getClass().getClassLoader()) self._context.afterPropertiesSet() class BindAuthenticator(object): def __init__(self, context_source=None, user_dn_patterns="uid={0},ou=people"): self.context_source = context_source self.user_dn_patterns = user_dn_patterns self.logger = logging.getLogger("springpython.security.providers.Ldap.BindAuthenticator") self._authenticator = None def authenticate(self, authentication): if self._authenticator is None: self._authenticator = org.springframework.security.providers.ldap.authenticator.BindAuthenticator(self.context_source._context) self._authenticator.setUserDnPatterns(array([self.user_dn_patterns], java.lang.String)) self._authenticator.afterPropertiesSet() #java.lang.Thread.currentThread().setContextClassLoader(self._authenticator.getClass().getClassLoader()) #print "BindAuthenticator class loader %s" % self._authenticator.getClass().getClassLoader() token = org.springframework.security.providers.UsernamePasswordAuthenticationToken(authentication.username, authentication.password) return self._authenticator.authenticate(token) class PasswordComparisonAuthenticator(object): def __init__(self, context_source=None, user_dn_patterns="uid={0},ou=people", password_attr_name="userPassword"): self.context_source = context_source self.user_dn_patterns = user_dn_patterns self.password_attr_name = password_attr_name self.encoder = LdapShaPasswordEncoder() self.logger = logging.getLogger("springpython.security.providers.Ldap.PasswordComparisonAuthenticator") def authenticate(self, authentication): if jython: raise Exception("This code doesn't work inside Jython.") class DefaultLdapAuthoritiesPopulator(object): def __init__(self, context_source=None, group_search_base="ou=groups", group_search_filter="(member={0})", group_role_attr="cn", role_prefix="ROLE_", conv ert_to_upper=True): self.logger = logging.getLogger("springpython.security.providers.Ldap.DefaultLdapAuthoritiesPopulator") self.context_source = context_source self.group_search_base = group_search_base self.group_search_filter = group_search_filter self.group_role_attr = group_role_attr self.role_prefix = role_prefix self.convert_to_upper = convert_to_upper self._populator = org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator(self.context_source._context, self.group_search_base) #java.lang.Thread.currentThread().setContextClassLoader(self._populator.getClass().getClassLoader()) self._populator.setGroupSearchFilter(self.group_search_filter) self._populator.setGroupRoleAttribute(self.group_role_attr) self._populator.setRolePrefix(self.role_prefix) self._populator.setConvertToUpperCase(self.convert_to_upper) print "LdapAuthoritiesPopulator class loader %s" % self._populator.getClass().getClassLoader() def get_granted_auths(self, user_details, username): results = self._populator.getGrantedAuthorities(user_details, username) print results return results class LdapAuthenticationProvider(AuthenticationProvider): def __init__(self, ldap_authenticator=None, ldap_authorities_populator=None): AuthenticationProvider.__init__(self) self.ldap_authenticator = ldap_authenticator self.ldap_authorities_populator = ldap_authorities_populator self.logger = logging.getLogger("springpython.security.providers.Ldap.LdapAuthenticationProvider") def authenticate(self, authentication): user_details = self.ldap_authenticator.authenticate(authentication) print "Context class loader %s" % user_details.getClass().getClassLoader() from copy import deepcopy results = deepcopy(authentication) results.granted_auths = self.ldap_authorities_populator.get_granted_auths(user_details, authentication.username) results.setAuthenticated(True) l.unbind() return results |
|||
msg5328 (view) | Author: Alan Kennedy (amak) | Date: 2009-11-30.14:08:14 | |
One interesting note in the Tomcat documentation, in relation to classloading, is this http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html """ As indicated in the diagram above, Tomcat 6 creates the following class loaders as it is initialized: * Bootstrap - [ .. snip ..] * System - This class loader is normally initialized from the contents of the CLASSPATH environment variable. All such classes are visible to both Tomcat internal classes, and to web applications. However, the standard Tomcat 6 startup scripts ($CATALINA_HOME/bin/catalina.sh or %CATALINA_HOME%\bin\catalina.bat) totally ignore the contents of the CLASSPATH environment variable itself, and instead build the System class loader from the following repositories: o $CATALINA_HOME/bin/bootstrap.jar - Contains the main() method that is used to initialize the Tomcat 6 server, and the class loader implementation classes it depends on. o $CATALINA_HOME/bin/tomcat-juli.jar - Package renamed Jakarta commons logging API, and java.util.logging LogManager. """ I will be investigating this further. |
|||
msg5329 (view) | Author: Marcin Kasperski (Mekk) | Date: 2009-11-30.14:21:25 | |
As I already noted, I was getting this error on weblogic. On Tomcat I brute-forced all permissions by dropping (in /etc/tomcat6/policy.d/04webapps.policy on my ubuntu): permission java.util.PropertyPermission "*", "read,write"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.catalina.connector"; permission java.lang.RuntimePermission "accessClassInPackage.org.apache.*"; but before I did it, I was getting some reasonable errors (which in particular helped me to detect proper names) |
|||
msg5330 (view) | Author: Alan Kennedy (amak) | Date: 2009-11-30.14:30:03 | |
Thanks for the further report Marcin. Did brute-forcing those permissions solve the problem? I.e. did therecursion problem go away? |
|||
msg5331 (view) | Author: Alan Kennedy (amak) | Date: 2009-11-30.14:35:35 | |
This is certainly a class-loading issue. As noted in an above message, this error only occurs (with Tomcat on Windows) when Tomcat is run as a service. But I have now solved that problem. By simply removing jython.jar from WEB-INF/lib, and moving it to $TOMCAT_HOME/lib, from where it is treated differently for class-loading purposes, the problem is eliminated, and the servlet runs correctly, even when Tomcat is run as a service. I still do not know why this class-loading issue creates the illustrated issue, but now at least we have a workaround, which is to move jython.jar up the class-loading hierarchy. To other people who have reported seeing this problem: Is it possible for you to move jython.jar up the class-loading hierarchy? I'm not familiar with the weblogic class-loading hierarchy. I don't know the class-loading scenario under which the Spring Security problem report was found. |
|||
msg5332 (view) | Author: Greg (gturnquist) | Date: 2009-11-30.14:51:00 | |
>I don't know the class-loading scenario under which the Spring Security >problem report was found. In my situation, I run jython -cp springsecurity.jar myscript.py, meaning one classloader has jython, another is setup for myscript.py. springsecurity.jar seems to be accessing the wrong class loader and not finding a critical class. Changing the classloader breaks jython with the infinite recursion loop, hence not allowing my script to work. Is there any way to turn on some jython log flags, so I can submit some more useful data? |
|||
msg5467 (view) | Author: Leonardo Soto (leosoto) | Date: 2010-01-29.23:14:53 | |
I tried to reproduce it on Tomcat 6.0.24 running as service on Windows XP. But the attached servlet works correctly. I'm trying to reproduce it since I'm working on the Jython internals that mess with ClassLoaders. Any idea on the particular software versions (tomcat? windows?) to reproduce it? |
|||
msg5470 (view) | Author: Alan Kennedy (amak) | Date: 2010-01-30.09:21:45 | |
My initial testing was carried out on Tomcat 6.0.18 and 6.0.20, under jdk1.5.0_21 and jdk1.6.0_13, running on Windows Server 2003. |
|||
msg5757 (view) | Author: Rafael Nunes (rafanunes) | Date: 2010-05-03.18:35:01 | |
Any progrees on this guys? In developer environment with Jetty 7 it was fine here. But can't deploy on Jboss5.1.0 because of this bug. When Jboss requests the app context, I always get a 'maximum recursion depth exceeded'. >JBoss5.1.0 >Jython 2.5.1 >JDK 1..6.0_15 >Ubuntu 9.10 |
|||
msg5759 (view) | Author: Alan Kennedy (amak) | Date: 2010-05-04.14:34:06 | |
Leo did some refactoring work on classloading which should have had some impact on this bug. However, it will not be included in a release yet, and won't be until 2.5.2 is released. So your options are, for now, 1. Download and build trunk and see if that solves your problem 2. Wait for a 2.5.2 release. |
|||
msg6018 (view) | Author: Jim Baker (zyasoft) | Date: 2010-08-26.00:28:40 | |
There has been some refactoring of classloaders issues, and this is a ongoing effort (see especially #1327). It may have resolved this issue. However, we need to ensure that the underlying issue, as pinpointed in PyReflectedConstructor by Alan in msg5291 is fixed. |
|||
msg6079 (view) | Author: Jim Baker (zyasoft) | Date: 2010-09-20.19:36:21 | |
Closing this bug as probably fixed, based on the issue log. Please reopen if I am mistaken, along with a test to reproduce. (Leo verified that Alan's test now works, although it would be ideal to include this in our test suite too.) |
|||
msg6176 (view) | Author: Alan Kennedy (amak) | Date: 2010-10-17.14:17:10 | |
Re-opening this bug, as I'm sorry to report that the behaviour is still broken. Detailed reports to follow. |
|||
msg6177 (view) | Author: Alan Kennedy (amak) | Date: 2010-10-17.14:30:57 | |
Running on Windows Server 2003, Tomcat 6.0.18, Jython trunk (revision 7153). When running the attached JythonServlet, with the __init__ method commented out, with jython.jar in WEB-INF/lib, I see the following in the logs. SEVERE: StandardWrapper.Throwable java.lang.StackOverflowError at java.util.concurrent.atomic.AtomicReferenceArray.get(AtomicReferenceArray.java:84) at org.python.google.common.collect.CustomConcurrentHashMap$Segment.getFirst(CustomConcurrentHashMap.java:1888) at org.python.google.common.collect.CustomConcurrentHashMap$Segment.getEntry(CustomConcurrentHashMap.java:1895) at org.python.google.common.collect.CustomConcurrentHashMap$Segment.get(CustomConcurrentHashMap.java:1922) at org.python.google.common.collect.CustomConcurrentHashMap.get(CustomConcurrentHashMap.java:2444) at org.python.core.PyType.fromClass(PyType.java:1279) at org.python.core.PyType.fromClass(PyType.java:1271) at org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:94) at org.python.core.PyReflectedConstructor.__call__(PyReflectedConstructor.java:94) [2043 identical lines snipped] |
|||
msg6178 (view) | Author: Alan Kennedy (amak) | Date: 2010-10-17.14:34:55 | |
Running on Windows Server 2003, Tomcat 6.0.18, Jython trunk (revision 7153) Running the attached JythonServlet as is, i.e. with __init__ enabled, and with jython.jar stored in WEB-INF/lib, I see the following in the logs 17-Oct-2010 15:32:10 org.apache.catalina.core.StandardContext loadOnStartup SEVERE: Servlet /jython_webapp threw load() exception Traceback (most recent call last): File "<string>", line 4, in __init__ RuntimeError: maximum recursion depth exceeded at org.python.core.PyException.fillInStackTrace(PyException.java:70) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.python.core.PyException.<init>(PyException.java:46) at org.python.core.PyException.<init>(PyException.java:43) at org.python.core.PyException.<init>(PyException.java:61) at org.python.core.Py.RuntimeError(Py.java:145) at org.python.core.Py.JavaError(Py.java:476) at org.python.core.PyTableCode.call(PyTableCode.java:168) at org.python.core.PyBaseCode.call(PyBaseCode.java:301) at org.python.core.PyBaseCode.call(PyBaseCode.java:194) at org.python.core.PyFunction.__call__(PyFunction.java:387) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:220) at org.python.core.PyMethod.__call__(PyMethod.java:211) at org.python.core.PyMethod.__call__(PyMethod.java:206) at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:1057) at org.python.core.PyType.type___call__(PyType.java:1561) at org.python.core.PyType.__call__(PyType.java:1544) at org.python.core.PyObject.__call__(PyObject.java:371) at JythonServlet.init(JythonServlet.java:38) at javax.servlet.GenericServlet.init(GenericServlet.java:212) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:987) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:583) 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.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) |
|||
msg6179 (view) | Author: Alan Kennedy (amak) | Date: 2010-10-17.14:44:41 | |
Running on Windows Server 2003, Tomcat 6.0.18, Jython trunk (revision 7153) Running the attached JythonServlet, either with __init__ enabled and disabled, but with jython.jar moved up the classloader hierarchy by placing it in $TOMCAT_HOME/lib, where it is treated differently for classloader purposes, the servlet runs without error or problems. In this scenario, the classloading level at which jython.jar is loaded is as described under "Common" on this page: http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html |
|||
msg6181 (view) | Author: Alan Kennedy (amak) | Date: 2010-10-17.15:01:52 | |
Sorry, disregard previous messages. There was an old copy of jython.jar lying around in my $TOMCAT_HOME/lib directory, including a cachedir, that may have interfered with my previous tests. When I removed all copies of jython.jar and cachedir from $TOMCAT_HOME/lib and placed it back into the WEB-INF/lib directory, everything started working as normal, without error. Pending confirmation from others, I voted to close this issue as "Fixed". |
|||
msg6184 (view) | Author: Jim Baker (zyasoft) | Date: 2010-10-17.17:05:50 | |
Closing per Alan's last message as fixed in the classloader changes. |
|||
msg6236 (view) | Author: Rafael Nunes (rafanunes) | Date: 2010-11-09.13:11:03 | |
Still getting this Exception. Jython 2.5.2rc2 + JBoss 5.1 + Ubuntu 10.10 + JDK 1.6.0_20 If I run in Jetty, it runs fine. Stack Trace: 18:03:29,271 ERROR [[/cds_py]] Servlet /cds_py threw load() exception Traceback (most recent call last): File "/home/rafael/dev/appserver/jboss51/server/q10/tmp/5c4o02w-vbz6rz-gg9s1iuk-1-gg9s4smx-av/cds_py.war/WEB-INF/lib-python/Lib/modjy/modjy.py", line 43, in __init__ HttpServlet.__init__(self) RuntimeError: maximum recursion depth exceeded at org.python.core.PyException.fillInStackTrace(PyException.java:70) at java.lang.Throwable.<init>(Throwable.java:181) at java.lang.Exception.<init>(Exception.java:29) at java.lang.RuntimeException.<init>(RuntimeException.java:32) at org.python.core.PyException.<init>(PyException.java:46) at org.python.core.PyException.<init>(PyException.java:43) at org.python.core.PyException.<init>(PyException.java:61) at org.python.core.Py.RuntimeError(Py.java:145) at org.python.core.Py.JavaError(Py.java:476) at org.python.core.PyTableCode.call(PyTableCode.java:168) at org.python.core.PyBaseCode.call(PyBaseCode.java:301) at org.python.core.PyBaseCode.call(PyBaseCode.java:194) at org.python.core.PyFunction.__call__(PyFunction.java:387) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:220) at org.python.core.PyMethod.__call__(PyMethod.java:211) at org.python.core.PyMethod.__call__(PyMethod.java:206) at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:1057) at org.python.core.PyType.type___call__(PyType.java:1561) at org.python.core.PyType.__call__(PyType.java:1544) at org.python.core.PyObject.__call__(PyObject.java:371) at com.xhaus.modjy.ModjyJServlet.init(ModjyJServlet.java:116) at javax.servlet.GenericServlet.init(GenericServlet.java:212) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1048) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:950) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4122) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4421) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:662) |
History | |||
---|---|---|---|
Date | User | Action | Args |
2010-11-09 13:11:05 | rafanunes | set | messages: + msg6236 |
2010-10-17 17:05:50 | zyasoft | set | status: open -> closed resolution: accepted -> fixed messages: + msg6184 |
2010-10-17 15:01:52 | amak | set | messages: + msg6181 |
2010-10-17 14:44:41 | amak | set | messages: + msg6179 |
2010-10-17 14:34:56 | amak | set | messages: + msg6178 |
2010-10-17 14:30:58 | amak | set | messages: + msg6177 |
2010-10-17 14:17:11 | amak | set | status: closed -> open messages: + msg6176 |
2010-09-20 19:36:22 | zyasoft | set | status: open -> closed messages: + msg6079 |
2010-08-26 00:28:42 | zyasoft | set | resolution: accepted messages: + msg6018 nosy: + zyasoft title: Jython crashes in unknown circumstances when running on some servlet containers. -> Classloader hierarchy interacts with proxy lookup to cause infinite recursion |
2010-05-04 14:34:06 | amak | set | messages: + msg5759 |
2010-05-03 18:35:02 | rafanunes | set | nosy:
+ rafanunes messages: + msg5757 |
2010-01-30 09:21:45 | amak | set | messages: + msg5470 |
2010-01-29 23:14:54 | leosoto | set | nosy:
+ leosoto messages: + msg5467 |
2009-11-30 14:51:00 | gturnquist | set | messages: + msg5332 |
2009-11-30 14:35:36 | amak | set | messages: + msg5331 |
2009-11-30 14:30:03 | amak | set | messages: + msg5330 |
2009-11-30 14:21:25 | Mekk | set | messages: + msg5329 |
2009-11-30 14:08:15 | amak | set | messages: + msg5328 |
2009-11-18 00:02:32 | gturnquist | set | nosy:
+ gturnquist messages: + msg5313 |
2009-10-28 21:29:59 | amak | set | messages: + msg5293 |
2009-10-28 21:19:38 | amak | set | messages: + msg5291 |
2009-10-28 21:10:32 | amak | set | messages: + msg5290 |
2009-10-28 11:29:13 | Mekk | set | messages: + msg5285 |
2009-10-28 11:23:25 | Mekk | set | messages: + msg5284 |
2009-10-28 11:13:54 | Mekk | set | messages: + msg5283 |
2009-10-27 17:46:16 | amak | set | messages: + msg5275 |
2009-10-27 17:44:46 | amak | set | messages:
+ msg5274 title: Jython crashes in unknown circumstances when running on Tomcat 6 as Windows Service. -> Jython crashes in unknown circumstances when running on some servlet containers. |
2009-10-27 17:18:29 | Mekk | set | nosy:
+ Mekk messages: + msg5272 |
2009-10-19 16:48:52 | amak | set | messages: + msg5237 |
2009-10-19 16:31:45 | fwierzbicki | set | nosy: + fwierzbicki |
2009-10-19 15:31:46 | amak | set | messages:
+ msg5236 title: Jython crashes in unknown circumstances when running on Tomcat 6. -> Jython crashes in unknown circumstances when running on Tomcat 6 as Windows Service. |
2009-10-19 15:14:58 | amak | set | messages: + msg5235 |
2009-10-19 15:14:03 | amak | set | messages: + msg5234 |
2009-10-19 15:13:26 | amak | set | messages: + msg5233 |
2009-10-19 15:11:06 | amak | set | files: + web.xml |
2009-10-19 15:10:04 | amak | set | files: + JythonServlet.java |
2009-10-19 15:08:50 | amak | create |
Supported by Python Software Foundation,
Powered by Roundup