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.
The Java EE wizards for creating Enterprise Application, EJB Module and Java Web Application have "Enable Contexts and Dependency Injection" checkbox enabled by default and this results in the creation and inclusion of an empty WEB-INF/beans.xml or META-INF/beans.xml in the archive. As per the CDI spec(JSR 299) section 12.1,inclusion of a beans.xml makes it a bean archive and the container searches for beans in the application classpath. This adds unnecessary deployment time overhead(deployment time and memory footprint impact) for applications that do not use CDI (most applications today do not use CDI). It would be great if - "enable CDI" is not enabled by default and the beans.xml is not included by default in all enterprise applications. - The requirement to include beans.xml is made lazily through the analysis of use of javax.inject annotations in classes in the application classpath or an explicit import and use of javax.inject annotations in the sources of the enterprise application. An issue related to this is at https://glassfish.dev.java.net/issues/show_bug.cgi?id=11668
As a clarification, is this behavior suggested as a temporary workaround for GlassFish bug https://glassfish.dev.java.net/issues/show_bug.cgi?id=11668, or as a permanent solution? One thing that is not clear to me is the exact workflow for adding beans.xml when javax.inject is introduced. Say I have an application that does not use CDI, and then I open a Java file and type: import javax.inject.*; What should happen at this point?
When I enabled CDI by default in all NB EE projects I assumed that "bean discovery" process is cheap and works similar as EJB or servlets discovery. After re-reading the CDI spec and http://seamframework.org/Documentation/WhatIsBeansxmlAndWhyDoINeedIt I think that: * CDI should be by default off and it is up to user to enable it - there will be more cases when CDI is off than on but this may change in future with adoption of CDI. * I would not include beans.xml lazily based on discovery of CDI API (too magical and not necessary always right, eg. user may intentionally disable CDI in a module) * if source code contains a reference to CDI API and beans.xml does not exist in such project then editor hint could suggest for example "Create beans.xml to enable CDI in this bean archive" hint and such hint would automatically create the file if chosen by user That's long term solution (next 6-12 months). In order to minimize impact of memory waste in current CDI impl (eg. https://glassfish.dev.java.net/issues/show_bug.cgi?id=11668) we should try to push this change to NB69 if it is not too late. Opinions?
Created attachment 99462 [details] patch of the fix Fix is safe and regression free.
Thanks - looks good and can be put into 6.9 IMO. The remaining part is to do the editor hint (that would not go to 6.9 though).
(In reply to comment #1) > As a clarification, is this behavior suggested as a temporary workaround for > GlassFish bug https://glassfish.dev.java.net/issues/show_bug.cgi?id=11668, or > as a permanent solution? This was suggested as a permanent solution. This would also prevent scenarios like 11668 happening more often. In 11668, a large Wicket application that was not using CDI had beans.xml and had an OOM on redeploy. > One thing that is not clear to me is the exact workflow for adding beans.xml > when javax.inject is introduced. Say I have an application that does not use > CDI, and then I open a Java file and type: > import javax.inject.*; > What should happen at this point? Ideally, only on first "use"(not "import") of a CDI annotation should we add beans.xml to the archive. However if that is difficult, a simpler fix would be to add beans.xml when a CDI annotation has been imported in a source file in the enterprise application archive. Thanks.
(In reply to comment #2) > When I enabled CDI by default in all NB EE projects I assumed that "bean > discovery" process is cheap and works similar as EJB or servlets discovery. > After re-reading the CDI spec and > http://seamframework.org/Documentation/WhatIsBeansxmlAndWhyDoINeedIt I think > that: > * CDI should be by default off and it is up to user to enable it - there will > be more cases when CDI is off than on but this may change in future with > adoption of CDI. > * I would not include beans.xml lazily based on discovery of CDI API (too > magical and not necessary always right, eg. user may intentionally disable CDI > in a module) Ok, I agree. > * if source code contains a reference to CDI API and beans.xml does not exist > in such project then editor hint could suggest for example "Create beans.xml to > enable CDI in this bean archive" hint and such hint would automatically create > the file if chosen by user Yes, this would help. By refer a CDI api, I am assuming you mean use of a CDI annotation, defining an Alternative,Interceptor,Decorators etc. If yes, this would be perfect. If an enterprise application uses CDI and a beans.xml file does not exist in the project, it would be great if netbeans could throw a WARNING indicating that. This is in addition to the source-code hint. Thanks again for partially handling this issue in 6.9 timeframe! > That's long term solution (next 6-12 months). In order to minimize impact of > memory waste in current CDI impl (eg. > https://glassfish.dev.java.net/issues/show_bug.cgi?id=11668) we should try to > push this change to NB69 if it is not too late. > > Opinions?
Committed to trunk per agreement with Martin S, following the HR process to put it into 6.9. http://hg.netbeans.org/web-main/rev/7fa9e61b867e
Verified in the trunk build by QE.
Transplanted to 6.9: http://hg.netbeans.org/release69/rev/3ce5352e179e
Integrated into 'main-golden', will be available in build *201005280001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7fa9e61b867e User: pjiricka@netbeans.org Log: #186650 - changing the default for enabling CDI to false when creating a new project.
v.