WCI changes introduce a jboss7 module which is only used if explicitly referenced in configuration - no impact on anything there. It also introduces a deadlock patch in wci-wci which adds an extra synchronized block. Without this patch a deadlock can occur (and often does occur on JBoss AS7) when shutting down the server. No impact on performance or memory usage.
Kernel changes are limited to exo.kernel.container module where in two places there was a need to introduce the use of TCCL for classloading instead of using a local ClassLoader.
The new classloading uses ‘TCCL first’ approach with fallback to the old behavior. The use of TCCL was necessary to allow GateIn services to properly startup in an environment of isolated classloaders.
I added a method:
org.exoplatform.container.util.ContainerUtil.class:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
ClassLoader cl = tccl != null ? tccl : localCl;
try
{
return cl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (cl == tccl)
return localCl.loadClass(type);
throw e;
}
}
It is used in two places instead of Class.forName():
- org/exoplatform/xml/object/XMLObject.java
- org/exoplatform/container/jmx/MX4JComponentAdapter.java
It’s possible to imagine a scenario where due to deployment archive packaging the same classes may be available through different .jars, .wars, .ears. In such a situation the new code may load the class from portlet application deployment archive, or portal extension deployment archive instead of gatein portal’s lib/*.jar (gatein.ear/lib on JBossAS5 / JBossAS6, $TOMCAT_HOME/lib on Tomcat).
Actually by making it local loader first with TCCL fallback there would be no chance of any side effects. It may even be more appropriate as it prevents the accidental override of GateIn's classes due to packaging.
So I'll change the method to:
public static Class loadClass(String type) throws ClassNotFoundException
{
ClassLoader tccl = Thread.currentThread().getContextClassLoader();
ClassLoader localCl = ContainerUtil.class.getClassLoader();
try
{
return localCl.loadClass(type);
}
catch (ClassNotFoundException e)
{
if (tccl != null)
return tccl.loadClass(type);
throw e;
}
}
I'll prepare a patch against exo.kernel.container trunk and attach it to the issue.
On Mon, Oct 10, 2011 at 4:20 PM, Nicolas FILOTTO
<nicolas.filotto@exoplatform.com> wrote:
Well, it depends on the expected fix version of this patch. Do you expect it in eXo JCR 1.14.x or in the future version? and What would be the deadline?
Anyway I know that Marko is very good and has a good knowledge of the kernel, however I still can't apply it blindly, I need to double check it to ensure that we will have no regression with it, so for me it is a real task that has to be planned. Thus I need your answers first to know when it can be planned according to your needs and expectations and ours.
NB: To be able to validate it, I will need a complete overview of what has been done not only at kernel level but even at GateIn level. Is it possible to describe a little bit all the patches that you proposed?
On Mon, Oct 10, 2011 at 1:16 PM, Boleslaw Dawidowicz
<boleslaw.dawidowicz@gmail.com> wrote:
Nicolas,
Julien told me you will be decision person to accept such patch into the kernel. Marko can apply details about the context of those changes if needed.
Bolek
On Oct 6, 2011, at 8:01 PM, Marko Strukelj wrote:
I had to do some classloading and logging changes for exo.kernel.container to work nicely on JBoss AS7.
I'd like to get these changes from my sandbox gatein-as7 branch to exo.kernel.container trunk.
- marko
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev