Re: WSDL gen error

[Demetris G]

Hi Dennis,
  
   apologies - I jumped into asking the Q without thinking ;)

   We need to run apps on mobile devices (as I mentioned in the past 
these are powerful devices such
as the Nokia N800 running Linux) that require both having Web services 
hosted locally on the device
as well as using local Web service clients to call remote Web Services. 
By running Axis 1.4 within an
OSGi container and over Jalimo (GNU classpath Java) I was able to build 
Web Service clients that can
call remote Web Services and retrieve their WSDL files. Subsequently I 
was able to use these WSDL files
to build stubs right on the devices (running the WSDL2Java module) and 
eventually use them in client
code to invoke the Web services.  The compilation of the stubs occurs 
off the device. This was straight
forward.
   But having the device host Web Services and register them in a local 
Axis server does not seem to
work - as I mentioned the WSDL generated is not valid etc. So I am 
trying now to (i) figure out
what is going on with the generation of the WSDL under Jalimo and (ii) 
to find an alternative solution
to abandon the Jalimo Java that causes these issues and run things over 
J2ME CDC runtimes. But
I cannot find - or this simply does not exist - J2ME CDC based SOAP engines.
   So my issue was indeed the WSDL generation on the mobile device and 
not the code generation
from it.
 
That's where I am at ...

Dennis Sosnoski wrote:
I'm not exactly sure what you're trying to do, Demetris. I haven't 
been following this thread, but if you're trying to generate code from 
WSDL on a mobile client you're probably going to have a very difficult 
time of it no matter what tool you use - JiBX's code generation from 
schema is only intended to work on JDK 1.4.1+, for instance.

Is there a reason you need to generate code on the mobile client? If 
you can do the code generation separately and then deploy the 
generated code to the client you'd probably be able to get things 
working using JiBX/WS.

 - Dennis


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