problem in generating a oneway web service from a java class in Axis 1.4

2009-09-03 Thread Akitoshi Yoshida
Hi,
When you deploy a service that has a void return type in Axis 1.4, I
noticed that its WSDL generator does not generate a oneway MEP WSDL
(i.e., having only the input element) but a normal request-response
MEP WSDL (i.e., having both the input and output elements). And when
the call is invoked, the service returns HTTP 200 with an empty SOAP
message instead of an HTTP 202 with no content.

I found a related issue AXIS-2538 in JIRA,  which talks about the
oneway issue for creating a java stub class from a oneway WSDL., but
didn't find the ticket for the other direction.

I modified the generator so that you get the correct oneway MEP WSDL
at the WSDL URL (http://...wsdl) and you get the correct HTTP 202
response when the call is successful.

other Axis 1.4 users might be interested in this oneway handling.


Re: Axis 1.4 and MTOM

2008-08-15 Thread Akitoshi Yoshida
Hi,
I don't know how you captured the message (response.txt).
The message seems to be corrupt with its MIME headers (there is no
line delimiter in the first few lines).
I don't know if there is some interoperability problem in the Axis 1.4
implementation.
Is it also not working if your client is talking to the Axis 1.4
server talking MTOM?

We have some MTOM scenarios with Axis 1.4.

Regards, Aki

2008/8/14  [EMAIL PROTECTED]:
 Hi group,



 I am currently trying to implement an axis 1.4 web service (with a client)
 with attachments using MTOM.



 Somewhere it was said, that this is also possible with axis 1.4. But
 unfortunately I don't get it working. I'm sending the attachments from the
 server side via MTOM, but I can't receive them on the client.

 The problem seems to be on the client side. On the client I get this error:
 [#text: Error in parsing mime data stream:  null

 I included the stacktrace and the response message as attachments.



 My questions:

 · Is it possible to implement a Web Service with Attachments using
 MTOM and Axis 1.4?

 · Do I have to tell the client somehow that MTOM is being used?

 · Can you provide some help to my issue?



 The future plan is to migrate to axis2, but this would take too long for my
 current issue.

 Hopefully waiting for your answers.



 Matthias.

 -
 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]



Question on porting axis handlers to axis 2 module environment

2008-06-12 Thread Akitoshi Yoshida
Hi,
I have a best practice question on how to organize and package axis
handlers into one or more modules.

I have a set of Axis 1.4 handlers that are used in several scenarios.
Depending on the scenarios, some handlers are not placed in the handler chain.
It was easy to have various configurations in Axis 1.4 because you can
specifically place these handlers based on your scenario.

With Axis 2, this general flexibility has been replaced by a more
pluggable module model where handlers are preconfigured in some
specific order.

For example, suppose we have three distinct scenarios using Axis 1.4
handlers A, B, C, D, and E.

Each scenario is configured with

Config 1 for scenario X
A B C

Config 2 for scenario Y
A D B D C

Config 3 for scenario Z
D B E C

How should I modify the 1.4 handlers and define new modules for Axis 2?

One extreme approach would be to define a module for each distinct
scenario. But I think this is very inefficient because we will need to
define many modules and need load the same classes for each module.

Another extreme approach would be to make each handler switchable
between active and inactive and define an aggregated sequence of these
handlers to cover all scenarios A D B D E C.  In this case, turning
off D and E will result in config 1. Turning off E will result in
config 2, etc. This is actually what we currently have. But I am not
sure if there is another approach.

Any suggestion would be appreciated.

Thanks

Regards, Aki

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]