OSGi (in)compatiblity about jackson-jq HOT 4 CLOSED

Thank you for reporting this.

We can't just leave out the thread's context class loader.

In #3, we've decided to use the thread's context class loader in preference to the class's class loader. If this doesn't work in OSGi, we probably need some means to explicitly specify from which class loader to load functions.

How about:

1. Mark no-arg Scope() constructor as @deprecated.
2. Add public loadFunctions(ClassLoader) method which does loadMacros() and loadBuiltinsFunctions() internally with a specified class loader.
3. Optionally add public loadFunctions() which calls loadFunctions(ClassLoader) with a default class loader (which is the thread's context class loader if set, or the class's class loader otherwise).

This can be used like this:

root = new Scope(null)
root.loadFunctions(Scope.class.getClassLoader()) // relatively heavy operation
scope = new Scope(root)

from jackson-jq.

Ah! I hadn't considered loading of custom function definitions. I've read #3 and it makes perfect sense.

In this case it's reasonable to assume that more than one class loader maybe required to load any and all function definitions.

Querying both classloaders would work too.

1. The Scope Class Loader to load the standard definitions.
2. The context class loader for custom definitions.

I can put another PR together for that if you like.

from jackson-jq.

In this case it's reasonable to assume that more than one class loader maybe required to load any and all function definitions.

I agree. In that case, probably we can call loadFunctions(ClassLoader) multiple times with the class loaders.

Querying both classloaders would work too.

I'd rather like to take an explicit loadFunctions(ClassLoader) approach because similar issues can happen sometime again. As to whether loadFunctions(/* no-arg *) should query both class loaders not just one of them, I am not sure. I kind of prefer to re-use the current heuristic (the thread's context class loader if set or the Scope's class loader otherwise) by default.

I can put another PR together for that if you like.

That's great! I'd appreciate it :)

from jackson-jq.

I've updated the PR with those changes.

I've included a couple of minor modifications to the POMs too; to support OSGi bundle JAR and wrapped the nexus plugin in a (default active) profile too. Hope those changes are acceptable.

from jackson-jq.