I cannot access sites in my local AEM instance.
I get the following error in the logs:
28.07.2017 13:13:36.500 *ERROR* [qtp804913074-64] 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.0: missing requirement [464.0] osgi.wiring.package; (osgi.wiring.package=javax.servlet))
org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.sling.commons.fsclassloader [464]: Unable to resolve 464.0: missing requirement [464.0] osgi.wiring.package; (osgi.wiring.package=javax.servlet)
Attempting to start the fsclassloader bundle does nothing.
I can access:
http://localhost:4502/system/console/bundles
http://localhost:4502/crx/de/index.jsp
but I cannot access:
http://localhost:4502/libs/cq/core/content/welcome.html
http://localhost:4502/system/console/slingjsp
* or any of my local sites.
Please help. Thank you.
Solved! Go to Solution.
Region Digraph was a bad thing and in a later service pack they removed it. If you revert your fsclassloader back to 1.0.2 and keep the digraph disabled you should be good.
Hi Alex,
Could you just try changing the JAVA version and restarting the instance.
Hope this should resolve your issues.
Thanks,
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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
Views
Replies
Total Likes
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.
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.
Views
Replies
Total Likes
Region Digraph was a bad thing and in a later service pack they removed it. If you revert your fsclassloader back to 1.0.2 and keep the digraph disabled you should be good.
I'll try that. I'll report back.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
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.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies