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 am trying to create a new project based on existing ant script for the software DoctorJ (http://sourceforge.net/project/showfiles.php?group_id=36094). After creating the project (I have done everything right, I assume), NB complains about illegal project.xml tag, but that tag looks OK. I can then build the project, but not run. After close and reopen of the project, the name turned to "???" and it's corrupted (no build possible anymore). Using NB 5.0 Beta, JDK 5.0_04.
Could you please attach the content of the nbproject directory of the newly created project? Also messages.log might be helpfull. Thanks.
Created attachment 25837 [details] nbproject
Just created the project again, because I did not find anything in messages.log and there is really nothing in messages.log. This is in output window: cvc-complex-type.2.4.a: Invalid content was found starting with element 'general-data'. One of '{WC[##other:"http://www.netbeans.org/ns/project/1"]}' is expected. Attaching freshly created project.xml.
Created attachment 25840 [details] project.xml
I think that messages.log would be helpfull in this case. The problem seems to be that the project.xml is "serialized" incorrectly (the elements have incorrect namespaces), which may be caused by some bad version of XML writer. BTW: there were a very similar bug recently, will try to find it.
Created attachment 25850 [details] messages.log
Maybe you mean issue #66015?
Nothing obviously wrong in the log. Could you please try to run the IDE on a clean userdir (./netbeans --userdir <some-userdir>)? Thanks.
OK, it does not happen with a fresh user dir and I also found out, why. It only happens, when our own NetBeans Plugin module (Tool plugin) is installed. This module brings its own version of Xerces and Xalan and I guess, that's the problem. Because when I do not include xalan.jar, xercesImpl.jar and xmlParserAPIs.jar in our plugin, then the problem does not happen. Is this forbidden? I could upload the plugin somewhere, if that helps (16 MB).
*** Issue 66015 has been marked as a duplicate of this issue. ***
Yes, that is probably the problem. Thanks for the info. Not sure if it is supported, but there is probably nothing projects can do about it (writing of the XML is done through XMLUtils.write). Reassigning to openide for further evaluation.
tboerkel, what version of xerces&xalan is bundled in your module? I can reproduce the problem with xerces 2.7.1 and xalan 2.7.0 placed in jre/lib/endorsed, as described in issue #66647. Thanks.
If I put xerces 2.7.1 and xalan 2.7.0 into jre/lib/endorsed, the XMLUtil.write produces incorrect project.xml (namespaces are written). Seems to me to be caused by the following commit. Jesse, could you please take a look on it? Please let me know if you need more info. Date: 2005/08/09 04:11:42 Author: jglick Log: Refactoring XMLUtil.write to deal with *part of* #61938 (not enough to make the IDE work under Mustang b46 however): try to use JAXP for serialization whenever possible, i.e. on JDK 1.5+. Members: nbproject/project.properties:1.7->1.8 src/org/openide/xml/XMLUtil.java:1.2->1.3 src/org/openide/xml/XMLUtilImpl.java:1.1->1.2(DEAD) test/unit/src/org/openide/xml/XMLUtilTest.java:INITIAL->1.1
*** Issue 66647 has been marked as a duplicate of this issue. ***
... (namespaces are written incorrectly).
The JDK I tested was "1.5.0_04".
Assuming I can reproduce as well, will probably be INVALID with a link to a Xerces bug report. We just call JAXP to serialize the document, so I suspect it is a regression in Xerces.
I was packaging in my module: Xerces 2.6.2 Xalan 2.6.0
I'm coming from #66647. Releases in the Xerces archive are 2.5.0 (Sep 2003), 2.6.0 (Nov 2003), 2.6.1 (Jan 2004), 2.6.2 (Feb 2004), 2.7.0 (Jun 2005) 2.7.1 (Jul 2005). I have 2.7.1, another user reports 2.6.2. That's a decent sort of a regression. How far back do we have to go?
ant -f openide/util/build.xml test-single -Dtest.includes='**/XMLUtilTest.java' -Dtest.unit.run.cp.extra=/tmp/xalan-j_2_7_0/xalan.jar fails in testNamespaces2. Xerces 2.7.1 does not cause a failure.
However Xalan 2.6.0 appears to have the same bug...
Filed a Xalan bug. Now the question remains whether we can work around it.
Broken only on JDK 1.5 - not 1.4, nor 1.6. We have a workaround for a JDK 1.5 indentation bug which seems to trigger the Xalan bug. If we remove that workaround, everything is still fine on JDK 1.4 and 1.6; on JDK 1.5, namespaces are written correctly but there is no indentation. That would be the lesser of two evils *if* we were bundling Xalan with the IDE, but we aren't. The only thing I can think of is to make XMLUtil.write ignore any JAXP implementations in loaded modules when running on JDK 1.5+. (On JDK 1.4, it has to use Xerces from a module, since the JDK's serialization is badly broken.) QA: easiest way to reproduce problem is to run IDE on JDK 5.0 with -J-Xbootclasspath/a:/tmp/xalan-j_2_7_0/xalan.jar:/tmp/xalan-j_2_7_0/xercesImpl.jar:/tmp/xalan-j_2_7_0/serializer.jar and try to make a new j2seproject. Go to Files tab and look at nbproject/project.xml. If correct, will see e.g. <project xmlns="http://www.netbeans.org/ns/project/1"> <type>org.netbeans.modules.java.j2seproject</type> <configuration> <data xmlns="http://www.netbeans.org/ns/j2se-project/3"> <name>JavaApplication2</name> ... If broken, will see e.g. <project xmlns="http://www.netbeans.org/ns/project/1"> <type>org.netbeans.modules.java.j2seproject</type> <configuration> <data xmlns="http://www.netbeans.org/ns/project/1"> <name xmlns="http://www.netbeans.org/ns/project/1">JavaApplication4</name> ... However the fix I will put in will *not* handle that case, since it only fixes the case that Xalan is loaded from a module, not from the bootclasspath, which we cannot control. To really test you need to make a lib wrapper module with those JARs and install it (have to make it non-autoload in order to turn it on). With that test case my patch fixes the problem, so I will do that.
committed Up-To-Date 1.7 openide/util/src/org/openide/xml/XMLUtil.java
Jesse, I'm not au fait with class loaders, so pardon my ignorance on this. I assume that what you have committed will not handle the case where I have xalan 2.7.0 and xerces 2.7.1 in endorsed, because they will be picked up by the bootclasspath loader. Is that correct?
I removed the xalan 2.7.0 and xerces 2.7.1 jars from endorsed, and, using 26-Oct build, I was able to create a new J2SE app of one file which single-file compiled and built successfully. If I leave the xerces 2.7.1 jars in endorsed, I get A java.lang.reflect.InvocationTargetException exception has occurred when I try to create the project.
Created attachment 26421 [details] NetBeans log
"I assume that what you have committed will not handle the case where I have xalan 2.7.0 and xerces 2.7.1 in endorsed, because they will be picked up by the bootclasspath loader. Is that correct?" - yes, that is correct. The fix only handles the case that someone bundles Xalan in a module for private use from their own code. Your new InvocationTargetException appears to be unrelated to this bug - some kind of version skew conflict, but I'm not sure what exactly. Maybe this wasn't made clear before or in the existing release notes, so: it is *never* supported to put anything into the jre/lib/ext/ or jre/lib/endorsed/ dirs of the JDK which you use to run NetBeans if those JARs might possibly conflict with existing software, or otherwise to modify the boot or extension classpaths. If it works for you, great, but if doesn't, don't bother filing bugs. The endorsed override mechanism was never really safe and I would not recommend using it at all, but if you must, keep a separate JDK installation for NetBeans. It is probably safe to add clearly new extensions; the only things that I can think of that would be generally useful to add as extensions and not conflict with other code would be special Swing L&F implementations, input methods for unusual scripts, and certain accessibility technologies.
Jesse, What's the ID for the Xalan bug?
See the URL field for a link to Jira.
*** Issue 65590 has been marked as a duplicate of this issue. ***
*** Issue 69001 has been marked as a duplicate of this issue. ***
*** Issue 69931 has been marked as a duplicate of this issue. ***
FYI: This bug in Xalan together with issue #70130 prevents NetBeans 5.0 to run on IBM JDK 1.5.0.
Created attachment 28613 [details] NetBeans on IBM JDK 1.5.0
thurka: if there is a problem with IBM's JDK I suggest you file it separately, though I don't know if it is fixable other than by getting IBM to fix it.
*** Issue 72815 has been marked as a duplicate of this issue. ***
I'm a developer on Xalan. By chance I am working on the defect pointed to by this one, http://issues.apache.org/jira/browse/XALANJ-2219. Please keep in mind that I'm a volunteer on Xalan. It looks like I have a fix for 2219, and will commit the change to the 2.7.0 Xalan code base. What is your expectation after that? A new release of Xalan? Or do you build it from the latest and greatest code, or .... ? Regards, Brian Minchau minchau@ca.ibm.com
brianminchau: the NetBeans product doesn't bundle Xalan at all. We use the version shipped with the JDK, which as far as I know doesn't have this problem in the Sun distribution. (Perhaps due to usage of XSLTC?) The problem arose with people bundling their own versions of Xalan with add-on modules, in which case the rest of the IDE would pick up the bundled Xalan instead of using the JDK's version. There is already a workaround in NetBeans which deals with this case (forcing the JAXP impl of XSLT to be used) provided that the JAXP version does not contain the bug. However see issue #70130. It seems that the IBM JDK 1.5.0 bundles a version of Xalan which does suffer from XALANJ-2219. For that reason, NB currently won't run on this JDK, as it has no working XSLT processor available and serialization of namespaced XML is critical for the project system to work. If a fix for XALANJ-2219 could be put into an update to the IBM JDK that would be great. The NB code already autodetects whether the JDK's Xalan has a fix for XALANJ-2219 or not (by testing its runtime behavior), so NB 5.0 ought to begin working unmodified on a patched IBM JDK. Thanks for the note! I know this situation is a bit complicated so feel free to contact me (jglick@netbeans.org) if you need more information.
I've attached a patch to http://issues.apache.org/jira/browse/XALANJ-2219. It is pending review. If anyone wants to take the latest code from Xalan, apply that patch and tests with NetBeans feel free. If anyone does that, the build will produce both xalan.jar and serializer.jar which should be put on the class path infront of IBM's JDK 1.5. Of course all of this bootclass path stuff is never offically OK, but what else are you going to do until the JDK has a fix. Regards, Brian Minchau
As a side note for all those who need an alternative till IBM resolves this (besides Xbootclasspath/p), Xalan-C is bundled with the IBM JRE 5.0 and can be specified as the default xslt processor for jaxp by including the following in your ${IBM_JDK_FOLDER}/jre/lib/jaxp.properties: javax.xml.transform.TransformerFactory=org.apache.xalan.xsltc.trax.TransformerFactoryImpl See the comments in ${IBM_JDK_FOLDER}/jre/lib/jaxp.properties.sample for a better description...
fasces - thanks for the tip. I have included your note at http://wiki.java.net/bin/view/Netbeans/FaqXalanOnCP
Old link doesn't work. Here is current http://wiki.netbeans.org/wiki/view/FaqXalanOnCP
v/c