I was able to reproduce the bug on a maven NB 7.3 project.

Create new Maven enterprise application project
try to add framework - this will work, cancel this step

Then open pom of web application and "destroy" it -e.g. by adding

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>     
</dependency>

Save pom, project becomes unloadable.
Add missing values and save again, project is valid again

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>     
  <version>4.10</version>       
  <scope>test</scope>
</dependency>

Try to add framework - this will lead to the error

Created attachment 134115 [details]
Enterprise Application with error

Workaround: I have added the framework using NB 7.2.1. Afterwards I was able to continue editing using NB 7.3

Forum thread with same issue: http://forums.netbeans.org/viewtopic.php?p=146758#146758

Issue is reproducible. JSF panel doesn't find any document root and complains about that fact by the error mentioned by jomu.

I debug the WebModuleImpl of the maven module and it looks that before the save of the broken pom.xml the project has documentRoot as usually, after the save one source disappear (the one defining TYPE_DOC_ROOT) and the web project becomes broken.

I believe the problem is a little bit deeper. From what I understand, the current behavior is following:

- For the new Maven Web project the LookupProviderSupport.SourcesImpl.getSourceGroups() returns correctly SourceGroup's from two registered Source's (general one MavenSourcesImpl and additional J2eeMavenSourcesImpl registered via @PSP annotation for War packaging) --> this is correct

- When breaking the project (using incomplete dependency) LookupProviderSupport.SourcesImpl.resultChanged() is called, it clear these two Source's and when the getSourceGroups() is called again, it return SourceGroup's from one registered Source (only the general one) --> this is correct because the pom is broken, we don't know packaging and thus War packaging services registered via @PSP shouldn't be present

- When fixing the project (completing dependency) LookupProviderSupport.SourcesImpl.resultChanged() is not called --> this does not seem to be correct as the Lookup should have changed (the packaging type has changed and we have to add additional services registered via @PSP for that type)

..reassigning to Project component for evaluation. Not sure who is responsible for calling resultChanged() in cases when only lookup difference is caused by @PSP ..if it's Project API job or Lookup itself.

org.netbeans.spi.project.support.DelegatingLookupImpl.doDelegate() method is crucial here.

1. initially both PSP instances are created on line 130

2. both their org.netbeans.modules.projectapi.LazyLookupProviders.forProjectServiceProvider()->.beforeLookup() methods are called.

when I change packaging from war to jar the Sources merger result gets changed. Correct, the j2ee impl lookup was removed.

when I change the packaging back to war
1. the j2ee PSP instance is created on line 130
2. BUT the before lookup method is not called.

I don't have an explanation for that yet, but the lookup merger is listening on changes in the right result, so either that is not working or we have some timing issue someplace with the various levels of proxy lookups someplace.

a workaround is to restart the IDE after the problem appears

related to issue 230469 maybe.

probably related to issue 210481 and issue 209322

reverting changeset http://hg.netbeans.org/main-golden/rev/548e5aad22d6 from issue 210481 appears to fix our issue, not sure *if* the stack overflow can appear again. It didn't for me.

please evaluate  (could be related it issue 232400, but not duplicate).

the problem in org.netbeans.spi.project.support.LookupProviderSupport.SourcesImpl is that the instance doesn't get notified of changes.

delegates = lookup.lookupResult(Sources.class);
delegates.addLookupListener(this);

*** Bug 225754 has been marked as a duplicate of this bug. ***

*** Bug 234389 has been marked as a duplicate of this bug. ***

(In reply to Milos Kleint from comment #11)
> please evaluate  (could be related it issue 232400, but not duplicate).

Issue 232400 was reproducible by enabling new (e.g. JavaEE) modules and that part was fixed. However I don't see anything related to changing state of modules in this issue. As such I don't believe it is related to fix made for 232400 at all. 

If I am confused and there is some change in module state in this bug, please point that out and assign back.

I haven't primarily reassigned because I believe it's a duplicate caused by the same code as issue 232400, I reassigned because the issue is a reproducible scenario where having a proxylookup delegating to multiple forPath() lookups fails to notify of changes in the lookup content for results obtained before the switch. Since I assumed the problem is not in proxylookup itself, it has to be somewhere in the forPath() code. That's why I reassigned.

OK, reproduced the scenario described in comment 1.

I believe the LazyLookupProviders ProxyLookup subclass is written a bit incorrectly. It will never notify any change by itself, it relies on somebody else to query it. That is not correct. It might have worked before issue 209322 was integrated (the ProxyLookup always recomputed completely), but it was more an accident than by design.

I'll see if I can come up with some solution.

Created attachment 139493 [details]
Solves the problems with missing source root

While the previous patch is not polished, it seems to fix the problem with missing J2ee source root. It tries to enforce refresh (previously done in beforeLookup) whenever the list of lookups we delegate to changes.

Possibly problems: 
1. some hook is instantiated more than once due to the forced refresh.
2. the refresh is done from synchronized block (as setLookups), which is potential reason for deadlocks

But I hope Miloš will be able to deal with it now, when the internal Lookup issues seem to be overcome.

(In reply to Jaroslav Tulach from comment #19)
> While the previous patch is not polished, it seems to fix the problem with
> missing J2ee source root. It tries to enforce refresh (previously done in
> beforeLookup) whenever the list of lookups we delegate to changes.
> 
> Possibly problems: 
> 1. some hook is instantiated more than once due to the forced refresh.


That's more or less a deal breaker. Do I understand it correctly that the user-space instances in @psp are now re-instantiated everytime some event comes around (new module enabled, change of packaging?, etc). That's about to change the semantics of the project lookup and will definitely break things. like ProjectOpenedHook and others.
It's ok to discard instances associated with "war" packaging when the project is no longer "war" project. However the basic maven user-space instances need to persist across changes in the lookup.

Maybe we should abandon the whole lazy loading charade and just have plain Lookup.fixed() for all instances registered via @psp. Would changing the packaging (and thus lookup content) work then?

(In reply to Milos Kleint from comment #20)
> (In reply to Jaroslav Tulach from comment #19)
> > While the previous patch is not polished, it seems to fix the problem with
> > missing J2ee source root. It tries to enforce refresh (previously done in
> > beforeLookup) whenever the list of lookups we delegate to changes.
> > 
> > Possibly problems: 
> > 1. some hook is instantiated more than once due to the forced refresh.
> 
> 
> That's more or less a deal breaker. Do I understand it correctly that the
> user-space instances in @psp are now re-instantiated everytime some event
> comes around (new module enabled, change of packaging?, etc). That's about
> to change the semantics of the project lookup and will definitely break
> things. like ProjectOpenedHook and others.
> It's ok to discard instances associated with "war" packaging when the
> project is no longer "war" project. However the basic maven user-space
> instances need to persist across changes in the lookup.
> 
> Maybe we should abandon the whole lazy loading charade and just have plain
> Lookup.fixed() for all instances registered via @psp. Would changing the
> packaging (and thus lookup content) work then?


I've tweaked to patch to just create the instance once per lookup (eg. global maven stuff is created once and the per packaging stuff is re-created on packaging change)

However I've also tried to just remove the entire lazy loading code and replace
it with Lookups.fixed() in @psp annotation processor. since both refresh() and createAdditionalLookup() are called on the same set of @psp instances, it's more or less the same effect with fairly less code.

mjanicek has come up with a harm reduction strategy: maintain the packaging (and thus the lookup associated with it) while the project is unloadable by transferring it from the old, correct maven instance.

http://hg.netbeans.org/core-main/rev/a6f8b3a1302f

mjanicek: please verify that the fix indeed works and we can backport to release74 branch then

What is the purpose of MavenProjectCache.isFallbackproject? The original NbMavenProject.isErrorPlaceholder seems more direct and reliable.

Great, the fix works correctly and seems to be safe. Thanks Milosi!

Ok, I will file a HR commit request.

Integrated into 'main-silver', will be available in build *201309050001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/a6f8b3a1302f
User: Milos Kleint <mkleint@netbeans.org>
Log: #229366 harm reduction bugfix - attempt to carry over packaging value from previously loaded MavenProject if the current one is broken, chances are the user will eventually fix the problem and this way packaging (and lookup) stays the same.

http://hg.netbeans.org/releases/rev/41581cb9229b

downgrading to P3, as the workaround applied to release74 branch significantly reduces the likelihood of the occurrence of the problem.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss