Re: Href attribute support in soap envelope body
Thanks for pointing me in the right direction, Ian. I also suspected
that it's an encoding problem but I wasn't sure.
Unfortunately, after some more trialerror tests, I didn't come to a
positive result. Removing the @SOAPBinding i.e. using wrapped
document/literal/wrapped generates a far more complex Delphi unit (that
would be the least of the problems) but furthermore, now no parameters
at all are correctly received in the Java Web service (only null values).
I looked up the Delphi documentation and after a little research added
the line
InvRegistry.RegisterInvokeOptions(TypeInfo(JobService), [ioDocument,
ioLiteral]);
in my Delphi client, so Delphi *should* definitively use
document/literal encoding. But no change.
But, if I use the document/literal/bare encoding, I receive the
following error message from CXF:
25-Feb-2008 11:05:07 org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Message part
{http://schemas.xmlsoap.org/soap/envelope/}string was not recognized.
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:178)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77)
...
Delphi sends the following SOAP request:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
stringvalueDelphi1/string
stringvalueDelphi2/string
/SOAP-ENV:stringArray
JobParamBean xmlns=http://annuaire.ciss.lu;
keykeyDelphi/key
value2/value
/JobParamBean
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This whole encoding issue is getting rather frustrating for me, having
in mind Web services should improve interoperability ... :-(
Pierre
Ian Roberts wrote:
The Delphi client is trying to use SOAP encoding (RPC/encoded) but the
CXF service expects RPC/literal. I don't know Delphi, is there any
configuration option to tell it to use literal rather than encoded?
Or if Delphi can't do RPC/literal, try removing the @SOAPBinding
annotation from your service to make it use wrapped document/literal
and see if Delphi likes that any better.
Ian
pierre post wrote:
Hi all,
I have a problem when calling an Apache CXF Web service (CXF version
is 2.0.4) running under Apache Tomcat 6 from a Delphi client program.
The third parameter JobParamBean that I receive in my Web service
on Tomcat is always null but there is no exception or any other hint
in the Tomcat logs. The parameter is a simple JavaBean class (uses
getters and setters for all properties and implements serializable).
Moreover, the problem does not appear when calling the same Web
service from a Java client. This is my Web service:
@WebService(name=JobService,
targetNamespace=http://annuaire.ciss.lu;)
@SOAPBinding(style=Style.RPC)
public interface JobService {
@WebMethod(operationName=ExecuteJob)
@WebResult(name=JobParamsOut)
public String[] executeJob(@WebParam(name=JobName) String jobName,
@WebParam(name=JobParamsIn) String[] input,
@WebParam(name=JobParamBean) JobServiceParam param) throws
ServiceException;
}
When calling this web service from the Delphi application (using the
latest available HTTPRIO component and WSDL importer), the
corresponding generated SOAP request produces null as JobParamBean
parameter:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
SOAP-ENV:Body
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:NS2=http://annuaire.ciss.lu;
NS1:ExecuteJob xmlns:NS1=http://annuaire.ciss.lu;
JobName xsi:type=xsd:stringTestFromDelphi/JobName
JobParamsIn xsi:type=SOAP-ENC:Array
SOAP-ENC:arrayType=xsd:string[2]
itemvalueDelphi1/item
itemvalueDelphi2/item
/JobParamsIn
JobParamBean href=#1 /
/NS1:ExecuteJob
NS2:JobServiceParamType id=1
xsi:type=NS2:JobServiceParamType
key xsi:type=xsd:stringparamkey/key
value xsi:type=xsd:stringparamval/value
/NS2:JobServiceParamType
/SOAP-ENV:Body
/SOAP-ENV:Envelope
I tried to call the same web service from Java (also using Apache CXF
2.0.4) and the generated SOAP request correctly creates a
JobParamBean instance:
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body
ns1:ExecuteJob
Re: Restful Declarative security?
Hi jsr-311 api 0.6 introduces a SecurityContext[1] to be available to a user code. Using Acegi (provided Acegi is enhanced a bit) as originally suggested by Donal seems like a more scalable solution in terms of the code maintenance. Cheers, Sergey [1] https://jsr311.dev.java.net/nonav/releases/0.6/index.html - Original Message - From: Arundel, Donal [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Tuesday, February 19, 2008 4:18 PM Subject: RE: Restful Declarative security? Hi again Barry, While I haven't tried this myself yet I imagine that an alternate feasible approach would be to use the ACEGI AOP support for annotations to allow you to associate roles with the JAX-RS implementation classes. ACEGI can be used to do a certain level of Authentication and authorization at the Servlet Filter level, limited to specifying Roles for a given RESt resource as mentioned in my post below. However ACEGI can also can be used to provide authorization level support for implementation code via its use of AOP and annotations (see the ACEGI docs for the Aspect-J and AOP-Alliance AOP implementations). This approach would possibly allow you to achieve what you want without needing to extend ACEGI. Maybe have a look at: http://www.acegisecurity.org/ Personally I'm not a huge fan of deployment specific annotations being embedded directly in code though, I would prefer the approach mentioned in my first mail. Security Roles are usually deployment specific data and supplying the actual values via annotations has operational consequences in terms of deployment, administration, and ease of modification. Obviously whether something is appropriate depends on many factors, and it might be okay for you. Cheers, Donal -Original Message- From: Arundel, Donal [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 12:50 To: cxf-user@incubator.apache.org Subject: RE: Restful Declarative security? Hi Barry, I have recently noticed that it would be a nice extension to ACEGI to support REST in this fashion. I personally think that URL pattern-based RBAC ACL would work really nicely with ACEGI and REST. ACEGI doesn't provide the ability to specify ACL based on the type of HTTP operation involved. This means that ACEGI doesn't naturally support REST out of the box, if you care about modification versus view semantics (which you do). The syntax ACEGI uses to specify the RBAC ACL patterns would need to be overhauled a bit to support this in an ergonomic fashion. It seems like this would be a very nice and very reusable little project though :-) Cheers, Donal -Original Message- From: Barry Fitzgerald [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 10:24 To: cxf-user@incubator.apache.org Subject: Restful Declarative security? Hi all, Just a general question - I'm using the JAX-RS implementation in CXF 2.1 for writing services and I have a requirement to secure certain aspects of the service. For example - I want everyone to be able to read a user but only certain people to update to a user. In a Restful these two calls would both be passed to the same url (update a POST, read a GET) Almost all security solutions I know simply protect URL's and can't protect a url for POST's but not for GET's. Has anyone else come across this problem? Any solutions/ workarounds? Obviously I could protect the calls programmatically but this seems a step backwards. Thanks, Barry IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: JAX-RS API version change
Hi This update is in place now, so if you're using CXF JAX-RS then please give it a try. Please note that a newer 0.6 version is already available, and from the user's perspective, upgrading to 0.6 will mean that existing @UriParam annotations will need to be replaced with @PathParam ones. It seems like the only change in 0.6 which can affect the existing user's code. 0.6 jar is not available on Maven yet, so this upgrade will be done a bit later Cheers, Sergey - Original Message - From: Sergey Beryozkin [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Friday, February 15, 2008 4:55 PM Subject: JAX-RS API version change Hi Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api. I'm looking into upgrading it to support a latest 0.5 version. There're some changes from 0.4 to 0.5 which would affect users. The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the current JAX-RS applications built on top of CXF : 1. @HttpMethod annotation is no longer supported, instead @GET, @POST, @PUT and @DELETE annotations will be used 2. @UriTemplate is not longer supported, @Path is used instead 3. EntityProvider interface has gone too, instead it has been split into two interfaces, MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces. Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers into the right lists itself... Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: How to pass a HashMap
Should be the latest one:2.0.4
Thanks for the reply.
On 2/23/08 11:49 AM, Benson Margulies [EMAIL PROTECTED] wrote:
What version of CXF have you got?
On Fri, Feb 22, 2008 at 4:39 PM, Li, Weiye [EMAIL PROTECTED] wrote:
The CXF document says that Aegis data binding can even works on Map. I
tried this, but it always return an empty one. Here's my testing codes. Did
I miss something? Or I need to write special config file?
@WebService(name=EmicroManager, targetNamespace=http://test.emicro )
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED)
public interface EmicroService {
@WebMethod
@RequestWrapper(className=test.model.Employee,
localName=employee, targetNamespace=
http://test.emicro/types )
@Oneway
public void addEmployee(Employee emp);
@WebMethod(operationName=getEmployeesAsMap)
@ResponseWrapper(className=java.util.HashMap,
localName=EmployeesMap, targetNamespace=
http://test.emicro/types;)
public Map getEmployeesMap();
}
public static void main(String args[]) throws Exception {
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(test.EmicroService.class);
factory.setAddress(http://localhost:9080/emicro-ws/EmicroService;);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
EmicroService client = (EmicroService)factory.create();
// add 2 employees here, then
MapInteger, Employee emap = client.getEmployeesMap();
logger.info(emap);
System.exit(0);
}
The backend configuration is just following the CXF tutorial
bean id=aegisBean class=
org.apache.cxf.aegis.databinding.AegisDatabinding scope=prototype/
bean id=jaxws-and-aegis-service-factory
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
scope=prototype
property name=dataBinding ref=aegisBean /
property name=serviceConfigurations
list
bean class=
org.apache.cxf.jaxws.support.JaxWsServiceConfiguration /
bean class=
org.apache.cxf.aegis.databinding.AegisServiceConfiguration /
bean class=
org.apache.cxf.service.factory.DefaultServiceConfiguration /
/list
/property
/bean
bean id=emicro class=org.stjude.ri.emicro.ws.EmicroServiceImpl
/
jaxws:endpoint id=helloWorld implementor=#emicro
address=/EmicroService
jaxws:serviceFactory
ref bean='jaxws-and-aegis-service-factory' /
/jaxws:serviceFactory
/jaxws:endpoint
Any advice? Thanks
Re: How to pass a HashMap
Please try my suggestion of declaring MapType,Type in your SEI instead of
just 'map'.
On Mon, Feb 25, 2008 at 10:04 AM, Li, Weiye [EMAIL PROTECTED] wrote:
Should be the latest one:2.0.4
Thanks for the reply.
On 2/23/08 11:49 AM, Benson Margulies [EMAIL PROTECTED] wrote:
What version of CXF have you got?
On Fri, Feb 22, 2008 at 4:39 PM, Li, Weiye [EMAIL PROTECTED] wrote:
The CXF document says that Aegis data binding can even works on Map. I
tried this, but it always return an empty one. Here's my testing codes.
Did
I miss something? Or I need to write special config file?
@WebService(name=EmicroManager, targetNamespace=http://test.emicro )
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED)
public interface EmicroService {
@WebMethod
@RequestWrapper(className=test.model.Employee,
localName=employee, targetNamespace=
http://test.emicro/types )
@Oneway
public void addEmployee(Employee emp);
@WebMethod(operationName=getEmployeesAsMap)
@ResponseWrapper(className=java.util.HashMap,
localName=EmployeesMap, targetNamespace=
http://test.emicro/types;)
public Map getEmployeesMap();
}
public static void main(String args[]) throws Exception {
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(test.EmicroService.class);
factory.setAddress(http://localhost:9080/emicro-ws/EmicroService
);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
EmicroService client = (EmicroService)factory.create();
// add 2 employees here, then
MapInteger, Employee emap = client.getEmployeesMap();
logger.info(emap);
System.exit(0);
}
The backend configuration is just following the CXF tutorial
bean id=aegisBean class=
org.apache.cxf.aegis.databinding.AegisDatabinding scope=prototype/
bean id=jaxws-and-aegis-service-factory
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
scope=prototype
property name=dataBinding ref=aegisBean /
property name=serviceConfigurations
list
bean class=
org.apache.cxf.jaxws.support.JaxWsServiceConfiguration /
bean class=
org.apache.cxf.aegis.databinding.AegisServiceConfiguration /
bean class=
org.apache.cxf.service.factory.DefaultServiceConfiguration /
/list
/property
/bean
bean id=emicro class=org.stjude.ri.emicro.ws.EmicroServiceImpl
/
jaxws:endpoint id=helloWorld implementor=#emicro
address=/EmicroService
jaxws:serviceFactory
ref bean='jaxws-and-aegis-service-factory' /
/jaxws:serviceFactory
/jaxws:endpoint
Any advice? Thanks
Re: How to pass a HashMap
I think I may have to declare .aegis.xml.
It was my 2nd try (I mean, use Map only). I did use MapInteger, Employee on
my first try and the outcome is the same: empty map returned.
On 2/24/08 12:09 PM, Benson Margulies [EMAIL PROTECTED] wrote:
It does work. But you have to tell it what's in the map. Either declare the
type as
MapA,B, or use a .aegis.xml file to tell it.
@WebService(name=EmicroManager, targetNamespace=http://test.emicro )
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED)
public interface EmicroService {
@WebMethod
@RequestWrapper(className=test.model.Employee,
localName=employee, targetNamespace=
http://test.emicro/types )
@Oneway
public void addEmployee(Employee emp);
@WebMethod(operationName=getEmployeesAsMap)
@ResponseWrapper(className=java.util.HashMap,
localName=EmployeesMap, targetNamespace=
http://test.emicro/types;)
public Map getEmployeesMap();
Re: Problem generating WSDL from Java API with CXF 2.0.3
Dan,
I've tried out the 2.1 snapshot available today and found that the API has
changed in some way in CXF so now trying to generate a WSDL from Java code
gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFactory.newBuilder()Lorg/apache/cxf/service/ServiceBuilder;
at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceBuilder(JavaToProcessor.java:144)
at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(JavaToProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the command
line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have a
method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-module
xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
xs:sequence
xs:element minOccurs=0 name=return/
/xs:sequence
/xs:complexType
...
/xs:schema
wsdl:types
...
wsdl:message name=getUser
wsdl:part name=parameters element=ns1:getUser
/wsdl:part
/wsdl:message
...
wsdl:message name=getUserResponse
wsdl:part name=parameters element=ns1:getUserResponse
/wsdl:part
/wsdl:message
...
wsdl:portType name=UserModule
wsdl:operation name=getUser
wsdl:input name=getUser message=ns1:getUser
/wsdl:input
wsdl:output name=getUserResponse
How to work with document type?
My testing Jax-WS with Aegis worked only with RPC style. When I changed
soapbinding with RPC style, the same codes give exception. Here's my WS file:
@WebService(name=EmicroManager, targetNamespace=http://emicro.test;)
@SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL,
parameterStyle=ParameterStyle.WRAPPED) public interface EmicroService {
.
}
When client tried to use the service: ws.addEmployee(Employee) or any other
method, exception thrown as:
Feb 25, 2008 9:32:29 AM org.apache.cxf.phase.PhaseInterceptorChain doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: NO_MESSAGE_FOR_PARTat
org.apache.cxf.aegis.databinding.XMLStreamDataWriter.write(XMLStreamDataWriter.java:72)
at
org.apache.cxf.aegis.databinding.XMLStreamDataWriter.write(XMLStreamDataWriter.java:45)
at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:93)
at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)at
$Proxy24.addEmployee(Unknown Source)
Where the Employee extends a base class People. Both of them are simple
Java bean.
The same codes works if I change DOCUMENT to RPC. I believe I must miss
something, but what's that?
Help?
Thanks.
Re: JAX-RS API version change
Sergey Beryozkin wrote: Hi This update is in place now, so if you're using CXF JAX-RS then please give it a try. Please note that a newer 0.6 version is already available, and from the user's perspective, upgrading to 0.6 will mean that existing @UriParam annotations will need to be replaced with @PathParam ones. It seems like the only change in 0.6 which can affect the existing user's code. 0.6 jar is not available on Maven yet, so this upgrade will be done a bit later Cheers, Sergey - Original Message - From: Sergey Beryozkin [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Friday, February 15, 2008 4:55 PM Subject: JAX-RS API version change Hi Currently, the CXF JAX-RS implementation depend upon a 0.4 version of the jaxrs-api. I'm looking into upgrading it to support a latest 0.5 version. There're some changes from 0.4 to 0.5 which would affect users. The following is the list of what has changed between 0.4 and 0.5 which will or may have an effect on the current JAX-RS applications built on top of CXF : 1. @HttpMethod annotation is no longer supported, instead @GET, @POST, @PUT and @DELETE annotations will be used 2. @UriTemplate is not longer supported, @Path is used instead 3. EntityProvider interface has gone too, instead it has been split into two interfaces, MessageBodyReader and MessageBodyWriter. If you provide custom providers and you'd like to have the same instance to handle both reads and writes, then you'd have to have its class implementing both interfaces. Existing spring configuration for injecting custom providers won't get changed, the runtime will sort difrerent types of handlers into the right lists itself... Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland This is cool. Did you update the JAX-RS sample too? I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? Thank you Arul
Re: JAX-RS API version change
Just to be clear: I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? If it's part of the spec, then yes, we do plan on providing it, just probably not immediately. The server side parts are a bit higher priority to the folks that are paying us to work on it. :-) However, if folks would like to jump in and help, feel free to start raising jira issues, submit patches, etc We'd LOVE to have the extra help. Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Hi, This is cool. Did you update the JAX-RS sample too? No, will do as part of the next patch, thanks for pointing it out.. I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? This is not a priority for CXF JAX-RS at the moment. Yes, that Client API looks cool, but I believe it's not something CXF JAX-RS users can't live without at this moment of time :-). Things like providing a UriInfo implementation, support for types like byte[], improving the URITemplating, etc are of higher priority at the moment. Thank you Arul Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: How to work with document type?
If you get rid of all your JAX-WS annotations except @WebParam, which are
not needed for CXF, you won't get this error. I tried it with your test
case.
On Mon, Feb 25, 2008 at 10:35 AM, Li, Weiye [EMAIL PROTECTED] wrote:
My testing Jax-WS with Aegis worked only with RPC style. When I changed
soapbinding with RPC style, the same codes give exception. Here's my WS
file:
@WebService(name=EmicroManager, targetNamespace=http://emicro.test;)
@SOAPBinding(style=Style.DOCUMENT, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED) public interface EmicroService {
.
}
When client tried to use the service: ws.addEmployee(Employee) or any
other method, exception thrown as:
Feb 25, 2008 9:32:29 AM org.apache.cxf.phase.PhaseInterceptorChaindoIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: NO_MESSAGE_FOR_PARTat
org.apache.cxf.aegis.databinding.XMLStreamDataWriter.write(
XMLStreamDataWriter.java:72)at
org.apache.cxf.aegis.databinding.XMLStreamDataWriter.write(
XMLStreamDataWriter.java:45)at
org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(
AbstractOutDatabindingInterceptor.java:93)at
org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(
BareOutInterceptor.java:68)at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
PhaseInterceptorChain.java:208)at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy24.addEmployee(Unknown Source)
Where the Employee extends a base class People. Both of them are
simple Java bean.
The same codes works if I change DOCUMENT to RPC. I believe I must miss
something, but what's that?
Help?
Thanks.
Re: Href attribute support in soap envelope body
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
Umm... why would the string and stringArray things be in the SOAP-ENV
namespace? That DEFINITELY looks bad. Looks like some more Delphi
configuration is needed somehow.
That said, you should definitely use a wrapped/doc/lit, not bare. So
the message should look something like;
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
ns1:executeJob xmlns:ns1=..
JobNameTestFromDelphi/JobName
/ns1:executeJob
/SOAP-ENV:Body
/SOAP-ENV:Envelope
Dan
On Monday 25 February 2008, pierre post wrote:
Thanks for pointing me in the right direction, Ian. I also suspected
that it's an encoding problem but I wasn't sure.
Unfortunately, after some more trialerror tests, I didn't come to a
positive result. Removing the @SOAPBinding i.e. using wrapped
document/literal/wrapped generates a far more complex Delphi unit
(that would be the least of the problems) but furthermore, now no
parameters at all are correctly received in the Java Web service (only
null values).
I looked up the Delphi documentation and after a little research added
the line
InvRegistry.RegisterInvokeOptions(TypeInfo(JobService), [ioDocument,
ioLiteral]);
in my Delphi client, so Delphi *should* definitively use
document/literal encoding. But no change.
But, if I use the document/literal/bare encoding, I receive the
following error message from CXF:
25-Feb-2008 11:05:07 org.apache.cxf.phase.PhaseInterceptorChain
doIntercept INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Message part
{http://schemas.xmlsoap.org/soap/envelope/}string was not recognized.
at
org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLi
teralInInterceptor.java:178) at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:208) at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
tionObserver.java:77) ...
Delphi sends the following SOAP request:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
SOAP-ENV:Body
SOAP-ENV:stringTestFromDelphi/SOAP-ENV:string
SOAP-ENV:stringArray
stringvalueDelphi1/string
stringvalueDelphi2/string
/SOAP-ENV:stringArray
JobParamBean xmlns=http://annuaire.ciss.lu;
keykeyDelphi/key
value2/value
/JobParamBean
/SOAP-ENV:Body
/SOAP-ENV:Envelope
This whole encoding issue is getting rather frustrating for me, having
in mind Web services should improve interoperability ... :-(
Pierre
Ian Roberts wrote:
The Delphi client is trying to use SOAP encoding (RPC/encoded) but
the CXF service expects RPC/literal. I don't know Delphi, is there
any configuration option to tell it to use literal rather than
encoded? Or if Delphi can't do RPC/literal, try removing the
@SOAPBinding annotation from your service to make it use wrapped
document/literal and see if Delphi likes that any better.
Ian
pierre post wrote:
Hi all,
I have a problem when calling an Apache CXF Web service (CXF
version is 2.0.4) running under Apache Tomcat 6 from a Delphi
client program. The third parameter JobParamBean that I receive
in my Web service on Tomcat is always null but there is no
exception or any other hint in the Tomcat logs. The parameter is a
simple JavaBean class (uses getters and setters for all properties
and implements serializable). Moreover, the problem does not appear
when calling the same Web service from a Java client. This is my
Web service:
@WebService(name=JobService,
targetNamespace=http://annuaire.ciss.lu;)
@SOAPBinding(style=Style.RPC)
public interface JobService {
@WebMethod(operationName=ExecuteJob)
@WebResult(name=JobParamsOut)
public String[] executeJob(@WebParam(name=JobName) String
jobName, @WebParam(name=JobParamsIn) String[] input,
@WebParam(name=JobParamBean) JobServiceParam param) throws
ServiceException;
}
When calling this web service from the Delphi application (using
the latest available HTTPRIO component and WSDL importer), the
corresponding generated SOAP request produces null as
JobParamBean parameter:
?xml version=1.0?
SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
Re: JAX-RS API version change
Client API It's not part of the spec (at the moment). It's something Jersey will provide Cheers, Sergey - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Monday, February 25, 2008 4:26 PM Subject: Re: JAX-RS API version change Just to be clear: I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? If it's part of the spec, then yes, we do plan on providing it, just probably not immediately. The server side parts are a bit higher priority to the folks that are paying us to work on it. :-) However, if folks would like to jump in and help, feel free to start raising jira issues, submit patches, etc We'd LOVE to have the extra help. Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Hi, This is cool. Did you update the JAX-RS sample too? No, will do as part of the next patch, thanks for pointing it out.. I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? This is not a priority for CXF JAX-RS at the moment. Yes, that Client API looks cool, but I believe it's not something CXF JAX-RS users can't live without at this moment of time :-). Things like providing a UriInfo implementation, support for types like byte[], improving the URITemplating, etc are of higher priority at the moment. Thank you Arul Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: How to pass a HashMap
On Monday 25 February 2008, Benson Margulies wrote:
The use of HashMap as a JAX-WS wrapper type may be a problem. Let me
try the Mapx,y experiment in my testbed.
Uhh yea. In general, unless you REALLY know what you are doing,
for code first, don't put @RequestWrapper and @ResponseWrapper
annotations.
Setting the classname in them to something other than a properly
constructed wrapper type can definitely lead to issues. In this
case, if you wanted to use them, you would have to create a bean like:
class GetEmployeesMap {
MapInteger, Employee _return;
getReturn getter
setReturn setter
}
Even then, I'm not sure it would work as I don't know how or if aegis can
deal with the wrapper types.
So, in summary, don't use them.Unless the code generator has
specifically put them there (wsdl2java), ignore them.
Dan
On Monday 25 February 2008, Benson Margulies wrote:
The use of HashMap as a JAX-WS wrapper type may be a problem. Let me
try the Mapx,y experiment in my testbed.
On Mon, Feb 25, 2008 at 10:29 AM, Li, Weiye [EMAIL PROTECTED]
wrote:
I think I may have to declare .aegis.xml.
It was my 2nd try (I mean, use Map only). I did use MapInteger,
Employee on my first try and the outcome is the same: empty map
returned.
On 2/24/08 12:09 PM, Benson Margulies [EMAIL PROTECTED]
wrote:
It does work. But you have to tell it what's in the map. Either
declare the
type as
MapA,B, or use a .aegis.xml file to tell it.
@WebService(name=EmicroManager,
targetNamespace=http://test.emicro;)
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED)
public interface EmicroService {
@WebMethod
@RequestWrapper(className=test.model.Employee,
localName=employee, targetNamespace=
http://test.emicro/types )
@Oneway
public void addEmployee(Employee emp);
@WebMethod(operationName=getEmployeesAsMap)
@ResponseWrapper(className=java.util.HashMap,
localName=EmployeesMap, targetNamespace=
http://test.emicro/types;)
public Map getEmployeesMap();
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: JAX-RS API version change
Client API It's not part of the spec (at the moment). It's something Jersey will provide Oh. Ok. Well, my comment still stands. Any help adding it to CXF would be greatly appreciated. :-) Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Cheers, Sergey - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Monday, February 25, 2008 4:26 PM Subject: Re: JAX-RS API version change Just to be clear: I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? If it's part of the spec, then yes, we do plan on providing it, just probably not immediately. The server side parts are a bit higher priority to the folks that are paying us to work on it. :-) However, if folks would like to jump in and help, feel free to start raising jira issues, submit patches, etc We'd LOVE to have the extra help. Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Hi, This is cool. Did you update the JAX-RS sample too? No, will do as part of the next patch, thanks for pointing it out.. I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? This is not a priority for CXF JAX-RS at the moment. Yes, that Client API looks cool, but I believe it's not something CXF JAX-RS users can't live without at this moment of time :-). Things like providing a UriInfo implementation, support for types like byte[], improving the URITemplating, etc are of higher priority at the moment. Thank you Arul Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: JAX-RS API version change
Well, my comment still stands. Any help adding it to CXF would be greatly appreciated. :-) +1 :-) Cheers, Sergey Client API It's not part of the spec (at the moment). It's something Jersey will provide Oh. Ok. Well, my comment still stands. Any help adding it to CXF would be greatly appreciated. :-) Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Cheers, Sergey - Original Message - From: Daniel Kulp [EMAIL PROTECTED] To: cxf-user@incubator.apache.org Sent: Monday, February 25, 2008 4:26 PM Subject: Re: JAX-RS API version change Just to be clear: I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? If it's part of the spec, then yes, we do plan on providing it, just probably not immediately. The server side parts are a bit higher priority to the folks that are paying us to work on it. :-) However, if folks would like to jump in and help, feel free to start raising jira issues, submit patches, etc We'd LOVE to have the extra help. Dan On Monday 25 February 2008, Sergey Beryozkin wrote: Hi, This is cool. Did you update the JAX-RS sample too? No, will do as part of the next patch, thanks for pointing it out.. I do have a question. 0.6 started implementing a REST client API. Does CXF plan to use this Client API or do you suggesting using the HTTP Client used in samples? This is not a priority for CXF JAX-RS at the moment. Yes, that Client API looks cool, but I believe it's not something CXF JAX-RS users can't live without at this moment of time :-). Things like providing a UriInfo implementation, support for types like byte[], improving the URITemplating, etc are of higher priority at the moment. Thank you Arul Cheers, Sergey IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog IONA Technologies PLC (registered in Ireland) Registered Number: 171387 Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
Re: MTOM attachments question
On Saturday 23 February 2008, Benson Margulies wrote:
2.0.4 doesn't know anything about xmime:expectedContentType, AFAIK. Do
you have the @MTOM annotation in place to enable the threshold?
Yea, you're backwords
2.0.4 should deal with the expectedContentType stuff fine. It DOESN'T,
however, have an @MTOM annotation. That was added in 2.1.
In general, and base64Binary thing in the wsdl should be attachable if
MTOM is turned on. However, our default threshold is 4K. Under 4k
and it will be inlined.
Dan
On Fri, Feb 22, 2008 at 8:01 PM, Glen Mazza [EMAIL PROTECTED]
wrote:
Some possibilities:
1.) From Step #5 of [1], make sure you have
xmime:expectedContentTypes declared in your WSDL (you can see me
using it under element name=getWeatherForecastResponse at the
top).
2.) From Step #6 of [1], make sure you use @BindingType annotation
just before your web service implementation.
3.) Also, your address in your cxf.xml (/FileTransferWebService)
may need to be a full URL as shown in our sample here[2].
HTH,
Glen
[1] http://www.jroller.com/gmazza/date/20071102
[2]
http://cwiki.apache.org/confluence/display/CXF20DOC/MTOM#MTOM-Config
File
Am Freitag, den 22.02.2008, 21:19 +0100 schrieb Eliú:
Hi, i'm new with CXF and i'm trying to use MTOM attachments in my
web services.
I followed the Apache CXF 2.0 User's Guide and right now i can get
a
binary
file from the server to my client using MTOM attachments.
My problem is that i cannot send a file from the client to the
server
using
MTOM. When I pass my JAXB class or the DataHandler
as a parameter to the Web Service, it always goes base64Binary
encoded
in
the request SOAP message.
In the server side, i have this endpoint declaration:
*jaxws:endpoint id=FileTransferWebService
implementor=
com.iafis.sici.server.webServiceImpl.FileTransferWebServiceImpl
address=/FileTransferWebService
jaxws:properties
entry key=mtom-enabled value=true/
/jaxws:properties
/jaxws:endpoint*
and this is my JAXB bean:
[EMAIL PROTECTED]
public class BinaryFile {
/**
* Contenido binario del archivo.
*/
@XmlMimeType(application/octet-stream)
private DataHandler imageData;
/**
* @return el valor de imageData como InputStream
* @throws IOException en caso de error al obtener el
* InputStream a partir del DataHandler
*/
public InputStream getInputStream() throws IOException {
return imageData.getInputStream();
}
/**
* @param imageData el valor de imageData a establecer
*/
public void setImageData(DataHandler imageData) {
this.imageData = imageData;
}
}*
When i call this service:
*BinaryFile getOperationCodesFile(String filePath);*
the file comes in the response SOAP as MTOM attachment, but when i
call
this
other:
*void updateOpCodesFileOnServer(BinaryFile file, Date
updateDate);*
the file goes in the request message inside the Envelope of the
SOAP
message
encoded as a base64Binary.
I need to know if i can send the file to the server as a MTOM
attachment with CXF and annotations for JAXB beans.
Thanks in advance.
P.D.: I'm not a member of this mailing list, so i'll thank you if
you
copy
your replay to this address. Thanks.
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
Re: Problem generating WSDL from Java API with CXF 2.0.3
Hmm..
Is this in maven or other build system? It looks like its picking up
some old jars someplace as the class:
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor
no longer even exists.
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
If using 2.1 snapshot, you may want to flip to 1.6.0_04. 03 includes
the 2.0 JAXWS/JAXB API's which may cause issues with the 2.1 versions
that CXF 2.1 requires._04 includes the proper 2.1 versions and I
have gone through and made sure CXF builds and runs with _04.
Dan
On Monday 25 February 2008, Phil Weighill-Smith wrote:
I've tried out the 2.1 snapshot available today and found that the API
has changed in some way in CXF so now trying to generate a WSDL from
Java code gives:
Exception in thread main java.lang.NoSuchMethodError:
org.apache.cxf.tools.java2wsdl.processor.internal.ServiceBuilderFactor
y.newBuilder()Lorg/apache/cxf/service/ServiceBuilder; at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.getServiceBui
lder(JavaToProcessor.java:144) at
org.apache.cxf.tools.java2wsdl.processor.JavaToProcessor.process(JavaT
oProcessor.java:87)
Note that this is both in the IDEA integration with CXF and via the
command line. The JDK I'm using is 1.6.0.03.
Any suggestions?
Phil :n.
- Original Message -
From: Daniel Kulp [EMAIL PROTECTED]
To: cxf-user@incubator.apache.org
Cc: Phil Weighill-Smith [EMAIL PROTECTED]
Sent: 22 February 2008 17:26:59 o'clock (GMT) Europe/London
Subject: Re: Problem generating WSDL from Java API with CXF 2.0.3
On Friday 22 February 2008, Phil Weighill-Smith wrote:
Dan, sorry it's been several weeks since you e-mailed this to me and
I've not actioned it. Where do I find CXF's official JIRA app?
https://issues.apache.org/jira/browse/CXF
That said, the namespace issue in the WrapperClassGenerator should be
fixed with the latest 2.1 snapshots. I'll probably be doing new
snapshots again today since I've fixed a TON of bugs over the last
couple days. That MAY also fix the other issues you note below as it
will totally delegate to JAXB to generate the getUserResponse type in
the wsdl. Any chance you can try with the latest 2.1 snapshots (or
wait till tomorrow/monday and try the ones I'll deploy later today?)
Dan
By the way, I have also hit a problem where the response parts are
generated with incomplete result definitions. For example, if I have
a method in my SEI like:
@WebService(name = UserModule,
targetNamespace =
http://www.volantis.com/xmlns/2008/01/mss/user-module;)
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT,
use = SOAPBinding.Use.LITERAL,
parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public interface UserModule {
User getUser(@WebParam(name=name) final String name);
...
}
where User is, for example, like this:
@XmlJavaTypeAdapter(UserAdapter.class)
public interface User {
String getName();
String getPassword();
}
with an implementation like:
@XmlType(name = User)
public class UserImpl implements User {
private String name;
private String password;
public void setName(final String name) {
this.name = name;
}
public String getName() {
return name;
}
public void setPassword(final String password) {
this.password = password;
}
public String getPassword() {
return password;
}
}
and the adapter looks like:
public final class UserAdapter extends
XmlAdapterUserImpl, User {
@Override
public UserImpl marshal(final User user) throws Exception {
return (UserImpl) user;
}
@Override
public User unmarshal(final UserImpl user) throws Exception {
return user;
}
}
I get some WSDL like this:
wsdl:definitions name=UserModuleService
targetNamespace=http://com.volantis.openapi.mss.usermodule;
xmlns:ns1=http://www.volantis.com/xmlns/2008/01/mss/user-module;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://com.volantis.openapi.mss.usermodule;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; wsdl:types
xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.volantis.com/xmlns/2008/01/mss/user-module;
attributeFormDefault=unqualified
elementFormDefault=unqualified
targetNamespace=http://www.volantis.com/xmlns/2008/01/mss/user-modu
le xs:element name=getUser type=getUser/
xs:complexType name=getUser
xs:sequence
xs:element minOccurs=0 name=name
type=xs:string/
/xs:sequence
/xs:complexType
xs:element name=getUserResponse
type=getUserResponse/ xs:complexType name=getUserResponse
RE: How to pass a HashMap
I reported the same issue in 2.0.3 a while back, and I did have my Map
specified as MapString, String. (It was a service that had previously
worked under XFire.)
I got no response, so I switched to JAXB and just wrapped the Map inside
a bean.
-Original Message-
From: Benson Margulies [mailto:[EMAIL PROTECTED]
Sent: Monday, February 25, 2008 10:20 AM
To: cxf-user@incubator.apache.org
Subject: Re: How to pass a HashMap
Please try my suggestion of declaring MapType,Type in your SEI instead
of
just 'map'.
On Mon, Feb 25, 2008 at 10:04 AM, Li, Weiye [EMAIL PROTECTED] wrote:
Should be the latest one:2.0.4
Thanks for the reply.
On 2/23/08 11:49 AM, Benson Margulies [EMAIL PROTECTED] wrote:
What version of CXF have you got?
On Fri, Feb 22, 2008 at 4:39 PM, Li, Weiye [EMAIL PROTECTED]
wrote:
The CXF document says that Aegis data binding can even works on Map.
I
tried this, but it always return an empty one. Here's my testing
codes.
Did
I miss something? Or I need to write special config file?
@WebService(name=EmicroManager,
targetNamespace=http://test.emicro )
@SOAPBinding(style=Style.RPC, use=Use.LITERAL, parameterStyle=
ParameterStyle.WRAPPED)
public interface EmicroService {
@WebMethod
@RequestWrapper(className=test.model.Employee,
localName=employee, targetNamespace=
http://test.emicro/types )
@Oneway
public void addEmployee(Employee emp);
@WebMethod(operationName=getEmployeesAsMap)
@ResponseWrapper(className=java.util.HashMap,
localName=EmployeesMap, targetNamespace=
http://test.emicro/types;)
public Map getEmployeesMap();
}
public static void main(String args[]) throws Exception {
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(test.EmicroService.class);
factory.setAddress(http://localhost:9080/emicro-ws/EmicroService
);
factory.getServiceFactory().setDataBinding(new
AegisDatabinding());
EmicroService client = (EmicroService)factory.create();
// add 2 employees here, then
MapInteger, Employee emap = client.getEmployeesMap();
logger.info(emap);
System.exit(0);
}
The backend configuration is just following the CXF tutorial
bean id=aegisBean class=
org.apache.cxf.aegis.databinding.AegisDatabinding
scope=prototype/
bean id=jaxws-and-aegis-service-factory
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
scope=prototype
property name=dataBinding ref=aegisBean /
property name=serviceConfigurations
list
bean class=
org.apache.cxf.jaxws.support.JaxWsServiceConfiguration /
bean class=
org.apache.cxf.aegis.databinding.AegisServiceConfiguration /
bean class=
org.apache.cxf.service.factory.DefaultServiceConfiguration /
/list
/property
/bean
bean id=emicro
class=org.stjude.ri.emicro.ws.EmicroServiceImpl
/
jaxws:endpoint id=helloWorld implementor=#emicro
address=/EmicroService
jaxws:serviceFactory
ref bean='jaxws-and-aegis-service-factory' /
/jaxws:serviceFactory
/jaxws:endpoint
Any advice? Thanks
best practices for Map and List in webservices
I have got some WebServices that basically take and return MapString,String and ListString. I am wondering what is considered the best way to do this, especially for interoperability with both Java and .NET. I don't have to use the Java collections (although it sure is convenient). Previously we used WebMethods Glue which provided this for us, but I understand it was not great for interoperability. Thanks, Dan
Re: best practices for Map and List in webservices
Maps are hard. JAXB barely support them, with a ton of snails, in 2.1. I would personally recommend specifying a vector or list of pairs instead. On Mon, Feb 25, 2008 at 6:24 PM, Daniel Lipofsky [EMAIL PROTECTED] wrote: I have got some WebServices that basically take and return MapString,String and ListString. I am wondering what is considered the best way to do this, especially for interoperability with both Java and .NET. I don't have to use the Java collections (although it sure is convenient). Previously we used WebMethods Glue which provided this for us, but I understand it was not great for interoperability. Thanks, Dan
