2008/8/4 Dave Sowerby <[EMAIL PROTECTED]>
> Hey Simon,
>
> Just realised I never responded to you questions - you are correct in
> your xalan/xerces comments - any webapp deployments we have made to
> websphere have required these additional jars.
>
> Dave.
>
> --
> Dave Sowerby MEng MBCS
>
>
>
> 2008/8/4 Simon Laws <[EMAIL PROTECTED]>:
> >
> >
> > 2008/8/3 Dave Sowerby <[EMAIL PROTECTED]>
> >>
> >> 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
> >> >
> >
> > Hi Dave
> >
> > Looking at google this has come up a few times and seems to be resolved
> by
> > doing the kinds of things you are already suggesting. I.e. checking
> Xerces,
> > Xalan, JAXP versions. Are you able to go ahead and give us a sample we
> can
> > try to see if we run into the same issue?
> >
> > Is it just the one application that fails for you. Do the samples run OK?
> > When testing for 1.3 I found that the calculator-webapp did need the
> xalan
> > and xerces jars copying into webapp/lib. However the calculator-ws-webapp
> > ran in websphere out of the box. Is that true for you?
> >
> > Simon
> >
>
Hi Dave,
I've made some progress on this. What I now see when I run the client is:
Attempting to say Hello to: Tuscany
Result: Hello Tuscany!
The changes I made to get to this are as follows...
simple-ear/pom.xml added
<!-- exclude stax 1.0.1 as we're also pulling in
javax\xml\stream\stax-api\1.0-2 -->
<dependency>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
<version>1.0.1</version>
<scope>provided</scope>
</dependency>
<!-- exclude xml-apis-1.3.03.jar as it is causing an incompatibility
with WebSphere -->
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.3.03</version>
<scope>provided</scope>
</dependency>
</dependencies>
The first one was just a tidy up as the EAR had two copies of stax
The second one fixes the
java.lang.ClassCastException:org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
incompatible with javax.xml.parsers.DocumentBuilderFactory problem by
exluding the Tuscany copy of the XML APIs. I have to admit that I'm not
absolutely sure what's going on. It seems that we are successfully able to
run Tuscany sample webapps in WebSphere with this in place but it cases a
problem in this EAR file. Even if I copy in versions of Xerces and Xalan
that I believe are compatible with xml-apis-1.3.03 it doesn't work. I'm
hoping someone will give us a hand here and explain the details of
classloading in an EAR and why this is not working.
simple-ejb/pom.xml added
<dependency>
<groupId>org.apache.tuscany.sca</groupId>
<artifactId>tuscany-implementation-java-runtime</artifactId>
<version>${tuscany.version}</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.example</groupId>
<artifactId>simple-impl</artifactId>
<version>${project.version}</version>
</dependency>
The composite needs implementation.java and the component implementation
class.
simple-ejb/src/main/resources/service.composite
Fixed the name of the reference target to read
target="SimpleServiceComponent"
Let me know if this works for you.
Regards
Simon
