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.
See issue 81154, comment: ------- Additional comments from tslota Mon Aug 21 17:45:39 +0000 2006 ------- Steps to reproduce are the same, but just opening the EJB project is enough. Andrei is on vacation, right? I will try to handle this. If you are here Andrei and want to handle it yourself, just reassign ;)
Actually this might be bug in the j2eeserver according to stacktrace. This bug is easily reproduced also with application client (and probably with web project as well). The problem is that in ProjectOpenedHooks project types call J2eeModuleProvider.ConfigSupport.ensureConfigurationReady(). So it depends under what conditions is JMP.CS.eCR() supposed to be called. Javadoc is not clear. Please evaluate and possibly fix or reassign back and it will get fixed in all project-types. Thanks.
I'm not certain there is a j2eeserver bug here, though there might be. ensureConfigurationReady() is being called correctly. It's that initConfiguration() is being called with invalid values down line due to the issue with the configuration folder. Blueprints would like that NetBeans support projects that do not even have a configuration folder (let alone any configuration files). Note that the project still must define where this folder would go, if it did exist (e.g. the "meta.inf" property for ejb jar projects). I don't see a problem with this in general, though I know there are a number of areas that are coded with the expectation that the directory does exist and that is what the popup message is trying to say.
Weird, this works for me. Does anyone have *reliable* steps to reproduce? Could this be related to the recent changes in config handling made by Libor?
No, this issue has nothing to do with Libor's fix. Peter is right, I think. The App Server plug-in needs to know where the server specific DD should go, no matter whether the config folder exists or not. The problem thus seems to be in the EjbJarProvider.getDeploymentConfigurationFile() method. Reassigning back to the ejbproject component.
Thanks for evaluation Stepane. You are right - even javadoc says so. Application client is broken (copy-pasted) as well. I'll check also web project.
Created attachment 33148 [details] patch to review
Review of the patch is welcome if anybody has better insight. This will still throw a minor exception (from "Sun J2EE DD GUI") which I'll file after fixing this one.
The fix seems to me clear and straightforward.
Could the "minor exception from Sun J2EE DD GUI" be fixed when Peter integrates his fix for issue 75710? Regarding the patch, I don't understand this part: return (ejbJar == null) ? EjbJar.VERSION_2_1 /* fallback */ : ejbJar.getVersion().toString(); Don't we want to assume that if there is no DD, then this is EJB 3?
> Could the "minor exception from Sun J2EE DD GUI" be fixed when Peter > integrates his fix for issue 75710? I've did a very fresh build and there is no exception anymore. > Regarding the patch, I don't understand this part: > return (ejbJar == null) ? EjbJar.VERSION_2_1 /* fallback */ : > ejbJar.getVersion().toString(); > Don't we want to assume that if there is no DD, then this is EJB 3? See EjbJarProvider.getEjbJar(), dd == null && version != 5.0 So fixed. Let's open another bugs if they appear since this scenario seems to be not tested so thoroughly. clientproject/nbproject/project.properties; 1.1.4.15 -> 1.1.4.16; clientproject/AppClientProvider.java; 1.1.4.12 -> 1.1.4.13; clientproject/test/unit/AppClientProjectTest.java; 1.1.2.5 -> 1.1.2.6; clientproject/test/unit/AppClientProviderTest.java; 1.1.2.2 -> 1.1.2.3; clientproject/test/unit/test/TestUtil.java; 1.1.2.11 -> 1.1.2.12; ejbjarproject/EjbJarProvider.java; 1.23.36.6.2.6 -> 1.23.36.6.2.7; ejbjarproject/test/unit/EjbJarProviderTest.java; 1.2.4.1.2.4 -> 1.2.4.1.2.5; ....forgot to check the webproject, leaving open....
webproject seems to have a little different logic but is also wrong. Issue 83177.
Is the fix only available as a patch?? I still cannot open the test project from issue 81154!
> Is the fix only available as a patch?? No. See commit log above. For webproject see issue 83177. > I still cannot open the test project from issue 81154! I can. Also written test passes. Could you attach a new exception here?
We talked with Tomasz -> filed 83257. Since this issue may reveal more code which depends on src/conf and/or DD existence, let's fill a new issue according to importance of the found bug.
*** Issue 80086 has been marked as a duplicate of this issue. ***