I am willing to bet you have a stray copy of some version of the
Xerces XML parser sitting in your JDK's jre/lib/ext/ directory. Please
remove it, it can only cause problems with apps like NetBeans that use
their own version of Xerces. See the IDE release notes and/or FAQ.

If this is not the case, please reopen and include your log file
(you're sure nothing got written to it?? very strange) or failing that
the contents of your console (use runide.exe rather than runidew.exe),
and specify your JDK version, exact version of NetBeans, and anything
else that might be relevant - this is surely a configuration problem,
not a code error.

Created attachment 4367 [details]
My ide.log

Well now there IS a dillema here.  JAXP requires these 2 specific
builds of Xalan and Xerces to be in the C:\j2sdk1.4\jre\lib\endorsed
directory, and cannot be put in the class path (as per the
documentation).  I followed Jesse's advice and If I don't have them
there, I get a massive stack dump when I try to run my code because
the TransformerFactory in the jars I need to use and they obviously
must be different than the ones that come with NetBeans.  Adding the
jars to the project helps me build the project fine, and I don't get
any errors thrown, but when I want to run it, it chokes and throws an
exception.  So I'm at a loss here.  If I put them in the
C:\j2sdk1.4\jre\lib\endorsed directory, I
literally crash NB 3.3.1 (it simply quits now doesn't even throw an
error - I even included my ide.log as is to verify that), and if I
don't I can't run my code within NB and use the debugger and all the
goodies.

This has got to be a considered a bug, or perhaps there is some other
funky workaround to this issue.

Robert also writes to me directly (earlier or later?):

"Downloaded RC2, removed the jars and mounted them in my project,
downloaded 1.4 rc and deleted my original preferences which I didn't
really care about since I just started using NB. Problem gone."

So is it OK or not? If it is OK, please close (WORKSFORME is fine),
else we can leave open. All comments should be attached to the bug
report, rather than sending mail about it.

Probably this is a matter for Petr to look at, he knows most about XML
parsers and their config... no idea what the "endorsed" directory is
myself.

I also do not understand "endorsed". What does it stay for? No JAXP
spec mentions something like this.

Generaly, it is implementation visible at classpath kind of bug. 

One solution is to register in IDE core JAXP factories that will load
implementations using an isolator classloader. It will mean that IDE
will not support JAXP parser plugability. JAXP will always return
implementation loaded from well-known.jar file by the isolator
classloader. It does not matter as JAXP does not support parser
features negotiation, application must simply accept a parser it
located as the first.

It does not matter to modules as well if they use JAXP interfaces
instead their private implementations. (XMLUtil.write() need to be
rewritten to load private implementation by the isolator classloader
to avoid clash with jre/lib/ext and rt.jar implementations.)


Besides it also means that adding Class-Path: xxx entry into module's
manifest does not guarante that the declared implementation will be
used as any other version may appear as a part of jre/lib/ext or
rt.jar. Could not it be handled by module loaders? They could prefer
looking into declared dependencies over parent class loader.

Do not you want to continue this bug as two enhancements?

Created attachment 4393 [details]
JavaTM API for XML Processing Release Notes, Specification 1.2

See the release notes on 1.4.  This is the release labeled for Winter 
2001, and it seems that the xerces.jar and xalan.jar are early access 
jars.  Still for some reason, JDK 1.4 wants to load them when the JVM 
is run.  Adding them to the class path, as per the docs, will not 
work.

There should perhaps be a way to support both the jars shipped with 
NB and the ones a user might want to add.  Is there a way why a check 
could not be made to see if the JDK has loaded them already, then NB 
would not load its own jars for it, or perhaps make it a properties 
which would allow the user the chance to either load or not load the 
xerces and xalan jar files but changing a setting in the ide.cfg or 
somewhere more appropriate.

Thanks for the explanation document.

It think that we must use isolator to protect our XML processors'
versions. Unfortunatelly it is 3.4 timeframe.

Jesse are you able to do a hotfix for 3.3.1 timeframe by removing
direct parser dependency replacing it by JAXP interfaces (AFAIK the
AntProjectSupport code does not relay on implementation specific
behaviour, so rewrite should be trivia).

AntProjectSupport does rely on Xerces serialization, it cannot use
XMLUtil.write which reformats code too much to be acceptable. (When
the XML module provides a stable API this code will be rewritten and
Xerces ser will no longer be needed.) So it does need xerces.jar,
though AFAIK the serializer is independent of the parser.

It may be able to work with different XML parsers, but it is very
sensitive to some known (to me) Xerces bugs involving DOM mutation
event firing, which I have carefully worked around in the current
code. Switching parsers should be possible but would mainly require a
fair amount of testing, I wouldn't want to attempt it for 3.3.1 anyway.

So for Robert: for 3.3.1 I would recommend you *not* put the JARs in
jre/lib/endorsed/ as recommended by the JAXP release notes. Instead,
to override the older xalan as they say, use
-Xbootclasspath/p:whatever.jar in other applications where you
actually want to use the newest JAXP and parsers. Not for NetBeans, of
course. (You can run user apps with these libraries by configuring
compiler, executor, and debugger types appropriately.)

Does that work? Provisionally marking WONTFIX under the assumption
that that is a good enough workaround.

No that won't work because I get the actual error when I am trying to
debug from within NB, not with other apps, and since I can't add the
-Xbootclasspath/p:whatever.jar to NB ide.cfg, then that kills the
whole thing.  The problem is the jars loaded by NB are getting in the
way of my running code in NB and debugging and all that cool stuff.

Perhaps if there isn't a quick fix, and I'm OK with that, this should
stay open so it is taken care of and tested for 3.3.4?

Can't you set the boot classpath for your debugger type to include the
XML files you need? For any user app launched from NB you are in
complete control of how it is run. Am I missing something?

Reported as JAXP bug #4626527.

Hyperlink BTW:

http://developer.java.sun.com/developer/bugParade/bugs/4626527.html

Petr, this is a bug that can be solved by loading parser
implementation using isolating classloader. The isolating classloader
logic need to be implemented in JAXP factories provided by core.

Isolating classloader also allows a module to declare explicit parser
implementation dependency (Jesse: module classloader must mask all
undeclared XML processor implementations, by prefering loading from
declared dependencies over parent classloader).

Consequently all accesses to XML processors can be done:
 - via JAXP providing the wellknown (isolated) implementation
 - directly access implementation by a module that declares explicit
   dependency

Summary:

  1) our JAXP factories should guarantee wellknown processor
     implementation
  2) module classloaders should prefer declared resources over
     unknown parent resources

See issue #19622 for more. For the record, I don't agree that module
extensions should generally be used in preference to parent
classloaders; this is abnormal and should not be the default behavior.
But in specific cases such as XML parsers we know we want to mask
certain classes.

I assume this: "our JAXP factories should guarantee wellknown
processor implementation" means that NB will ship with a predefined
set of parsers (Crimson & Xerces I presume), providing preferentially
Crimson for nonvalidating SAX and Xerces for validating SAX and also
DOM; will load these parsers from dynamic classloaders; and JAXP calls
from within the NB VM will ignore any general JAXP defaults (1.4 JDK's
defaults, or user-defined JAXP system properties).

Jesse's assumtion is the goal (extended by transformation libs too).

For the record, why do you disagree with generally reversed
classloader delegating model (prefering explicitly declared resources
over parent resources)?

Because the general model for classloader usage in Java is to search
parents first. If we need to break it for a specific reason, OK, but
it should be exceptional cases only, and clearly documented. Consider
modules shipping copies of java/lang/String.class, for example. Making
NetBeans generally reverse the style of loading that people are
accustomed to doesn't seem desirable.

Making it too easy for people to abuse classloaders will tempt them to
do things the wrong way and override classes whenever they feel like
it, which is in most cases a bad idea and indicates incorrect design.
Naturally you can always construct your own classloader manually and
delegate whatever you like, if you know what you are doing. In the
past this has been recommended for various module authors - in all
cases due to the XML parser problem.

It seems we have to make an exception for XML parsers because the JDK
team decided to bundle parsers developed outside the JDK while there
are active development efforts on newer versions of these parsers.
That is why I consider JDC #4626527 a bug we have to work around.

We also made a change to the usual model by forbidding a package to be
loaded by more than one classloader, i.e. treating all packages as
implicitly sealed. But this may be necessary for performance reasons,
so the domain cache in ProxyClassLoader can work.

Jesse, is this one solved (after 19622)? What can we (I) do? Don't you
want to take care of it? I would recommend to close the bug but you
know more details than me.

NB 3.4 still has xerces.jar on its classpath, but this is not
accessible to most modules, unlike xml-apis.jar.

Issue #20269 requests that the Ant module not make any direct
references to Xerces parser impl classes. That ought to let it use
whatever parser is around. Currently it still requires a parser
version close to the one shipped with NB.

I still recommend not using the endorsed directory, and using
-Xbootclasspath/p wherever necessary, e.g. in the NB debugger type
configuration.

*** This issue has been marked as a duplicate of 20269 ***

Resolved for 3.4.x or earlier, no new info since then -> verified.

Resolved for 3.4.x or earlier, no new info since then -> closing.