You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Dave Sowerby <da...@gmail.com> on 2008/08/02 11:59:36 UTC

Problem using createSCANodeFromClassLoader from an EJB with websphere

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

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
Hey Simon,

Thanks for the hard work on this - it's very much appreciated!

I'll give this a whirl now and see how I get on :)

Cheers,

Dave.

--
Dave Sowerby MEng MBCS



2008/8/5 Simon Laws <si...@googlemail.com>:
>
>
> 2008/8/4 Dave Sowerby <da...@gmail.com>
>>
>> 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 <si...@googlemail.com>:
>> >
>> >
>> > 2008/8/3 Dave Sowerby <da...@gmail.com>
>> >>
>> >> 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 <si...@googlemail.com>:
>> >> >
>> >> >
>> >> > 2008/8/3 Dave Sowerby <da...@gmail.com>
>> >> >>
>> >> >> 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 <da...@gmail.com>:
>> >> >> > 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 <en...@gmail.com>:
>> >> >> >> 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"
>> >> >> >> <da...@gmail.com>
>> >> >> >> 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
>
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Simon Laws <si...@googlemail.com>.
2008/8/4 Dave Sowerby <da...@gmail.com>

> 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 <si...@googlemail.com>:
> >
> >
> > 2008/8/3 Dave Sowerby <da...@gmail.com>
> >>
> >> 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 <si...@googlemail.com>:
> >> >
> >> >
> >> > 2008/8/3 Dave Sowerby <da...@gmail.com>
> >> >>
> >> >> 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 <da...@gmail.com>:
> >> >> > 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 <en...@gmail.com>:
> >> >> >> 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" <
> dave.sowerby@gmail.com>
> >> >> >> 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

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
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 <si...@googlemail.com>:
>
>
> 2008/8/3 Dave Sowerby <da...@gmail.com>
>>
>> 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 <si...@googlemail.com>:
>> >
>> >
>> > 2008/8/3 Dave Sowerby <da...@gmail.com>
>> >>
>> >> 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 <da...@gmail.com>:
>> >> > 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 <en...@gmail.com>:
>> >> >> 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" <da...@gmail.com>
>> >> >> 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
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
Hi Simon,

Please find attached the example.

It should just be a case of building the example from simple.zip, then
deploying the ear - I've got the ejb bound to jndi name
"ejb/SimpleService"

The simple-ejb-client.zip is an eclipse project, which needs to
variables defined: WEBSPHERE_HOME and M2_REPO it also needs to be
executed within an IBM JDK.

The host and port are hardcoded in there, so you'll probably need to
update those as appropriate.

Cheers,

Dave.

--
Dave Sowerby MEng MBCS

2008/8/4 Simon Laws <si...@googlemail.com>:
>
>
> 2008/8/3 Dave Sowerby <da...@gmail.com>
>>
>> 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 <si...@googlemail.com>:
>> >
>> >
>> > 2008/8/3 Dave Sowerby <da...@gmail.com>
>> >>
>> >> 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 <da...@gmail.com>:
>> >> > 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 <en...@gmail.com>:
>> >> >> 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" <da...@gmail.com>
>> >> >> 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
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Simon Laws <si...@googlemail.com>.
2008/8/3 Dave Sowerby <da...@gmail.com>

> 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 <si...@googlemail.com>:
> >
> >
> > 2008/8/3 Dave Sowerby <da...@gmail.com>
> >>
> >> 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 <da...@gmail.com>:
> >> > 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 <en...@gmail.com>:
> >> >> 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" <da...@gmail.com>
> >> >> 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

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
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 <si...@googlemail.com>:
>
>
> 2008/8/3 Dave Sowerby <da...@gmail.com>
>>
>> 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 <da...@gmail.com>:
>> > 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 <en...@gmail.com>:
>> >> 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" <da...@gmail.com>
>> >> 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
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Simon Laws <si...@googlemail.com>.
2008/8/3 Dave Sowerby <da...@gmail.com>

> 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 <da...@gmail.com>:
> > 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 <en...@gmail.com>:
> >> 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" <da...@gmail.com>
> 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

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
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 <da...@gmail.com>:
> 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 <en...@gmail.com>:
>> 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" <da...@gmail.com> 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
>>
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
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 <en...@gmail.com>:
> 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" <da...@gmail.com> 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
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Raymond Feng <en...@gmail.com>.
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" <da...@gmail.com>  
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

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Dave Sowerby <da...@gmail.com>.
Thanks Simon - I'll throw together an example of this behaviour now.

Cheers,

Dave.

--
Dave Sowerby MEng MBCS



On Sat, Aug 2, 2008 at 11:41 AM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Sat, Aug 2, 2008 at 10:59 AM, Dave Sowerby <da...@gmail.com>
> 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
>
> It looks like TUSCANY-2219 has been applied to NodeImpl but of course the
> code path in your example may not be hitting it for some reason. Looking at
> the stack trace it looks like it has actually identified a .composite file
> artifact in the contribution as it's got into the read phase but then if
> gets the Xerces exception. Is there anything strange about your composite
> file.
>
> If you attach an example one of us can give it a spin and see what's going
> on.
>
> Thanks
>
> Simon
>

Re: Problem using createSCANodeFromClassLoader from an EJB with websphere

Posted by Simon Laws <si...@googlemail.com>.
On Sat, Aug 2, 2008 at 10:59 AM, Dave Sowerby <da...@gmail.com>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

It looks like TUSCANY-2219 has been applied to NodeImpl but of course the
code path in your example may not be hitting it for some reason. Looking at
the stack trace it looks like it has actually identified a .composite file
artifact in the contribution as it's got into the read phase but then if
gets the Xerces exception. Is there anything strange about your composite
file.

If you attach an example one of us can give it a spin and see what's going
on.

Thanks

Simon