nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

ReflectUtil.loadClass() and custom classloader

pgadecki

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();
   
   // First exception in chain of classloaders will be used as cause when no class is found in any of them
   Throwable throwable = null;
   
   if(classLoader != null) {
     try {
       LOG.finest("Trying to load class with custom classloader: " + className);
            clazz = Class.forName(className, true, classLoader);
     } catch(Throwable t) {
       throwable = t;
     }
   }
…
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Is there any particular reason to load class using custom classloader in this way:

clazz = Class.forName(className, true, classLoader);‍

instead of directly calling classloader method:

clazz = classLoader.loadClass(className);‍

?

My goal is to have possibility to load two versions of the same class during runtime depending on deployment's id during runtime.
It seems that call with Class.forName() my classloader is not called but some cached class is loaded which is not what I (and probably other custom classloader developers) want to achieve.

Find more posts tagged with

Comments

meyerd

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.

pgadecki

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.

pgadecki

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.

meyerd

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.

pgadecki

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

oefimov

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>).

jbarrez

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.

oefimov

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

jbarrez

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.

oefimov

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.

jbarrez

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!

redguy1

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

oefimov

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

oefimov

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.

jbarrez

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.

oefimov

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

oefimov

TWIMC: bundled in 5.17.0, thanks to Activiti team.