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)


Also for the record, we discovered that when using crimson, it throws an exception when using some of the XSD model-based tools such as the WSDL and XSD Editors.  

When the XSD model loads the schema for schema, it tries to load xml.xsd which is a document that describes the XML Namespace.  This file references XMLSchema.dtd via a docType tag and the crimson parser throws an exception when it fails to resolve it.   Because the XSD model catches and handles this exception and because the reference to the schema seems to be unnecessary (ie. remove the docType tag), the creation of the schema for schema doesn't appear to be affected.

After testing the tools, this exception doesn't appear to have any adverse effect functionally to the tools.  You'll only get the following trace in the log file:

org.xml.sax.SAXParseException: Relative URI "XMLSchema.dtd"; can not be resolved without a base URI.
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3339)
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3333)
        at org.apache.crimson.parser.Parser2.resolveURI(Parser2.java:2915)
        at org.apache.crimson.parser.Parser2.maybeExternalID(Parser2.java:2887)
        at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.java:1276)
        at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:623)
        at org.apache.crimson.parser.Parser2.parse(Parser2.java:333)
        at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448)
        at org.apache.crimson.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:185)
        at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
        at org.eclipse.xsd.util.XSDResourceImpl.getDocument(XSDResourceImpl.java:238)

Regards,
Keith Chong
D3/QCS/8200/MKM
Phone: (905) 413-4370    T/L: 969-4370
e-mail: kchong@xxxxxxxxxx




Craig Salter/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx

04/25/2005 12:26 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)






Just for the record all of our XML validators have a hard requirement on xerces.  A generic XML parser does not provide the level of control we need to produce good validation behaviour (dependency resolution, error messages with good coordinates etc.).  


thanks

Craig


Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM
Phone: (905) 413-3918  TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@xxxxxxxxxx     Notes: Craig Salter/Toronto/IBM@IBMCA



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

04/25/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


Back to the top