|Anonymous | Login | Signup for a new account||04-24-2019 13:08 PDT|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0003339||[Resin]||feature||always||02-12-09 04:35||02-25-09 15:33|
|Summary||0003339: JavaRebel & Resin integration hurdles|
JavaRebel has supported Resin 3.0 with a simple runtime patch, http://code.google.com/p/zt-oss/source/browse/JavaRebelUtils/trunk/src/org/zeroturnaround/javarebel/integration/generic/FindClassClassBytecodeProcessor.java [^]
This is used to runtime patch com.caucho.loader.DynamicClassLoader. Everything used to work great.
However starting with version 3.1 Resin startup has gone through a lot of changes. First a daemon WatchDog is spawned which spawns another process with the -Djava.system.class.loader=com.caucho.loader.SystemClassLoader
As SystemClassLoader extends EnvironmentClassLoader which extends DynamicClassLoader we cant patch the DynamicClassLoader as it is loaded before the javaagent is even initialized. There are some workarounds available for us to still patch the classloader before it is loaded, but they are unnecessarily complicated to make and maintain.
Therefore we would like to ask you to help us support the Resin JavaRebel users:
*) Can you make the SystemClassLoader standalone? Not extending the other classloaders in such a way, so that it would be possible to do runtime patching without the trouble.
*) Maybe you are willing to integrate with us? We can provide you a patch but you'll have to depend on our OSS SDK (http://repos.zeroturnaround.com/maven2/org/zeroturnaround/javarebel-sdk/) [^] for building.
Can you give me some details on the patch?
We can compile and release integration jars as part of our release (we create artifact jars and publish them to our maven repository.) So it's perfectly fine for us to create a classloader that extends from our SystemClassLoader and use that for launching Resin. (We might need to add a configuration item to select the system classloader, but that's easy.)
That sounds like the simplest way of handling this case, but I'm not sure if you have other requirements to make the system work.
Adding a <system-class-loader> configuration in the <server> or <server-default>, so a user can specify the system classloader to use. In the case of JavaRebel, this would be a classloader extending com.caucho.loader.SystemClassLoader which overrides methods as needed for JavaRebel.
|02-12-09 04:35||toomasr||New Issue|
|02-12-09 04:36||toomasr||Issue Monitored: toomasr|
|02-12-09 06:02||nam||Project||Quercus => Resin|
|02-15-09 14:50||ekabanov||Issue Monitored: ekabanov|
|02-18-09 10:27||ferg||Note Added: 0003830|
|02-25-09 15:33||ferg||Note Added: 0003840|
|02-25-09 15:33||ferg||Assigned To||=> ferg|
|02-25-09 15:33||ferg||Status||new => closed|
|02-25-09 15:33||ferg||Resolution||open => fixed|
|02-25-09 15:33||ferg||Fixed in Version||=> 4.0.0|
|03-23-09 05:36||toomasr||Issue End Monitor: toomasr|
|03-23-09 05:36||toomasr||Issue Monitored: toomasr|
| Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
37 total queries executed.|
29 unique queries executed.