Skip to main content

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


Before refactoring Xerces into private copies. I want to say that I think I have a fix for the Web Services Explorer problem. The problem is actually in Crimson's Element.replaceChild(.....) method. I'm investigating whether the J2EE problem is a similar deal. If so, then there may be a simple change in our code that can workaround this Crimson bug... I'll report to this list asap.

Thanks,

Jeffrey Liu
IBM Rational Software - Performance Analyst
IBM Toronto Lab.
8200 Warden Ave. Markham, Ontario, L6G 1C7
Internal mail: D3/R8V/8200/MKM (D3-268)
T/L: 969 3531
Tel: (905) 413 3531
Fax: (905) 413 4920
jeffliu@xxxxxxxxxx



Arthur Ryman/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 02:23 PM

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

To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Issues with Xerces (was: IMPORTANT:        defect/build        procedure this week for WTP M4)






Our immediate objective is to produce a stable M4 candidate, so I am OK with each plug-in having a private copy of Xerces if that solves the problem. We can find a better solution after M4.


Would all component leads (I assume Chris, Craig, David) that need Xerces please repond ASAP with a Yes/No to the proposal to have private copies of Xerces. Please prototype this before responding and confirm that it works for you.


I think the java.endorsed.dirs approach needs to be carefully assessed before we adopt it. WTP should be unintrusive.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/


Kathy Chan/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 01:40 PM

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

To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] Issues with Xerces (was: IMPORTANT: defect/build        procedure this week for WTP M4)








Hi,

I would like to add that setting "java.endorsed.dirs" to the Xerces directory does not seem to help with the running of the Web services scenarios.  I am still running into a similar error (NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist) from similar stack trace (EMF2DOMAdapterImpl) except it's now a DOMException rather than a Crimson exception.  The problem is still intermitten but would usually occurs after running 2 or 3 Web services scenarios.  There's also an "OutOfMemory" error when it occurs and the workbench becomes unusable.  More detail/history of this bug can be found in defect
91927.


Kathy Chan
Rational Studio Java Web Services, IBM Toronto Lab
D3-354, D3/R8V/8200/MKM, 8200 Warden Avenue, Markham, Ontario, Canada, L6G 1C7
kathy@xxxxxxxxxx, (905) 413-3022, tieline: 969-6038, fax: (905) 413-4920


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

25/04/2005 11:32 AM

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


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
[wtp-dev] Issues with Xerces (was: IMPORTANT: defect/build procedure this week for WTP M4)










I agree, I'd like to understand better too :)


The endorsed/libs solution is a brute force solution that should not be required for the kinds of problems being reported

(and is undesirable for the reason's Jeffrey has mentioned).

I suspect there are "hidden" problems that either we don't have our imports/exports correct, or, worse, someone
is circumventing the normal Eclipse classloading behavior (and therefore making the classes loaded highly
dependent on the order of actions a user performs).

In reality, there is limited need we have, several of the validators were using it (and doing their own
exports to avoid multiple copies., and I think we'd run into the same problem if the order of user actions were just right).

I requested it be distributed as a separate plugin because
1) when we originally approached as solving as a "private" prereq, one of the project leaders :)

suggested that Xerces was a commonly used open source solution that did provide legitimate function
above/beyond JAXP, so would be desirable to include as normal plugin,
2) having it a separate plugin solved some awkward dependancies and unnatural plugin divisions.

3) if anyone could solve the Xerces problem it would be the WTP team


But, solving "the Xerces problem" is not a P1 priority, so if its more expedient for M4,
I have no problem returning to the "private prereq" solution (though to avoid the
problem completely, we might have to have multiple copies, to avoid "leaking" its
classes by re-exporting them.

So, is it only required by WSDL validation? (It was being used by XML Validation, even DTD validation, I think,
maybe others?).

Also, does anyone knowingly circumvent the Eclipse class loader and if so is this required? Or something left
over from 2.x stream, where it might have been required.

David




Arthur Ryman <ryman@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 10:52 AM

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


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] IMPORTANT: defect/build procedure this week for WTP M4












I'd like to understand this situation better. My understanding of why we need Xerces is for performing validation of inline schemas in WSDL. It sounds like Xerces is also needed to work around a Crimson bug in the Sun JDK. Is this correct? Are there any other reasons we need Xerces, e.g an EMF dependency?


If the WSDL validator is the only component that has a hard depency on Xerces, maybe a better approach is to modify the XSDL validator to directly call Xerces for the inline schema validation task, and to make WTP work with a generic JAXP parser.



Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/
Chris Brealey/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 10:35 AM

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


To
naci.dai@xxxxxxxxxxxxx, "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
Re: [wtp-dev] IMPORTANT: defect/build procedure this week for WTP M4














Naci,

Thanks. Jeffrey and I have both tried this workaround. It solves the problem in the Web Services Explorer (92402). Can we fashion a "wtp.exe" equivalent to "eclipse.exe" and burn the "-vmargs -Djava.endorsed.dirs ..." workaround into it?


It may not solve the problem in 91927. More to the point, I may have bumped into the intermittent exception described in 91927, only in the form of the moral equivalent exception from Xerces (instead of from Crimson) while running WTP with the workaround.


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
Naci Dai <naci.dai@xxxxxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 09:01 AM

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


To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
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.

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


To
wtp-dev@xxxxxxxxxxx
cc
Subject
[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
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_______________________________________________
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
_______________________________________________
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
_______________________________________________
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


Back to the top