Hey Simon,
Ah I see, that does make sense then :)
The ejb/ear has it's classpath loading set to PARENT_LAST and the
class loader policy set to SINGLE
Dave.
--
Dave Sowerby MEng MBCS
2008/8/3 Simon Laws <[EMAIL PROTECTED]>:
>
>
> 2008/8/3 Dave Sowerby <[EMAIL PROTECTED]>
>>
>> As I've just realised that stack was out by a few lines thanks to my
>> debugging, here's the accurate stack (with only //throw ce;
>> uncommented):
>>
>> java.lang.ClassCastException:
>> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> javax.xml.parsers.DocumentBuilderFactory
>> at
>> org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:188)
>> at
>> org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
>> Caused by:
>> org.apache.tuscany.sca.contribution.service.ContributionException:
>> org.apache.tuscany.sca.contribution.service.ContributionReadException:
>> java.lang.ClassCastException:
>> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> javax.xml.parsers.DocumentBuilderFactory
>> at
>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:390)
>> at
>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:190)
>> at
>> org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:488)
>> at
>> org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:186)
>> ... 15 more
>> Caused by:
>> org.apache.tuscany.sca.contribution.service.ContributionReadException:
>> java.lang.ClassCastException:
>> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> javax.xml.parsers.DocumentBuilderFactory
>> at
>> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:111)
>> at
>> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:56)
>> at
>> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:96)
>> at
>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:493)
>> at
>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:388)
>> ... 18 more
>> Caused by: java.lang.ClassCastException:
>> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> javax.xml.parsers.DocumentBuilderFactory
>> at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown
>> Source)
>> at
>> org.apache.tuscany.sca.policy.util.PolicyComputationUtils.addApplicablePolicySets(PolicyComputationUtils.java:345)
>> at
>> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:98)
>> ... 22 more
>>
>>
>> --
>> Dave Sowerby MEng MBCS
>>
>>
>>
>> 2008/8/3 Dave Sowerby <[EMAIL PROTECTED]>:
>> > Hi Guys,
>> >
>> > Of course your both absolutely right:
>> >
>> > Simon, the NodeImpl changes picked up this url before it was actually
>> > used - I had debugged a little too early.
>> > Raymond, that one disappeared once I encoded the file appropriately :)
>> >
>> > Moving on from this, I'm now getting another stack, as follows:
>> >
>> > java.lang.ClassCastException:
>> > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> > javax.xml.parsers.DocumentBuilderFactory
>> > at
>> > org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:190)
>> > at
>> > org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
>> > Caused by:
>> > org.apache.tuscany.sca.contribution.service.ContributionException:
>> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
>> > java.lang.ClassCastException:
>> > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> > javax.xml.parsers.DocumentBuilderFactory
>> > at
>> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:390)
>> > at
>> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:190)
>> > at
>> > org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:490)
>> > at
>> > org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:186)
>> > ... 15 more
>> > Caused by:
>> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
>> > java.lang.ClassCastException:
>> > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> > javax.xml.parsers.DocumentBuilderFactory
>> > at
>> > org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:122)
>> > at
>> > org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:56)
>> > at
>> > org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:96)
>> > at
>> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:493)
>> > at
>> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:388)
>> > ... 18 more
>> > Caused by: java.lang.ClassCastException:
>> > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with
>> > javax.xml.parsers.DocumentBuilderFactory
>> > at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown
>> > Source)
>> > at
>> > org.apache.tuscany.sca.policy.util.PolicyComputationUtils.addApplicablePolicySets(PolicyComputationUtils.java:345)
>> > at
>> > org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:102)
>> > ... 22 more
>> >
>> > Taking a look for previous instances of this behaviour, I find that
>> > this is due to websphere's implementation being incompatible with the
>> > sun implementation (or something like that). I've tried adding a
>> > xerces implementation to my ear, also adding the class selection to
>> > META-INF/services/javax.xml.parsers.DocumentBuilderFactory. None of
>> > this appears to work - does anyone have any suggestions as to how I
>> > can progress this one as I'm out of ideas....
>> >
>> > On the same theme, I had to make a change to
>> > CompositeDocumentProcessor.java in the follow snippet to find this
>> > exception stack:
>> >
>> > } catch ( Exception e ) {
>> > ContributionReadException ce = new
>> > ContributionReadException(e);
>> > error("ContributionReadException", scdlStream, ce);
>> > //throw ce;
>> > }
>> >
>> > As this exception is being consumed the fact that scdlStream is null
>> > (in this case) is being ignored - so this exception in the normal 1.3
>> > RC3 codebase manifests itself as an NPE. Does anyone know why this is
>> > commented out?
>> >
>> > Cheers,
>> >
>> > Dave.
>> >
>> >
>> > --
>> > Dave Sowerby MEng MBCS
>> >
>> >
>> >
>> > 2008/8/2 Raymond Feng <[EMAIL PROTECTED]>:
>> >> Hi，
>> >>
>> >> It seems that the composite file is not utf-8 encoded. Do you have the
>> >> encoding for the <?xml ...>?
>> >>
>> >> Thanks,
>> >> Raymond
>> >>
>> >> Sent from my iPod
>> >>
>> >> On Aug 2, 2008, at 2:59 AM, "Dave Sowerby" <[EMAIL PROTECTED]>
>> >> wrote:
>> >>
>> >>> Hi All,
>> >>>
>> >>> I'm having an issue with 1.3 RC3 when trying to lookup a Service from
>> >>> with an EJB (within Websphere 6.1)
>> >>>
>> >>> After quite a bit of investigation, I managed to dig out this stack,
>> >>> which had been consumed:
>> >>>
>> >>> Caused by:
>> >>> org.apache.tuscany.sca.contribution.service.ContributionReadException:
>> >>> org.apache.xerces.impl.io.MalformedByteSequenceException: Invalid byte
>> >>> 2 of 2-byte UTF-8 sequence.
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:107)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.read(CompositeDocumentProcessor.java:56)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.read(ExtensibleURLArtifactProcessor.java:96)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:492)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:387)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:189)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:489)
>> >>> at
>> >>> org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:186)
>> >>> at
>> >>>
>> >>> org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
>> >>>
>> >>> Further debugging highlighted that the contribution is loaded from a
>> >>> wsjar:file:/ protocol based file, is it possible that a change similar
>> >>> to TUSCANY-2219 is required here as well to cope with this case?
>> >>>
>> >>> I can prepare an example which demonstrates this case if it's useful.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Dave.
>> >>>
>> >>> --
>> >>> Dave Sowerby MEng MBCS
>> >>
>> >
>
> Hi Dave, have you got the classpath for this webapp set to parent last?
>
> The code that consumes the exception is intended to cache the exception in
> the Monitor for later analysis by the runtime. This happens in various
> places now but obviously we have to be careful that this doesn't have any
> adverse effects to subsequent processing. This must be a case that we didn't
> get right so we need to fix it as the intention isn;t to just swallow the
> excetion silently.
>
> Regards
>
> Simon
>
