Thank you for your answer.
We decided, on our side, to not go further in the migration process,
and stick currently to Axis1, because :
- the session : flash webservices classes do not support WS-
Adressing, (and we cannot add a custom soap enveloppe).
- complex beans with arrays would have made us use the wsdl2java
which would have been a major rewrite of the app (a dozen services,
maybe 50 operations per service, a lot of beans, ...)
and a lack of time to do all of this, we sadly a small structure and
cannot afford having these kind of major changes.
Thanks anyway.
Tom
On 5 avr. 08, at 16:43, Anne Thomas Manes wrote:
I gather that your original WSDL is using RPC/encoded.
Axis2 does not support SOAP encoding, and it is more rigorous about
SOAP and WSDL conformance than Axis. According to the specifications,
faults MUST be defined using document/literal; therefore, the fault
message parts MUST reference elements rather than types.
Try this:
In the bindings, change all use="encoded" attributes to use="literal".
In your types section, add an element definition for each fault
message and define its type as the type used in the part definition,
e.g., for this fault:
<wsdl:message name="OurCustomException">
<wsdl:part name="fault" type="impl:OurCustomException"/>
</wsdl:message>
define the following element:
<xsd:element name="OurCustomException"
type="impl:OurCustomException"/>
And modify the fault message definition like so:
<wsdl:message name="OurCustomException">
<wsdl:part name="fault" element="impl:OurCustomException"/>
</wsdl:message>
Anne
On Tue, Apr 1, 2008 at 10:21 AM, Thomas Burdairon
<[EMAIL PROTECTED]> wrote:
Thank you for your advices, I'm trying to generate java classes
from my old
wsdl files,
and while java files are generated almost without problems (need
to remove
some use="encoded" so the operation is OK),
I cannot manage to generate java files from WSDL with operations
declared
with faults.
ex :
<wsdl:message name="OurCustomException">
<wsdl:part name="fault" type="impl:OurCustomException"/>
</wsdl:message>
-> we get Part 'fault' of fault message
'{urn:our.package.SoapGeography}
OurCustomException' must be defined with 'element=QName' and not
'type=QName'
-> change to element="impl:OurCustomException"
But at this time we get some
Exception in thread "main"
org.apache.axis2.wsdl.codegen.CodeGenerationException:
org.apache.axis2.wsdl.codegen.CodeGenerationException:
org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type
was mapped
to the name OurCustomException with namespace
urn:our.package.SoapGeography
that prevent java classes to be generated, and I cant see what's
wrong.
the command line used is :
.build/axis2-1.3/bin/wsdl2java.sh -d xmlbeans -uri
~/Desktop/wsdls/Geography.wsdl -ss -g -sd -o output -p our.package
Another question while here :
In Axis 1.4, we were using the class
org.apache.axis.handlers.SimpleSessionHandler to manage the session.
On 1st works, i used a soapsession for my services and so my
messages now
contain some WS Addressing parts.
The problem is that our clients are written in flash
actionscript, and
webservice is very limited on this platform, and the addressing
namespace
does not seem to be declared.
Is there any simplier solution?
Has anybody ever used Flash with axis2 and a session management ?
Thanks for your time !
Tom
On 29 mars 08, at 14:14, Anne Thomas Manes wrote:
If you want to keep the WSDL the same, then I suggest you use the
WSDL-first approach rather than the POJO approach. Take the WSDL
from
your Axis 1.4 service and use WSDL2Java to generate a new service
skeleton.
Anne
On Fri, Mar 28, 2008 at 5:47 AM, Thomas Burdairon
<[EMAIL PROTECTED]> wrote:
Greatings
I'm working on a migration from Axis1.4 to Axis2 1.3.
We choosed to use the POJO approach since it seems to be the
easiest
one. That means I don't generate my WSDL, they are
autogenerated by
axis.
I am currently encountering 2 major problems.
- Beans presents in WSDL
Some of our services return different objects depending of the
parameters. To do so, we have a simple inheritance schema that
look
like :
interface A
object B implements Aobject C implement A...
All the methods in the service return A, so by default the
generated
WSDL only contains the definition of A.
In Axis1, there an extraClasses parameter in the WSDL that we were
using to declare objects B and C.I couldn't find an equivalent in
Axis2 (in the service.xml).I've read http://issues.apache.org/
jira/
browse/AXIS2-1056, but it seem to fix only java2wsdl and this
isn't
what I am looking for.Is there any way for it?or, in your opinion,
would a patch be easy to write?
- Beans description in WSDL for List :Some of the javabeans
sent or
received by our webservices contains List
One nice feature in axis1 was that java.util.List were
converted in
the WSDL as type="impl:ArrayOf_xsd_anyType"Now, it looks like
type="xs:anyType"
i tried to convert some of them ito arrays, just to see and i get
maxOccurs="unbounded" minOccurs="0" seems weird since it is not
explicitly said it is an array, but why not ...
problem is i used to use List<Number> as type and it's strangely
deserialized.is Number type supported by Axis2?is there an
official
list of supported java types ?
thanks for your time and your answers
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
