Created attachment 71579 [details]
stacktrace

Build: NetBeans IDE Dev (Build 200810100201)
VM: Java HotSpot(TM) Client VM, 11.0-b11, Java(TM) SE Runtime Environment, 1.6.0_10-beta-b21
OS: Windows XP, 5.1, x86

User Comments: 
Steps to reproduce:
1) Create EJB Module project
2) Goto source packages folder and right click and select properties(NOT project proprties)
3) In the Source packages properties windows change the name field from java to some other name like 1
4) Then add a new WS to this projet

Stacktrace: 
java.lang.NullPointerException
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.updateCreatedFolder(SimpleTargetChooserPanelGUI.java:407)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.actionPerformed(SimpleTargetChooserPanelGUI.java:443)
        at javax.swing.JComboBox.fireActionEvent(JComboBox.java:1240)
        at javax.swing.JComboBox.setSelectedItem(JComboBox.java:567)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.initValues(SimpleTargetChooserPanelGUI.java:136)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanel.readSettings(SimpleTargetChooserPanel.java:147)

Created attachment 71580 [details]
stacktrace

*** Issue 149797 has been marked as a duplicate of this issue. ***

This issue has already 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=121054

Build: NetBeans IDE Dev (Build 200810140201)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc2-b32
OS: Windows Vista, 6.0, x86

User Comments: 
Clicked on new file -> New Webservice from WSDL and got this exception

Stacktrace: 
java.lang.NullPointerException
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.updateCreatedFolder(SimpleTargetChooserPanelGUI.java:407)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.actionPerformed(SimpleTargetChooserPanelGUI.java:443)
        at javax.swing.JComboBox.fireActionEvent(JComboBox.java:1240)
        at javax.swing.JComboBox.setSelectedItem(JComboBox.java:567)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.initValues(SimpleTargetChooserPanelGUI.java:136)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanel.readSettings(SimpleTargetChooserPanel.java:147)

Created attachment 72077 [details]
stacktrace

Build: NetBeans IDE Dev (Build 200810161401)
VM: Java HotSpot(TM) Client VM, 11.0-b15, Java(TM) SE Runtime Environment, 1.6.0_10-rc2-b32
OS: Linux, 2.6.24-21-generic, i386

User Comments: 


Stacktrace: 
java.lang.NullPointerException
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.updateCreatedFolder(SimpleTargetChooserPanelGUI.java:407)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.actionPerformed(SimpleTargetChooserPanelGUI.java:443)
        at javax.swing.JComboBox.fireActionEvent(JComboBox.java:1240)
        at javax.swing.JComboBox.setSelectedItem(JComboBox.java:567)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.initValues(SimpleTargetChooserPanelGUI.java:136)
        at org.netbeans.modules.project.ui.SimpleTargetChooserPanel.readSettings(SimpleTargetChooserPanel.java:147)

Created attachment 72093 [details]
stacktrace

This issue has already 10 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=121054

Created attachment 74696 [details]
stacktrace

*** Issue 158409 has been marked as a duplicate of this issue. ***

Fixed: http://hg.netbeans.org/main/rev/eb56cc65aab7

I've enhanced the fix with secondary check for null directly in place where the NPE was throwing. Based on discussion
with mkubec this secondary fix is not that much necessary, but it should go to a patch in which higher assurance that
the NPE does not throw again is better. Especially in this case where we are not able to reproduce the bug.

http://hg.netbeans.org/main/rev/ced42c07a494

"if (root == null) return;" should be deleted or replaced with an assertion "assert root != null : sg;", since it is
illegal for a SourceGroup to ever return null from this method.

Yes, seems to have been fixed in build 200902121452.

Integrated into 'main-golden', will be available in build *200902180201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/ced42c07a494
User: Rudolf Balada <rbalada@netbeans.org>
Log: #149798: [65cat] NullPointerException at org.netbeans.modules.project.ui.SimpleTargetChooserPanelGUI.updateCreatedFolder

Does this mean the fix will be deployed via on-line updates in the next few days ? (Help -> Check for Updates) 

I marked it as patch 3 candidate. QE will evaluate if it is possible, but the patch seems to be easily backported.

Regards

Fixed in release65_fixes: http://hg.netbeans.org/release65_fixes/rev/3bac919fd9d7

Reopening.

The bugfix fixes a result, not it cause.

The root cause seems to be "strange" project configuration. I was able to reproduce this issue even with this fix.

The steps to reproduce are:

#1 install NetBeans 6.5 (full, or at least with java web support)
#2 create new web application project (you can use defaults offered)
#3 right-click on project node and select "Properties" from the context menu
#4 remove all source directories listed and click OK
#5 right-click on project node and create New Webservice

And the exception is thrown, red icon blinking in bottom right corner of your IDE. It may but must not behave
differently if you remove also test directories.

Suggested workaround:
Try to keep one source root and one test source root.
For creating a project with existing source if it does not work for you, create new empty web application project and
reconfigure source roots.

The fix actually has to happen in web module, in a class (Sources.java) which is responsible for recognizing source root
from test source root.

This issue could be in very wild and happening also for other project types as that routine for recognizing source root
from test source root was copy&pasted in several projects and that routine does not work well for project configurations
which deviate from "one source root and one test source root" configuration. IMHO it uses strange logic/assumption
covering just major cases and leaving corner cases in jeopardy.

The "strange" project configuration that you describe is perhaps no that unusual.

In my older NetBeans projects java source files are located at:
<project directory>/src
The directory which is now favoured for java source
<project directory>/src/java
does not exist

Is this the root cause of the problem ?

Very likely. 

Because the NPE was thrown when attempting to retype result of SourceGroup.getRootFolder() method to FileObject
instance. When the directory does not exist on filesystem, its FileObject instance in NetBeans for it cannot exist as well.

I found that when trying to reproduce the issue and tracking the project behavior during resolution of the escalation
with Sun Support Services.

I'm still working on the fix, but at least we have got workaround.

The last comment from rbalada was reproduced in Product Version: NetBeans IDE 6.5.1 (Build 200902270001). 

@mkubec, how does it look like with this issue? Are you going to do something about this for 6.5.1? There is a
workaround so not a stopper for 6.5.1 but I can't verify in this state. 

Thanks. 

fzamboj,

reassigning to me as I tracked the issue to root cause. Unfortunately it may require changes in multiple projects. Also
the fix may require "hacking" as there's no explicit marking which source group is "simple" source group or "test"
source group (or other kind of source group).

I'm considering to check SourceGroup.<something>.Name starts with "${src." or "${test.", but it's ehm bit ugly and may
not work for all project types existing now or in future. But this may help in 6.5 context.

OK. So does that mean it is not safe to backport to 6.5.1 and we leave this issue to 67M3? In my opinion this a P3,
partially fixed so it shouldn't harm in 6.5.1 as it is now and you can come up with a good (and tested) solution for M3.
Would that be ok? 

Thanks. 

verified. This bug was partially fixed and there is workaround for it. However, there is a bug reported by rbalada. So
closing this one and opening another based on rbalada report.