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.

Bug 198491 - NoSuchMethodError: org.netbeans.modules.web.jsfapi.spi.JsfSupportProvider.get(Ljavax/swing/text/Document;)Lorg/netbeans/modules/web/jsfapi/api/JsfSupport;
Summary: NoSuchMethodError: org.netbeans.modules.web.jsfapi.spi.JsfSupportProvider.get...
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: JSF Editor (show other bugs)
Version: 7.0.1
Hardware: All All
: P2 normal (vote)
Assignee: Marek Fukala
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-10 19:24 UTC by Exceptions Reporter
Modified: 2011-07-25 11:25 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 178745


Attachments
stacktrace (2.46 KB, text/plain)
2011-05-10 19:24 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2011-05-10 19:24:37 UTC
Build: NetBeans IDE 6.9.1 (Build nbms-and-javadoc-7085-on-20110425)
VM: Java HotSpot(TM) Client VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02
OS: Windows XP

User Comments:
rweaver: Just starting up and editing




Stacktrace: 
java.lang.NoSuchMethodError: org.netbeans.modules.web.jsfapi.spi.JsfSupportProvider.get(Ljavax/swing/text/Document;)Lorg/netbeans/modules/web/jsfapi/api/JsfSupport;
   at org.netbeans.modules.web.jsf.editor.JsfSupportImpl.findFor(JsfSupportImpl.java:84)
   at org.netbeans.modules.web.jsf.editor.hints.LibraryDeclarationChecker.checkLibraryDeclarations(LibraryDeclarationChecker.java:107)
   at org.netbeans.modules.web.jsf.editor.hints.LibraryDeclarationChecker.compute(LibraryDeclarationChecker.java:87)
   at org.netbeans.modules.web.jsf.editor.hints.HintsRegistry.gatherHints(HintsRegistry.java:79)
   at org.netbeans.modules.web.jsf.editor.JsfHtmlExtension.computeErrors(JsfHtmlExtension.java:593)
   at org.netbeans.modules.html.editor.gsf.HtmlHintsProvider.computeErrors(HtmlHintsProvider.java:248)
Comment 1 Exceptions Reporter 2011-05-10 19:24:42 UTC
Created attachment 108217 [details]
stacktrace
Comment 2 Marek Fukala 2011-05-11 05:50:35 UTC
Caused by the changeset http://hg.netbeans.org/web-main/rev/4671383c98ab

However in the the web.jsfapi spec version has been increased to 1.15 and the web.jsf.editor dependency updated accordingly.

So I do not understand how this NSME can happen when updating the modules. The web.jsf.editor is apparently in the older version but the web.jsfapi is the latest. Reported, did you do a regular autoupdate or did you fiddle with the modules manually? Or did you build the ide by yourself?
Comment 3 Jesse Glick 2011-05-11 16:25:04 UTC
(In reply to comment #2)
> Caused by 4671383c98ab
> 
> However in the the web.jsfapi spec version has been increased to [1.5] and the
> web.jsf.editor dependency updated accordingly.
> 
> So I do not understand how this NSME can happen when updating the modules. The
> web.jsf.editor is apparently in the older version but the web.jsfapi is the
> latest.

Exactly. You did not push a newer version of web.jsf.editor (or web.jsf), so anyone with an older build will get just the newer version of web.jsfapi, resulting in NSMEs. The immediate fix is to increment the versions of web.jsf.editor and web.jsf, which will avoid the problem for anyone who accepts all updates.

In the future you should anyway avoid making incompatible changes such as removing methods. When they are necessary, it is best to indicate them to the module system by incrementing the major release version, e.g.

OpenIDE-Module: org.netbeans.modules.web.jsfapi/1
                                               ^^

This prevents the user from running mismatched versions, if for example they only accepted certain updates. Then you push new versions of _all_ modules depending on this API. The two which required changes should specify <release-version>1</> in project.xml, as well as requesting the new <specification-version>1.5</> in case they are also using newly introduced APIs. The other three (e.g. web.project) which were not affected by the incompatibility can add <release-version>0-1</> (leaving the older <specification-version>1.0</> or whatever), indicating that they can continue to run with the older _or_ newer API, at least for now.
Comment 4 Marek Fukala 2011-05-13 15:50:11 UTC
(In reply to comment #3)
I didn't realize the bidirectionality of the dependency in the sense of the update center. I was under wrong assumption that if one updates the web.jsfapi to the new version (1.5), the modules depending at the version (web.jsf.editor) will update as well. Now when I think of that I see the foolishness of that idea. Thanks for the help Jesse.

fixed in web-main#809c8d5956bb
Comment 5 Marek Fukala 2011-05-13 15:59:34 UTC
changeset:   198145:288f0cad2bcd
branch:      release701
Comment 6 Jesse Glick 2011-05-19 19:14:53 UTC
(In reply to comment #4)
> fixed in web-main#809c8d5956bb

You neglected to update spec versions of (both kinds of) modules depending on web.jsfapi as part of this change. So, again, anyone getting the new web.jsfapi will find all these modules unloadable.

Also web.project/nbproject/project.xml had a change that looks unrelated - suspicious.
Comment 7 Vladimir Riha 2011-07-25 11:25:50 UTC
Since I have no problem with editing JSF files (*.xhtml and *.jsp), marking as verified...

Product Version: NetBeans IDE 7.0.1 (Build 201107211357)
Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b17
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)