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<[email protected]> 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<[email protected]> 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