Web Module getDocumentBase() Returns null

[bill-humblcloud]

Apache NetBeans version

Apache NetBeans 28 latest release candidate

What happened

When loading my web app projects (which use a small subset of EE technologies) a NullPointerException is thrown when attempting to load the webapp components. As such, those components are not directly accessible in NetBeans. Here is the stacktrace...

java.lang.NullPointerException: The file parameter cannot be null
	at org.openide.util.Parameters.notNull(Parameters.java:64)
	at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:889)
	at org.netbeans.modules.gradle.javaee.web.WebModuleImpl.getDocumentBase(WebModuleImpl.java:90)
	at org.netbeans.modules.web.api.webmodule.WebModule.getDocumentBase(WebModule.java:127)
	at org.netbeans.modules.web.jsf.api.facesmodel.JsfVersionUtils.get(JsfVersionUtils.java:238)
	at org.netbeans.modules.web.jsf.api.facesmodel.JsfVersionUtils.forWebModule(JsfVersionUtils.java:99)
	at org.netbeans.modules.web.jsf.hints.JsfHintsContext.<init>(JsfHintsContext.java:42)
	at org.netbeans.modules.web.jsf.hints.JsfHintsUtils.createJsfHintsContext(JsfHintsUtils.java:63)
	at org.netbeans.modules.web.jsf.hints.JsfHintsUtils.getOrCacheContext(JsfHintsUtils.java:53)
	at org.netbeans.modules.web.jsf.hints.rules.JakartaFacesBeanIsGonnaBeDeprecated.run(JakartaFacesBeanIsGonnaBeDeprecated.java:92)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
[catch] at org.netbeans.modules.java.hints.providers.code.CodeHintProviderImpl$WorkerImpl.createErrors(CodeHintProviderImpl.java:306)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.runHint(HintsInvoker.java:721)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.runAndAdd(HintsInvoker.java:596)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:615)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:562)
	at com.sun.source.util.TreeScanner.scan(TreeScanner.java:110)
	at org.netbeans.api.java.source.support.CancellableTreePathScanner.scan(CancellableTreePathScanner.java:78)
	at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:118)
	at com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:151)
	at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:627)
	at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:66)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker$ScannerImpl.scan(HintsInvoker.java:640)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHintsImpl(HintsInvoker.java:240)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:224)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:191)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:166)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:128)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:111)
	at org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:62)
	at org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:273)
	at org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:288)
	at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702)
	at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
	at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1403)
	at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
	at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
	at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2018)

Language / Project Type / NetBeans Component

Gradle "war" project created from command line

How to reproduce

Happens on load of any of my "war" projects

Did this work correctly in an earlier version?

Apache NetBeans 27

Operating System

Mac OS X version 15.7.1 running on aarch64; UTF-8; en_US (nb)

JDK

25.0.1; OpenJDK 64-Bit Server VM 25.0.1 from homebrew

Apache NetBeans packaging

Other

Anything else

I am using the "NetBeans macOS Bundle" tool to package the macOS app directly from the 28-rc2 download link.

Are you willing to submit a pull request?

No

[matthiasblaesing]

Please provide real steps to reproduce. I opened a war project yesterday with a more or less recent master build and that worked nicely.

[mbien]

As such, those components are not directly accessible in NetBeans.

I am not completely sure what this means but based on the stack trace and the way the exception is caught it is "just" a editor hint failing. Although a bug, this should not affect anything outside of the light bulbs not updating. (edit: added #8982 so that one failure does not influence other hints)

It might not be the right exception for the symptom. Reproducer would be great, full log file too in case there are other exceptions in it.

[bill-humblcloud]

I've been working on reproducibility on rc2, but short of sending one of my projects, I am not really finding a way to make something that is useful to you. I have found 2 things as I've been working on this:

1. Removing [project-dir]/.gradle/nb-cache eliminates the issue
2. The build associated with fixing 8960 also appears to me to eliminate the issue

So, my thinking is that this has been addressed elsewhere and this issue should be closed.

I am seeing another issue both with rc2 and the 8960 build and that relates to not seeing the "Web Pages" item in the Projects pane (which I described poorly in my report as the "components are not directly accessible in NetBeans". This seems to be related to the following:

the return value of "org.netbeans.modules.gradle.javaee.api.GradleWebProject.getWebAppDir()" is null

...which I think should be reported as a separate issue, right? It seems different enough to me to make a new issue unless you think otherwise. Thanks for the time and effort you've spent on this.

[bill-humblcloud]

I appreciate the attention people have given to this issue. Thank you.

I believe I've broadly figured out what is going on. If I run NetBeans 27, 28-rc2, or a daily build using Gradle 8.14.3 on JDK 24, everything works perfectly. The issue of "Web Pages" not appearing in the "Projects" pane occurs on all platforms if I attempt to use Gradle 9.x.x on JDK 25. I believe this problem is related to the original issue I raised.

My best guess is that when NetBeans instantiates GradleWebProjectBuilder against a Gradle 9.x.x project, it is not getting the webAppDirName property from Gradle. While I looked, I couldn't discern from where in the code base GradleWebProjectBuilder is invoked, so I couldn't confirm this hunch further.

Regardless, this seems to be a Gradle 9.x.x compatibility issue, which I assume is on someone's radar and is probably not part of the plans for the NB 28 release. This issue, therefore, can be safely closed. Thanks, again.

[wrprice]

Can reproduce the NPE with a skeleton project on Gradle 9.x, though in my case I trigger it through something other than the hint code. Does not occur w/ the same skeleton project when the project's Gradle wrapper is downgraded to 8.13.

It appears that in GradleWebProjectBuilder#build() most of the info property keys have changed, and I have not confirmed if any of the values' object types changed, either. A quick diff suggests:

• webapp_dir -> war.webAppDirectory
• webxml -> war.webXml
• web_classpath -> war.classpath
• main_war -> war.archiveFile
• exploded_war_dir seems to remain available

gradle9warproject.zip

[lkishalmi]

Thank you! Will be addressed in NB29.