topic Re: ReflectUtil.loadClass() and custom classloader in Alfresco Archive

ReflectUtil.loadClass() and custom classloader

pgadecki — Thu, 17 Nov 2011 15:11:41 GMT

I'm implementing custom classloader which loads classes from BAR archives and I'm wondering why it is not directly called in ReflectUtil.loadClass()public static Class<?> loadClass(String className) { Class<?> clazz = null; ClassLoader classLoader = getCustomClassLoader(); // Fi

Re: ReflectUtil.loadClass() and custom classloader

meyerd — Mon, 21 Nov 2011 09:51:52 GMT

http://www.javaworld.com/javaworld/javaqa/2003-03/01-qa-0314-forname.html

Class.forName() does what you want but activiti caches instances of JavaDelegate in the DeploymentCache.
This hurts you if you deploy a process and then redeploy your classes without creating a new process engine deployment. Then the DeploymentCache will continue to hold on to your "old" class definition.

Re: ReflectUtil.loadClass() and custom classloader

pgadecki — Tue, 22 Nov 2011 10:45:24 GMT

Could you be more specific on how DeploymentCache is meant to hold classes?

I've written my own BarDeployer on top of com.camunda.fox.activiti.enterprise.deployer.ActivitiDeployerJboss5. For each BAR deployment it creates a BarClassloader(also written by myself) which caches and loads classes from BAR resource file. I can see two possibilities here: I can manage handling class caching with DeploymentCache or give up DeploymentCache and do it all by myself. But to do it I would have to know how is it done in engine.
I've debbuged DeploymentCache uses during deployment of Bar file and all that is done there is that the process definition is added to the cache.

Re: ReflectUtil.loadClass() and custom classloader

pgadecki — Wed, 23 Nov 2011 14:34:42 GMT

I did more research and debugging and with
clazz = classLoader.loadClass(className);the method loadClass of my classLoader is called every time loadClass in ReflectUtil was called - which is the way I want to achieve
but with original
clazz = Class.forName(className, true, classLoader);it is done only for the first time the class is loaded

So maybe I have to change my question to: What I have to do to be sure that my classloader is called every time some activiti engine class calls ReflectUtil.loadClass?

From my point of view, possibility of specifying custom classloader in the enginge is a great idea, but it gives a user almost no flexibility with dynamic loading different versions of the same class.

Re: ReflectUtil.loadClass() and custom classloader

meyerd — Mon, 28 Nov 2011 06:11:05 GMT

Hi Pawel,

1) On the deployment cache:

Instances of JavaDelegate/ActivityBehavior referenced by a process are loaded by activiti at process execution time. (See for instance org.activiti.engine.impl.bpmn.helper.ClassDelegate.activityBehaviorInstance).

However, as activiti maintains a cache of process definitions (the org.activiti.engine.impl.persistence.deploy.DeploymentCache), process definitions will continue to reference an ActivityBehavior instance for the lifetime of the process engine (the cache does not support eviction).

This means that:

after an instance of the delegate is loaded for the first time the process engine continues referencing that instance through the DeploymentCache

instances of JavaDelegate are shared between all process instances in the same process engine

you will see inconsistent behavior if you use custom classloaders and the the deployment lifecycle of your classes is not in sync with your processes (i.e. if you redeploy your classes without creating a new process definition, activiti will continue referencing the "old" classes. If you "restart" the engine, it will load the "new" classes.)

also in combination with a custom classloader: activiti will continue to hold on to any classes loaded by the process definition: even if you "undeploy" these classes through some other mechanism (ie. if you load classes fro man osgi bundle and undeploy that bundle, activiti will still reference them)

Here are a few tips on how to deal with this:

deactivate the deployment cache (implement a subclass which does not cache anything)

use proxy delegates (a delegate which loads the "actual" delegate)

do not use java delegates (but lookup objects the lifecycle of which is managed by some other container like EJB/CDI, OSGi, Spring, … )

The related Jira is ACT-834.

2) On Class.forName(name, initialize, classloader) vs. Classloader.loadClass(name)

You have to garbage collect the classloader that loaded a class / create a new instance of your classloader. If you don't, the JVM will not attempt to reload the class. Th JVM will ask the same classloader only once for the same class. Maybe that is the behavior you see.

Re: ReflectUtil.loadClass() and custom classloader

pgadecki — Mon, 28 Nov 2011 11:04:05 GMT

Hi Daniel,
thanks for the comprehensive reply.

At the end of the last week I had an idea to override ProcessEngineConfigurationImpl.getClassLoader() in the manner that it returns deployment-based classloader (deploymentId is obtained from the ExecutionContext; if there's no classloader for specified deployment or there's no execution context, some default classloader is returned) and it seems that in my simple test cases for all of the processes proper version of classes are loaded.

Do you see any possible drawbacks in doing it this way?
(Actually I have to think it over as well

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Wed, 13 Aug 2014 07:33:48 GMT

On Class.forName(name, initialize, classloader) vs. Classloader.loadClass(name)

Method forName caches classes (see http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html) internally in native implementation for no understandable reason.

This blocks implementing per-deployment class loading with a single dispatcher class loader set to activiti configuration, which detects deployment context and delegates to a per-deployment class loader.

Could anyone explain why ReflectUtil shouldn't use ClassLoader.loadClass instead of Class.forName?

To anyone who is trying to implement per-deployment class loading: the workaround is to override <java>org.activiti.engine.ProcessEngineConfiguration.getClassLoader()</java> method and return your per-deployment class loader (you can detect deployment context via <java>org.activiti.engine.impl.context.Context.getExecutionContext().getProcessDefinition().getDeploymentId()</java>).

Re: ReflectUtil.loadClass() and custom classloader

jbarrez — Tue, 19 Aug 2014 09:28:00 GMT

I didn't know that. I don't think there is a reason for it - the main bit is that the correct classloader is used.

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Tue, 19 Aug 2014 14:36:22 GMT

Joram, the problem is that the correct classloader doesn't have a chance to be used – Java caches the result and bypasses classloader invocation!

Re: ReflectUtil.loadClass() and custom classloader

jbarrez — Wed, 20 Aug 2014 18:46:27 GMT

Yes - indeed (according to the article). I remember we added the Class.forName method back in the day when we added OSGI support.

Do you reckon it is simply a matter of changing the implementation? I'm kind of nervous cause the OSGO bits are always hard (and hard to test!) and I definitely don't want to go break them.

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Thu, 21 Aug 2014 07:07:43 GMT

Joram, I've looked through the ReflectUtil change history – Class.forName has been used since the first version, OSGI changes (commit 1 and commit 2) only added fallback strategy (custom cl -> tccl -> local cl).

I'm not an expert in OSGI, but I believe this change won't make any unforeseen consequences. On the other hand, I understand your adherence to conservative code changes.

Maybe it's possible to add configuration option to support both behaviours? E.g.:
1. boolean property useClassForNameClassLoading in class org.activiti.engine.ProcessEngineConfiguration set to true by default
2. System property org.activiti.engine.useClassForNameClassLoading with the same semantics

I can provide pull request if you approve one of these options.

Re: ReflectUtil.loadClass() and custom classloader

jbarrez — Sat, 30 Aug 2014 16:36:36 GMT

Option 1 is the typical way of doing it in Activiti.

If you would create a pull request, I would most certainly be happy to review it!

Re: ReflectUtil.loadClass() and custom classloader

redguy1 — Wed, 24 Sep 2014 10:42:28 GMT

Any progress on this? I am also interested in calling classloader rather than Class.forName with its caching…

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Wed, 24 Sep 2014 10:50:19 GMT

I haven't made a pull request yet – probably in a week or two I'll come up with it.

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Thu, 23 Oct 2014 15:07:11 GMT

Hello Joram,

I've thought about the two options and saw the following problem with the option 1:
I need the configurable parameter in the static context of ReflectUtil, and it will be available only in non-static context of ProcessEngineConfiguration instance.

Could you please suggest smth? Is it acceptable to implement option 2 in Activiti?

Regards,
Oleg.

Re: ReflectUtil.loadClass() and custom classloader

jbarrez — Fri, 24 Oct 2014 06:50:58 GMT

good point. There is a way though, the ProcessEngineConfiguration is set in a static threadlocal, see org.activiti.engine.impl.context.Context. So in theory you can access the configuration through there.

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Sat, 25 Oct 2014 08:57:15 GMT

Created https://github.com/Activiti/Activiti/pull/414

Re: ReflectUtil.loadClass() and custom classloader

oefimov — Mon, 19 Jan 2015 11:26:03 GMT

TWIMC: bundled in 5.17.0, thanks to Activiti team.