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

Reply via email to