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.
I have 36 projects opened: 2 EARs: first have 14 EJB modules, second 13 4 J2SE projects: Swing client and some libraries. There is about 150 entities, 200-250 session beans and about 10 MDBs. After startup, when Scanning classpaths disapears, 100% CPU load is for 15-20 min. Configuration: P4 2.8GHz, 1.3GB RAM, Windows XP Prof.
*** Issue 82395 has been marked as a duplicate of this issue. ***
I found that on startup even if NNListener instance was known, it was not always used directly, but there was iteration over all listeners and checking of classpath from cache and so on... I made some VERY primitive measurement. On my machine opening (opening + later CPU load) of 2 EARs, 22 EJBs ans 1 WAR took 53 seconds. After applying simple patch the time decreased to 40 seconds. I hope this is good start for performance enhancements. Can somebody else try to measure this too? http://j2ee.netbeans.org/source/browse/j2ee/metadata/src/org/netbeans/modules/j2ee/metadata/NNMDRListener.java?r1=1.1.2.26&r2=1.1.2.27
is this related? http://www.netbeans.org/issues/show_bug.cgi?id=83250
Next enhancement: stripped classpath is used (not using app server libraries) for 'find usage' of annotations. On my sample project, now CPU is down immediately after projects are open. Opening of the projects takes about 24s.
Created attachment 33272 [details] Commit log for 'stripped classpath' in EJB modules
wulgar, can you please make measurement with new daily build? I am not sure when are daily builds created, but for sure this change will be present in 20060826. Thanks.
Starting NB is a pleasure now. But when I open entity class it does change nothing. 100% CPU for 5 min.
OK, nice to hear :-) I'll fix also JPA and Web annotation parsing, now only EJBs are done.
Now I realized the fix is not correct. Classpath for resolving of types should not be stripped. It means that we will be back in bad numbers.
while fixing this issue you seem to have broken the spi in a non-compatible way by itroducing the getMetadataUnit() method to EjbJarImlementation. The change was never submitted to apireviews. please rollback. while being generally a bad practise, it also breaks 3rd party modules. see http://jira.codehaus.org/browse/MEVENIDE-452.
Cau Milosi, since this is a friend API, we did not realize the Maven module was using it. Martin is now working on addressing this issue - please wait until he has the final solution for it, and then we will decide whether this change will be rolled back, or whether some API change is needed. Thanks.
cau, the maven support is not friends with anyone :) EjbjarImplementation interface is in an api module with public packages. It's there since 4.1 or 5.0 times.
EjbJarImplementation is not in public api module. Check http://www.netbeans.org/download/dev/javadoc/org-netbeans-modules-j2ee-api-ejbmodule/architecture-summary.html It doesn't have explicit list of friends, but the API's stability is marked as friend and there is no guarantee that nothing will be changed.
oh well, I give up. just a side note: noone reads and cares about the stability level in the architecture description document. I even doubt any of the info there is updated after it was initially written. If there's code means to enforce a contract, it should be used. http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#how-vers
Fixed. Please reevaluate. Very special thanks to Tomas Hurka for his help! To API change: that's another story. Let's track it in issue 84646. /cvs/j2ee/metadata/src/org/netbeans/modules/j2ee/metadata/Attic/NNMDRListener.java,v <-- NNMDRListener.java new revision: 1.1.2.35; previous revision: 1.1.2.34
This broke the commit validation. Checking in NNMDRListener.java; /cvs/j2ee/metadata/src/org/netbeans/modules/j2ee/metadata/Attic/NNMDRListener.java,v <-- NNMDRListener.java new revision: 1.1.2.36; previous revision: 1.1.2.35 done
Thanks for fix.
What about this? http://www.netbeans.org/issues/show_bug.cgi?id=84692