Announcement Announcement Module
Collapse
No announcement yet.
STS 2.9.2 released Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • STS 2.9.2 released

    Dear Spring Community,

    I am happy to announce the update release 2.9.2 of the SpringSource Tool Suite (STS).

    Fixes in this update release include:
    • updated to tc Server 2.7.0
    • IDE-1246: An internal error occurred during: "Updating Maven Configuration". NPE in RooProjectConfigurator.doConfigure
    • IDE-1244: RequestMappings does not include mappings defined on interfaces
    • IDE-1243: Search Pointcut Matches returns no results
    • STS-2592: RequestMappings and Controllers do not appear in the Spring Explorer view
    • STS-2571: update equinox weaving for AJDT to latest from Eclipse 3.8 streams
    • STS-2569: NullPointerException in LegacyProjectChecker
    • STS-2563: Grails 2.0.3 plugin update
    • STS-2553: update tc Server integration for upcoming tc Server 2.7
    • STS-2493: Spring nature not automatically added when project has spring-core dependency
    • STS-2490: Grails Plugin Manager will not launch
    • STS-2274: No property tester contributes a property org.springframework.ide.eclipse.beans.core.model.i sInfrastructureBean to type class org.springframework.ide.eclipse.beans.core.interna l.model.Bean

    More details can be found in the New and Noteworthy document.
    As always downloads are available from the STS download page.

    Regards,
    Martin

  • #2
    Upgrade from 2.9.1 failed in Kubuntu 11.10. My package explorer or JUnit views on the left don't work. Package explorer tab says:

    Code:
    Could not create the view: Plug-in org.eclipse.jdt.ui was unable to load class org.eclipse.jdt.internal.ui.packageview.PackageExplorerPart.
    There's a button "Details >>", too. Clicking it reveals a textbox with stack trace:

    Code:
    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)
    Error Log view also lists tens of errors and warnings.

    Looks like I'll have to reinstall STS from scratch...

    Comment


    • #3
      Hey!

      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


      • #4
        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.

        plugins/org.springframework.ide.eclipse.webflow.core_2.9.1 .201203220057-RELEASE.jar
        plugins/org.springframework.ide.eclipse.webflow.core_2.9.2 .201205070117-RELEASE.jar

        (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.)

        Comment


        • #5
          Hey!

          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.

          -Martin

          Comment


          • #6
            Hey!

            Originally posted by jkk View Post
            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?

            Originally posted by jkk View Post
            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.

            plugins/org.springframework.ide.eclipse.webflow.core_2.9.1 .201203220057-RELEASE.jar
            plugins/org.springframework.ide.eclipse.webflow.core_2.9.2 .201205070117-RELEASE.jar

            (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


            • #7
              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:

              Code:
              #
              # A fatal error has been detected by the Java Runtime Environment:
              #
              #  SIGSEGV (0xb) at pc=0x00007fd75eec8c50, pid=4004, tid=140563188668160
              #
              # JRE version: 6.0_23-b23
              # Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops)
              # Derivative: IcedTea6 1.11pre
              # Distribution: Ubuntu 11.10, package 6b23~pre11-0ubuntu1.11.10.2
              # Problematic frame:
              # C  [libgobject-2.0.so.0+0x18c50]  g_object_get_qdata+0x20
              #
              # An error report file with more information is saved as:
              # .../hs_err_pid4004.log
              #
              # If you would like to submit a bug report, please include
              # instructions how to reproduce the bug and visit:
              #   https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
              # The crash happened outside the Java Virtual Machine in native code.
              # See problematic frame for where to report the bug.
              #
              
              #
              # A fatal error has been detected by the Java Runtime Environment:
              #
              #  SIGSEGV (0xb) at pc=0x00007ffafb696c50, pid=4501, tid=140716070053632
              #
              # JRE version: 6.0_23-b23
              # Java VM: OpenJDK 64-Bit Server VM (20.0-b11 mixed mode linux-amd64 compressed oops)
              # Derivative: IcedTea6 1.11pre
              # Distribution: Ubuntu 11.10, package 6b23~pre11-0ubuntu1.11.10.2
              # Problematic frame:
              # C  [libgobject-2.0.so.0+0x18c50]  g_object_get_qdata+0x20
              #
              # An error report file with more information is saved as:
              # .../hs_err_pid4501.log
              #
              # If you would like to submit a bug report, please include
              # instructions how to reproduce the bug and visit:
              #   https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
              # The crash happened outside the Java Virtual Machine in native code.
              # See problematic frame for where to report the bug.
              #
              I tried attaching these hs_err_pid* files to this post but the forum maximum size for text files seems to be 20 kB and the files are 80 kB each. Would these files be helpful to you?

              Comment


              • #8
                Originally posted by jkk View Post
                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


                • #9
                  In the message it says this:

                  # See problematic frame for where to report the bug.

                  Did you include the whole error message? I don't see stackframe info. This info may help identify which native code the crash is in.

                  Kris

                  Comment


                  • #10
                    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.

                    The STS issue tracker is here:
                    https://issuetracker.springsource.com/browse/STS

                    Thanks,

                    Kris

                    Comment


                    • #11
                      I updated today, from 2.9.1.

                      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?
                      Last edited by mayjay; May 29th, 2012, 12:24 PM.

                      Comment


                      • #12
                        Hey!

                        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


                        • #13
                          Hello,
                          Jps shows just this:
                          Code:
                          1424 Jps
                          344 Program
                          And jstack output is attached.

                          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?
                          Last edited by mayjay; May 30th, 2012, 05:02 AM.

                          Comment


                          • #14
                            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.

                            Any suggestion about this?

                            Comment


                            • #15
                              Hey!

                              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...

                              -Martin

                              Comment

                              Working...
                              X