[
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)
|
Title: Message
Keith,
I saw
this error last week and was going to investigate, because it (or some
unrelated, unreported error) does have a negative effect in one situation.
If I open a schema using "open external file" outside of my workspace, the
schema opens fine, but I cannot open any of the imported schemas. I choose
the context menu action to open an imported schema and nothing happens in the
editor --- but I get this trace in the log. I thought this was the cause,
but maybe not.
Cheers,
Dave Carlson
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
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
