Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Re: [wtp-releng] help needed on build test failures
Niel, I'm not sure if this is going to help or not but thought I'd put it out here and others more knowledgeable on the interaction might be able to respond.
I noticed that the org.eclipse.wst.xml.core plugin Re-Exports the org.apache.xerces orbit bundle. According to the documentation from PDE we should becareful about reexporting:
You can select the *Re-export this dependency* option to re-export your dependency in order to make it automatically visible to any downstream plug-in that require it. Please note that you should only re-export a given plug-in dependency only if your plug-in exposes one ore more API's from that dependency.
I don't think that org.eclipse.wst.xml expose any of the API's from the xerces plugin for consumption. I changed it locally to not re-export, and the plugins that the dependency need to be added are, the org.eclipse.wst.xsl.core, org.eclipse.wst.xsd.core, org.eclipse.wst.xsd.ui.
If you depend on org.eclipse.wst.xml.core you may need to add the org.apache.xerces orbit plugin specifically if you change the Re-Export Dependency.
Nitin or anybody else is there a particular reason we re-export the dependency? 

Dave


David Carver wrote:
The Neil, the reason in the XML tests that it isn't failing the tests, is that we log the error message but discard it. For the process that it is showing up in it isn't overly critical, as we will just default to a 1.0 configuration for XSL grammars instead of what is defined in the XSL Attributes.
With this said, I have just checked in a possible fix for this issue, to make sure that the factory we are requesting and setting up to the SAX parsing is set for the XML Reader to NOT be XInclude aware. I need to tag and release the code and then will check the logs later tonight, or tomorrow, to see if it addressed the issue.
After getting your SAXFactory and creating the instance, check to see if factory.isXIncludeAware() returns true. If so, then you need to do factory.setXIncludeAware(false);.
I'll reply here and your other bug if it fixes it for the XML tests. The funny thing is that we will only hit this particular scenario during unit testing. All other times we get the value we expect from the SSE Model. 

Dave

Neil Hauge wrote:
I've been looking into this issue recently and noticed that there are similar exceptions logged in the wst.xml.core.tests (which don't appear to be causing test failures). Specifically in
org.eclipse.wst.xml.core.tests.format.TestPartitionFormatterXML.testXSLFormat()
This can be seen most clearly in the 3.1 release build (before the Dali related issues appeared). They are occurring consistently in recent 3.2 builds as well, in addition to the Dali related exceptions. 

Link to 3.1 R build console log:
http://download.eclipse.org/webtools/downloads/drops/R3.1/R-3.1-20090616035105/testResults/consolelogs/org.eclipse.wst.xml.core.tests.consolelog.txt
Wanted to make sure you guys were aware of this. We are tracking the Dali related failures in bug 283721 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=283721. 


Neil



David Carver wrote:

Valentin Baciu wrote:


Hi Karen,
The changes Dave alluded to are only applicable to the WTP XML validator. These changes were made quite a while back (WTP 3.0, https://bugs.eclipse.org/bugs/show_bug.cgi?id=205989) and I very much doubt they will impact code other than the the WTP XML validator.
Correct, they would only affect her if they were using those particular plugins. Wasn't sure if the changes had gone beyond those plugins or not.
I have asked around and it seems that the most likely cause of the issue you're experiencing is a ClassLoader issue. It is possible that your code is loading different parts of Xerces from different sources (JDK and perhaps the WTP Xerces plug-in?). In that case, the two classes are not compatible because their interfaces are loaded by different ClassLoaders.
Which is why JAXP's SAXFactory.newInstance() is not very OSGi friendly. The instance that can be returned could have changed by some plugin specifically setting the System property for which parser is to be used. This can be done in any plugin anywhere, so you may not get what you think you should be getting. Plus if a plugin is expecting a particular implementation of a XML parser and something is configured with a different parser or implementation, you get the issue that is currently happening. It can go undetected until just the right circumstances are hit.
Ideally all implementations would use the OSGI XMLParsuerActivator class if they must use JAXP interfaces to get a particular configuration of an XML parser they need.
http://docs.huihoo.com/javadoc/osgi/r3/org/osgi/util/xml/XMLParserActivator.html 

Dave
I hope this helps. 

Regards,
Valentin Baciu
Rational XML Web Services Tools


From:     karen moore <karen.moore@xxxxxxxxxx>
To: Webtools releng discussion list <wtp-releng@xxxxxxxxxxx>, wtp-dev@xxxxxxxxxxx 
Date:     06/30/2009 12:51 PM
Subject: [wtp-dev] Re: [wtp-releng] help needed on build test failures 
Sent by:     wtp-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
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
_______________________________________________
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-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng

Back to the top