Re: How can I get a class Holder
Hi wei, For an example of how to generate a holder class have a look at the $AXIS_HOME/test/wsdl/wrapperHolder or wrapperHolder2 tests packaged with the axis source distribution! Regards, Hans wei dongfeng wrote: >Hi, > I'm a learner. > It says in the axis documents "A holder class is only generated for a >type if that type is used as an inout or out parameter".But how can I get >the type which is used as an inout or out parameter?Can you give me an >example in which a holder class is generated when I run java >org.apache.axis.wsdl.WSDL2Java?Please help me! Thanks a lot > > >
Re: xsd:any
Done - http://issues.apache.org/jira/browse/AXIS-2301 I will attach a testcase and maybe a fix later on. Regards, Hans Davanum Srinivas wrote: Please log a bug with your WSDL. thanks, dims On 11/10/05, Hans Planting (CWEU-USERS/CWNL) <[EMAIL PROTECTED]> wrote: Hi there, According to the JAX-RPC 1.1 specification xsd:any should be mapped to an attribute of type javax.xml.soap.SOAPElement when maxOccurs="1", or javax.xml.soap.SOAPElement[] when maxOccurs is greater than 1. However, Axis will always generate an array, regardless of the maxOccurs attribute - should this be considered a bug? I didn't find any related issues in Jira. Did anyone experience interoperatability problems because of this (for example when receiving or sending a message to a .net webservice)? Kind regards, Hans -- Davanum Srinivas : http://wso2.com/blogs/
xsd:any
Hi there, According to the JAX-RPC 1.1 specification xsd:any should be mapped to an attribute of type javax.xml.soap.SOAPElement when maxOccurs="1", or javax.xml.soap.SOAPElement[] when maxOccurs is greater than 1. However, Axis will always generate an array, regardless of the maxOccurs attribute - should this be considered a bug? I didn't find any related issues in Jira. Did anyone experience interoperatability problems because of this (for example when receiving or sending a message to a .net webservice)? Kind regards, Hans
Re: SOAP:Header question
It should look like:
**
...
...
http://xxx/webservices/GetFinancialDetail";
style="document" />
...
When running wsdl2java you should get something like 'getFinancialData(String
clientid, Authorization auth)' as the webservices endpoint method. The clientid
will be sent in the soap:body, the auth in the soap:header of the envelope.
The Axis java source distribution contains a good example of this in
[axishome]/test/wsdl/header
Hans
You got the idea: have the endpoint method (getFinancialData) handle this
data - and obviously, it requires extra parameters to do that. The question
is how to transfer this authentication data from the header to this
parameter.
Or do I misunderstand?
Just for clearence:
I got a WSDL from which I created the JAVA sources using WSDL2Java
--server-side, that gave me (amongst others) OrgWebservice.java and
OrgWebServiceImpl.java. The last one is the one that implements the actual
services, amongst the GetFinancialDetails (java.lang.String clientid). Is
that what you call the "endpoint method"?
Obviously, that one nedds to get the authentication data, and I don't care
if that would be in the form of an object:
Object class Authentication
java.lang.String region ;
java.lang.String department ;
java.lang.String desk ;
java.lang.String username ;
or whatever, or as separate arguments. Lets assume the first.
So the service - now generated as:
FinDetails class getFinancialDetails (java.lang.String clientid)
would need to be:
FinDetails class getFinancialDetails (java.lang.String clientid,
Authetication authentication)
so I could use the data - directly or by a getter.
Would this be the idea of WSDL:
...
...
...
http://xxx/webservices/GetFinancialDetail";
style="document" />
...
This is in the WSDL already, but the header data is not included in the
generated JAVA code:
public interface OrgWebServiceSoap extends java.rmi.Remote {
...
public xxx.FinDetails getFinancialDetail(java.lang.String clientid) ;
...
}
and I don't find any refererence to the haeder data either when searching
all java files.
So HOW to change the WSDL to get this information included in the interface?
Or should I just add it and create a WSDL from the java code? Quite a nasty
job since so much needs to be coded. By that: the nasty part, at the moment,
is that the WSDL is _delivered_ to me - there is already a webservice (on
another platform) that works with it. The good side is that we're in the
stage of preparing a new version so changes can be incoprorated. If only I
had some idea.
Willem
PS. Original names in code adapted for display, because of policy.
-Oorspronkelijk bericht-
Van: Hans Planting (CWEU-USERS/CWNL)
[mailto:[EMAIL PROTECTED]
Verzonden: donderdag 20 oktober 2005 11:29
Aan: axis-user@ws.apache.org
Onderwerp: Re: SOAP:Header question
Hi Willem,
It sounds to me that you need to use explicit service context: the
signature of the webservices endpoint method is extended with the parts
of the soap:header.
This way the getFinancialDetails method will have an additional
parameter for the authentication data - however the authentication data
in the soap envelope is transported in the header. So you don't create a
separate handler to deal with the header but instead deal with it in the
endpoint method. Make sure that in the wsdl the soapheader element
refers to a part in the request message.
Regards,
Hans
Hi,
Some help is rquired with the following problem:
I have an application on a OpenVMS system that is used by different
regional
offices, where all use the same executables, but the data is completely
separated. If a person logs in, the OS will know which scripts to execute
to
setup the right paths to the data, and the application will then be able to
check the authorisations of that user. If the user uses the application, he
will only have access - by this setup - to the data of his regional office.
It happens that a .NET application will access the data by a SOAP-based
webservice. This application is used by the same regional offices that use
the OpenVMS application, and will access only the data of that office. Only
users of the .NET application that are authorized will be allowed access -
be it anyone within a deparetment, or a specific user. In some cases, data
can just be accessed if requested from a certain desk only.
This authorization is set within the dataset on the VMS machine and
maintained on that system only (for security reasons).
That means that the webservice needs to be able to set the right access
paths to the data, in order to check access by that
Re: SOAP:Header question
Hi Willem, It sounds to me that you need to use explicit service context: the signature of the webservices endpoint method is extended with the parts of the soap:header. This way the getFinancialDetails method will have an additional parameter for the authentication data - however the authentication data in the soap envelope is transported in the header. So you don't create a separate handler to deal with the header but instead deal with it in the endpoint method. Make sure that in the wsdl the soapheader element refers to a part in the request message. Regards, Hans Hi, Some help is rquired with the following problem: I have an application on a OpenVMS system that is used by different regional offices, where all use the same executables, but the data is completely separated. If a person logs in, the OS will know which scripts to execute to setup the right paths to the data, and the application will then be able to check the authorisations of that user. If the user uses the application, he will only have access - by this setup - to the data of his regional office. It happens that a .NET application will access the data by a SOAP-based webservice. This application is used by the same regional offices that use the OpenVMS application, and will access only the data of that office. Only users of the .NET application that are authorized will be allowed access - be it anyone within a deparetment, or a specific user. In some cases, data can just be accessed if requested from a certain desk only. This authorization is set within the dataset on the VMS machine and maintained on that system only (for security reasons). That means that the webservice needs to be able to set the right access paths to the data, in order to check access by that user, on a request-by-request basis, because, IIRC, SOAP:Header can contain authentication information, and this can be specified in some structure. So my idea is to use a structure in the SOAP:header, since it is required for each and every request. An example: I'm working at the ICT department, and logged in on PC at the infodesk of region . I need to get information on the financial details of client with code 123456. The ,NET application will build up a SOAP message containing my login information (in the header) and the requested information in the body: ITC infodesk Grooters 123456 and sends it to tehet webservice, method "getFinancialDetails" The method would normally get the clientid from AXIS, but it needs the header information as well, to be able to: 1 Set the right access paths to the data () 2 Authorize the request (against the data of region ) (, and 3 If authorized, access the data of the client () The problem is that it seems that I have no access to the header information when I need it: in the service itself. How can this be solved - with this info in the SOAP Header - not moved to the body (I'm stuck to this structure) Disclaimer: The information contained in this E-mail and its attachments is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance of the contents of this E-mail and any attachments is strictly prohibited and may be unlawful. The CIP or ISC is neither liable for the proper and complete transmission of the information contained in this E-mail and any attachments nor for any delay in its receipt. If received in error, please contact The CIP or ISC on +31(0)522 72 quoting the name of the sender and the addressee and then delete it from your system. Please note that the The CIP or ISC does not accept any responsibility for viruses and it is your responsibility to scan the E-mail and attachments (if any). No contracts may be concluded on behalf of The CIP or ISC by means of E-mail communications.
Re: set headers on the function return message ?
Hi, If you want your server to return a response message with soap:headers you can either create a handler that adds a header to the soap message (implicit service context) or you could let axis generate ws specific implementation classes for your server from your wsdl (wsdl2java -s) and have soap:headers specified there. If the part in the header refers to a part in the response message, then the header will become a part of the signature of the endpoint method in the implementation class (though the data is send in the soap message of course). This way the class handling the service will deal with soap:headers. Regards, Hans Tiberiu Stef-Praun wrote: Hi I have an axis-based web service which I need it to be able to send me some headers in addition to the actual return value. I can set headers easily on the request, but I have not figured out how to set them on the message containing the return value. Do I need to install a handler for this web service, and manage the headers in the handler, or can I do the trick from the class implementing the service itself ? The trick with returning an AxisFault is a hack... is there any other way ? Thanks Tiberiu
Re: soap:headers and explicit service context
Check JAX-RPC 1.1 #11.2 and WSDL 1.1 Example 3. Change your wsdl to something like: * * Reset a user's password * * I'm not sure I follow, given these fragments, why don't any of the headers specified in the binding appear in the method signature ? Is this another JAX-RPC snafu ? Cheers Simon Reset a user's password -Original Message- From: Hans Planting (CWEU-USERS/CWNL) [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 2:25 AM To: axis-user@ws.apache.org Subject: Re: soap:headers and explicit service context Hi, But it doesn't expose these headers are part of the method signature. This is what I thought as well, hence my question, but it turns out my wsdl was incorrect. If you want your soap:headers be part of the method signature (explicit service context) then as far as I understand it you need to set the part attribute of the soap:header to a wsdl:part in the wsdl:message that is refered to by the wsdl:input/wsdl:output of the wsdl:operation. If the part attribute refers to a part in a message not refered to by the input or output of the message then the header parts will not be part of the method signature and you need to write custom handlers in order to deal with headers (implicit service context). However there are still a couple of strange things I encountered when using soap:headers in document/literal style documents: - the parameters generated from the wsdl:input parts are wrapped in a java object, while when not using headers they are not; - when combining explicit and implicit soap:headers in one wsdl document the wrapped java object mentioned above is not generated but is actually refered to by the generated stub. Regards, Hans But it doesn't expose these headers are part of the method signature. You're left to call setHeader yourself (and therefore have to manualy copy over the element names & namespaces from the WSDL, which is error prone). I think I logged a bug for this a while back. Cheers Simon -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 7:35 AM To: axis-user@ws.apache.org Subject: Re: soap:headers and explicit service context If you set up the wsdl correctly, then the generated code has the addition java objects for the stuff in soap headers. -- dims On 8/23/05, Hans Planting (CWEU-USERS/CWNL) <[EMAIL PROTECTED]> wrote: Hi there, Is there support planned for explicit soap headers as described in JAX-RPC 1.1 chapter 11.2.2? With explicit soap headers I'd expect Axis to append additional parameters for soap:headers following the service endpoint defined paramers in the remote method signature. Also no custom parsing/deserialization would need to be implemented. Currently in order to process soap:headers you need to implement a handler or use the setHeader and getHeader methods in org.apache.axis.client.Stub and in both cases implement code to parse/deserialize the soap elements; Axis does not deserialize the contents of soap:headers to Java objects (correct me if I'm wrong - is there a way to do this?). Thanx! Hans -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: soap:headers and explicit service context
Hi, But it doesn't expose these headers are part of the method signature. This is what I thought as well, hence my question, but it turns out my wsdl was incorrect. If you want your soap:headers be part of the method signature (explicit service context) then as far as I understand it you need to set the part attribute of the soap:header to a wsdl:part in the wsdl:message that is refered to by the wsdl:input/wsdl:output of the wsdl:operation. If the part attribute refers to a part in a message not refered to by the input or output of the message then the header parts will not be part of the method signature and you need to write custom handlers in order to deal with headers (implicit service context). However there are still a couple of strange things I encountered when using soap:headers in document/literal style documents: - the parameters generated from the wsdl:input parts are wrapped in a java object, while when not using headers they are not; - when combining explicit and implicit soap:headers in one wsdl document the wrapped java object mentioned above is not generated but is actually refered to by the generated stub. Regards, Hans But it doesn't expose these headers are part of the method signature. You're left to call setHeader yourself (and therefore have to manualy copy over the element names & namespaces from the WSDL, which is error prone). I think I logged a bug for this a while back. Cheers Simon -Original Message- From: Davanum Srinivas [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 23, 2005 7:35 AM To: axis-user@ws.apache.org Subject: Re: soap:headers and explicit service context If you set up the wsdl correctly, then the generated code has the addition java objects for the stuff in soap headers. -- dims On 8/23/05, Hans Planting (CWEU-USERS/CWNL) <[EMAIL PROTECTED]> wrote: Hi there, Is there support planned for explicit soap headers as described in JAX-RPC 1.1 chapter 11.2.2? With explicit soap headers I'd expect Axis to append additional parameters for soap:headers following the service endpoint defined paramers in the remote method signature. Also no custom parsing/deserialization would need to be implemented. Currently in order to process soap:headers you need to implement a handler or use the setHeader and getHeader methods in org.apache.axis.client.Stub and in both cases implement code to parse/deserialize the soap elements; Axis does not deserialize the contents of soap:headers to Java objects (correct me if I'm wrong - is there a way to do this?). Thanx! Hans -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: soap:headers and explicit service context
Ok, but if I for example use 'getHeader' in org.apache.axis.client.Stub, I get a SOAPHeaderElement - is there a way to deserialize this to a java object (using BeanDeserializer etc) without having to write code to parse the contents of the elements? Hans Davanum Srinivas wrote: If you set up the wsdl correctly, then the generated code has the addition java objects for the stuff in soap headers. -- dims On 8/23/05, Hans Planting (CWEU-USERS/CWNL) <[EMAIL PROTECTED]> wrote: Hi there, Is there support planned for explicit soap headers as described in JAX-RPC 1.1 chapter 11.2.2? With explicit soap headers I'd expect Axis to append additional parameters for soap:headers following the service endpoint defined paramers in the remote method signature. Also no custom parsing/deserialization would need to be implemented. Currently in order to process soap:headers you need to implement a handler or use the setHeader and getHeader methods in org.apache.axis.client.Stub and in both cases implement code to parse/deserialize the soap elements; Axis does not deserialize the contents of soap:headers to Java objects (correct me if I'm wrong - is there a way to do this?). Thanx! Hans
soap:headers and explicit service context
Hi there, Is there support planned for explicit soap headers as described in JAX-RPC 1.1 chapter 11.2.2? With explicit soap headers I'd expect Axis to append additional parameters for soap:headers following the service endpoint defined paramers in the remote method signature. Also no custom parsing/deserialization would need to be implemented. Currently in order to process soap:headers you need to implement a handler or use the setHeader and getHeader methods in org.apache.axis.client.Stub and in both cases implement code to parse/deserialize the soap elements; Axis does not deserialize the contents of soap:headers to Java objects (correct me if I'm wrong - is there a way to do this?). Thanx! Hans
