Community
Participate
Working Groups
Launching the Web Page Editor on an JSPX file fails with the following error: eclipse.buildId=I20080515-2000 java.version=1.5.0_07 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -Xmx512M -XX:MaxPermSize=512M Command-line arguments: -os win32 -ws win32 -arch x86 -clean -Xmx512M -XX:MaxPermSize=512M Error Fri May 16 12:49:20 PDT 2008 Unable to create editor ID org.eclipse.jst.pagedesigner.PageDesignerEditor: The editor class could not be instantiated. This usually indicates a missing no-arg constructor or that the editor's class name was mistyped in plugin.xml. java.lang.ClassFormatError: Illegal field name "(Z)L;" in class org/eclipse/jst/pagedesigner/parts/DocumentEditPart at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:444) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328) at java.lang.Class.getConstructor0(Class.java:2640) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:170) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:867) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:259) at org.eclipse.ui.internal.registry.EditorDescriptor.createEditor(EditorDescriptor.java:233) at org.eclipse.ui.internal.EditorManager.createPart(EditorManager.java:846) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:606) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:428) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:594) at org.eclipse.ui.internal.EditorReference.getEditor(EditorReference.java:266) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2784) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2693) at org.eclipse.ui.internal.WorkbenchPage.access$11(WorkbenchPage.java:2685) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2637) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2632) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2616) at org.eclipse.ui.actions.OpenWithMenu.openEditor(OpenWithMenu.java:337) at org.eclipse.ui.actions.OpenWithMenu.access$0(OpenWithMenu.java:325) at org.eclipse.ui.actions.OpenWithMenu$2.handleEvent(OpenWithMenu.java:187) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1002) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3801) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3400) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2387) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2351) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2203) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:112) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) 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:379) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
It seems like some has become corrupt in the WPE feature, but I'm having trouble understanding why. I'm trying to go back over the last few builds, and can't even get WTP to load in those builds. Is this a P2 problem or something specific to WTP?
Do you have any other (vendor's) VM you could try? I was able to reproduce this error result with Sun's VM (1.5 and 1.6) but not IBM's (neither 1.5 nor 1.6). This is a "stab in the dark", but one difference between between the two family's of VM is how they handle encoding/charsets. Usually, rare, corner cases, but ... I did notice that your plugin.xml for org.eclipse.jst.pagedesigner does not have the usual XML Decl at the beginning of the file: <?xml version="1.0" encoding="UTF-8"?> BTW, we did change the base builder at "the last minute" right before M7. If this bug exists in M7, then might be related to the base builder change. After that though, nothing has really changed about the build infrastructure. I'll try and look in detail at the jar file now, but thought I'd document what I've seen.
I cannot reproduce this issue when running build S-3.0RC1-20080516071848 on a workspace containing all HEAD JSF Tools plugins and launching a runtime workbench from it. I can only reproduce when running directly from the build. This would suggest our code is not broken, but the build system is not correctly building our code in some way.
(In reply to comment #3) > I cannot reproduce this issue when running build S-3.0RC1-20080516071848 on a > workspace containing all HEAD JSF Tools plugins and launching a runtime > workbench from it. I can only reproduce when running directly from the build. > This would suggest our code is not broken, but the build system is not > correctly building our code in some way. > There probably wouldn't be a difference in VM's, then, which is why I was hoping someone could see if they see the same thing. There's quite a large number of differences between running a second instance from a workbench, and running directly, so I'm not sure that says too much. And, BTW, I'm not saying it is your code ... just trying to narrow it down. I did try an M7 install I had (the EPP JEE version) and it seemed to run ok, even with Sun's VM, so don't think it's the byte codes generated by JDT.
(In reply to comment #4) > There probably wouldn't be a difference in VM's, then, which is why I was > hoping someone could see if they see the same thing. > There's quite a large number of differences between running a second instance > from a workbench, and running directly, so I'm not sure that says too much. > And, BTW, I'm not saying it is your code ... just trying to narrow it down. > I did try an M7 install I had (the EPP JEE version) and it seemed to run ok, > even with Sun's VM, so don't think it's the byte codes generated by JDT. I apologize if I seemed to imply that you were saying it was our code, David; we cross-posted, I hadn't seen your comment when I wrote mine, so it was not a direct response to anything you had said. We, too, are trying to narrow it down, but frankly, I am a little puzzled right now. We have made no changes since before M7 to the areas of code that are experiencing sudden issues as in this bug, bug 232609, and bug 232610. - Ian
I've opened Bug 232641 ... maybe the JDT experts can help us out.
As some of have suspected, our class files were being corrupted, and this was being done by "pack200". There is an infamous corruption bug with pack200 which has been previously observed and discussed in bug 154069 (and bugs it points to). The work around for this bug has always been to specify -E4 to pack200 to downgrade the compression effort it attempts. We do this in our build scripts by adding a 'pack.properties' to our zip files, before submitting them to the "jarProcessor" utilities. And, there was an error in the way I was doing this. I had the following in our scripts <exec executable="zip"> <arg line="-r ${buildDirectory}/${buildLabel}/${archiveName} ${wtp.builder.home}/scripts/build/pack.properties" /> </exec> but this put the pack.properties file in the zip file with the wrong path, it should be "at the root". The script should have been <exec dir="${wtp.builder.home}/scripts/build" executable="zip"> <arg line="-r ${buildDirectory}/${buildLabel}/${archiveName} pack.properties" /> </exec> The -E4 parameter is recored in the eclipse.inf file, that is added to a conditioned jar. The clue to this problem was that I was checking that our jars for that parameter, saw it was in wst level jars, as expected, but that in our jst (and dali) jars, it was not there ... it said only that they were conditioned, not that they were conditioned with the E4 parameter. So, using that clue I began to look closer at our scripts to do this work and comparing it to the script in the platform builds which do this work (from which I probably originally copied this script from, but must have not done quite right). In fact, I don't know why the above incorrect script worked at all, for the wst case ... some fluke I guess ... and I probably just "spot checked" when I originally added it and assume if it was in wst code, it'd be everywhere (since the logic is the same). As far as I know, this error has always been there, and we've just finally hit upon some pattern of byte codes that caused the corruption to show up in an obvious way (class format error). I fixed scripts, respun the RC1 build candidate, and the web page editor would open (and the jars I spot checked had -E4 in the eclipse.inf file.
FYI, I've opened bug 232679 as a "follow up" to this bug.
Verified fixed in build S-3.0RC1-20080517195317 Thanks David!
