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.
