There are different options to specify the default implementations for DocumentBuilder; Dims only mentioned one. See the Javadoc of DocumentBuilderFactory#newInstance() for more details.
Andreas On Fri, Jul 17, 2009 at 22:17, Demetris G<demet...@ece.neu.edu> wrote: > > So - any suggestions on this? Unless I manage to replace the GNU classpath > Parser on the mobile device I have no hope on running Axis/Axis2 on it > correct? > Any other ideas from anyone regarding running a SOAP server engine on a > mobile > device? > Dennis - would JiBX be my only hope? > > Thanks very much > > Demetris G wrote: >> >> Hi Andreas and Dims, >> >> this is what the code that Dims suggested returns in the respective >> devices - >> >> on device #1 (linunx desktop) where the WSDL is parsed I get - >> Parser is >> com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl >> >> on device #2 (Nokia N800 Linux) where the WSDL is generated I get the >> gnu parser ... >> Parser is gnu.xml.dom.DomDocumentBuilder >> >> So apparently the two parsers are different - one options as you >> suggsted >> was to drop the xerces parser into the jre of the runtime I use. I am not >> sure where >> that would be in Jalimo-Java but I will look around. >> >> Thanks again >> >> >> Andreas Veithen wrote: >>> >>> 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. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> >>>>> >>> >>> >> >