This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | NoClassDefFoundError: Could not initialize class org.netbeans.modules.glassfish.javaee.Hk2LibraryProvider | ||
---|---|---|---|
Product: | serverplugins | Reporter: | Tomas Danek <musilt2> |
Component: | GlassFish | Assignee: | TomasKraus |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | anebuzelsky, jrechtacek, jskrivanek, kganfield, mjanicek, mmirilovic, phejl, pjiricka |
Priority: | P2 | Keywords: | RELNOTE |
Version: | 7.3 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | 200250 |
Attachments: |
stacktrace
Diff against release73 branch Diff against release73 branch Diff against release73 branch for final rewiew Common GF module for testing JavaEE GF module for testing Commong GF module nbm JavaEE GF module nbm Diff against release73 branch for rewiew Diff against release73 branch for rewiew GF common nbm GF JavaEE nbm messages.log with new exception |
Description
Tomas Danek
2013-06-03 08:37:39 UTC
Created attachment 135249 [details]
stacktrace
In fact, the problem is reproducible by following: - have 7.3 full IDE w/ ergonomics - have javase activated and updated - open webapplication -> Web and j2ee will activate, but exception is thrown and project is not opened - after a while, notification for new updates (for web and j2ee) appear - perform update, restart project can be opened fine. *** Bug 230654 has been marked as a duplicate of this bug. *** This is the first exception I can see in the messages log http://statistics.netbeans.org/exceptions/messageslog?id=674617 J2EE/DeploymentPlugins/gfv3/OptionalFactory.instance java.lang.NoSuchMethodError: org.netbeans.modules.glassfish.spi.ServerUtilities.getPreludeUtilities()Lorg/netbeans/modules/glassfish/spi/ServerUtilities; at org.netbeans.modules.glassfish.javaee.Hk2OptionalFactory.createPrelude(Hk2OptionalFactory.java:83) Caused: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) NoSuchMethodError is usually a sign of wrong versioning. The module Hk2OptionalFactory seems to depend on ServerUtilities but probably without requesting different API. Maintainers of Hk2OptionalFactory and ServerUtilities need to tell us what changes have been made since 7.3 FCS or patch1 and verify they are properly versioned. It would help not to remove methods from classes during releases which are marked as mutually compatible: http://hg.netbeans.org/releases/diff/20c0edef014e/glassfish.common/src/org/netbeans/modules/glassfish/spi/ServerUtilities.java This is similar (but more poorly versioned) case as described at http://wiki.apidesign.org/wiki/Incremental_deployment Fix is simple. Develop compatibly (at least on patch branch, if one is not able to do so during regular development). Unfortunately 7.3.1 development scenario was designed the way which did not allow me to keep 7.3 branch without API changes because of continuous javaee7 merges into trunk. In regular development cycles once release branch is forked, it should live it's own life until death. In our case doing large changes in trunk without javaee7 synchronization caused large conflicts during those automatoc merges. I had to implement couple of new things - add REST GlassFish interface support and remove old prelude code for something what is not supported for years. Doing such a thing in trunk for 7.4 only will for sure avoid such a problams, but as I noticed before, we should follow revommended strategy in branching and backward proting of new features. Tomas, I agree the process could have been better and there should be some automated tests to prevent this incompatible change. But the main point is, can you please fix this so it can be put into the 7.3.1 release? Thanks. Yes, sure. I just have to find out how to do it best. Problem is in glassfish.common which was moved from IDE to Java cluster and code references for removed prelude code are not being updated together. Created attachment 135343 [details]
Diff against release73 branch
Added "Class Hk2LibraryProvider was not found. Please check for GlassFish Server modules update." message pop-up window to be shown instead of NoClassDefFoundError exception.
I just have no idea how to verify this in my environment.
Created attachment 135345 [details]
Diff against release73 branch
One more diff with specification versions update. glassfish.javaee now depends on last glassfish.common.
This is the last pending stopper for 7.3.1, anybody review and Tomas integrate into release73 ASAP ! Created attachment 135368 [details]
Diff against release73 branch for final rewiew
Checked into release73:
-----------------------
changeset: 252388:f3d6a5348fa5
branch: release73
summary: #230645 - Display popup window to run update
when Hk2LibraryProvider class is missing
Here is diff for final review without exception throw to always open dialog.
(In reply to comment #12) > Here is diff for final review without exception throw to always open dialog. Thanks Tomas, could you please also attach both nbms, so we can proceed with verification before actual integration into release73 ? Thanks in advance. Created attachment 135371 [details]
Common GF module for testing
Created attachment 135372 [details]
JavaEE GF module for testing
Here are both modules for testing.
Tomas, please attach NBMs (as Marian noted in comment 13) , we need NBMs, not JARs. Thanks in advance. But how can I generate them? 'ant nbm' from command line. (In reply to comment #17) > But how can I generate them? Created attachment 135377 [details]
Commong GF module nbm
Created attachment 135378 [details]
JavaEE GF module nbm
The patch seems to be safe though under different circumstances I would choose a different message (user does not care which class we are missing). Some autoupdate expert (Jirka, Jarda) should review it anyway. Unfortunately, fix is not working; the reason is that implemented try-catch with warning dialog is in glassfish.javaee, and glassfish.javaee is not updated yet when this code is invoked. It seems like fix must go into glassfish.commons; probably good idea is to return o.n.m.glassfish.spi.ServerUtilities.getPreludeUtilities()Lorg/netbeans/modules/glassfish/spi/ServerUtilities method back with either correct implementation, or show some dialog there, if correct functional implementation is not possible. getPreludeUtilities() sice muzu obnovit a nasimulovat to co delala, ale support pro GF v3 prelude v 7.3.1 uz neni, takze on se pak problem objevi o kus dal. Takze bych tam prestehoval ten dialog co byl v javaee. Oops, wrong language, switching back ... I can restore getPreludeUtilities() and simulate what it did nefore but GF v3 prelude support is not in 7.3.1 anymore so problem will occur on another place. So I'll just move dialog from javaee there after 'hg strip f3d6a5348fa5'. Created attachment 135387 [details]
Diff against release73 branch for rewiew
Created attachment 135388 [details]
Diff against release73 branch for rewiew
Bundle.properties was missing so here it is. I have to rebuild new nbms now so it will take some time.
Created attachment 135390 [details]
GF common nbm
Created attachment 135391 [details]
GF JavaEE nbm
Please verify newly attached nbms. Well, the original exception is gone, dialog appears, but new exc. is thrown, see attached messages.log Created attachment 135401 [details]
messages.log with new exception
1st one I see is java.lang.ClassNotFoundException: org.glassfish.tools.ide.server.config.LibraryConfig$Next at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) ... this is external library that is shared by both modules. So glassfish.common update updated it to current version but we still have old glassfish.javaee which is referencing old code in this library. Unfortunately here I have no idea how to move on without updating both glassfish.common and glassfish.javaee together. Simply whenever old glassfish.javaee code is called it will fail on this library references because library was already updated with glassfish.common. So if noone can think of a better solution, should we just accept the fix that Tomas provided so far? It's not ideal, but I am not sure we can find anything better. Tomasi D, what do you think? (In reply to comment #33) > So if noone can think of a better solution, should we just accept the fix that > Tomas provided so far? It's not ideal, but I am not sure we can find anything > better. Tomasi D, what do you think? We talked with Tomas D. about it, if we can't fix an exception, we would like to not fix it at all and add note into release notes. RELNOTE: ??? still not final one - Tomas & Jirka & Tomas please check and confirm : "To prevent this exception, please activate JavaEE functionality (push main menu Tools|Plugins ... Installed, select 'Java Web adn EE' and push 'Activete') and run update of the IDE (push main menu Help|Check for Updates and update)." I think that pop-up window will give this information to more people than release notes but on the other hands who uses GlassFish plugin with JavaEE turned off? I'm ok with this. Fortunately next time this won't happen again because both plugins are in the same cluster now. (In reply to comment #35) > I'm ok with this. Fortunately next time this won't happen again because both > plugins are in the same cluster now. I would expect this won't happen again because you'll take API development more seriously - without doing major incompatible changes to patch releases and if possible in general. See Jarda's comment #5. Well, I got this information 2 days before final build. Knowing it at the beginning I would had open some discussion on this topic and the way we were developing 7.3.1. Doing such a huge changes like adding GF v4 suppport into v3 plugin in minor release without possibility to redesign some API is bad anyway. For most of you large changes are coming with new major releases but for me it's connected with new glassfish and it will be minor release next time again. Fortunately both modules are in the same cluster so this won't happen anymore. But for the future we have to follow few rules: * I'll keep public API for modules outside those 2 plugins untouched during minor update * GF tooling library can be used only by modules in the same cluster * There must be an option to implement new features in 2 different ways without causing conflicts - in trunk with API redesign - in minor update branch with old API - no automatic forward ports from already branched release (In reply to comment #34) > (In reply to comment #33) > > So if noone can think of a better solution, should we just accept the fix that > > Tomas provided so far? It's not ideal, but I am not sure we can find anything > > better. Tomasi D, what do you think? > > We talked with Tomas D. about it, if we can't fix an exception, we would like > to not fix it at all and add note into release notes. > > RELNOTE: ??? still not final one - Tomas & Jirka & Tomas please check and > confirm : > "To prevent this exception, please activate JavaEE functionality (push main > menu Tools|Plugins ... Installed, select 'Java Web adn EE' and push 'Activete') > and run update of the IDE (push main menu Help|Check for Updates and update)." Added to NB 7.3.1 Release Notes. (In reply to comment #37) > Doing such a huge changes like adding GF v4 suppport into v3 plugin in minor > release without possibility to redesign some API is bad anyway. API redesign is bad on its own. Either it is an API and should evolve compatibly or it's not an API. I tried to explain that to you. Jarda's wiki and book is a good source of knowledge. In my case it's maybe better to stop calling it API between both plugins and join both plugins together. In curent state there is no serious reason to keep those 2 pieces of code separated. There are only few pieces which are real interfaces to anything else. I won't do this in 7.4 but I'll put joining plugins and some refactoring to keep real API that shall be untouched into my TODO list for next development cycle. So does this need to be (at least partially) addressed for 7.4 Beta? Do we support automatic updates from 7.3 to 7.4 the way it's done from 7.3 to 7.3.1? If not, then this issue makes no sense for 7.4 and we can simply close it. I don't have enough information to agree with closing it, but anyway as this is not a beta stopper, I am changing this to P2. (In reply to comment #42) > Do we support automatic updates from 7.3 to 7.4 the way it's done from 7.3 to > 7.3.1? If not, then this issue makes no sense for 7.4 and we can simply close > it. No, but we will for sure support upgrade from 7.4 to 7.4.1 ... so in case this particular problem will not be faced by people after that upgrade - I am fine with closing it as WONTFIX. Thanks in advance. I've already learned to not remove classes/methods in once released branch. Also in 7.4 both modules are in the same cluster so they will be upgraded together. So closing as won't fix because this was 7.3.1 only. java.lang.NoClassDefFoundError: Could not initialize class org.netbeans.modules.glassfish.javaee.Hk2LibraryProvider at org.netbeans.modules.glassfish.javaee.Hk2JavaEEPlatformImpl.<init>(Hk2JavaEEPlatformImpl.java:114) at org.netbeans.modules.glassfish.javaee.Hk2JavaEEPlatformFactory.getJ2eePlatformImpl(Hk2JavaEEPlatformFactory.java:125) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.getJ2eePlatformImpl(ServerInstance.java:347) at org.netbeans.modules.j2ee.deployment.devmodules.api.J2eePlatform.create(J2eePlatform.java:281) at org.netbeans.modules.j2ee.deployment.devmodules.api.ServerInstance.getJ2eePlatform(ServerInstance.java:147) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerPanel.initServers(ProjectServerPanel.java:741) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerPanel.addNotify(ProjectServerPanel.java:157) at java.awt.Container.addImpl(Container.java:1114) at java.awt.Container.add(Container.java:966) at org.openide.WizardDescriptor$WizardPanel.setRightComponent(WizardDescriptor.java:2935) at org.openide.WizardDescriptor.updateStateOpen(WizardDescriptor.java:948) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:820) at org.openide.loaders.TemplateWizard.updateState(TemplateWizard.java:754) at org.netbeans.modules.project.ui.NewProjectWizard.updateState(NewProjectWizard.java:71) at org.openide.WizardDescriptor._updateState(WizardDescriptor.java:798) at org.openide.WizardDescriptor.access$200(WizardDescriptor.java:90) at org.openide.WizardDescriptor$Listener.stateChanged(WizardDescriptor.java:2094) at org.openide.util.WeakListenerImpl$Change.stateChanged(WeakListenerImpl.java:329) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:133) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:119) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerWizardPanel.fireChangeEvent(ProjectServerWizardPanel.java:138) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerPanel.insertUpdate(ProjectServerPanel.java:1020) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:202) at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:749) at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:708) at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130) at javax.swing.text.AbstractDocument.replace(AbstractDocument.java:670) at javax.swing.text.JTextComponent.setText(JTextComponent.java:1718) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerPanel.read(ProjectServerPanel.java:665) at org.netbeans.modules.j2ee.common.project.ui.ProjectServerWizardPanel.readSettings(ProjectServerWizardPanel.java:143) at org.openide.WizardDescriptor.updateStateOpen(WizardDescriptor.java:865) at org.openide.WizardDescriptor.updateState(WizardDescriptor.java:820) at org.openide.loaders.TemplateWizard.updateState(TemplateWizard.java:754) at org.netbeans.modules.project.ui.NewProjectWizard.updateState(NewProjectWizard.java:71) at org.openide.WizardDescriptor._updateState(WizardDescriptor.java:798) at org.openide.WizardDescriptor.goToNextStep(WizardDescriptor.java:1070) at org.openide.WizardDescriptor.access$1800(WizardDescriptor.java:90) at org.openide.WizardDescriptor$Listener$1.run(WizardDescriptor.java:2122) at org.openide.WizardDescriptor.lazyValidate(WizardDescriptor.java:1502) at org.openide.WizardDescriptor.access$1900(WizardDescriptor.java:90) at org.openide.WizardDescriptor$Listener.actionPerformed(WizardDescriptor.java:2141) 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:606) at org.openide.util.WeakListenerImpl$ProxyListener.invoke(WeakListenerImpl.java:458) at com.sun.proxy.$Proxy27.actionPerformed(Unknown Source) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) at java.awt.Component.processMouseEvent(Component.java:6505) at javax.swing.JComponent.processMouseEvent(JComponent.java:3321) at java.awt.Component.processEvent(Component.java:6270) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4861) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) at java.awt.Container.dispatchEventImpl(Container.java:2273) at java.awt.Window.dispatchEventImpl(Window.java:2719) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87) at java.awt.EventQueue$4.run(EventQueue.java:708) at java.awt.EventQueue$4.run(EventQueue.java:706) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:705) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:154) at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:182) at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:221) at java.security.AccessController.doPrivileged(Native Method) at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:219) at java.awt.Dialog.show(Dialog.java:1082) at org.netbeans.core.windows.services.NbPresenter.superShow(NbPresenter.java:1076) at org.netbeans.core.windows.services.NbPresenter.doShow(NbPresenter.java:1126) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:1098) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:128) at org.openide.util.Mutex.doEventAccess(Mutex.java:1363) at org.openide.util.Mutex.readAccess(Mutex.java:273) at org.netbeans.core.windows.services.NbPresenter.show(NbPresenter.java:1083) at java.awt.Component.show(Component.java:1651) at java.awt.Component.setVisible(Component.java:1603) at java.awt.Window.setVisible(Window.java:1014) at java.awt.Dialog.setVisible(Dialog.java:1005) at org.netbeans.core.windows.services.DialogDisplayerImpl$1AWTQuery.showDialog(DialogDisplayerImpl.java:260) at org.netbeans.core.windows.services.DialogDisplayerImpl$1AWTQuery.run(DialogDisplayerImpl.java:186) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:703) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) at java.awt.EventDispatchThread.run(EventDispatchThread.java:91) Please, can you provide some background for last stack trace - e.g. what were you doing, how to reproduce it, etc. asac1991, don't change metadata of issue, we do need to know in which version it was reported initially. If you have a reproducible case in NetBeans 7.4 (Beta?, Dev build), please provide information which Tomas asked for and reopen the issue. Thank you |