Re: Mapping of Map with "required=false, nillable=true"

[Default SPAM]

Thank you very much Daniel.

The XmlAdapter is fixing the issue. I've used the java_first_jaxws sample
in the CXF distribution as a template for the implementation.

But I have added a check for null value at the beginning of marshal and
unmarshal functions (to avoid NullPointerException):

public StringStringMap marshal(Map entries) throws
Exception{
if (entries==null){
return null;
}
[...]
}

public Map unmarshal(StringStringMap ssm) throws
Exception {
if (ssm==null){
return null;
}
[...]
}

Regards.
Johann

2011/12/8 Daniel Kulp 

>
> You've hit one of those "funny" things with JAXB that I've never quite
> understood.   Officially, JAXB does not support Maps.   However, the JAXB
> runtime does kind of handle them as long as you don't specifically tell
> JAXB
> about them by annotating it with and JAXB annotation.   As soon as you do,
> it
> barfs.
>
> The only way to handle this is to write an XmlAdapter that would map the
> Map
> into a class that JAXB would understand and then wire that in with
> @XmlJavaTypeAdapter along with your XmlElement annotation.
>
> You can see an example of how to handle maps like that in the
> java_first_jaxws
> sample in the CXF distribution.
>
> Dan
>
>
> On Wednesday, December 07, 2011 10:10:05 AM Default SPAM wrote:
> > Hi all,
> >
> > I would like to submit a question since I have noticed an inconsistency
> > between WSDL generated by "org.apache.cxf.tools.java2ws.JavaToWS" and
> > response sent by CXF.
> >
> > > I have a service like this:
> > @WebService(endpointInterface = "be.eft.cbkv3.ws.WSExampleService",
> > serviceName = "WSExampleService")
> > public class WSExampleServiceImpl implements WSExampleService{
> > protected final Log log= LogFactory.getLog(this.getClass());
> >
> > public WSExample getExample(String exampleId){
> > return new WSExample();
> > };
> > }
> >
> > > This service is returning a WSExample that is a simple bean that
> > > contains
> >
> > a Map:
> >
> > public class WSExample implements Serializable{
> >
> > /** identifier field */
> > private Long id;
> >
> > /**
> >  * @return Returns the id.
> >  * @hibernate.id column = "ID" length = "19"
> >  * generator-class = "native"
> >  */
> > public Long getId() {
> > return id;
> > }
> > public void setId(Long id) {
> > this.id = id;
> > }
> >
> > /** An object containing all business data related to the auto-action
> > */
> > private Map arguments;
> >
> > /**
> >  * @hibernate.map cascade= "all" table= "CBK_AUTOACTIONARGS"
> >  * @hibernate.key column= "CBK_AUTOACTIONID"
> > foreign-key="AAARG_CBKAAID_FK"
> >  * @hibernate.index   column= "NAME" type= "java.lang.String"
> >  * @hibernate.element column= "VALUE" type= "java.lang.String"
> >  * @return the arguments
> >  */
> > public Map getArguments() {
> > return arguments;
> > }
> > public void setArguments(Map arguments) {
> > this.arguments = arguments;
> > }
> > }
> >
> > > The WSDL generated looks like:
> > 
> > http://ws.cbkv3.eft.be/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> > xmlns:tns="http://ws.cbkv3.eft.be/"; xmlns:xsd="
> > http://www.w3.org/2001/XMLSchema"; xmlns:soap="
> > http://schemas.xmlsoap.org/wsdl/soap/";>
> >   
> > http://www.w3.org/2001/XMLSchema"; xmlns="
> > http://ws.cbkv3.eft.be/"; attributeFormDefault="unqualified"
> > elementFormDefault="unqualified" targetNamespace="
> http://ws.cbkv3.eft.be/";>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >   
> >   
> > 
> > 
> >   
> >   
> > 
> > 
> >   
> >   
> > 
> >   
> > 
> >> message="tns:getExampleResponse">
> > 
&

Mapping of Map with "required=false, nillable=true"

[Default SPAM]

Hi all,

I would like to submit a question since I have noticed an inconsistency
between WSDL generated by "org.apache.cxf.tools.java2ws.JavaToWS" and
response sent by CXF.

> I have a service like this:

@WebService(endpointInterface = "be.eft.cbkv3.ws.WSExampleService",
serviceName = "WSExampleService")
public class WSExampleServiceImpl implements WSExampleService{
protected final Log log= LogFactory.getLog(this.getClass());

public WSExample getExample(String exampleId){
return new WSExample();
};
}


> This service is returning a WSExample that is a simple bean that contains
a Map:

public class WSExample implements Serializable{

/** identifier field */
private Long id;

/**
 * @return Returns the id.
 * @hibernate.id column = "ID" length = "19"
 * generator-class = "native"
 */
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}

/** An object containing all business data related to the auto-action
*/
private Map arguments;

/**
 * @hibernate.map cascade= "all" table= "CBK_AUTOACTIONARGS"
 * @hibernate.key column= "CBK_AUTOACTIONID"
foreign-key="AAARG_CBKAAID_FK"
 * @hibernate.index   column= "NAME" type= "java.lang.String"
 * @hibernate.element column= "VALUE" type= "java.lang.String"
 * @return the arguments
 */
public Map getArguments() {
return arguments;
}
public void setArguments(Map arguments) {
this.arguments = arguments;
}
}

> The WSDL generated looks like:


http://ws.cbkv3.eft.be/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
xmlns:tns="http://ws.cbkv3.eft.be/"; xmlns:xsd="
http://www.w3.org/2001/XMLSchema"; xmlns:soap="
http://schemas.xmlsoap.org/wsdl/soap/";>
  
http://www.w3.org/2001/XMLSchema"; xmlns="
http://ws.cbkv3.eft.be/"; attributeFormDefault="unqualified"
elementFormDefault="unqualified" targetNamespace="http://ws.cbkv3.eft.be/";>
































  
  


  
  


  
  

  

  


  
  
http://schemas.xmlsoap.org/soap/http"/>

  
  

  
  

  

  
  

  http://localhost:9090/WSExampleServiceImplPort
"/>

  


> That's looks more or less fine, but once we receive a response from the
server when there is no arguments (the WSExample#arguments is null) then we
receive something like:
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ws="http://ws.cbkv3.eft.be/";>
   
   
  
 
myId
 
  
   


> This response is not "compliant" with the WSDL since  should
be present, we should receive from server (running CXF):
http://schemas.xmlsoap.org/soap/envelope/";
xmlns:ws="http://ws.cbkv3.eft.be/";>
   
   
  
 


myId
 
  
   


To workaround this, I can explicitely (and manually) add 'minOccurs="0"
nillable="true"' to 'arguments' element:


That way, my WSDL is consistent with what CXF is returning.

But, it means we also cannot rely on the WSDL dynamically generated (with
?wsdl) once my service is deployed.

I tried to add "@XmlElement(required=false, nillable=true)" annotation to
getArguments() function but I got an error like:
Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 2
counts of IllegalAnnotationExceptions
 [java] java.util.Map is an interface, and JAXB can't handle interfaces.
 [java] this problem is related to the following location:
 [java] at java.util.Map
 [java] at public java.util.Map
be.eft.cbkv3.data.schema.WSExample.getArguments()
 [java] at be.eft.cbkv3.data.schema.WSExample
 [java] java.util.Map does not have a no-arg default constructor.
 [java] this problem is related to the following location:
 [java] at java.util.Map
 [java] at public java.util.Map
be.eft.cbkv3.data.schema.WSExample.getArguments()
 [java] at be.eft.cbkv3.data.schema.WSExample
 [java] at
com.sun.xml.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:106)
 [...]

It sounds logic that if "arguments can be null" (and it can) we can get
SOAP response with no  tag then CXF response sounds correct to
me.
But WSDL generated should then contains <... minOccurs="0" nillable="true">
instead of nothing (knowing that when such arguments are not specified,
defaults are <... minOccurs="1" nillable="false">.

Any idea how to fix this inconsistency?

Regards.
Johann

NB: Tried with CXF 2.2.9 and CXF 2.5.0.

Fwd: Commons http client support? Better way to handle SPNEGO.

[Spam]

Hi all,

I'm digging into including SPNEGO support for the web services (based on
CXF 2.2.4) I'm implementing.

On server side, using 'Servlet Transport
', it shouldn't be an
issue since handling of (SPNEGO) authentication is performed by Tomcat.
On client side, I can successfully authenticate myself to Tomcat using
Commons HTTP Client 4.x (with some tweaking around 'Custom
authentication scheme').
So I plan to use something like a 'Commons HTTP Client Transport' for
CXF, which sounds good from my newbies mind.

Reading JIRA, and your mail, I'm a bit disappointed since 'Commons HTTP
Client Transport' is far to be a reality.

Do you have some hints about a way to support SPNEGO for web services
based on CXF (at least for client side, i.e. 'Client HTTP Transport'
)?

Any help would be greatly appreciated.
Johann

-- Forwarded message --
From: *Daniel Kulp* mailto:dk...@apache.org>>
Date: Mon, Oct 5, 2009 at 11:13 PM
Subject: Re: Commons http client support?
To: users@cxf.apache.org 
Cc: Kevin Priebe mailto:ke...@realtyserver.com>>



I'm definitely not sure what would be causing that sort of timeout.  
Strange.

I did look a little into doing an http-client based conduit, but it's not
exactly an easy task.   The API's are pretty much backwords from
HTTPUrlConnection which makes mapping it hard.   Basically, the
URLConnection
gives you an OutputStream that you write to as need to.   With http-client,
you provide an object that it calls with the Outputstream when IT wants you
to.   Thus, we would need to do some fancy PhaseInterceptorChain
pause/resume/reenter things to get it to still stream.   Either that or just
don't stream which is another option.

HTTPs is another whole HUGE HUGE issue.Mapping all the CXF https options
onto http-client is not easy, and in some cases, not possible due to missing
stuff in http-client (although that investigation was against http-client 3,
not 4 so things have possibly changed).

Anyway, from my personal perspective, it just hasn't been enough of a
priority
to really start it.   The customers I have dealt with haven't really hit any
issues with the current conduit to justify the amount of work to do this.

That said, if I was to start the work, I'd really suggest a layered approach
of subclassing the current conduit and just invoke the http-client stuff in
the "known cases" where it would work well.  Example: allow the existing
code
to handle https for now, only use http-conduit if streaming is turned off
anyway (no chunking), etc...   Then expand out from there.

Dan


On Mon October 5 2009 1:01:09 pm Kevin Priebe wrote:
> Hi,
>
>
>
> I have been transitioning our users from our old XFire client to a new CXF
> client over the past few months.  I have been getting a lot more calls
> lately about read timeouts (SOAPFaultException: Could not send Message. -
> caused by - SocketTimeoutException: Read timed out).  Here are my
> observations:
>
>
>
> -  The users were successfully using the XFire client, and as soon
> as they start using the CXF client, they seem to randomly get these
errors.
>
> -  Reverting to the old XFire client works fine for these users
>  with no problems
>
> -  Both web services are on the same server, running in the same
> tomcat instance - no other changes were made
>
> -  It affects Satellite Internet users more, but also happens to
> fast Cable Internet users
>
> -  A ping to our server for a Satellite user was always less
than 2
> seconds, which is far less than the read timeout
>
> -  Read timeout is set to 30 seconds - all requests are simple and
> should be fast - less than 5 seconds for sure
>
> -  I have increased the timeout to 60 seconds, but got the same
> behaviour - either it successfully connects within seconds, or never does.
> The timeout just seems to delay the error...
>
> -  I have experienced this problem when connecting to the live
> server myself, but only 2-3 times in the last few months.
>
>
>
> XFire just seems a little more resilient to connection problems than CXF.
> Perhaps this is because it uses the Apache commons httpclient?
>
>
>
> Are there any plans to use the commons httpclient in CXF?  I found
this old
> open issue https://issues.apache.org/jira/browse/CXF-291 which appears to
> have been forgotten.  The description says it shouldn't be hard to
> integrate.  I even started looking into doing it myself, but am not sure I
> have time.  If anyone has any pointers or partial code, that would be
> helpful.
>
>
>
> Thank you for any help or insight as to why this might be happening
and how
> to fix it.  If you need additional information, let me know.  We are using
>  a pretty basic setup with the tomcat CXF servlet and JaxWS.  We are using
>  the GZip feature, and the following client 

CXF - JAX-WS Configuration With Spring

[Spam]

With 2.2.4 it works fine :-)

I still mustn't add these imports:

   
   
   

But I'm now able (with 2.2.4) to configure

>  
> 
> 
> 
> 

without any problem.

For my knowledge, could you give me the JIRA issue number that is
related to your ' processing modifications'?

Thank you for you help.

Johann



On Fri, Oct 9, 2009 at 8:59 AM, Johann DUPUIS mailto:johann.dup...@gmail.com>> wrote:

Thanks I will give 2.2.4 a try.

Johann


On Thu, Oct 8, 2009 at 10:56 PM, Daniel Kulp mailto:dk...@apache.org>> wrote:


I think this is one of the bugs I fixed in 2.2.4.   If made some
modifications
to the  processing stuff to grab the default bus (which
is what you
see being created) if one isn't already in the context.   Thus,
this may be
fixed in 2.2.4 (which is being voted on now)

    Dan

On Tue October 6 2009 3:44:38 am Spam wrote:
> In my 'web.xml' I load services related configuration with:
>
> 
> CXFServlet
> CXF Servlet
>
>

org.apache.cxf.transport.servlet.CXFServlet
> 
> config-location
>  
 /WEB-INF/services-server.xml
> 
> 1
>  
>
> 
> CXFServlet
> /services/*
>   
>
> If i remove those lines from 'services-server.xml', then
imports looks
>
> like useless:
> >  
> > 
> > 
> > 
> > 
>
> For info, here is the beginning of 'services-server.xml' file:
> 
> http://www.springframework.org/schema/beans";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xmlns:simple="http://cxf.apache.org/simple";
>   xmlns:soap="http://cxf.apache.org/bindings/soap";
>   xmlns:cxf="http://cxf.apache.org/core";
>   xmlns:jaxws="http://cxf.apache.org/jaxws";
>   xsi:schemaLocation="
> http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
> http://cxf.apache.org/bindings/soap
> http://cxf.apache.org/schemas/configuration/soap.xsd
> http://cxf.apache.org/simple
http://cxf.apache.org/schemas/simple.xsd
> http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
> http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd
> "
> default-autowire="byName">
>
>
> Looking at Tomcat starting I can read:
> 09:31:10,191 INFO  [BusApplicationContext] No cxf.xml
configuration file
> detected, relying on defaults.
> 09:31:10,191 DEBUG [BusApplicationContext] Creating
application context
> with resources: [class path resource [META-INF/cxf/cxf.xml],
class path
> resource [META-INF/cxf/cxf-extension-corba.xml], class path
resource
> [META-INF/cxf/cxf-extension-jaxws.xml], ...
>
> So I guess there is a fallback that workaround the missing
'cxf.xml' and
> related files.
>
> The problem is I cannot configure  since adding
imports is
> breaking (without error) the WS deployment.
>
> Regards.
> Johann
>
>
> On Mon, Oct 5, 2009 at 8:42 PM, Daniel Kulp mailto:dk...@apache.org>
> <mailto:dk...@apache.org <mailto:dk...@apache.org>>> wrote:
>
>
> I guess it kind of depends on how this config is picked up...
>
> Is this a cxf-servlet.xml thing that the CXFServlet is
    loading (in
> which case
> you shouldn't have the imports as your config is loaded on
top of the
> "Default" bus configs)  or is this a
applicationContext.xml type
> thing that
> the sping context listener is picking up (in which case it
IS needed)?
>
> Dan
>
> On Mon October 5 2009 4:37:25 am Spam wrote:
> 

CXF - JAX-WS Configuration With Spring

[Spam]

In my 'web.xml' I load services related configuration with:


CXFServlet
CXF Servlet
   
org.apache.cxf.transport.servlet.CXFServlet

config-location
   /WEB-INF/services-server.xml

1   
 


CXFServlet
/services/*
  

If i remove those lines from 'services-server.xml', then imports looks
like useless:
>  
> 
> 
> 
> 

For info, here is the beginning of 'services-server.xml' file:

http://www.springframework.org/schema/beans";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xmlns:simple="http://cxf.apache.org/simple";
  xmlns:soap="http://cxf.apache.org/bindings/soap";
  xmlns:cxf="http://cxf.apache.org/core";
  xmlns:jaxws="http://cxf.apache.org/jaxws";
  xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://cxf.apache.org/bindings/soap
http://cxf.apache.org/schemas/configuration/soap.xsd
http://cxf.apache.org/simple http://cxf.apache.org/schemas/simple.xsd
http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
"
default-autowire="byName">


Looking at Tomcat starting I can read:
09:31:10,191 INFO  [BusApplicationContext] No cxf.xml configuration file
detected, relying on defaults.
09:31:10,191 DEBUG [BusApplicationContext] Creating application context
with resources: [class path resource [META-INF/cxf/cxf.xml], class path
resource [META-INF/cxf/cxf-extension-corba.xml], class path resource
[META-INF/cxf/cxf-extension-jaxws.xml], ...

So I guess there is a fallback that workaround the missing 'cxf.xml' and
related files.

The problem is I cannot configure  since adding imports is
breaking (without error) the WS deployment.

Regards.
Johann


On Mon, Oct 5, 2009 at 8:42 PM, Daniel Kulp mailto:dk...@apache.org>> wrote:


I guess it kind of depends on how this config is picked up...

Is this a cxf-servlet.xml thing that the CXFServlet is loading (in
which case
you shouldn't have the imports as your config is loaded on top of the
"Default" bus configs)  or is this a applicationContext.xml type
thing that
the sping context listener is picking up (in which case it IS needed)?

Dan


On Mon October 5 2009 4:37:25 am Spam wrote:
> Hi All,
>
> I answer by myself.
>
> Even if I don't really know why, removing following lines from  my
> services configuration is fixing the issue (services are visible
and are
> running perfectly):
>
> 
> 
> 
>
>
> 
> 
> 
> 
> 
>
> Any idea why these lines are preventing web services to be usable
while
> no error message is issued?
>
> Regards.
> Johann
>
> Spam a écrit :
> > Hi All,
> >
> > I've followed the guidelines from
> > "http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html"; to
> > configure my web services inside Tomcat 6.0.
> >
> > If I use the following configuration, everything in the cxf
(log4j) log
> > file looks like the services are deployed successfully, but checking
> > with "http://localhost:8080/myWebApp/services/"; results in "No
services
> > have been found.".
> >
> >  > class="be.eft.cbkv3.ws.WSUserServicePortTypeImpl">
> > 
> >  > implementor="#WSUserServicePortType"
> > address="/WS_UserService.srv">
> > 
> >  
> >   
> > 
> >
> >  > class="be.eft.cbkv3.ws.WSClaimServicePortTypeImpl">
> > 
> >  > implementor="#WSClaimServicePortType"
> > address="/WS_ClaimService.srv">
> > 
> >  
> >   
> >   
> >
> > I changed configuration in that way (not using implementor but
> > implementorClass only):
> >  >
> > implementorClass="be.eft.cbkv3.ws.WSUserServicePortTypeImpl"
> > address="/WS_UserService.srv">
> > 
> >  
> >   
> > 
> >

Re: CXF - JAX-WS Configuration With Spring

[Spam]

Hi All,

I answer by myself.

Even if I don't really know why, removing following lines from  my
services configuration is fixing the issue (services are visible and are
running perfectly):



   
 







Any idea why these lines are preventing web services to be usable while
no error message is issued?

Regards.
Johann

Spam a écrit :
> Hi All,
>
> I've followed the guidelines from
> "http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html"; to
> configure my web services inside Tomcat 6.0.
>
> If I use the following configuration, everything in the cxf (log4j) log
> file looks like the services are deployed successfully, but checking
> with "http://localhost:8080/myWebApp/services/"; results in "No services
> have been found.".
>
>  class="be.eft.cbkv3.ws.WSUserServicePortTypeImpl">   
>   
>  implementor="#WSUserServicePortType"
> address="/WS_UserService.srv">
> 
>  
> 
> 
>
>  class="be.eft.cbkv3.ws.WSClaimServicePortTypeImpl">   
>
>  implementor="#WSClaimServicePortType"
> address="/WS_ClaimService.srv">
> 
>  
>  
>   
>
> I changed configuration in that way (not using implementor but
> implementorClass only):
> 
> implementorClass="be.eft.cbkv3.ws.WSUserServicePortTypeImpl"
> address="/WS_UserService.srv">
> 
>  
> 
> 
>   
> 
> implementorClass="be.eft.cbkv3.ws.WSClaimServicePortTypeImpl"
> address="/WS_ClaimService.srv">
> 
>  
>  
>   
> Then I get on "http://localhost:8080/myWebApp/services/"; (looks good,
> isn't it?):
> Available SOAP services:
> WSClaimServicePortType
> * getClaim
> * identify
>
> WSUserServicePortType
> * openSession
> * identify
> * closeSession
> But when I try to use the Web Services by running the WS consumers, I
> get this error (in tomcat log):
>02 Oct 2009 at 18.06.57,929WARN
> (SessionId=,org.apache.cxf.common.logging.LogUtils,345,http-8080-1) [] 
> Application has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: object is not an instance of declaring
> class while invoking public java.lang.String
> myPackage.ws.WSUserServicePortTypeImpl.openSession(java.lang.String,java.lang.String,java.lang.Short,java.lang.String)
> throws myPackage.ws.LoginException_Exception with params [login,
> password, 0, localhost].
> at
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:152)
> at
> org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:83)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:126)
> at
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
> at
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
> at
> org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:452)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:196)
> at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:220)
> at
> 

CXF - JAX-WS Configuration With Spring

[Spam]

Hi All,

I've followed the guidelines from
"http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html"; to
configure my web services inside Tomcat 6.0.

If I use the following configuration, everything in the cxf (log4j) log
file looks like the services are deployed successfully, but checking
with "http://localhost:8080/myWebApp/services/"; results in "No services
have been found.".

   
  


 



   
   


 
 
  

I changed configuration in that way (not using implementor but
implementorClass only):


 


  


 
 
  
Then I get on "http://localhost:8080/myWebApp/services/"; (looks good,
isn't it?):
Available SOAP services:
WSClaimServicePortType
* getClaim
* identify

WSUserServicePortType
* openSession
* identify
* closeSession
But when I try to use the Web Services by running the WS consumers, I
get this error (in tomcat log):
   02 Oct 2009 at 18.06.57,929WARN
(SessionId=,org.apache.cxf.common.logging.LogUtils,345,http-8080-1) [] 
Application has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: object is not an instance of declaring
class while invoking public java.lang.String
myPackage.ws.WSUserServicePortTypeImpl.openSession(java.lang.String,java.lang.String,java.lang.Short,java.lang.String)
throws myPackage.ws.LoginException_Exception with params [login,
password, 0, localhost].
at
org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:152)
at
org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:83)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:126)
at
org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:55)
at
org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:68)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:98)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:104)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:452)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:196)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:220)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServlet.java:153)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.service(AbstractCXFServlet.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: object is not an instance
of declaring class
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)

CXF - Simple and JAX-WS frontends interoperability

[Spam]

Hi all,

I've written a two web services using Simple frontend.

For the first service (called 'WSClaimService') the (runtime) generated
WSDL looks like:
 Could someone explain me what a such difference?

Starting from these wsdl I've generated using "WSDLToJava" the java
stubs to implement the web services using JAX-WS frontend.

Due to the "elementFormDefault" value, each function parameters are
associated with a TargetNamespace:
@WebParam(name = "arg0", targetNamespace =
"http://myNamespace.be";)

As a consequence the server implemented (generated by "WSDLToJava" with
-all option) fail to start with following error:
javax.xml.bind.JAXBException: {http://myNamespace.be/}arg0
is not a valid property on class be.eft.cbkv3.ws.OpenSession

--> Is there a reason why the automatically generated server
implementation fail to start? (either WSDL is invalid and generation
should fail, or WSDL is valid and startup should be successful)

I've modified the WSDL of 'WSUserService' to set elementFormDefault to
"unqualified", as a consequence the @WebParam is generated with
targetNamespace= "".
And server implementation successfully start and web service is OK.

I tried to use the Simple Frontend for client side and JAXWS server side
implementation and it works perfectly.

Then, I tried to use the JAXWS client side implementation with Simple
frontend based server implementation, but all arguments to openSession
are set to 'null' on the server (whatever the value in the xml request).

In fact the Simple frontend client side implementation is generating the
following request:
 http://schemas.xmlsoap.org/soap/envelope/";>
 
 http://myNamespace.be/";>
  http://myNamespace.be/";>login
  http://myNamespace.be/";>password
  http://myNamespace.be/";>0
  http://myNamespace.be/";>localhost
  
  
  

While the JAXWS client side implementation is generating the following
request:  
-   <#>http://schemas.xmlsoap.org/soap/envelope/";>
- <#>   
-   <#>http://myNamespace.be/";>
 cbkadm
 admin
 0
 localhost
 
   
   

Adding the targetNamespace to @WebParam doesn't fix this issue.

--> Is there a way to 'ask' JAXWS client side implementation to provide
the namespace? Is there a way to 'ask' Simple server side implementation
to support missing namespace?
  That's strange the targetNamespace is not provided by JAXWS client
side implementation even if provided in @WebParam, right?

Any help would be appreciate.
Don't hesitate if you need more information.

Best regards.
Johann