AEM 6.1 Unable to Start Apache Sling Commons FileSystem ClassLoader (org.apache.sling.commons.fsclassloader)

Hi Alex,

Could you just try changing the JAVA version and restarting the instance.

Hope this should resolve your issues.

Thanks,

Techaspect Solutions.

Hi, always ran under jdk1.7.0_79. I stoppped my instance and ran it under jdk1.8.0_65 and I get the exact same issues.

Does this happen when you install a bundle - looks like the issue is something is referencing a wrong Java library:

Unable to resolve 464.0: missing requirement [464.0] osgi.wiring.package; (osgi.wiring.package=javax.servlet

Hi, the error occurs on startup.

I did recently install a few hotfixes for ACM support. My current strategy is backup my crx-quickstart folder and then uninstall those hotfixes from package manager and see if I can revert to a previous state where it was working.

I'll keep the thread informed if this resolves the issue.

Thanks,

Alex

Check your bundles to see if you have something called "Region digraph" If that's there, disable it.

Hi, an update: I've disabled Region Digraph.

• I tried uninstalling the hotfixes but it made a bigger mess of everything, so I have since reverted back to my "backup" of crx-quickstart to continue attempting to resolve the fsclassloader issue.

• I attempted to update the Apache Sling Commons FileSystem ClassLoader (org.apache.sling.commons.fsclassloader) bundle from version 1.0.2 to 1.0.6. Same error and issues.

• I've disabled Region Digraph. I then attempted to start the fsclassloader bundle. The error has since changed from:

31.07.2017 14:50:50.670 *ERROR* [qtp911233101-268] org.apache.felix.http.jetty %bundles.pluginTitle: Cannot start (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.commons.fsclassloader [464]: Unable to resolve 464.1: missing requirement [464.1] osgi.wiring.package; (osgi.wiring.package=javax.management))

org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.commons.fsclassloader [464]: Unable to resolve 464.1: missing requirement [464.1] osgi.wiring.package; (osgi.wiring.package=javax.management)

TO

31.07.2017 15:38:05.912 *ERROR* [qtp911233101-268] org.apache.felix.http.jetty %bundles.pluginTitle: Cannot start (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.commons.fsclassloader [464]: Unable to resolve 464.1: missing requirement [464.1] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.lang3)(version>=3.4.0)(!(version>=4.0.0))))

org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.commons.fsclassloader [464]: Unable to resolve 464.1: missing requirement [464.1] osgi.wiring.package; (&(osgi.wiring.package=org.apache.commons.lang3)(version>=3.4.0)(!(version>=4.0.0)))

This may be a step in the right direction. Thank you for the suggestion. And thank you everyone for the ongoing help.

I'll try that. I'll report back.

Thank you, JE Bailey. The combination of disabling/uninstalling Region Digraph and reverting back to FileSystem Class Loader 1.0.2 from 1.0.6 did the trick.

I wish I understood better why Region Digraph was at the core of this problem, but for now, simply many thanks to you for your help. Sincerely, thank you thank you.

Cause knowledge is power

The idea behind the region digraph is that it intercepts and shortcuts the wiring framework to tell your bundle what the available package versions are.

There's two possible reasons that I'm aware of that this would have been implemented. The first is that it could maintain a state of what the OSGi bundle relationships are without having those bundles actually available. This would have assisted in the scenarios where you have complicated relationships of dependencies during startup.

The other possibility is that it would have assisted with multi-tenancy. You could define a "region" within your application that was comprised of some bundles but not others. Allowing you to run multiple applications without touching each other.

What happened however is that occasionally it gets in a state where it doesn't realize that the bundles have been changed when they have. So even though you have a bundle sitting there saying "I have foo.bar v3" no other bundle can see it, they have been told by the digraph that "foo.bar v2" was there and in fact it wasn't.

You can safely delete this bundle and I would highly recommend it.