This is a well konw problem with the use of Xerces and JDK releases 1.4
and up. The fix is not clean but can be done by adding the following
to your VM arguments.
Also see the notes on the emf page that suffers from the same problem.
http://download.eclipse.org/tools/emf/scripts/downloads-xerces.php
If we keep Xerces, we will have to live with it. Ugly but a fact of
life.
To all, but especially folks most in
the know on the nature of WTP's inclusion of Xerces, a critical problem
exists between Crimson and Xerces that would, in my opinion, block M4.
There are two bugs that are making
me
nervous: 91927 [1] and 92402 [2]. The Web Services and J2EE teams are
both
observing exceptions thrown by the Crimson parser very consistently:
org.apache.crimson.tree.DomEx:
NOT_FOUND_ERR:
That node does not exist in this context.
at
org.apache.crimson.tree.ParentNode.replaceChild(ParentNode.java:469)
...
org.apache.crimson.tree.DomEx:
NOT_FOUND_ERR:
That node does not exist in this context.
at
org.apache.crimson.tree.ParentNode.removeChild(ParentNode.java:500)
...
In the Web Services case, the Web
services
wizards and the Web Services Explorer are both suffering. Jeff Liu
mentioned
that changes were made a week or two ago to how the Xerces parser was
bundled
within our stack of plugins and to the extent its jars were exported.
If
memory serves, the above Crimson exceptions began showing up around the
same time. Jeff theorized that classes from Crimson and Xerces were
bumping
into each other in that infamous manner unique to the Eclipse plugin
classloading
mechanism.
So, I tried two experiments using
the
Web Services Explorer, one of the components getting hammered by the
first
exception above.
1. Ran Eclipse WTP on Sun's JRE*.
The
scenario described in 92402 [2] explodes.
2. Ran Eclipse WTP on IBM's JRE**.
The
scenario described in 92402 [2] works.
The Sun JRE includes Crimson. The
IBM
JRE includes Xerces. WTP includes Xerces. Coincidence? I think not!
We need help working out a solution
to this problem. It seems either Xerces needs to be isolated into a
very
small box so that higher order plugins in the stack that rely on XML
parsing
(Crimson) don't know its there, or we need to remove our dependency on
Xerces once and for all (and I realize this latter thought is easier
said
than done).
* java -version
java version "1.4.2_05"
Java(TM) 2 Runtime Environment,
Standard
Edition (build 1.4.2_05-b04)
Java HotSpot(TM) Client VM (build
1.4.2_05-b04,
mixed mode)
** java -version
java version "1.4.1"
Java(TM) 2 Runtime Environment,
Standard
Edition (build 1.4.1)
Classic VM (build 1.4.1, J2RE 1.4.1
IBM Windows 32 build cn1411-20030930 (JIT enabled: jitc))
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=91927
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=92402
Cheers - CB.
Chris Brealey
Rational Studio Java Web Services, IBM Canada Ltd.
D3-275, D3/ENX/8200/MKM, 8200 Warden Avenue, Markham, Ontario, Canada,
L6G 1C7
cbrealey@xxxxxxxxxx, 905.413.6038, tieline:969.6038, fax:905.413.4920
Here's what I suggest for our build/defect fixing procedure this week,
in anticipation of declaring M4 on 4/29 ... we need to have a slow
steady progressively better build.
Suggestions welcome.
One planned re-build on Tuesday at noon (EDT).
Any fixes going into this Tuesday build must be listed to
wtp-dev so project leads (and we all) get an idea of what's
going into the build. Its up to the component leads best
judgement to balance things which must be fixed, with
risk of destabilizing the build. -- and we still expect
a small number .. 10 to 30. [and, remember, there's no
need to fix 'normal' problems at this point].
One more possible rebuild on Thursday at noon (EDT),
if needed.
Same procedure: any fixes listed to wtp-dev, only now
even much smaller number expected, like 5, for only the most
blocking and the most safest fixes.
Presumably after each of these builds, teams will test
that the blocking defect was fixed, and no regressions
introduced.
I'm hoping this is enough of a controlled process and
that we don't need to start a hierarchy of reviews and
approvals ... but if things seem to get out of control, that will
come next.
If anyone has doubts about whether to include a fix,
doen't hesitate to ask others (like me) for advice or
perspective.
Sound feasible?_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
--
Naci Dai,
eteration a.s.
Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 34742
+90 (533) 580 2393 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com/
mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx
|
