Created attachment 24373 [details]
messages.log

reassigning

No first glance kinds of issues visible.

I have removed this assertion, as (a) the message is incorrect -- it is the
resource dir that is null, not the config files dir and (b) I'm not sure it is
necessary.  It may very well be acceptable that resourceDir is null for an EAR.
 I will take that issue up separately.

Marking fixed.

It still throws exception:
java.lang.IllegalStateException: No Project and/or J2eeModuleProvider located
for E:\Projects\import\converter\src\conf\sun-application.xml

Created attachment 24446 [details]
exceptions

Please attach the group of sources that was used to produce this exception.  My
attempts have only caused the wizard to flag the source tree as "not a blue
print application".

Ok, I reread the initial description and noticed the reference to a reproducible
case.  Working on this one now and it will be fixed soon.

I narrowed it down to this line that is failing:

provider = (J2eeModuleProvider)
project.getLookup().lookup(J2eeModuleProvider.class);

I have confirmed that 'project' is in fact the correct project (and of type
EarProject) and that it's constructor fully initialized, which *should* mean
that it's lookup has been fully initialized as well (and includes an instance of
J2eeAppProvider, as it should).  So I don't know why this call is failing.  A
similar call looking for J2eeAppProvider also fails.  I am continuing my
investigation.

Ok.  The reason that J2eeModuleProvider is null is because under the
circumstances where this bug appears, the project instance that the IDE is
returning via FileOwnerQuery is NbProject.  I added some System.out.println's to
demonstrate this and they can be seen if NB is run w/ console visible.  (I tried
to put messages in the log but for some reason that was not working.)  Here's an
example of the output when it fails:

Querying for J2eeModuleProvider:
  FileObject to locate project from is:
MasterFileObject@1b41650[file:/C:/work/cdp_plugin/j2ee/test/qa-functional/data/f
reeform_projects/Secure/src/conf/]
  Project instance of type: org.netbeans.modules.apisupport.project.NbModuleProject
  Lookup query returned: null

I don't know why the project being returned is an NbProject.  The EarProject has
been created at this point.  It may have something to do with the fact that the
actual EarProject is elsewhere on the file system pointing to these source
directories and FileOwnerQuery is merely crawling the directory structure
looking for the first parallel nbproject directory.  This seems like a bug in
FileOwnerQuery to me.

Please have someone in Prague familiar with the peculiarities of this situation
tell me if this should have worked.  I think it should have, but I could be wrong...

Re-assigning...

I am looking into it.

Some notes:
1. Seems to be random (at least on my computer).
2. It seems that if the bug occurs, the getOwner is called before markExternal
(so the external
"j2ee/test/qa-functional/data/freeform_projects/Secure/src/conf/" is not marked
as  part of the newly created project and therefore it is not recognized as part
of it). If the bug does not occur, the methods are called in the correct order
(markExternal, getOwner).

I will investigate further.

I hopefully have some more information, see the attached log:
1.if everything goes OK (this bug does not occur, but see below),
"org.netbeans.modules.j2ee.deployment.config.ConfigSupportImpl.getDeploymentConfiguration(ConfigSupportImpl.java:291)"
is called and then
"org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getSourceFileMap(J2eeModuleProvider.java:210)"
is called, which in turn calls FOQ.markExternalOwner, so the files are correctly
recognized as part of the project.
2. if the bug occurs,
"org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getSourceFileMap(J2eeModuleProvider.java:210)"
is not called, so FOQ.markExternalOwner is not called (soon enough) and this
causes the problem.

So probably something goes wrong after calling
"org.netbeans.modules.j2ee.deployment.devmodules.spi.J2eeModuleProvider.getSourceFileMap(J2eeModuleProvider.java:210)"

Reassigning to J2EE for further evaluation.

Note: by the "bug does not occur" I mean that the project is created (and is OK
on the first sight), but the attached IllegalStateException is thrown. I think
that this should be solved as a separate issue.

Created attachment 24520 [details]
Trace for the analysis.

Created attachment 24521 [details]
IllegalStateException.

Created attachment 24522 [details]
Stack Trace for markExternalOwner if everything goes "OK".

Please, disregard my last comment. It seems that the external roots should have
been marked before the described calls, but they are not for some reason. I will
need to investigate it further.

I have probably found the problem. It seems that it was caused by a weak
listener which wasn't held by a strong reference. I am attaching patch that
seems to fix the problem. The second ISE still occurs, but is probably unrelated
to this problem.

Note: the patch makes EarSources similar to J2SESources, but I think that both
should be improved. It may be also necessary to port "externalRootsRegistered"
flag from J2SESources into EarSources.

Created attachment 24527 [details]
Patch that seems to fix the problem.

Honzo, thanks a lot for the investigation! I see that a similar code pattern as
in EarSources is also present in webproject's and ejbjar-project's
implementations of Sources. This could be a problem too.

BTW, would it make sense to have a common abstract implementation of Sources
that could be reused by all projects implementations, so bugs such as this one
are more easily avoided?

Re: generic implementation: I have created issue #63679 to cover this. Not 100%
sure if some support will be possible.

IMO, also javadoc for SourcesHelper should be corrected to state that the client
should strongly hold the created instance. I will take care about this.

Proposed patch applied.

Checking in EarSources.java;
/cvs/j2ee/earproject/src/org/netbeans/modules/j2ee/earproject/EarSources.java,v
 <--  EarSources.java
new revision: 1.2; previous revision: 1.1
done

Re "generic implementation": Yes, would be nice. Definitely not in NB 5.0 though.

Patch applied also to web and ejbjar projects to prevent potential problems.

Checking in WebSources.java;
/cvs/web/project/src/org/netbeans/modules/web/project/WebSources.java,v  <-- 
WebSources.java
new revision: 1.13; previous revision: 1.12
done

Checking in EjbJarSources.java;
/cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/EjbJarSources.java,v
 <--  EjbJarSources.java
new revision: 1.7; previous revision: 1.6
done

When I verified this issue an exception was thrown so I filled it as issue #64157.