Ok thanks Andreas I will look into that.
Andreas Veithen wrote:
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.
