When the issue refers to "parsers", it actually means the JAXP/SAX/DOM implementation. It doesn't say whether the issue occurs during parsing or serialization (or somewhere else). Did you follow Dims suggestion and tried to determine what is the implementation used on the mobile environment?
Andreas On Wed, Jul 15, 2009 at 21:33, Demetris G<demet...@ece.neu.edu> wrote: > > Hi Andreas, > > yes you are right and may be my wording was a bit confusing. What I was > saying was that > the error is exhibited on the client side when the client modules parse the > incoming WSDL > file in order to generate the stubs- but it IS indeed originating (the error > that is) on the server > side. So is AXIS-2336 suggesting that the parsers on the server side are > also the issue? Excuse > my non-in-depth-knowledge of the Axis implementation, but does Axis use a > parser in its > WSDL generation process? What is it parsing? > > Andreas Veithen wrote: >> >> According to AXIS-2335/AXIS-2336, the issue is not on the client side >> but with the parser on the server side. >> >> On Wed, Jul 15, 2009 at 20:53, Demetris G<demet...@ece.neu.edu> wrote: >> >>> >>> Hi Dims, >>> >>> and here I was trying to figure out how to include in paths the >>> xercesImpl.jar that resides in the axis bundles >>> installation of the Knopflerfish OSGi (under fwdir/bs ...). I was not >>> sure >>> how I could have set the system properties >>> in Knopflerfish's OSGi but as you suggest the jars need to be dropped in >>> the >>> JRE dirs - I am using jre1.5.0_07 >>> on both devices and there is no endorsed dirs in there already so I am >>> assuming I will add it myself .. >>> I try what you suggest below and let you know how it behaves in the two >>> devices. Let's say it works - how would I >>> be able to includes these in the axis bundle distribution? Is there a way >>> to >>> include them without needing to modify the >>> axis bundle activator? >>> The other question I have is, I understand fully that the parser is an >>> issue on the client side, as AXIS-2336 denotes, >>> but what causes the Axis server to generate the two different WSDL tags - >>> <wsdl:types> vs. <types>? I am sure if >>> I manage to get the above to work this will go away but I am curious as >>> to >>> why these two files are different. >>> >>> Thanks for the good pointers >>> >>> Davanum Srinivas wrote: >>> >>>> >>>> Demetris, >>>> >>>> Try this piece of code in say an activator of some osgi bundle in your >>>> container on both devices. It's not the container itself that's in issue >>>> it's the active dom and sax parser at issue. >>>> >>>> Usually i'd recommend that you need to make sure that latest xerces is >>>> used by setting the system property as shown in AXIS-2336. typically it >>>> involved dropping the jars in endorsed directory of your JRE >>>> (http://java.sun.com/j2se/1.4.2/docs/guide/standards/). >>>> >>>> thanks, >>>> dims >>>> >>>> import javax.xml.parsers.DocumentBuilder; >>>> import javax.xml.parsers.DocumentBuilderFactory; >>>> >>>> DocumentBuilderFactory documentbuilderfactory = >>>> DocumentBuilderFactory.newInstance ( ) ; >>>> DocumentBuilder documentbuilder = >>>> documentbuilderfactory.newDocumentBuilder ( ) ; >>>> System.out.println ( "Parser is " + documentbuilder.getClass ( ) >>>> .getName ( ) ) ; >>>> >>>> >>>> >>>> On 07/15/2009 01:38 PM, Demetris G wrote: >>>> >>>>> >>>>> Hi Andreas, >>>>> >>>>> what Axis-2336 is clear enough as far as my knowledge of English can >>>>> tell - however, >>>>> what does that mean? Why is the same Axis binaries/configuration on two >>>>> different >>>>> Linux devices would generate two different WSDL files? Isn't that clear >>>>> enough of a question? >>>>> Regardless of what the parser is complaining about this does not seem >>>>> normal to me until >>>>> I hear an explanation for it. >>>>> May be you would be kind enough to a suggest a parser for me that would >>>>> not complain on >>>>> whatever Axis generates at all cases - if you generate it that means >>>>> you >>>>> are expecting some >>>>> parser to always deal with all of it. What do you think? >>>>> One additional pt- 2336 does not offer a resolution to my problem - >>>>> their problem was that >>>>> they were getting issues when they moved Axis on a different container. >>>>> In my case, Axis >>>>> is still soaking in the same container on both devices. >>>>> >>>>> Thanks for your response and many regards to you >>>>> >>>>> Andreas Veithen wrote: >>>>> >>>>>> >>>>>> Isn't the conclusion in AXIS-2336 clear enough: "Problem is with the >>>>>> XML parser, not Axis" ? >>>>>> >>>>>> On Wed, Jul 15, 2009 at 17:37, Demetris G<demet...@ece.neu.edu> wrote: >>>>>> >>>>>>> >>>>>>> I have been asking this Q below on the axis-user but didn't get much >>>>>>> response. I am hoping >>>>>>> someone on the dev side may have some insights - as a complementary >>>>>>> to what >>>>>>> I am asking >>>>>>> below here is the exception I get - apologies to those who are >>>>>>> subscribed to >>>>>>> both mailing lists >>>>>>> and this is a multiple posting to them: >>>>>>> >>>>>>> We have the Axis (1.4) bundles running in the OSGi container on a set >>>>>>> of >>>>>>> Linux machines with >>>>>>> no issues. Web Services can be published and invoked upon - the WSDL >>>>>>> files >>>>>>> that are generated >>>>>>> by these Axis bundles are correct and they can generate correct >>>>>>> operational >>>>>>> stubs. >>>>>>> We needed to run a few of these on some powerful mobile devices that >>>>>>> can >>>>>>> actually run Jalimo, >>>>>>> a full version (for fhe most part) of Java 1.5 based on the GNU >>>>>>> libraries. >>>>>>> So we simply installed >>>>>>> the same OSGi container and Axis (1.4) bundles on them and ran them. >>>>>>> The >>>>>>> Axis servers work >>>>>>> as they should, the generate WSDL files when invoked - however, the >>>>>>> WSDL >>>>>>> file they generate >>>>>>> encaplsulate the scheme definitions in <types> tags instead of >>>>>>> <wsdl:types> >>>>>>> ! This is an issue >>>>>>> because the XML parsers that process <wsdl:types> tags nicely have a >>>>>>> problem with the <types> >>>>>>> tags. >>>>>>> After hours of searching I came upon this - >>>>>>> http://issues.apache.org/jira/browse/AXIS-2336. >>>>>>> Others a while back have encountered the same issue when running Axis >>>>>>> on >>>>>>> particular containers. >>>>>>> However, (a) their resolution is specific to their container (b) my >>>>>>> issue is >>>>>>> not the type of container >>>>>>> since the OSGi container works fine with Axis. My issue is that I >>>>>>> moved more >>>>>>> a Linux desktop >>>>>>> to a Linux mobile device, even though the executables and runtime >>>>>>> remained >>>>>>> the same. >>>>>>> >>>>>>> In case it helps the case here is the exception I get on the client >>>>>>> side - >>>>>>> >>>>>>> [java] WSDLException (at /wsdl:definitions/types): >>>>>>> faultCode=INVALID_WSDL: >>>>>>> Encountered illegal >>>>>>> extension element 'types' in the context of a >>>>>>> 'javax.wsdl.Definition'. >>>>>>> Extension elements must be in a namespace >>>>>>> other than WSDL's.: >>>>>>> [java] at >>>>>>> com.ibm.wsdl.xml.WSDLReaderImpl.parseExtensibilityElement(Unknown >>>>>>> Source) >>>>>>> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown >>>>>>> Source) >>>>>>> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >>>>>>> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >>>>>>> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >>>>>>> [java] at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) >>>>>>> [java] at Utils.myWSDLParser.parseWSDL(myWSDLParser.java:46) >>>>>>> >>>>>>> Any ideas greatly appreciated - thanks. >>>>>>> >>>>>>> >>>>>>> >> >> >
