This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

java.lang.IllegalArgumentException: Argument "clazz" must not be null!
at org.eclipse.equinox.weaving.internal.caching.BundleCachingService.storeClass(Unknown Source)
at org.eclipse.equinox.weaving.adaptors.WeavingAdaptor.storeClass(Unknown Source)
at org.eclipse.equinox.weaving.hooks.WeavingHook.recordClassDefine(Unknown Source)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:614)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:562)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:486)
at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:459)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:400)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:476)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:429)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:417)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:345)
at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:229)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1207)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:268)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:264)
at org.eclipse.ui.internal.registry.ViewDescriptor.createView(ViewDescriptor.java:63)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:327)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:229)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:595)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:313)
at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:534)
at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:180)
at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:270)
at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:473)
at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1245)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:662)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:570)
at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:568)
at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:272)
at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:981)
at org.eclipse.ui.internal.WorkbenchPage.onActivate(WorkbenchPage.java:2714)
at org.eclipse.ui.internal.WorkbenchWindow$28.run(WorkbenchWindow.java:3030)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70)
at org.eclipse.ui.internal.WorkbenchWindow.setActivePage(WorkbenchWindow.java:3011)
at org.eclipse.ui.internal.WorkbenchWindow$21.runWithException(WorkbenchWindow.java:2297)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212)
at org.eclipse.ui.application.WorkbenchAdvisor.openWindows(WorkbenchAdvisor.java:803)
at org.eclipse.ui.internal.Workbench$33.runWithException(Workbench.java:1600)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3563)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3212)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2609)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2499)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:679)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:668)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

This looks indeed like the update didn't run correctly and didn't update everything as it should have. The stack trace from above refers to a bug in Equinox Weaving that got fixed and that fix should be included in STS 2.9.2, therefore the update definitely didn't run correctly.

Can you try to re-install STS 2.9.2 from scratch? That would be great. I apologize for the inconvenience and will try to investigate why the update didn't work correctly for you.

-Martin

Comment

I tried installing 2.9.2 from scratch but I had problems importing my Maven project. If I started STS from the command line I got a note that OpenJDK crashed and the crash cause was in native code and not in Java code. That might be a bug in OpenJDK, but it was keeping me from working so I deleted the 2.9.2 installation.

I'm not sure what exactly helped, but now I'm running the previous installation (I didn't delete it before trying to install 2.9.2 from scratch) and so far it's working fine. One change is that I'm using a new workspace now. What's curious is that this installation reports its version to be 2.9.1.RELEASE (build 201203221000). I thought I updated this installation of STS so it's a mystery to me why it's still 2.9.1 and not 2.9.2. The installation directory at /opt/sts/sts-2.9.0.RELEASE has files referring to both versions, e.g.

I investigated the update problem and there was indeed a misconfigured composite update site (pointed to the wrong Mylyn version) so that the update did not update your complete STS installation. This is fixed now and I apologize for the inconvenience here. Hope this works now all again.

I tried installing 2.9.2 from scratch but I had problems importing my Maven project. If I started STS from the command line I got a note that OpenJDK crashed and the crash cause was in native code and not in Java code. That might be a bug in OpenJDK, but it was keeping me from working so I deleted the 2.9.2 installation.

If the JDK crashed, there is not much we can do here, but the report might be worth to take a look at. So if you have a crash log, it would be at least interesting to see whether it crashed in some Eclipse native code parts or somewhere else. Can you attach it here?

I'm not sure what exactly helped, but now I'm running the previous installation (I didn't delete it before trying to install 2.9.2 from scratch) and so far it's working fine. One change is that I'm using a new workspace now. What's curious is that this installation reports its version to be 2.9.1.RELEASE (build 201203221000). I thought I updated this installation of STS so it's a mystery to me why it's still 2.9.1 and not 2.9.2. The installation directory at /opt/sts/sts-2.9.0.RELEASE has files referring to both versions, e.g.

(The installation directory path says 2.9.0 because that was the version I installed from scratch and I later updated from 2.9.0 to 2.9.1.)

This is because of the misconfigured composite update site that I mentioned in my previous post. I would recommend not to continue with that old installation, because it clearly seems to be only half-upgraded (I was able to reproduce that here) and it is now somewhat unpredictable what works and what might be broken because of this half-way-through upgrade.

I would suggest to try to install STS 2.9.2 again to see if the OpenJDK crash is reproduceable (and possibly update that as well). The other option would be to install STS 2.9.1 from scratch, see if that works with your JDK and then do the "check for updates" again. Since I fixed the problem with the update site, the update should work now.

HTH,
Martin

Comment

Thanks for investigating the issue. It seems that I can make STS 2.9.2 OpenJDK crash very easily. Here are the steps I did:

1. Run springsource-tool-suite-2.9.2.RELEASE-e3.7.2-linux-gtk-x86_64-installer.sh (md5sum b82f760a0c514232a2247ad95e2b30f5).
2. Install to /opt/sts as a normal user (the user has write permission to /opt/ ).
3. Use /usr/lib/jvm/java-6-openjdk as the JDK path.
4. Launch STS from command line by typing: /opt/sts/sts-2.9.2.RELEASE/STS
5. Create a new workspace or open an existing one.

By following these steps I was able to get STS to crash at least twice. Here are two samples of what gets printed to console:

Comment

Thanks for investigating the issue. It seems that I can make STS 2.9.2 OpenJDK crash very easily. Here are the steps I did:

1. Run springsource-tool-suite-2.9.2.RELEASE-e3.7.2-linux-gtk-x86_64-installer.sh (md5sum b82f760a0c514232a2247ad95e2b30f5).
2. Install to /opt/sts as a normal user (the user has write permission to /opt/ ).
3. Use /usr/lib/jvm/java-6-openjdk as the JDK path.
4. Launch STS from command line by typing: /opt/sts/sts-2.9.2.RELEASE/STS
5. Create a new workspace or open an existing one.

Interesting. The OpenJDK issue comes up also if I install 2.9.1 from scratch and try to open a workspace. It does not come up when I install 2.9.0, not even after upgrading 2.9.0 to 2.9.2.

Comment

I just noticed you mentioned earlier about posting the log text and it being too long for the forum. In that case, perhaps it is best to create a bug ticket in the STS Jira. You should be able to attach as much text as you want there. Also that's a better place for a problem report like this than the current thread on the forum.

Comment

At first, the subversion metadata of all the projects in the workspace (there are more than 70) were no more recognized, so I had to uninstall Subclipse and reinstall it (I'm using 1.6.x). That fixed it.

Next, it looks like each change to Spring context xml file makes the building phase take ages: in the Progress window I often see "Building all...: Loading [...]/context.xml"; it took quite less time to build before.

Is there any configuration I must update, or anything?

Thanks

P.s.: At times it shows "Building AOP (something)". Can this be the cause of the slowdown? In case, how do I disable it?

Updating from 2.9.1 to 2.9.2 shouldn't cause a slowdown in project building or anything like that. Therefore I would be very interested to get more details on this. Can you take a thread dump while the build is running and taking long? (using jps and jstack commands from the command line) And post the thread-dump here or in a new thread on this forum? That would be great!!!

-Martin

Comment

My workspace has many projects, three of those are web applications that get published in the Tomcat 7.0.26 server inside STS. The dependencies are managed through Maven 3.0.3, and each time there's only one web application deployed to the webserver - so the other context files are built, but never used.

While I'm composing this message the building is still running, I think it's taking more than half an hour, while it finished within minutes with the previous version.

I'd like to add that I reinstalled 2.9.1 from the zip distribution and I'm noticing that all my projects now show an "S" in the right-upper corner of their icon, where there was a "J"; the "S" came up in 2.9.2 but seems that it is being conserved here in 2.9.1.

Plus, the slowdown seems to be still present. Can that "S" be the source of the problem? Maybe that means STS is applying some additional steps to the context file in the building phase?

Comment

Yes, it looks like the Spring Nature was the cause.
I removed that nature from all my projects. They all got back to their "J", and the building process returned to the usual minutes.
I'm a bit worried that switching forward to 2.9.2 could re-add the Spring nature to all the projects, so I won't do that attempt now.

The "S" indicates the Spring nature of a project, but that shouldn't be added automatically for each project as long as there is no Spring involved. Do you use Spring in those projects? But it does sound like a bug that this nature got added automatically after you upgraded from 2.9.1 to 2.9.2. Can you send my such a project before it got updated? Maybe I can reproduce this issue somehow.

Regarding the slowdown: The Spring nature does indeed add additional functionality that is executed during a build. However, this should not cause your build to run for half an hour or so. I can see disc access in the thread dumps. Is your workspace on a local hard drive or on a network-attached storage? That could cause those slowdowns...