[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-dev] Re: [wtp-releng] help needed on build test failures
|
Sending to wtp-dev for a larger audience. Valentin, David said you have
worked in this area recently?
I just don't see how content-types in core eclipse can work if
SAXParserFactory is so flaky. While they don't call SAXParserFactory in
their XmlRootHandler, it *is* being used under the covers in the
Activator class. This means that core eclipse uses it, JST uses it in
their copy of XmlRootHandler, and for some reason it happens not to work
in the JPT copy? I'm not really comfortable just randomly setting flags
in hopes things might work.
I'm ok with trying out your second suggestion, I just don't understand
why we would have to do it that way when others don't. And maybe our
tests will just happen to pass the next time the build runs? Awfully
suspicious we have never seen this problem before.
Thanks,
Karen
On 6/30/2009 12:20 PM, David Carver wrote:
Now I think we are getting to the reason for the issue.
SAXParserFactory is the JAXP way of creating the SaxFactory to be
used. However since you let JAXP determine and figure out the
configuration and the parser to be used, you can run into
configuration issues.
My experience with using JAXP within OSGI based bundles is that you
can get some unexpected results that crop up. There are a couple of
possible solutions.
1. Try setting the setXIncludeAware() method to either true or false
to see if that fixes your problem. You many need to set the other
configuration options as well.
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/parsers/SAXParserFactory.html
2. Call and use the Xerces specific implementations directly, and
setup your configurations.
I personally try to avoid using JAXP within OSGi because of the
unpredictablility when it interacts between bundles.
It may work for a while, and then it just goes nuts one day.
Dave
karen moore wrote:
The org.eclipse.jst.jee.util.internal.XmlRootHandler uses
SAXParserFactory factory = SAXParserFactory.newInstance();
while the org.eclipse.core.internal.content.XmlRootHandler uses
Activator.getDefault().getFactory() (our JPT copy uses this
as well)
Will changing our JPT copy to use the former fix this problem? And
if so I don't understand why the problem suddenly cropped up. I
apologize if I seem clueless about this, it's because I am :)
Thanks,
Karen
On 6/30/2009 11:40 AM, karen moore wrote:
I copied XmlRootHandler from
org.eclipse.core.internal.content.XmlRootHandler and that class has
not changed since 2008. Not really sure how that could have
suddenly caused this problem.
Karen
On 6/30/2009 11:34 AM, David Carver wrote:
How ever your orm content type is being set up, and where you are
getting your XML parser is causing the issue. The WTP parser is
setup to be an XInclude aware configuration. You can't cast
between these to configurations.
I'd check to see how your SAX based parsing and content resolver
are being setup and configured when calling Xerces. Particularly
check your createParser code.
Dave
karen moore wrote:
JPT has a bunch of test failures in last night's build and I am
unsure of the cause. We did release, but I am confused by the
exception (see below) appearing in the log file that are
preventing our xml content types from being loaded. I updated my
target workspace to last night's build and do not have test
failures. Any ideas would be appreciated.
Thanks,
Karen
!MESSAGE Could not create content describer for
org.eclipse.jpt.core.content.orm. Content type has been disabled.
!STACK 0
java.lang.ClassCastException:
org.apache.xerces.parsers.XIncludeAwareParserConfiguration
incompatible with org.apache.xerces.xni.parser.XMLParserConfiguration
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown
Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at
org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown
Source)
at
org.eclipse.jpt.core.internal.resource.xml.XMLRootHandler.createParser(XMLRootHandler.java:118)
at
org.eclipse.jpt.core.internal.resource.xml.XMLRootHandler.parseContents(XMLRootHandler.java:186)
at
org.eclipse.jpt.core.internal.resource.xml.XMLRootElementContentDescriber.checkCriteria(XMLRootElementContentDescriber.java:169)
at
org.eclipse.jpt.core.internal.resource.xml.XMLRootElementContentDescriber.describe(XMLRootElementContentDescriber.java:204)
at
org.eclipse.core.internal.content.ContentType.describe(ContentType.java:161)
at
org.eclipse.core.internal.content.ContentTypeCatalog.collectMatchingByContents(ContentTypeCatalog.java:189)
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
