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.
After update to the latest NetBeans binary (build 200703211900), Visual Web framework is no longer working! It got the attached exceptions. To reproduce it, 1. download Visual Web zip files or pack installer from http://clue.sfbay.sun.com//kits/rave/visualweb/Build070321_13/ under NetBeans binary build 200703211900. 2. Create a visual web project by, File -> New Project -> Web -> Web Application -> (project name, server, ...) -> (Next) -> Under Frameworks page, check 'Visual Web JavaServer Faces' -> (Finish)
Created attachment 39831 [details] Exceptions I got
Created attachment 39832 [details] Sometime I got different but similar exceptions
An easier way to debug visualweb under NetBeans workspace: Under NetBeans source root, 1. cvs co visualwebstandard 2. cd visualweb/ravebuild 3. ant 4. cd rave/build 5. nb.exe Then debugging both NetBeans and Visualweb will be simple.
Milan Kuchtiak wrote: > Seems that libraries are added to the project and probably Project is being > saved multiple times. > Please, can you describe the steps to reproduce. I finally can reproduce this fatal showstopper by creating a NetBeans web project with JavaServer Faces framework enabled. When adding framework, Visual Web framework needs to add several libraries to the project not like the other lightweight framework that only 1 or 2 libraries are involved. Therefore, I make the NetBeans web project 'JavaServer Faces' framework add more libraries to reproduce this symptom. I.e., I modify org.netbeans.modules.web.jsf.JSFFrameworkProvider.extend() to: ... try { cpExtender.addLibrary(jsfLibrary); cpExtender.addLibrary(jsfLibrary); Library jstlLibrary = LibraryManager.getDefault().getLibrary("jstl11"); if (jstlLibrary != null){ cpExtender.addLibrary(jstlLibrary); cpExtender.addLibrary(jstlLibrary); } ... Then when I create a NetBeans web project + JSF framework, I got the same fatal error. (exceptions attached)
Created attachment 39838 [details] When NetBeans web JSF framework add more libraries
*** Issue 98704 has been marked as a duplicate of this issue. ***
I can reproduce it only with JDK 1.5, with 1.6 it works fine.
Seems that WebProjectClasspathModifier calls the ProjectManager.saveProject multiple times when a web project is being created. We did nothing with GeneratedFilesHelper recently.
Created attachment 39863 [details] I put the dumpStack into GeneratedFilesHelper:generateBuildScriptFromStylesheet() method
I think the problem is more complicated. The project is saved very often because of the fix for issue #56140. It is bad and it should be optimized. But the real problem is in my opinion in refreshing build script when project is saved (org.netbeans.modules.web.project.WebProject$ProjectXmlSavedHookImpl.projectXmlSaved(WebProject.java:634)). If JAX-WS needs to refresh it, it should be done only when it is necessary. I don't see any reason to do it when a project is created, library added or library modified.
Not a real fix but the problem should not appear so often, hopefully - little bit optimized project saving and refreshing build script postponed about two seconds. Hopefully this can at least little bit help for milestone 8 but need to be reviewed and fixed by a better way in milestone 9. I wouldn't say the problem is related to WebProjectClassPathModifier. It was implemented on March 14 and the problem appeared on March 21 when changes in GeneratedFilesHelper were done. WebProjectClassPathModifier do almost the same as previous version of WebProjectClassPathExtender. Rico, could you verify that there is no problem in GeneratedFilesHelper, please? I'm attaching the exception thrown when this fix was applied. Checking in classpath/WebProjectClassPathModifier.java; /cvs/web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathModifier.java,v <-- WebProjectClassPathModifier.java new revision: 1.2; previous revision: 1.1 done Checking in WebProject.java; /cvs/web/project/src/org/netbeans/modules/web/project/WebProject.java,v <-- WebProject.java new revision: 1.108; previous revision: 1.107 done
Created attachment 39897 [details] Exception thrown when the fix was applied
> Rico, could you verify that there is no problem in GeneratedFilesHelper, please? Yes, please! Sanity tests in visualweb build are still seeing this exception almost every build.
I locally rollbacked the changes related to WebProjectClassPathModifier and I'm still able to reproduce this problem with the old implementation of WebProjectClassPathExtender. That's why I believe the problem is related to the changes in org.netbeans.modules.websvc.api.jaxws.project.GeneratedFilesHelper which were done on March 21. Attaching a stack trace without WebProjectClassPathModifier.
Created attachment 40041 [details] Exception thrown with the old implemantation of WebProjectClassPathExtender
> That's why I believe the problem is related to the > changes in org.netbeans.modules.websvc.api.jaxws.project.GeneratedFilesHelper > which were done on March 21. Yes, I can confirm that the visualweb sanity test started to fail (~90% failed because of this issue) exactly after importing NetBeans March 21 binary.
One more comment: regarding to issue #98704 (which was closed as a duplicate of this issue) and regarding to my investigation this issue is random when creating web project just with JSF or Struts framework.
Hi Potingwu, are you able to reproduce the bug in 100% on more computers and also manually? In case the bug isn't 100% reproducible it seems like no P1 since there are no data lost and we will not assume the bug as stopper in Milestone 8.
PoTing is out of the office today. The issue can be reproducible manually intermittently but quite frequent. Our QE team is going to verify (again) if this bug is still a showstopper since Po-Ting had put in a workaround for it. We'll let you know.
I made some changes in web project and webswc/jaxwsmodel. Please test this patch.
Created attachment 40097 [details] org-netbeans-modules-web-project.jar
Created attachment 40098 [details] org-netbeans-modules-websvc-jaxwsmodel.jar
I'm still seeing this exception after applying your patch! I'm not sure whether it's less frequently or not. But after few project creations, I have seen it 2 or 3 times.
Po-Ting, kindly describe the steps to reproduce this. I followed the steps described earlier in this bug but have been unsuccessful in reproducing it. Thanks. Rico
Please see my reproduce steps at "Thu Mar 22 19:34:36". You can reproduce it easier when the framework adding more libraries. Therefore, I add more libraries in NetBeans JSF framework and make the exceptions easier to appear. I.e., I modify org.netbeans.modules.web.jsf.JSFFrameworkProvider.extend() to: ... try { cpExtender.addLibrary(jsfLibrary); cpExtender.addLibrary(jsfLibrary); Library jstlLibrary = LibraryManager.getDefault().getLibrary("jstl11"); if (jstlLibrary != null){ cpExtender.addLibrary(jstlLibrary); cpExtender.addLibrary(jstlLibrary); } ...
Found this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5056688
This has been removed from the showstopper list see: http://www.netbeans.org/issues/show_bug.cgi?id=99045. Also, this does not happen in JDK 1.6. The xsl script was changed significantly on March 21. From the explanation in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5056688, there was a problem in JDK 1.5 where large xsl scripts exhibited this problem. This may explain why this does not happen in JDK 1.6.
*** Issue 99552 has been marked as a duplicate of this issue. ***
I closed issue #99552 as a duplicate of this issue. While investigating that issue I got the attached exception and build-impl.xml regenerate dialog was shown. Created project contained an empty build-impl.xml.
Created attachment 40206 [details] regenerate dialog
Created attachment 40207 [details] Exception thrown while investigating issue #99552
Radko, cud not find any attached file. Was it the same transformer error as previously described or is it a different error? Kindly attach the exception that you got. Thanks.
Since yesterday, 03/29/2007, this issue becomes more serious! It's not only dumping the exceptions, but also display >2 dialogs showing 'build-impl.xml regenerate'. Then the created project contained an empty build-impl.xml. As I seen from the comments that this may be a JDK bug. But we should try to not trigger it as we did before 03/21. Thanks!
The build-impl.xsl file of the web project was modified again which made it an even larger file. Looking at this closely and will let you know.
This is what I did to confirm the "size" theory (and clear particulars from REST script section): (1) I tried removing the 25 lines that I added on 3/30. This does make the IOException go away. (2) Then I added about 30 line of dummy: <echo>Fooling around with size ${{what.is.size.limit}}</echo> in some target. This recreate the IOException. Rico is trying TransformationFactory option to not inline templates. If this does not work, I think we have other options: #1: temporary solution: clean up build-impl.xsl to reduce size. #2: partition the xsl using import mechanism. I guess the build script extension framework is not ready for M9?
Fixed. The problem was that the main template became very large. Since each template in the xsl script was generated into Java methods, it came to a point where the generated Java method for the main template exceeded the 64K limit for methods in the JVM. I fixed this by refactoring the build-impl.xsl script to reduce the size of the main template. The script for calling wsimport now invokes a template which takes care of the different permutations of the options passed in to wsimport, i.e., jaxws 2.1 vs. 2.0, jsr109 vs. non-jsr109, etc.
btw, xalan in JDK 1.5 was not inlining all the templates into one method. It was 1 template to 1 method. The problem was that the method exceeded 64K. So passing the inlining attribute to the TransformationFactory was not the solution.
Created attachment 40242 [details] Diff file of build-impl.xsl for fixing 98703
I'm glad that this is now fixed. In which NB build that has the fix? Thanks.
This was fixed around 1 a.m. April 2 PST, so any build after that will have this fix.
Reopening because of the following comment I sent to cvs@web.netbeans.org and to which I got no reply: Not very well visible from the text diff, but you have: <xsl:variable name="jaxws21_var"> <xsl:choose> <xsl:when test="$jaxwsversion = 'jaxws21lib'"> <xsl:value-of select="true()"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="false()"/> </xsl:otherwise> </xsl:choose> </xsl:variable> which looks overcomplicated. Can't you just <xsl:variable name="jaxws21_var" select="$jaxwsversion = 'jaxws21lib'"> ? Also, in the invokeWsimport template, which the jaxws21_var variable is passed to, you have: <xsl:if test="$isJaxws21 = 'true' and $isJSR109 = 'true'"> Since these variables contain boolean values, can't you just <xsl:if test="$isJaxws21 and $isJSR109"> ? Why is the conversion to string necessary?
OK will implement these improvements. Thanks.
Original issue is fixed => P3
Fixed. Diff: http://web.netbeans.org/source/browse/web/project/src/org/netbeans/modules/web/project/resources/build-impl.xsl?r1=1.129&r2=1.130