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.
Summary: | Creating Enteprise Application with Existing sources doesn't work | ||
---|---|---|---|
Product: | javaee | Reporter: | L Martinek <lmartinek> |
Component: | Code | Assignee: | Radko Najman <rnajman> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jchalupa, jlahoda, pjiricka |
Priority: | P1 | Keywords: | REGRESSION |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 63382 | ||
Attachments: |
messages.log
exceptions Trace for the analysis. IllegalStateException. Stack Trace for markExternalOwner if everything goes "OK". Patch that seems to fix the problem. |
Description
L Martinek
2005-08-30 17:17:23 UTC
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. |