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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>

Reply via email to