Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] IMPORTANT: defect/build procedure this week for WTP M4

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.

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(

org.apache.crimson.tree.DomEx: NOT_FOUND_ERR: That node does not exist in this context.
        at org.apache.crimson.tree.ParentNode.removeChild(

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


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

David M Williams <david_williams@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/24/2005 10:59 PM

Please respond to
"General discussion of project-wide or architectural issues."


[wtp-dev] defect/build procedure this week for WTP M4

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

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

Sound feasible?
wtp-dev mailing list

_______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx

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)

Back to the top