Bug 66563

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).

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).

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