Fix Jackson ServiceConfigurationError caused by NetBeans classloader conflict

[jGauravGupta]

Fix Jackson ServiceConfigurationError caused by NetBeans classloader conflict

While invoking the AI assistant, the following error occurred:

java.util.ServiceConfigurationError:
com.fasterxml.jackson.module.jaxb.JaxbAnnotationModule not a subtype

This happens because Jackson discovers modules using ServiceLoader, which relies on the Thread Context ClassLoader (TCCL).
In NetBeans, the default TCCL may point to the platform classloader, which exposes Jackson modules bundled with NetBeans (e.g. JaxbAnnotationModule).

Since the plugin uses its own Jackson dependencies, the same classes are loaded by different classloaders, causing the JVM to treat them as incompatible types.

Fix

Before initializing the chat / LangChain4j components, the plugin now explicitly sets the plugin classloader as the thread context classloader:

private void usePluginClassLoader() {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
}

This ensures ServiceLoader only scans modules bundled with the plugin, preventing conflicts with NetBeans platform libraries.

[stefanofornari]

WOW! this is a great catch. I am wondering, however, if we can exclude to include langchain4j's jackson jars at build level?

[jGauravGupta]

I tried excluding LangChain4j’s Jackson and relying on the NetBeans org-netbeans-libs-jackson module. However, that module depends on org-netbeans-libs-jaxb, which is a friend-only module and not publicly accessible. I also tried adding jaxb-api to provide javax.xml.bind.annotation.XmlElement, but the issue still occurs because the NetBeans Jackson module expects its own JAXB module. Due to these module restrictions, the safer approach is to keep LangChain4j’s Jackson dependencies bundled with the plugin.

[stefanofornari]

mmh.... very strange; what do you think explains why on your environment is not working and on mine it works?

[jGauravGupta]

Good question — I’m actually not completely sure why the behavior differs between our environments.

[stefanofornari]

That's the risk; we may fix one env but break others. What we can tell is that if on some NB envs it works, it's probably not something that has to do with a plain NB installation; maybe it is due to other modules? or maybe Windows? I tested on Linux and MacOS not windows. I'll try that.
Is the issue there even starting with a fresh new userdir?

[jGauravGupta]

Yes — I tested with a fresh new userdir, and the issue does not occur there.

This suggests the problem is not OS-specific, but rather environment-specific and related to the NetBeans setup. It may be caused by other installed modules altering the classpath or classloader behavior, which can lead to conflicting versions of the same libraries.

In the past, we also encountered a similar situation where other plugins clashed with Jeddict Modeler (and vice versa) on the NetBeans classpath, producing comparable classloader conflicts.

With the current fix, the Thread Context ClassLoader is restricted to the Jeddict AI plugin classpath, so ServiceLoader only discovers modules bundled with the plugin. This should prevent conflicts with public libraries coming from other plugins.

Wdyt?

[stefanofornari]

IMHO tweaking the classpath in a unconventional way for NB is committing to future headaches. I would first isolate which is the module that causes the issue by starting from the clean environment and adding plug-ins one by one.
Based on that we can decide if it is worth more effort, it may end up we could live without that module.

The other thing I would try is to add the dependency directly in jeddict; maybe in this way NB will find them in the module classpath?

[jGauravGupta]

You're right. Unfortunately I lost the environment/cache where the issue was reproducible after a clean build, so I can't currently identify which module caused the conflict. With a fresh userdir the problem no longer appears.

For now I'll skip this PR for the release and revisit it if I'm able to reproduce and isolate the conflicting module.

[jGauravGupta]

Hi @stefanofornari,

I observed that in my case the issue appears even when starting with a fresh workspace. After using the IDE for about 2–3 days, the error starts occurring again, even though no additional plugins were installed during that time.

So it doesn’t seem directly related to installing a specific plugin, which makes the root cause a bit harder to isolate.

[stefanofornari]

Hi @jGauravGupta, ok, let's go with this fix for now. I would suggest to create an issue with the stacktrace you get and link it to this PR. we will keep it open until we find a better fix.
I'd also set the classpath in JeddicBrain.pariProgrammer() rather than in AssistantChatManager to make sure the fix applies regardless how and where it was invoked from.

[stefanofornari]

Opened #298 to keep an eye on it. @jGauravGupta can you please add the full stacktrace? I'd like to see if the langchain4j guys have any idea.

[jGauravGupta]

Thanks, updated the ticket!