Issue1489

classification
Title: Classloader hierarchy interacts with proxy lookup to cause infinite recursion
Type: crash Severity: urgent
Components: Core Versions: 2.5.1
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: amak Nosy List: Mekk, amak, fwierzbicki, gturnquist, leosoto, rafanunes, zyasoft
Priority: urgent Keywords:

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:05rafanunessetmessages: + msg6236
2010-10-17 17:05:50zyasoftsetstatus: open -> closed
resolution: accepted -> fixed
messages: + msg6184
2010-10-17 15:01:52amaksetmessages: + msg6181
2010-10-17 14:44:41amaksetmessages: + msg6179
2010-10-17 14:34:56amaksetmessages: + msg6178
2010-10-17 14:30:58amaksetmessages: + msg6177
2010-10-17 14:17:11amaksetstatus: closed -> open
messages: + msg6176
2010-09-20 19:36:22zyasoftsetstatus: open -> closed
messages: + msg6079
2010-08-26 00:28:42zyasoftsetresolution: 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:06amaksetmessages: + msg5759
2010-05-03 18:35:02rafanunessetnosy: + rafanunes
messages: + msg5757
2010-01-30 09:21:45amaksetmessages: + msg5470
2010-01-29 23:14:54leosotosetnosy: + leosoto
messages: + msg5467
2009-11-30 14:51:00gturnquistsetmessages: + msg5332
2009-11-30 14:35:36amaksetmessages: + msg5331
2009-11-30 14:30:03amaksetmessages: + msg5330
2009-11-30 14:21:25Mekksetmessages: + msg5329
2009-11-30 14:08:15amaksetmessages: + msg5328
2009-11-18 00:02:32gturnquistsetnosy: + gturnquist
messages: + msg5313
2009-10-28 21:29:59amaksetmessages: + msg5293
2009-10-28 21:19:38amaksetmessages: + msg5291
2009-10-28 21:10:32amaksetmessages: + msg5290
2009-10-28 11:29:13Mekksetmessages: + msg5285
2009-10-28 11:23:25Mekksetmessages: + msg5284
2009-10-28 11:13:54Mekksetmessages: + msg5283
2009-10-27 17:46:16amaksetmessages: + msg5275
2009-10-27 17:44:46amaksetmessages: + 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:29Mekksetnosy: + Mekk
messages: + msg5272
2009-10-19 16:48:52amaksetmessages: + msg5237
2009-10-19 16:31:45fwierzbickisetnosy: + fwierzbicki
2009-10-19 15:31:46amaksetmessages: + 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:58amaksetmessages: + msg5235
2009-10-19 15:14:03amaksetmessages: + msg5234
2009-10-19 15:13:26amaksetmessages: + msg5233
2009-10-19 15:11:06amaksetfiles: + web.xml
2009-10-19 15:10:04amaksetfiles: + JythonServlet.java
2009-10-19 15:08:50amakcreate