Component bundles are not loaded.

2
I just want to know if anyone has ever had this error and how did they solve it "Component bundles are not loaded"? Basically this is a M2EE error. Ever since I started using version 5 of the Mendix Modeler I get this at least 7 times a day. Here is the stack trace: com.mendix.m2ee.api.AdminException: Component bundles are not loaded. at com.mendix.core.impl.MxRuntimeImpl.start(MxRuntimeImpl.java:281) at com.mendix.core.impl.MxRuntimeImpl.start(MxRuntimeImpl.java:229) at com.mendix.m2ee.appcontainer.actions.StartAction.startRuntime(StartAction.java:56) at com.mendix.m2ee.appcontainer.actions.StartAction.execute(StartAction.java:34) at com.mendix.m2ee.appcontainer.server.handler.HttpAdminHandler.handle(HttpAdminHandler.java:135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:368) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:647) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) at java.lang.Thread.run(Thread.java:745)
asked
3 answers
2

The times I encountered this stacktrace, it was always accompanied by a stacktrace indicating issues with the project's Java version. In these cases there was a mismatch between the JDK with which the MDA was created, and the Java version which the environment is set up to use. So in other words, if the modeler is configured to use a Java 8 JDK whereas the environment is configured to use a Java 7 JDK (either through the m2ee.yaml file or the setting in the cloud portal) you'd get this error.

So unless there's other issues which generate a similar stacktrace, could be worthwile to compare the java version your environment uses and the JDK configured in the modeler used to generate the MDA.

Typical stacktrace for this:

ERROR - OSGi: (1/2) Unsupported class version error for bundle 'project'. Probably your project was compiled with Java 8, but you are currently running Mendix with Java 7. Please run Mendix using Java 8 or recompile the actions using Java 7 or by setting the Java source and target version to 7.
ERROR - OSGi: (2/2) [system.UserActionsRegistrar] Unexpected throwable from attempt to collect dependencies (bundle: project, service: )
ERROR - OSGi: (1/28) java.lang.UnsupportedClassVersionError: system/UserActionsRegistrar : Unsupported major.minor version 52.0
ERROR - OSGi: (2/28) at java.lang.ClassLoader.defineClass1(Native Method)
ERROR - OSGi: (3/28) at java.lang.ClassLoader.defineClass(Unknown Source)
ERROR - OSGi: (4/28) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2279)
ERROR - OSGi: (5/28) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1501)
ERROR - OSGi: (6/28) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
ERROR - OSGi: (7/28) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
ERROR - OSGi: (8/28) at java.lang.ClassLoader.loadClass(Unknown Source)
ERROR - OSGi: (9/28) at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1844)
ERROR - OSGi: (10/28) at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
ERROR - OSGi: (11/28) at org.apache.felix.scr.impl.manager.AbstractComponentManager.initDependencyManagers(AbstractComponentManager.java:725)
ERROR - OSGi: (12/28) at org.apache.felix.scr.impl.manager.AbstractComponentManager.collectDependencies(AbstractComponentManager.java:762)
ERROR - OSGi: (13/28) at org.apache.felix.scr.impl.manager.AbstractComponentManager$Unsatisfied.activate(AbstractComponentManager.java:1492)
ERROR - OSGi: (14/28) at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:550)
ERROR - OSGi: (15/28) at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:261)
ERROR - OSGi: (16/28) at org.apache.felix.scr.impl.config.ImmediateComponentHolder.enableComponents(ImmediateComponentHolder.java:328)
ERROR - OSGi: (17/28) at org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:158)
ERROR - OSGi: (18/28) at org.apache.felix.scr.impl.BundleComponentActivator.<init>(BundleComponentActivator.java:113)
ERROR - OSGi: (19/28) at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:261)
ERROR - OSGi: (20/28) at org.apache.felix.scr.impl.Activator.bundleChanged(Activator.java:179)
ERROR - OSGi: (21/28) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
ERROR - OSGi: (22/28) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
ERROR - OSGi: (23/28) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
ERROR - OSGi: (24/28) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4403)
ERROR - OSGi: (25/28) at org.apache.felix.framework.Felix.startBundle(Felix.java:2092) ERROR - OSGi: (26/28) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291)
ERROR - OSGi: (27/28) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
ERROR - OSGi: (28/28) at java.lang.Thread.run(Unknown Source)
ERROR - M2EE: Component bundles are not loaded.
ERROR - M2EE: (1/19) com.mendix.m2ee.api.AdminException: Component bundles are not loaded.
ERROR - M2EE: (2/19) at com.mendix.core.impl.MxRuntimeImpl.start(MxRuntimeImpl.java:287)
ERROR - M2EE: (3/19) at com.mendix.core.impl.MxRuntimeImpl.start(MxRuntimeImpl.java:243)
ERROR - M2EE: (4/19) at com.mendix.m2ee.appcontainer.actions.StartAction.startRuntime(StartAction.java:50)
ERROR - M2EE: (5/19) at com.mendix.m2ee.appcontainer.actions.StartAction.execute(StartAction.java:31)
ERROR - M2EE: (6/19) at com.mendix.m2ee.appcontainer.server.handler.HttpAdminHandler.handle(HttpAdminHandler.java:122)
ERROR - M2EE: (7/19) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
ERROR - M2EE: (8/19) at org.eclipse.jetty.server.Server.handle(Server.java:368)
ERROR - M2EE: (9/19) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
ERROR - M2EE: (10/19) at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
ERROR - M2EE: (11/19) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
ERROR - M2EE: (12/19) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
ERROR - M2EE: (13/19) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
ERROR - M2EE: (14/19) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
ERROR - M2EE: (15/19) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:628)
ERROR - M2EE: (16/19) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
ERROR - M2EE: (17/19) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
ERROR - M2EE: (18/19) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
ERROR - M2EE: (19/19) at java.lang.Thread.run(Unknown Source)

answered
0

I have seen this error a lot of times as well. Usually with other people working on the project. Have never been able to find the real cause. As you describe, it seems like sometimes specific people run into this all the time for a few days, and suddenly it disappears and is gone for a few months.

What's always worth a try is cleaning the deployment dir, or if that doesn't help, checking out a fresh copy of the project and work on that.

answered
0

In my case, killing tsvncache.exe did the trick. I found the culprit using Process Explorer (from Microsoft Sysinternals) and search for the name of the folder that contains my Mendix projects. See also https://serverfault.com/a/1980.

answered