RE: Exposing methods

[Liu, Jervis]

Hi Julio, this should work. But sometimes it can happen if the CXF runtime can 
not load  the endpoint class specified by endpointInterface =  
"com.rbx.test.webservices.UserWebService", in that case, CXF will use impl 
class (i.e., the UserWebServiceImpl ) to build a service model. And if this 
does happen, all the methods you defined in your impl class will get into your 
WSDL. So could you please check whether or not you have specified your 
endpointInterface correctly, for example, the package name etc.

Hope this helps,

Jervis


-Original Message-
From: Julio Arias [mailto:[EMAIL PROTECTED]
Sent: 2007?7?13? 7:08
To: cxf-user@incubator.apache.org
Subject: Exposing methods


The dependencies setters from my service impl are getting expose in  
the WSDL even though I'm specifying the endpoint interface in the  
implementor. How can I hide this methods?

I have the following code and config:

+ UserWebService.java

@WebService(name = "UserService")
public interface UserWebService {
@WebMethod
User getUserById(@WebParam(name = "id") Long id);
}

+ UserWebServiceImpl.java

@WebService(endpointInterface =  
"com.rbx.test.webservices.UserWebService", name = "UserService")
public class UserWebServiceImpl implements UserWebService {

private UserManager userManager;

public void setUserManager(UserManager userManager) {
this.userManager = userManager;
}

public User getUserById(Long id) {
return userManager.getUser(id);
}
}

+ Endpoint config:












Julio Arias
Java Developer
Roundbox Global : enterprise : technology : genius
-
Avenida 11 y Calle 7-9, Barrio Amón, San Jose, Costa Rica
tel: 404.567.5000 ext. 2001 | cell: 11.506.849.5981
email: [EMAIL PROTECTED] | www.rbxglobal.com
-


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Exposing methods

[Liu, Jervis]

Hi Julio, if exclude=true did work, this proved that your endpointInterface 
class didnt get loaded by CXF. The logic behind the scene is that CXF will try 
to load endpointInterface class using @WebService(endpointInterface ="") 
annotation, if it successfully gets the interface loaded, only methods defined 
in the interface marked with @WebMethod get published into WSDL. If CXF can not 
load endpointInterface class, all methods in the impl class will be published 
into WSDL unless there is an "exclude".

Cheers,
Jervis

-Original Message-
From: Julio Arias [mailto:[EMAIL PROTECTED]
Sent: 2007?7?13? 11:41
To: cxf-user@incubator.apache.org
Subject: Re: Exposing methods


Hi Jim,

Thanks I found that property for the @WebMethod annotation too and it  
works fine. But is this a normal behavior to expose everything in the  
implementor, I thought it would only expose the methods on my interface.

On Jul 12, 2007, at 9:05 PM, Jim Ma wrote:

> Hi Julio,
>
> I think you can add @WebMethod(exclude=true)  for the setter method.
>
>@WebMethod (exclude=true)
> setUserManager(UserManager userManager)
>
> Cheers
>
> Jim
>
>
> Julio Arias wrote:
>> The dependencies setters from my service impl are getting expose  
>> in the WSDL even though I'm specifying the endpoint interface in  
>> the implementor. How can I hide this methods?
>>
>> I have the following code and config:
>>
>> + UserWebService.java
>>
>> @WebService(name = "UserService")
>> public interface UserWebService {
>> @WebMethod
>> User getUserById(@WebParam(name = "id") Long id);
>> }
>>
>> + UserWebServiceImpl.java
>>
>> @WebService(endpointInterface =  
>> "com.rbx.test.webservices.UserWebService", name = "UserService")
>> public class UserWebServiceImpl implements UserWebService {
>>
>> private UserManager userManager;
>>
>> public void setUserManager(UserManager userManager) {
>> this.userManager = userManager;
>> }
>>public User getUserById(Long id) {
>> return userManager.getUser(id);
>> }
>> }
>>
>> + Endpoint config:
>>
>> 
>> 
>> 
>> 
>> 
>>
>>
>>
>>
>>
>> Julio Arias
>> Java Developer
>> Roundbox Global : enterprise : technology : genius
>> -
>> Avenida 11 y Calle 7-9, Barrio Amón, San Jose, Costa Rica
>> tel: 404.567.5000 ext. 2001 | cell: 11.506.849.5981
>> email: [EMAIL PROTECTED] | www.rbxglobal.com
>> -
>>
>>




Julio Arias
Java Developer
Roundbox Global : enterprise : technology : genius
-
Avenida 11 y Calle 7-9, Barrio Amón, San Jose, Costa Rica
tel: 404.567.5000 ext. 2001 | cell: 11.506.849.5981
email: [EMAIL PROTECTED] | www.rbxglobal.com
-


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Exposing methods

[Liu, Jervis]

Hi, I actually believe this is a bug in CXF. What happened in CXF is that we 
first reflect impl class, all methods defined in impl class become potential 
candidates for publishing. Then we check interface, if the method under 
consideration does not exist in the interface, we will fall back to the impl 
class to do a further check . This is wrong. According to the spec, if the 
interface is found, we should not look for any information from impl class:  " 
if the WebService annotation on the class under consideration has an 
endpointInterface element, then the interface referredby this element is for 
all purposes the SEI associated with the class."

Cheers,
Jervis


-Original Message-
From: Willem Jiang [mailto:[EMAIL PROTECTED]
Sent: 2007?7?13? 14:14
To: cxf-user@incubator.apache.org
Subject: Re: Exposing methods


Hi,

I just dug the code,  here is the code in the JaxWsServiceConfiguration 
to tell which method is the WebMethod.

@Override
public Boolean isOperation(Method method) {
Method origMethod = method;
method = getDeclaredMethod(method);
if (method.getReturnType().equals(Future.class)
|| method.getReturnType().equals(Response.class)) {
return false;
}
   
if (method != null) {
WebMethod wm = method.getAnnotation(WebMethod.class);
if (wm != null) {
if (wm.exclude()) {
return Boolean.FALSE;
} else {
return Boolean.TRUE;
}
} else {
if (method.getDeclaringClass().isInterface()) {
return hasWebServiceAnnotation(method)
||  hasWebServiceAnnotation(origMethod);
}
return hasWebServiceAnnotation(method); 
}
}
return Boolean.FALSE;
}
   
private boolean hasWebServiceAnnotation(Method method) {
return 
method.getDeclaringClass().getAnnotation(WebService.class) != null;
}

And there are some descriptions of the WebMethod definition can explain 
the code.
JAX-WS 2.0 specification (Final Release April 19, 2006)
Chapter 3 "Java to WSDL 1.1 Mapping" P30.

" In order to allow for a separation between Web service interface and 
implementation, if the WebService
annotation on the class under consideration has a endpointInterface 
element, then the interface referred
by this element is for all purposes the SEI associated with the class.

Otherwise, the class implicitly defines a service endpoint interface 
(SEI) which comprises all of the public
methods that satisfy one of the following conditions:
1. They are annotated with the javax.jws.WebMethod annotation with the 
exclude element set to
false or missing (since false is the default for this annotation element).
2. They are not annotated with the javax.jws.WebMethod annotation but 
their declaring class has a
javax.jws.WebService annotation.

For mapping purposes, this implicit SEI and its methods are considered 
to be annotated with the same Web
service-related annotations that the original class and its methods have.
*In pratice*, in order to exclude a public method of a class annotated 
with WebService and not directly
specifying a endpointInterface from the implicitly defined SEI, it is 
necessary to annotate the method
with a WebMethod annotation with the exclude element set to true."

And Jim's suggestion is right , you just need to  add the @WebMethod 
(exclude=true)  annotation to the method that you do not want to export 
as a WebMethod.


Cheers,

Willem.


Jim Ma wrote:
> Yes . It's the normal behavior. The runtime will reflect every method 
> in impl class and expose it unless the
> method is annotated with exclude WebMethod .
> CXF also can support publishing a service with a pojo class without 
> implementing any interface :
>
> @WebService
> public class UserWebServiceImpl {
>
>private UserManager userManager;
>   @WebMethod (exclude=true)
>public void setUserManager(UserManager userManager) {
>this.userManager = userManager;
>}
>   @WebMethod
>public User getUserById(Long id) {
>return userManager.getUser(id);
>}
> }
>
> Cheers
>
> Jim
>
> Julio Arias wrote:
>> Hi Jim,
>>
>> Thanks I found that property for the @WebMethod annotation too and it 
>> works fine. But is this a normal behavior to expose everything in the 
>> implementor, I thought it would only expose the methods on my interface.
>>
>> On Jul 12, 2007, at 9:05 PM, Jim Ma wrote:
>>
>>> Hi Julio,
>>>
>>> I think you can add @WebMethod(exclude=true)  for the setter method.
>>>
>>>@WebMethod (exclude=true)
>>> setUserManager(UserManager userManager)
>>>
>>> Cheers
>>>
>>> Jim
>>>
>>>
>>> Julio Arias wrote:
 The dependencies setters from my service impl are getting expose in 
 the WSDL even though I'm specifying the endpoint interface in the 
 implementor. How can I hide this methods

RE: Need to eliminate use of SOAP for Http-REST

[Liu, Jervis]

Hi Brad, 

Currently there are two ways to build RESTful service with CXF, using CXF HTTP 
binding or using JAX-WS Dispatch/Provider API. JAX-WS Dispatch/Provider 
approach is just using JAX-WS API, so it is SOAP/HTTP based (but you can also 
configure it to use XML binding instead). CXF HTTP binding maps operations from 
URI or HTTP verbs,  the input parameters can be extracted from URL or Http 
payload using different content types such as POX or JSON, it definitely does 
not need SOAP in this case.  I can not tell which approach you are using from 
the code snippet you have enclosed, I will need your 
com.nextrials.kilter.service.user.UserService class. But it seems that you are 
using JAX-WS Dispatch/Provider approach otherwise you wont get back an error 
message wrapped with SOAP Envelope.

Cheers,
Jervis

-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 2007?7?14? 1:39
To: cxf-user@incubator.apache.org
Subject: Need to eliminate use of SOAP for Http-REST


Hello,

I have followed the instructions in the documentation for RESTful 
services to with the intention of creating a pure Http-XML service 
without SOAP. However, when I hit one of my service URL's from a browser 
(without parameters, just to see what would happen) I get the following:




soap:Server
wrong number of arguments




I do not want to use SOAP. I want only an XML document passed as a 
parameter over Http -- no SOAP. This seems to indicate that SOAP is 
still in the mix, but I need to remove it. I have this configured in 
Spring, according to the documentation. Here is the content of my spring 
beans.xml (verbatim from the doc):

http://www.springframework.org/schema/beans";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:jaxws="http://cxf.apache.org/jaxws";
xsi:schemaLocation="
http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>






 


Here is the content of my web.xml, verbatim from the doc:

http://java.sun.com/dtd/web-app_2_3.dtd";>




contextConfigLocation
WEB-INF/beans.xml




org.springframework.web.context.ContextLoaderListener




CXFServlet
CXF Servlet

org.apache.cxf.transport.servlet.CXFServlet

1



CXFServlet
/*




How do I remove SOAP from the mix?

Thanks!

Brad




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Need to eliminate use of SOAP for Http-REST

[Liu, Jervis]

Opps, just saw that long discussion, glad to see the problem has fixed (or will 
be fixed :-)). 

Cheers,
Jervis

-Original Message-
From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
Sent: 2007?7?16? 10:22
To: cxf-user@incubator.apache.org
Subject: Re: Need to eliminate use of SOAP for Http-REST


Jervis,

Thanks for the reply. An update on the situation -- there is (was) a bug 
here, which Dan Diephouse is addressing. He found me a workaround to my 
problem for now.

Brad

Liu, Jervis wrote:
> Hi Brad, 
>
> Currently there are two ways to build RESTful service with CXF, using CXF 
> HTTP binding or using JAX-WS Dispatch/Provider API. JAX-WS Dispatch/Provider 
> approach is just using JAX-WS API, so it is SOAP/HTTP based (but you can also 
> configure it to use XML binding instead). CXF HTTP binding maps operations 
> from URI or HTTP verbs,  the input parameters can be extracted from URL or 
> Http payload using different content types such as POX or JSON, it definitely 
> does not need SOAP in this case.  I can not tell which approach you are using 
> from the code snippet you have enclosed, I will need your 
> com.nextrials.kilter.service.user.UserService class. But it seems that you 
> are using JAX-WS Dispatch/Provider approach otherwise you wont get back an 
> error message wrapped with SOAP Envelope.
>
> Cheers,
> Jervis
>
> -Original Message-
> From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
> Sent: 2007?7?14? 1:39
> To: cxf-user@incubator.apache.org
> Subject: Need to eliminate use of SOAP for Http-REST
>
>
> Hello,
>
> I have followed the instructions in the documentation for RESTful 
> services to with the intention of creating a pure Http-XML service 
> without SOAP. However, when I hit one of my service URL's from a browser 
> (without parameters, just to see what would happen) I get the following:
>
> 
> 
> 
> soap:Server
> wrong number of arguments
> 
> 
> 
>
> I do not want to use SOAP. I want only an XML document passed as a 
> parameter over Http -- no SOAP. This seems to indicate that SOAP is 
> still in the mix, but I need to remove it. I have this configured in 
> Spring, according to the documentation. Here is the content of my spring 
> beans.xml (verbatim from the doc):
>
> http://www.springframework.org/schema/beans";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxws="http://cxf.apache.org/jaxws";
> xsi:schemaLocation="
> http://www.springframework.org/schema/beans 
> http://www.springframework.org/schema/beans/spring-beans.xsd
> http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd";>
>
> 
> 
> 
>
>id="userService"
>   implementor="com.nextrials.kilter.service.user.UserService"
>   address="/UserService" />
>  
> 
>
> Here is the content of my web.xml, verbatim from the doc:
>
>  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>
> 
>
> 
> contextConfigLocation
> WEB-INF/beans.xml
> 
>
> 
> 
> org.springframework.web.context.ContextLoaderListener
> 
> 
>
> 
> CXFServlet
> CXF Servlet
> 
> org.apache.cxf.transport.servlet.CXFServlet
> 
> 1
> 
>
> 
> CXFServlet
> /*
> 
>
> 
>
> How do I remove SOAP from the mix?
>
> Thanks!
>
> Brad
>
>
>
> 
> 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: Adobe FLex 2 JSON client: problem with parameter order

[Liu, Jervis]

Hi Luca,  the parameter orders on the client side should not matter. The server 
retrieves input using name/value pairs. Having this said, I cant guarantee you 
that it is bug-free. ;-) I just added a REST system test using JSON as content 
type 
(trunk\systests\src\test\java\org\apache\cxf\systest\rest\RestClientServerBookTest.java).
 If you have access to svn and feel comfortable working on CXF source code, you 
can try to modify the test case to see if the problem can be reproduced based 
on that system test. 

Thanks,
Jervis

-Original Message-
From: Luca Ceppelli [mailto:[EMAIL PROTECTED]
Sent: 2007?7?15? 23:58
To: cxf-user@incubator.apache.org
Subject: Adobe FLex 2 JSON client: problem with parameter order




Hi all.


 


I’m trying to create a Adobe Flex 2 client which has to
communicate with a cxf service exposed through Json.  I used the following code 
for the initialization of the service.


 


ServerFactoryBean sf = new ServerFactoryBean();


 


Class serviceClass = 
JsonServiceBean.class.getClassLoader().loadClass(getServiceClass());


sf.setServiceClass(serviceClass);


 


Object instance;


if (getServiceBeanInstance() == null) { 


Class serviceImplClass =
JsonServiceBean.class.getClassLoader().loadClass(getServiceBean());


instance = serviceImplClass.newInstance();


 


} else {


instance =
getServiceBeanInstance();


}


 


sf.setServiceBean(instance);


 


sf.setAddress(getAddress());


 


 


sf.setBindingId("http://cxf.apache.org/bindings/xformat";);


sf.setTransportId("http://schemas.xmlsoap.org/wsdl/http/";);


 


sf.getServiceFactory().setWrapped(isWrapped());


Map properties = new
HashMap();


properties.put("Content-Type",
"text/plain");


 


// Set up the JSON StAX implementation


Map nstojns = new HashMap();


nstojns.put("http://cxf.apache.org/bindings/xformat";,
"xformat");


 


Iterator> iter =
getNamespaces().entrySet().iterator();


 


while (iter.hasNext()) {


Entry entry = (Entry) iter.next();


   
nstojns.put(entry.getKey(),entry.getValue());


}


 


MappedXMLInputFactory xif = new
MappedXMLInputFactory(nstojns);


properties.put(XMLInputFactory.class.getName(), xif);


 


org.codehaus.jettison.mapped.Configuration conf = new
org.codehaus.jettison.mapped.Configuration();


conf.setXmlToJsonNamespaces(nstojns);


 


 


MappedXMLOutputFactory xof = new
MappedXMLOutputFactory(conf);


properties.put(XMLOutputFactory.class.getName(), xof);


 


sf.setProperties(properties);


Server server = sf.create();


 


The signature of the remote method is:


 


Result createUser(Token token, String email, String userPwd,
String name, String surname);


 


The generated wsdl has as expected the following schema of
the message element


 





 


  


   


   


   


   


   


 


 








With the following JSON request:


 


{createUser:{token:{"token":"12345678"},
email:[EMAIL PROTECTED], userPwdID:pwd, name:Luca, surname:Ceppelli}}


 


the service works fine.


 


 


 


But, when the Flex 2 Client generates the request, the
parameters order is not respected. 
Following the code I used for the JSON service invocation:


 


import com.adobe.serialization.json.JSON;


 


…


 


httpService.request = JSON.encode({createUserss:{token:token,
email:emailID.text, userPwdID:userPwdID.text, name:nameID.text,
surname:surnameID.text}});


 


 


The problem is related with the Action Scripts Object: the
properties: token, name, email, ecc are stored in an internal map of the
root object. When the JSON.encode() static method accesses to the map
for retrieving the properties, theirs order is not respect. (I suspect that the
same problem could be happening also with a JAVA Script client).


 


I think that the easy solution is to use, instead of the SEQUENCE
complex type, the ALL complex type. What do you think about?


 


How is it possible to specify to use ALL instead of SEQUENCE
when the JSON service is created?


 


Have you other idea/suggestions to overcome this problem?


 


Thanks,


Luca.



  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: attempting HelloWorld service, getting NULL return value

[Liu, Jervis]

Hi Marty, as you said, you've examined the message flowing between client and 
client and it is correct, in this case, must be sth wrong with your client. You 
may want to send us your client code, so that we can take a quick look to see 
what happened there.

Thanks,
Jervis

-Original Message-
From: Marty Saxton [mailto:[EMAIL PROTECTED]
Sent: 2007?7?18? 3:35
To: cxf-user@incubator.apache.org
Subject: attempting HelloWorld service, getting NULL return value


I am using CXF as both the client and server, and I'm just trying to get
the following simple service working:
 
@WebService
public interface HelloWorld {
String sayHi(String text);
}
 
 
The implementation just returns "Hello " + text.  I examined the XML
flowing between the client & server and it appears correct, the server
is returning a correct message.  On the client side, using the jax-ws
frontend, I get a null instead of a string for the return value.  I must
be doing something terribly wrong, but I'm not sure where to begin
debugging this problem.
 
Thanks in advance!
 
 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Using Local Transport for JUnit Tests

[Liu, Jervis]

Hi Chris, to use local transport, you need to manually register 
LocalTransportFactory with all the namespaces that might be used, for example, 
"http://schemas.xmlsoap.org/soap/http";. An example of how this is done can be 
found from 
\trunk\rt\frontend\jaxws/src/test/java/org/apache/cxf/jaxws/AbstractJaxWsTest.java.
 Actually almost all unit tests under jaxws module are written with local 
transport, so just grab one CXF unit test then copy&paste, should work. 

Cheers,
Jervis

-Original Message-
From: Christopher Moesel [mailto:[EMAIL PROTECTED]
Sent: 2007?7?18? 2:04
To: cxf-user@incubator.apache.org
Subject: Using Local Transport for JUnit Tests


Hello All,

I'm trying to write some JUnit tests that can test my SOAP web services
using the local transport
(http://cwiki.apache.org/CXF20DOC/local-transport.html).

Normally I run my services using the CXF Servlet, so doing it
servlet-less is somewhat new to me.  Here is what I'm doing:

Using a Spring ClassPathXmlApplicationContext to load up the following
CXF spring configs:
- META-INF/cxf/cxf.xml
- META-INF/cxf/cxf-extension-soap.xml
- META-INF/cxf/cxf-extension-policy.xml

and also loading up my own spring configs that contain the endpoint,
like so:


  

  

  


But... when I load them up, I get an exception with the following
message:
No DestinationFactory was found for the namespace
http://schemas.xmlsoap.org/soap/http.

I suspect I'm missing a CXF config file that defines the
DestinationFactory, I'm not setting up something right on the endpoint,
or I'm just completely wrong and can't even use the local transport in
this way.

Could someone with a clue please help me out? ;)  The full stack trace
is at the bottom of this message.

-Chris

org.apache.cxf.service.factory.ServiceConstructionException
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:
105)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBea
n.java:142)
at
org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:277)
at
org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:223)
at
org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:175)
at
org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderI
mpl.java:74)
at javax.xml.ws.Endpoint.publish(Endpoint.java:156)
at
com.myco.ws.client.BaseWebServiceTest.runsOnceBeforeAllTests(BaseWebServ
iceTest.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at
org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAf
terRunner.java:74)
at
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfte
rRunner.java:50)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAf
terRunner.java:33)
at
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at
com.intellij.rt.junit4.Junit4TestMethodAdapter.run(Junit4TestMethodAdapt
er.java:54)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: org.apache.cxf.BusException: No DestinationFactory was found
for the namespace http://schemas.xmlsoap.org/soap/http.
at
org.apache.cxf.transport.DestinationFactoryManagerImpl.getDestinationFac
tory(DestinationFactoryManagerImpl.java:101)
at
org.apache.cxf.endpoint.ServerImpl.initDestination(ServerImpl.java:85)
at org.apache.cxf.endpoint.ServerImpl.(ServerImpl.java:69)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:
90)
... 27 more


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: POSTing customer using REST

[Liu, Jervis]

Hi Mansour, do you have targetNamespace attribute defined in your WebService 
annotation, such as @WebService(targetNamespace = "http://book.acme.com";)? This 
targetNamespace is needed for marshal/unmarshal between input and your Customer 
object. There were similar problem reported in the mailing list when 
targetNamespace is missing. If this does not help, you may want to post out 
your service interface/impl code.

Thanks,
Jervis

-Original Message-
From: Mansour Raad [mailto:[EMAIL PROTECTED]
Sent: 2007?7?24? 9:49
To: cxf-user@incubator.apache.org
Subject: POSTing customer using REST


Given the customer http rest sample, I defined a spring config with  
the following endpoint:

http://apache.org/cxf/binding/http";>
 
 
 
 
 
 

I'm bootstrapping CXF from tomcat using the following web.xml

 
 contextConfigLocation
 classpath:applicationContext.xml
 

 
 Spring Context Loader
 org.springframework.web.context.ContextLoaderListener
 

 
 CXFServlet
 org.apache.cxf.transport.servlet.CXFServlet
 1
 

 
 CXFServlet
 /cxf/*
 

When I post a request using

wget --post-file add.xml http://localhost:8080/cxf/xml/customers

I can see the function being called, however the name is null in the  
customer argument  any clues 

Thanks.
Mansour
:-)




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

Hi Michal, 

The short answer is we do not support Provider right now in CXF, 
I will discuss into details why we can not support Provider with 
standard JAX-WS APIs in a following email. You mentioned CORBA binding is 
working for you with the SEI style(client and server generated by wsdltojava), 
so why you wanted to try Provider interface? Is it because you want to access 
raw message that sent and received by CORBA binding? If this is the case, 
interceptors might help. I am not familiar with YOKO, but the underlying 
principles should be same as other bindings, i.e., they should have some CORBA 
binding interceptors that take an input stream, parse the input to get binding 
operation info, such as operation name, input parameter types etc so that they 
know how to dispatch the request into implementation. At the same time, some 
other CORBA binding interceptors will retrieve the payload from request (maybe 
the CDR format?) and turn it into some kind of objects that represent CORBA 
payload (maybe the CorbaMessage u referred to?). Lets say interceptor B, C, D 
are used by CORBA binding to do the work mentioned about, at the end of 
interceptor D, both operation info and message payload will be available for 
accessing.  So if you can ask YOKO team, they might help you to find out what 
interceptors are used by CORBA binding and how they work. You shall be able to 
access raw information from these interceptor directly. If you prefer not 
modify or use these CORBA interceptors directly, you can write you own 
interceptor. As long as you put this interceptor in a proper position of 
interceptor chain, you shall be able access all the information as well. An 
example of how to write and configure your own interceptor can be found from 
samples\streamInterceptor in CXF distribution.

Hope this helps,
Jervis

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 2007?7?30? 16:31
To: cxf-user@incubator.apache.org
Subject: RE: YOKO & CXF CORBA Web Service using Provider


Thanks guys for your helpful replies. Isn't there any way how to solve my
problem using Interceptor? I'll try ServerFactoryBean as you mentioned.
Thanks


> Michal,

> Right now, we don't support any Provider (or Dispatch) that takes the raw 
> CXF Message types.   That's a good suggestion though.  Could you log a 
> Jira for it?
>
> What's worse, looking at the code for the Dispatch/Provider stuff on 
> trunk, it only will work for XML and SOAP bindings.   It specifically 
> checks for those and does "bad" things.   I was hoping to say you could 
> do something like:
>
> public class CalculatorImpl implements Provider {
> }
>
> to use the data from the CORBA stream reader, but that doesn't even work 
> right now. Even trying a Source doesn't work.I think some Jira's 
> need to be added for that as well.
>
>
> Dan
>
>
> > On Friday 27 July 2007 09:29, Michal Šafr wrote:
> >
> > firstly I'm not sure, if this is CXF or YOKO problem, so please excuse
> > me if I've sent this problem to a wrong place. I've got the problem
> > described below.
> >
> > I started from simple WSDL describing service with CORBA binding. I
> > generated standalone server and client using CXF tool wsdl2java
> > -server (-client) . Implemented service and everything worked fine
> > without any problem. I was able to call WS using generated client and
> > WS was returning expected values. Then I decided to implement WS using
> > interface javax.xml.ws.Provider so I had:
>
> //Service class, annotations are not mentioned here, but i changed
> @WebService annotation to @WebServiceProvider and added @ServiceMode
>
> public class CalculatorImpl implements Provider {
>
>   public CorbaMessage invoke(CorbaMessage arg0) {
>
> System.out.println("corba service called");
>
> return arg0;
>
>   }
>
> }
>
>
>
> Every time I try to call WS a receive following exception on the
> client side:
>
>
>
> org.omg.CORBA.MARSHAL:   vmcid: SUN  minor code: 207  completed: No
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6386)
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6408)
>
>   at
> com.sun.corba.se.impl.encoding.BufferManagerReadStream.underflow(Buffe
>rManag erReadStream.java:93)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_
>1_1.ja va:75)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInp
>utStre am_1_2.java:80)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_longlong(CDRInp
>utStre am_1_0.java:504)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_double(CDRInput
>Stream _1_0.java:526)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream.read_double(CDRInputStre
>am.jav a:153)
>
>   at
> com.pikeelectronic.calc._CalculatorStub.add(_CalculatorStub.java:182)
>
> 

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

Coming to think of this again, I found supporting Provider isn't 
that difficult as I originally thought. We have some manual checks of binding 
type in DispatchInDatabindingInterceptor\DispatchOutDatabindingInterceptor, 
such as if (binding == soapbinding) then blabla. Actually we were just being 
lazy, we should really implement DispatchInDatabindingInterceptor as 
DispatchInSoapBindingDatabindingInterceptor and 
DispatchInXMLbindingDatabindingInterceptor. This way, different 
dispatch/provider interceptors for different bindings can be added by 
corresponding binding providers, which allows the support of new bindings 
without the need to modify existing code base. E.g., adding  CORBA binding 
support for dispatch/provider involves in writing a 
DispatchInCorbaBindingDatabindingInterceptor, doing whatever you want in this 
interceptor then making sure the CORBABinding provider has this 
DispatchInCorbaBindingDatabindingInterceptor registered into interceptor chain 
during provider/dispatch case.

Cheers,
Jervis

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 2007年7月28日 11:23
To: cxf-user@incubator.apache.org
Cc: Michal ?afr; [EMAIL PROTECTED]
Subject: Re: YOKO & CXF CORBA Web Service using Provider



Michal,

Right now, we don't support any Provider (or Dispatch) that takes the raw 
CXF Message types.   That's a good suggestion though.  Could you log a 
Jira for it?

What's worse, looking at the code for the Dispatch/Provider stuff on 
trunk, it only will work for XML and SOAP bindings.   It specifically 
checks for those and does "bad" things.   I was hoping to say you could 
do something like:

public class CalculatorImpl implements Provider {
}

to use the data from the CORBA stream reader, but that doesn't even work 
right now. Even trying a Source doesn't work.I think some Jira's 
need to be added for that as well.


Dan


On Friday 27 July 2007 09:29, Michal Šafr wrote:
>
> firstly I'm not sure, if this is CXF or YOKO problem, so please excuse
> me if I've sent this problem to a wrong place. I've got the problem
> described below.
>
> I started from simple WSDL describing service with CORBA binding. I
> generated standalone server and client using CXF tool wsdl2java
> -server (-client) . Implemented service and everything worked fine
> without any problem. I was able to call WS using generated client and
> WS was returning expected values. Then I decided to implement WS using
> interface javax.xml.ws.Provider so I had:
>
> //Service class, annotations are not mentioned here, but i changed
> @WebService annotation to @WebServiceProvider and added @ServiceMode
>
> public class CalculatorImpl implements Provider {
>
>   public CorbaMessage invoke(CorbaMessage arg0) {
>
> System.out.println("corba service called");
>
> return arg0;
>
>   }
>
> }
>
>
>
> Every time I try to call WS a receive following exception on the
> client side:
>
>
>
> org.omg.CORBA.MARSHAL:   vmcid: SUN  minor code: 207  completed: No
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6386)
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6408)
>
>   at
> com.sun.corba.se.impl.encoding.BufferManagerReadStream.underflow(Buffe
>rManag erReadStream.java:93)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_
>1_1.ja va:75)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInp
>utStre am_1_2.java:80)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_longlong(CDRInp
>utStre am_1_0.java:504)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_double(CDRInput
>Stream _1_0.java:526)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream.read_double(CDRInputStre
>am.jav a:153)
>
>   at
> com.pikeelectronic.calc._CalculatorStub.add(_CalculatorStub.java:182)
>
>   at
> com.pikeelectronic.calc.CORBAClient.Client.main(Client.java:32)
>
>
>
> And following exception on the server side:
>
>
>
> 27.7.2007 13:21:05 org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
>
> INFO: Interceptor has thrown exception, unwinding now
>
> java.lang.NullPointerException
>
>   at java.lang.Class.isAssignableFrom(Native Method)
>
>   at
> org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa
>taRead er.java:56)
>
>   at
> org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa
>taRead er.java:52)
>
>   at
> org.apache.cxf.databinding.source.XMLStreamDataReader.read(XMLStreamDa
>taRead er.java:48)
>
>   at
> org.apache.cxf.interceptor.BareInInterceptor.handleMessage(BareInInter
>ceptor .java:138)
>
>   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
>rChain .java:206)
>
>   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitia
>tionOb server.ja

RE: http rest sample does not compile

[Liu, Jervis]

Thanks for the report. Fixed.

Cheers,
Jervis

-Original Message-
From: Mansour Raad [mailto:[EMAIL PROTECTED]
Sent: 2007?7?30? 18:24
To: cxf-user@incubator.apache.org
Subject: http rest sample does not compile


svn up the latest.
cd [install]/samples/restful_http_binding
ant server
I get the following:

Buildfile: build.xml

maybe.generate.code:

compile:
 [mkdir] Created dir: /Users/mansour/apache-cxf-2.1-incubator- 
SNAPSHOT/samples/restful_http_binding/build/classes
 [mkdir] Created dir: /Users/mansour/apache-cxf-2.1-incubator- 
SNAPSHOT/samples/restful_http_binding/build/src
 [javac] Compiling 11 source files to /Users/mansour/apache- 
cxf-2.1-incubator-SNAPSHOT/samples/restful_http_binding/build/classes
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:44: package  
org.codehaus.jettison.mapped does not exist
 [javac] import org.codehaus.jettison.mapped.MappedXMLInputFactory;
 [javac] ^
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:45: package  
org.codehaus.jettison.mapped does not exist
 [javac] import org.codehaus.jettison.mapped.MappedXMLOutputFactory;
 [javac] ^
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:114: cannot find  
symbol
 [javac] symbol  : class MappedXMLInputFactory
 [javac] location: class com.acme.customer.Main
 [javac] MappedXMLInputFactory xif = new  
MappedXMLInputFactory(nstojns);
 [javac] ^
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:114: cannot find  
symbol
 [javac] symbol  : class MappedXMLInputFactory
 [javac] location: class com.acme.customer.Main
 [javac] MappedXMLInputFactory xif = new  
MappedXMLInputFactory(nstojns);
 [javac] ^
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:117: cannot find  
symbol
 [javac] symbol  : class MappedXMLOutputFactory
 [javac] location: class com.acme.customer.Main
 [javac] MappedXMLOutputFactory xof = new  
MappedXMLOutputFactory(nstojns);
 [javac] ^
 [javac] /Users/mansour/apache-cxf-2.1-incubator-SNAPSHOT/samples/ 
restful_http_binding/src/com/acme/customer/Main.java:117: cannot find  
symbol
 [javac] symbol  : class MappedXMLOutputFactory
 [javac] location: class com.acme.customer.Main
 [javac] MappedXMLOutputFactory xof = new  
MappedXMLOutputFactory(nstojns);
 [javac]  ^
 [javac] 6 errors

Any clues ?

Mansour
:-)




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Plain Old Xml over Http

[Liu, Jervis]

Hi Ray, What do you mean by "not do the auto-magical xml stuff that CXF seems 
to support now in the REST support"? Do you mean you want to access the raw xml 
message payload instead of marshalling the xml into objects? If this is the 
case, you probably want to use the JAX-WS Provider/Dispatch approach: 
http://cwiki.apache.org/CXF20DOC/rest-with-jax-ws-provider-and-dispatch.html



Cheers,
Jervis

-Original Message-
From: Ray Krueger [mailto:[EMAIL PROTECTED]
Sent: 2007?7?30? 19:26
To: cxf-user@incubator.apache.org
Subject: Plain Old Xml over Http


I'm loving CXF right now by the way, so thanks for that :)

I'd like to be able to send my current WSDL types over the wire
without soap envelopes as plain-old-xml via http POST operations.

I started with a WSDL and a pair of Request/Response type objects...

Running wsdl2java generates a perfectly working service with jaxb
inputs/outputs...
(summarizing code here, not copy and pasting)

@WebService
interface CurrencyExchange {
  @WebResult, @WebMethod
  ExchangeResponse exchange(@WebParam ExchangeRequest)
}

Great, all this SOAP stuff works as advertised and that's fantastic.
I'd like people to be able to use a REST-like url (really, I don't
care what the url looks like), but not do the auto-magical xml stuff
that CXF seems to support now in the REST support.

I'd like to use the same schemas I use for the input and output mesage
types in the wsdl.

via the POX approach...
http://localhost:8080/CurrencyExchange/exchange
POST .
returns 

via the SOAP approach...
http://localhost:8080/CurrencyExchange
POST .
returns 

Any ideas where I could start or what I could touch to make this work?

(Hopefully the half-assery that are my code examples; don't confuse anyone)


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

Hi Michael, I will be working on this tomorrow or the day after tomorrow. 

Cheers,
Jervis

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 2007年7月30日 19:52
To: cxf-user@incubator.apache.org; Liu, Jervis
Subject: RE: YOKO & CXF CORBA Web Service using Provider


Hi Jervis, it really sounds great, cxf would be more flexible then. Thank you 
for your replies. So do you plan adding support of that to cxf? And would it be 
possible to know when? :-)

Cheers,
Michael


-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 30, 2007 1:12 PM
To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
Cc: Michal ?afr; [EMAIL PROTECTED]
Subject: RE: YOKO & CXF CORBA Web Service using Provider

Coming to think of this again, I found supporting Provider isn't 
that difficult as I originally thought. We have some manual checks of binding 
type in DispatchInDatabindingInterceptor\DispatchOutDatabindingInterceptor, 
such as if (binding == soapbinding) then blabla. Actually we were just being 
lazy, we should really implement DispatchInDatabindingInterceptor as 
DispatchInSoapBindingDatabindingInterceptor and 
DispatchInXMLbindingDatabindingInterceptor. This way, different 
dispatch/provider interceptors for different bindings can be added by 
corresponding binding providers, which allows the support of new bindings 
without the need to modify existing code base. E.g., adding  CORBA binding 
support for dispatch/provider involves in writing a 
DispatchInCorbaBindingDatabindingInterceptor, doing whatever you want in this 
interceptor then making sure the CORBABinding provider has this 
DispatchInCorbaBindingDatabindingInterceptor registered into interceptor chain 
during provider/dispatch case.

Cheers,
Jervis

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 2007年7月28日 11:23
To: cxf-user@incubator.apache.org
Cc: Michal ?afr; [EMAIL PROTECTED]
Subject: Re: YOKO & CXF CORBA Web Service using Provider



Michal,

Right now, we don't support any Provider (or Dispatch) that takes the raw 
CXF Message types.   That's a good suggestion though.  Could you log a 
Jira for it?

What's worse, looking at the code for the Dispatch/Provider stuff on 
trunk, it only will work for XML and SOAP bindings.   It specifically 
checks for those and does "bad" things.   I was hoping to say you could 
do something like:

public class CalculatorImpl implements Provider {
}

to use the data from the CORBA stream reader, but that doesn't even work 
right now. Even trying a Source doesn't work.I think some Jira's 
need to be added for that as well.


Dan


On Friday 27 July 2007 09:29, Michal Šafr wrote:
>
> firstly I'm not sure, if this is CXF or YOKO problem, so please excuse
> me if I've sent this problem to a wrong place. I've got the problem
> described below.
>
> I started from simple WSDL describing service with CORBA binding. I
> generated standalone server and client using CXF tool wsdl2java
> -server (-client) . Implemented service and everything worked fine
> without any problem. I was able to call WS using generated client and
> WS was returning expected values. Then I decided to implement WS using
> interface javax.xml.ws.Provider so I had:
>
> //Service class, annotations are not mentioned here, but i changed
> @WebService annotation to @WebServiceProvider and added @ServiceMode
>
> public class CalculatorImpl implements Provider {
>
>   public CorbaMessage invoke(CorbaMessage arg0) {
>
> System.out.println("corba service called");
>
> return arg0;
>
>   }
>
> }
>
>
>
> Every time I try to call WS a receive following exception on the
> client side:
>
>
>
> org.omg.CORBA.MARSHAL:   vmcid: SUN  minor code: 207  completed: No
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6386)
>
>   at
> com.sun.corba.se.impl.logging.ORBUtilSystemException.endOfStream(ORBUt
>ilSyst emException.java:6408)
>
>   at
> com.sun.corba.se.impl.encoding.BufferManagerReadStream.underflow(Buffe
>rManag erReadStream.java:93)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_1.grow(CDRInputStream_
>1_1.ja va:75)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_2.alignAndCheck(CDRInp
>utStre am_1_2.java:80)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_longlong(CDRInp
>utStre am_1_0.java:504)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream_1_0.read_double(CDRInput
>Stream _1_0.java:526)
>
>   at
> com.sun.corba.se.impl.encoding.CDRInputStream.read_double(CDRInputStre
>am.jav a:153)
>
>   at
> com.pikeelectronic

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

Hi, have a new question. I suppose the reason why you want to use Provider 
interface for CORBA binding is that you want to access "raw CORBA message 
payload" so that you can parse operation info and input parameters by yourself. 
However the question is what the "raw CORBA message payload" is? In the world 
of SOAP binding or XML binding, the content sent on the wire normally can be 
represented as XML, thus we can have typed provider interface like 
Provider, Provider. However, in the world of CORBA, I 
don't think we have a well-defined type to represent "raw CORBA message 
payload", do we? Please note, org.apache.yoko.bindings.corba.CorbaMessage is 
not the one we are looking for. Same as the 
org.apache.cxf.binding.soap.SoapMessage and 
org.apache.cxf.binding.xml.XMLMessage, they are just a content holder, which 
represent the whole input/output message rather than the message payload. The 
type class that can be used in Provider is sth that can be produced by 
Object = DataReader.read(...).  Before we can go ahead to support 
Provider for CORBA binding, we really need to figure out what the T is. 

BTW, if what you want is CorbaMessage, you can access it from Exchange. See 
Dan's previous comment in this thread on how to access Exchange.

I will send this message across to yoko mailing list, hopefully Yoko guys can 
give some insight on this.

Cheers,
Jervis


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 2007年7月30日 19:52
To: cxf-user@incubator.apache.org; Liu, Jervis
Subject: RE: YOKO & CXF CORBA Web Service using Provider


Hi Jervis, it really sounds great, cxf would be more flexible then. Thank you 
for your replies. So do you plan adding support of that to cxf? And would it be 
possible to know when? :-)

Cheers,
Michael


-Original Message-
From: Liu, Jervis [mailto:[EMAIL PROTECTED] 
Sent: Monday, July 30, 2007 1:12 PM
To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
Cc: Michal ?afr; [EMAIL PROTECTED]
Subject: RE: YOKO & CXF CORBA Web Service using Provider

Coming to think of this again, I found supporting Provider isn't 
that difficult as I originally thought. We have some manual checks of binding 
type in DispatchInDatabindingInterceptor\DispatchOutDatabindingInterceptor, 
such as if (binding == soapbinding) then blabla. Actually we were just being 
lazy, we should really implement DispatchInDatabindingInterceptor as 
DispatchInSoapBindingDatabindingInterceptor and 
DispatchInXMLbindingDatabindingInterceptor. This way, different 
dispatch/provider interceptors for different bindings can be added by 
corresponding binding providers, which allows the support of new bindings 
without the need to modify existing code base. E.g., adding  CORBA binding 
support for dispatch/provider involves in writing a 
DispatchInCorbaBindingDatabindingInterceptor, doing whatever you want in this 
interceptor then making sure the CORBABinding provider has this 
DispatchInCorbaBindingDatabindingInterceptor registered into interceptor chain 
during provider/dispatch case.

Cheers,
Jervis

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: 2007年7月28日 11:23
To: cxf-user@incubator.apache.org
Cc: Michal ?afr; [EMAIL PROTECTED]
Subject: Re: YOKO & CXF CORBA Web Service using Provider



Michal,

Right now, we don't support any Provider (or Dispatch) that takes the raw 
CXF Message types.   That's a good suggestion though.  Could you log a 
Jira for it?

What's worse, looking at the code for the Dispatch/Provider stuff on 
trunk, it only will work for XML and SOAP bindings.   It specifically 
checks for those and does "bad" things.   I was hoping to say you could 
do something like:

public class CalculatorImpl implements Provider {
}

to use the data from the CORBA stream reader, but that doesn't even work 
right now. Even trying a Source doesn't work.I think some Jira's 
need to be added for that as well.


Dan


On Friday 27 July 2007 09:29, Michal Šafr wrote:
>
> firstly I'm not sure, if this is CXF or YOKO problem, so please excuse
> me if I've sent this problem to a wrong place. I've got the problem
> described below.
>
> I started from simple WSDL describing service with CORBA binding. I
> generated standalone server and client using CXF tool wsdl2java
> -server (-client) . Implemented service and everything worked fine
> without any problem. I was able to call WS using generated client and
> WS was returning expected values. Then I decided to implement WS using
> interface javax.xml.ws.Provider so I had:
>
> //Service class, annotations are not mentioned here, but i changed
> @WebService annotation to @WebServiceProvider and added @ServiceMode
>
> public class CalculatorImpl implements Provider {
>
>   public CorbaMessage invoke(CorbaMessage arg0) {
>
>

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

JAX-WS does not support DII except the Dispatch interface, the old JAX-RPC spec 
does. The reason is because DII in its nature, does not work well with Doc/Lit 
style web services. BTW, one could also argue Dispatch interface is more 
powerful than DII.

Cheers,
Jervis 

-Original Message-
From: Lukas Zapletal [mailto:[EMAIL PROTECTED]
Sent: 2007年8月2日 16:11
To: cxf-user@incubator.apache.org
Subject: Re: YOKO & CXF CORBA Web Service using Provider


Hello,

is it possible to call CORBA service with CXF using DII? How could I
pass the request through the binding?

LZ

2007/7/30, Liu, Jervis <[EMAIL PROTECTED]>:
> Hi Michal,
>
> The short answer is we do not support Provider right now in 
> CXF, I will discuss into details why we can not support 
> Provider with standard JAX-WS APIs in a following email. You 
> mentioned CORBA binding is working for you with the SEI style(client and 
> server generated by wsdltojava), so why you wanted to try Provider interface? 
> Is it because you want to access raw message that sent and received by CORBA 
> binding? If this is the case, interceptors might help. I am not familiar with 
> YOKO, but the underlying principles should be same as other bindings, i.e., 
> they should have some CORBA binding interceptors that take an input stream, 
> parse the input to get binding operation info, such as operation name, input 
> parameter types etc so that they know how to dispatch the request into 
> implementation. At the same time, some other CORBA binding interceptors will 
> retrieve the payload from request (maybe the CDR format?) and turn it into 
> some kind of objects that represent CORBA payload (maybe the CorbaMessage u 
> referred to?). Lets say interceptor B, C, D are used by CORBA binding to do 
> the work mentioned about, at the end of interceptor D, both operation info 
> and message payload will be available for accessing.  So if you can ask YOKO 
> team, they might help you to find out what interceptors are used by CORBA 
> binding and how they work. You shall be able to access raw information from 
> these interceptor directly. If you prefer not modify or use these CORBA 
> interceptors directly, you can write you own interceptor. As long as you put 
> this interceptor in a proper position of interceptor chain, you shall be able 
> access all the information as well. An example of how to write and configure 
> your own interceptor can be found from samples\streamInterceptor in CXF 
> distribution.
>
> Hope this helps,
> Jervis
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 2007?7?30? 16:31
> To: cxf-user@incubator.apache.org
> Subject: RE: YOKO & CXF CORBA Web Service using Provider
>
>
> Thanks guys for your helpful replies. Isn't there any way how to solve my
> problem using Interceptor? I'll try ServerFactoryBean as you mentioned.
> Thanks
>
>
> > Michal,
>
> > Right now, we don't support any Provider (or Dispatch) that takes the raw
> > CXF Message types.   That's a good suggestion though.  Could you log a
> > Jira for it?
> >
> > What's worse, looking at the code for the Dispatch/Provider stuff on
> > trunk, it only will work for XML and SOAP bindings.   It specifically
> > checks for those and does "bad" things.   I was hoping to say you could
> > do something like:
> >
> > public class CalculatorImpl implements Provider {
> > }
> >
> > to use the data from the CORBA stream reader, but that doesn't even work
> > right now. Even trying a Source doesn't work.I think some Jira's
> > need to be added for that as well.
> >
> >
> > Dan
> >
> >
> > > On Friday 27 July 2007 09:29, Michal Šafr wrote:
> > >
> > > firstly I'm not sure, if this is CXF or YOKO problem, so please excuse
> > > me if I've sent this problem to a wrong place. I've got the problem
> > > described below.
> > >
> > > I started from simple WSDL describing service with CORBA binding. I
> > > generated standalone server and client using CXF tool wsdl2java
> > > -server (-client) . Implemented service and everything worked fine
> > > without any problem. I was able to call WS using generated client and
> > > WS was returning expected values. Then I decided to implement WS using
> > > interface javax.xml.ws.Provider so I had:
> >
> > //Service class, annotations are not mentioned here, but i changed
> > @WebService annotation to @WebServiceProvider and added @ServiceMode
> >
> > public class CalculatorImpl implements Provider {
> >
> >   public 

RE: Good way to return a RowSet from a service?

[Liu, Jervis]

It looks like you are trying to do some kind of Database Web services. I am 
afraid in the world of Database web services, you would never want to return 
RowSet directly because RowSet object is too complex/big to be mapped to XML, 
not to mention other concerns like performance etc. Many database vendors and 
web services framework vendors have done a lot in the Database web services 
area. There are two most common approaches. One is you map JDBC types to XML 
types (and vice versa) either by an O/R mapping framework (like Hibernate) or 
by yourself. Take an example, if you have a SQL statement "SELECT employee_name 
from employee where employee_id=?", this can be mapped to an operation in your 
WSDL, and the corresponding java operation is String getEmployeeName(String 
employeeID). When a request coming said I want to invoke getEmployeeName with a 
string parameter, the web service stack will first dispatch the incoming SOAP 
message to getEmployeeName(String employeeID) method, then the DB web service 
code (you write this piece of code or it is a functionality provided by DB web 
service vendor) maps employeeID to JDBC type then invoke the SQL of  "SELECT 
employee_name from employee where employee_id=?".  Of course this is just a 
version simplified for the purpose illustration, the real process can be more 
complex.

Another approach is to utilize the XML database or XML interface provided on 
top of traditional database. Now that the output of database is already in XML 
format, it is just a simple matter how you expose certain DB queries 
appropriately as web services and how you organize the result and return it 
back. This is indeed a very interesting topic, especially when this offering is 
combined with REST. Think about it this way, database in its nature, is a 
resource repository. All these SQL queries do is to navigate among resources 
(i.e., tables, columns.). This is exactly what REST is. I am personally very 
interested in this topic and would like to see how we can explore this 
potential using CXF REST support. Sth similar to what Microsoft Astoria is done 
[1]. If you have any comments or suggestions, I would be very happy to hear 
from you.

Let me know if this answered your question.

[1].   
http://astoria.mslivelabs.com/Overview.doc

Jervis

-Original Message-
From: Glen Mazza [ mailto:[EMAIL PROTECTED]
Sent: 2007?8?3? 10:39
To: cxf-user@incubator.apache.org
Subject: Re: Good way to return a RowSet from a service?


Mark Hansen's pretty-good-if-tad-bit-pricey SOA book
( http://www.soabook.com/) covers XmlAdapters in a fair amount of detail
on p.245-256, although I'm not certain it would solve the user's problem
here.

Glen

Am Donnerstag, den 02.08.2007, 12:54 -0400 schrieb Daniel Kulp:
> This is actually an "interesting" question that's been on my "todo" list
> to investigate for ages.  It relates to things like HashMaps and such.
>
> The JAXB Javadoc describes some stuff about XmlAdapters:
> http://java.sun.com/javase/6/docs/api/javax/xml/bind/annotation/adapters/XmlAdapter.html
> that supposedly could be used to map non-jaxb objects into objects that
> JAXB can understand.   That javadoc describes a sample thing for
> HashMaps, but I haven't actually tried doing it to see how it would work
> or how to integrate it into CXF.
>
> Dan
>
>
>
> On Tuesday 31 July 2007 23:34, Jeremy Isikoff wrote:
> > Hi all, I'm trying to return a RowSet (data and schema info) from a
> > cxf webservice. I tried returning instances of CachedRowSetImpl or
> > WebRowSetImpl directly but they both cause stack overflows when
> > deploying to tomcat. Is there some better way to do this or do I have
> > write my own class?
> >
> >
> > java.lang.StackOverflowError
> > at java.lang.Class.privateGetDeclaredFields(Class.java:2278)
> > at java.lang.Class.getDeclaredFields(Class.java:1743)
> > at
> > org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitial
> >izer.java:130) at
> > org.apache.cxf.jaxb.JAXBContextInitializer.addClass(JAXBContextInitial
> >izer.java:131) at org.apache.cxf.jaxb.JAXBContextInitializer.a
> >
> >
> >
> > __
> >__ Looking for a deal? Find great prices on flights and
> > hotels with Yahoo! FareChase. http://farechase.yahoo.com/
>




IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Good way to return a RowSet from a service?

[Liu, Jervis]

RowSet itself contains too much information that wont be used when it is being 
marshalled into XML, and some information inside RowSet are impossible to be 
marshalled to XML as well. JAXB wont know how to marshal RowSet(or WebRowSet). 
What the approach one I mentioned previously tries to do is given an Database 
schema and JDBC types, how you map them into XML schema and XML types. This is 
the problem you have resolve as well. In your case, you have a RowSet which 
contains both data resulted from query and the meta-data - the database schema. 
WebRowSet is just one way to do this. Haven't tried this by myself, but I 
presume somehow you can use WebRowSet.writeXml(OutputStream oStream) to 
generate a xsd:string or xsd:any and return it back. Another way to look into 
this is if you know your query is fixed, for example, you only use query 
"SELECT employee_name from employee where employee_id=?", you can map this 
query to a java method manually, then expose this java method as web services. 
The benefit of doing so is your web service schema is fixed in the design time, 
not like using the WebRowSet, all you know about the schema of your web service 
response is it is a xsd:any, or even worse, xsd:string, and of course, the 
performance is much better, as you are sending back much less information.

Cheers,
Jervis


-Original Message-
From: Jeremy Isikoff [mailto:[EMAIL PROTECTED]
Sent: 2007年8月3日 12:52
To: cxf-user@incubator.apache.org
Subject: Re: Good way to return a RowSet from a service?


Sorry if this is getting a bit off topic...I know in .Net a dataset is XML 
serializable no problem with both schema and data and I'm coming from .net and 
moving to java

What I'm doing is running scheduled queries on a server and then need to feed 
them to a client that charts this data  at a later time.  I need to 1) store 
the results in the server db in some serialized format probably as xml in a 
clob and 2) return them to the client over a webservice 

I was thinking WebRowSet would be useful for this but I couldn't manage to get 
it to work.I tried returning a WebRowSetImpl directly from a webservice but it 
wouldnt make thorugh JAXB.  I'm thinking now of making a dumb wrapper for it 
and just using its WriteXML method to write itself into a string property in 
the wrapper instead.

Like I said Im coming from .Net and Im used to classes implementing 
XMLSerializable which is what is naturally called when a web service tries to 
serialize their data.

So the crux of the problem really is how to get rowset data and schema across 
the wire without writting a brand new class and why WebRowSet doesnt seen to 
work for this?

----- Original Message 
From: "Liu, Jervis" <[EMAIL PROTECTED]>
To: cxf-user@incubator.apache.org
Sent: Thursday, August 2, 2007 11:53:34 PM
Subject: RE: Good way to return a RowSet from a service?


It looks like you are trying to do some kind of Database Web services. I am 
afraid in the world of Database web services, you would never want to return 
RowSet directly because RowSet object is too complex/big to be mapped to XML, 
not to mention other concerns like performance etc. Many database vendors and 
web services framework vendors have done a lot in the Database web services 
area. There are two most common approaches. One is you map JDBC types to XML 
types (and vice versa) either by an O/R mapping framework (like Hibernate) or 
by yourself. Take an example, if you have a SQL statement "SELECT employee_name 
from employee where employee_id=?", this can be mapped to an operation in your 
WSDL, and the corresponding java operation is String getEmployeeName(String 
employeeID). When a request coming said I want to invoke getEmployeeName with a 
string parameter, the web service stack will first dispatch the incoming SOAP 
message to getEmployeeName(String
 employeeID) method, then the DB web service code (you write this piece of code 
or it is a functionality provided by DB web service vendor) maps employeeID to 
JDBC type then invoke the SQL of  "SELECT employee_name from employee where 
employee_id=?".  Of course this is just a version simplified for the purpose 
illustration, the real process can be more complex.

Another approach is to utilize the XML database or XML interface provided on 
top of traditional database. Now that the output of database is already in XML 
format, it is just a simple matter how you expose certain DB queries 
appropriately as web services and how you organize the result and return it 
back. This is indeed a very interesting topic, especially when this offering is 
combined with REST. Think about it this way, database in its nature, is a 
resource repository. All these SQL queries do is to navigate among resources 
(i.e., tables, columns.). This is exactly what REST is. I am personally very 
interested in this topic and would like to see how we can explore this 
potentia

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

Hi Lukas, none of these Provider, Provider or 
Provider is supposed to work with CORBA binding. The type class T in 
Provider has to be something that can represent the message (or message 
payload) you sent on the wire DIRECTLY. What I mean by “directly” is without 
any extra marshaling/unmarshalling or transformation for example, using a data 
binding to map one type to another type.  In the case of SOAP binding or XML 
binding, the content type is text/xml, the wire message can always be 
represented as Source or SOAPMessage (SOAP binding) object.  The message sent 
on the wire for CORBA biding is in binary format. A simple question, in the 
Dispatch example you gave in your previous email, how can you transform a 
Source that represents a xml document of "http://schemas.apache.org/yoko/idl/calc/> 
http://schemas.apache.org/yoko/idl/calc/>" into a binary format of CORBA 
message? The T in Provider or Dispatch has to be something that you can 
take it and sent it out on the wire directly without any transformation. This 
is why Dispatch won’t work.

To get Dispatch/Provider interface working with CORBA binding, we need to 
figure out what the T is in the Provider.

If you use CORBA server & web services client as described in YOKO 
ws\hello_world sample (i.e., the server is using CORBA binding, the client is 
using SOAP or XML binding), Dispatch should definitely work, because 
what sent on the wire is SOAP or XML message.

Jervis

-Original Message-
From: Lukas Zapletal [ mailto:[EMAIL PROTECTED]
Sent: 2007年8月2日 23:00
To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
Subject: Re: YOKO & CXF CORBA Web Service using Provider


Hello,

the operation info and CORBA parameters are not the reason why do we
need the support. We would like to create a web service provider that
will be accessible from CORBA client. We have no clue how to do this
because we cannot simply create Provider,
Provider or even Provider. Exception occurs when
we try this so it seems nobody ever used it before and the code
contains a bug or we are doing something wrong.

On the other side we are also trying to call (normal) CORBA service
with web service client implemented in CXF/Yoko dynamicaly (DII
client). We do not know if is it possible to create SOAPMessage and
pass it to Yoko CORBA binding along with WSDL file to make a dynamic
call.

It seems to me the terms "corba cxf binding" and "dynamic" cannot live
together...

Best regards, Lukas

2007/8/2, Liu, Jervis <[EMAIL PROTECTED]>:
> Hi, have a new question. I suppose the reason why you want to use Provider 
> interface for CORBA binding is that you want to access "raw CORBA message 
> payload" so that you can parse operation info and input parameters by 
> yourself. However the question is what the "raw CORBA message payload" is? In 
> the world of SOAP binding or XML binding, the content sent on the wire 
> normally can be represented as XML, thus we can have typed provider interface 
> like Provider, Provider. However, in the world of CORBA, 
> I don't think we have a well-defined type to represent "raw CORBA message 
> payload", do we? Please note, org.apache.yoko.bindings.corba.CorbaMessage is 
> not the one we are looking for. Same as the 
> org.apache.cxf.binding.soap.SoapMessage and 
> org.apache.cxf.binding.xml.XMLMessage, they are just a content holder, which 
> represent the whole input/output message rather than the message payload. The 
> type class that can be used in Provider is sth that can be produced by 
> Object = DataReader.read(...).  Before we can go ahead to support 
> Provider for CORBA binding, we really need to figure out what the T is.
>
> BTW, if what you want is CorbaMessage, you can access it from Exchange. See 
> Dan's previous comment in this thread on how to access Exchange.
>
> I will send this message across to yoko mailing list, hopefully Yoko guys can 
> give some insight on this.
>
> Cheers,
> Jervis
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
> Sent: 2007年7月30日 19:52
> To: cxf-user@incubator.apache.org; Liu, Jervis
> Subject: RE: YOKO & CXF CORBA Web Service using Provider
>
>
> Hi Jervis, it really sounds great, cxf would be more flexible then. Thank you 
> for your replies. So do you plan adding support of that to cxf? And would it 
> be possible to know when? :-)
>
> Cheers,
> Michael
>
>
> -Original Message-
> From: Liu, Jervis [ mailto:[EMAIL PROTECTED]
> Sent: Monday, July 30, 2007 1:12 PM
> To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
> Cc: Michal ?afr; [EMAIL PROTECTED]
> Subject: RE: YOKO & CXF CORBA Web Service using Provider
>
> Coming to think of this again, I found supporting Provider 
> isn't that diff

RE: YOKO & CXF CORBA Web Service using Provider

[Liu, Jervis]

We have no clue how to do this
> > because we cannot simply create Provider,
> > Provider or even Provider. Exception 
> occurs when
> > we try this so it seems nobody ever used it before and the code
> > contains a bug or we are doing something wrong.
> >
> > On the other side we are also trying to call (normal) CORBA service
> > with web service client implemented in CXF/Yoko dynamicaly (DII
> > client). We do not know if is it possible to create SOAPMessage and
> > pass it to Yoko CORBA binding along with WSDL file to make a dynamic
> > call.
> >
> > It seems to me the terms "corba cxf binding" and "dynamic" 
> cannot live
> > together...
> >
> > Best regards, Lukas
> >
> > 2007/8/2, Liu, Jervis <[EMAIL PROTECTED]>:
> > > Hi, have a new question. I suppose the reason why you 
> want to use Provider interface for CORBA binding is that you 
> want to access "raw CORBA message payload" so that you can 
> parse operation info and input parameters by yourself. 
> However the question is what the "raw CORBA message payload" 
> is? In the world of SOAP binding or XML binding, the content 
> sent on the wire normally can be represented as XML, thus we 
> can have typed provider interface like Provider, 
> Provider. However, in the world of CORBA, I 
> don't think we have a well-defined type to represent "raw 
> CORBA message payload", do we? Please note, 
> org.apache.yoko.bindings.corba.CorbaMessage is not the one we 
> are looking for. Same as the 
> org.apache.cxf.binding.soap.SoapMessage and 
> org.apache.cxf.binding.xml.XMLMessage, they are just a 
> content holder, which represent the whole input/output 
> message rather than the message payload. The type class that 
> can be used in Provider is sth that can be produced by 
> Object = DataReader.read(...).  Before we can go ahead to 
> support Provider for CORBA binding, we really need to 
> figure out what the T is.
> > >
> > > BTW, if what you want is CorbaMessage, you can access it 
> from Exchange. See Dan's previous comment in this thread on 
> how to access Exchange.
> > >
> > > I will send this message across to yoko mailing list, 
> hopefully Yoko guys can give some insight on this.
> > >
> > > Cheers,
> > > Jervis
> > >
> > >
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]
> > > Sent: 2007年7月30日 19:52
> > > To: cxf-user@incubator.apache.org; Liu, Jervis
> > > Subject: RE: YOKO & CXF CORBA Web Service using 
> Provider
> > >
> > >
> > > Hi Jervis, it really sounds great, cxf would be more 
> flexible then. Thank you for your replies. So do you plan 
> adding support of that to cxf? And would it be possible to 
> know when? :-)
> > >
> > > Cheers,
> > > Michael
> > >
> > >
> > > -Original Message-
> > > From: Liu, Jervis [ mailto:[EMAIL PROTECTED]
> > > Sent: Monday, July 30, 2007 1:12 PM
> > > To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
> > > Cc: Michal ?afr; [EMAIL PROTECTED]
> > > Subject: RE: YOKO & CXF CORBA Web Service using 
> Provider
> > >
> > > Coming to think of this again, I found supporting 
> Provider isn't that difficult as I originally 
> thought. We have some manual checks of binding type in 
> DispatchInDatabindingInterceptor\DispatchOutDatabindingInterce
> ptor, such as if (binding == soapbinding) then blabla. 
> Actually we were just being lazy, we should really implement 
> DispatchInDatabindingInterceptor as 
> DispatchInSoapBindingDatabindingInterceptor and 
> DispatchInXMLbindingDatabindingInterceptor. This way, 
> different dispatch/provider interceptors for different 
> bindings can be added by corresponding binding providers, 
> which allows the support of new bindings without the need to 
> modify existing code base. E.g., adding  CORBA binding 
> support for dispatch/provider involves in writing a 
> DispatchInCorbaBindingDatabindingInterceptor, doing whatever 
> you want in this interceptor then making sure the 
> CORBABinding provider has this 
> DispatchInCorbaBindingDatabindingInterceptor registered into 
> interceptor chain during provider/dispatch case.
> > >
> > > Cheers,
> > > Jervis
> > >
> > > -Original Message-
> > > From: Daniel Kulp [ mailto:[EMAIL PROTECTED]
> > > Sent: 2007年7月28日 11:23
> > > To: cxf-user@incubator.apache.org
> > > Cc: Michal ?afr; [EMAIL PROTECTED]
>

RE: Restful service parameter

[Liu, Jervis]

Hi, I am afraid there is a bug in the way how CXF HTTP binding handles wrapped 
request, filed a jira for this: https://issues.apache.org/jira/browse/CXF-903

At the mean time, you can try unwrapped style as a work around. Note, you will 
need to create a wrapper class for EchoData in this case, sth like below:

@XmlRootElement
public class EchoData {
private String echoData;

public String getEchoData() {
return echoData;
}

public void setEchoData(String b) {
this.echoData = b;
}
}

public class TestServiceImpl implements TestService {
@Get
@HttpResource(location = "/echo/{echoData}")
String echo(EchoData echoData) {
.
}

Cheers,
Jervis

> -Original Message-
> From: Janos Haber [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?9? 22:14
> To: cxf-user@incubator.apache.org
> Subject: Restful service parameter
> 
> 
> Hi!
> 
> I create a simple echo restful service.
> The java side:
> 
> @WebService(endpointInterface = "hu.javaportal.www.test.TestService")
> public class TestServiceImpl implements TestService {
> 
> @Get
> @Override
> @HttpResource(location="/echo/{echoData}")
> public String echo(String echoData) {
> return "Echo:" + echoData;
> }
> 
> }
> 
> The spring xml:
>  class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
> 
> 
> ...
>  implementor="hu.javaportal.www.test.impl.TestServiceImpl"
> address="/service/xml"
> bindingUri="http://apache.org/cxf/binding/http";>
> 
> 
> 
> 
> 
> 
> I tried to call my service like:
> http://localhost:8080/testproject/service/xml/echo?echoData=test
> http://localhost:8080/testproject/service/xml/echo/echoData=test
> etc...
> but without success
> the method called but the parameter is empty...
> 
> How can I solve this problem?
> 
> Cow
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: JAX-WS MessageContext properties

[Liu, Jervis]

The support for  WSDL_DESCRIPTION etc was added into CXF after 2.0 release. Try 
CXF2.0.1 instead. 

Cheers,
Jervis

> -Original Message-
> From: Bokde, Dhiraj [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月11日 3:07
> To: cxf-user@incubator.apache.org
> Subject: JAX-WS MessageContext properties
> 
> 
> Hi,
> 
> I am building an application using a JAX-WS DOMSource 
> Provider and I was
> hoping I would get values for the following JAX-WS properties from the
> runtime without having to parse the DOMSource:
> 
> WSDL_DESCRIPTION (Type: java.net.URI)
> WSDL_SERVICE (Type: javax.xml.namespace.QName ) WSDL_PORT (Type:
> javax.xml.namespace.QName ) WSDL_INTERFACE (Type:
> javax.xml.namespace.QName ) WSDL_OPERATION (Type:
> javax.xml.namespace.QName )
> 
> But in my testing with the samples/dispatch_provider demo, these
> properties are not set in the MessageContext at all. Any ideas
> whether/how I could get these from the runtime in a JAX-WS DOMSource
> Provider? Or are these only set when using a server with an Impl? 
> 
> Thanks,
> Dhiraj.
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: JRAStrategry work incorrectly?

[Liu, Jervis]

Kevin, internally CXF follows JAX-WS spec to process annotations. JAX-WS 
section 3.3, "if the WebService annotation on the class under consideration has 
a endpointInterface element, then the interface referred by this element is for 
all purposes the SEI associated with the class.". I.e., if you have 
@WebService(endpointInterface = "xyz") specified correctly in your impl class, 
the annotation defined in interface will be used, otherwise it is the impl 
class being used.


Cheers,
Jervis


> -Original Message-
> From: kevin.shen [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?13? 0:49
> To: cxf-user@incubator.apache.org
> Subject: Re: JRAStrategry work incorrectly?
> 
> 
> 
> willem, i can export the web service successful when i wrote 
> the anotations
> in implement class.
> but i am confused that why those factories have different 
> ways to proccess
> the service class.
> i think the factory must get all anntations from the interface class.
> 
> Jiang, Ning (Willem) wrote:
> > 
> > Hi Kevin,
> > 
> > I think you just make sure the service class which you 
> passed to the 
> > JaxWsserviceFactoryBean get the right jra annotation.
> > That can address your concern :)
> > 
> > Willem.
> > kevin.shen wrote:
> >> if i write the jra annotations in interface , and 
> JaxWsserviceFactoryBean
> >> use
> >> implementor to get annotations' meta data, it can not recognize the
> >> method
> >> correctly.
> >> if i write the the jra annotation in implementor, and
> >> JaxWsServerFactorybean
> >> use interface  to get annotations' meta data, it can not 
> recognize the
> >> method correctly too.
> >>
> >>  so i need to write jra annotations in both interface and 
> implementor, 
> >> but
> >> it is so ugly.
> >>  who can tell me the correct way to write the jra 
> annotations? Thanks
> >> very
> >> much.
> >>
> >>   
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/JRAStrategry-work-incorrectly--tf4224578
.html#a12115813
Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: JRAStrategry work incorrectly?

[Liu, Jervis]

BTW, this is similar to a discussion we had before [1]. I.e., which method 
annotation is supposed to take effect, the annotation in impl class or the 
annotation in SEI.

[1]. 
http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/200707.mbox/[EMAIL 
PROTECTED]

Jervis

> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?13? 11:04
> To: cxf-user@incubator.apache.org
> Subject: RE: JRAStrategry work incorrectly?
> 
> 
> Kevin, internally CXF follows JAX-WS spec to process 
> annotations. JAX-WS section 3.3, "if the WebService 
> annotation on the class under consideration has a 
> endpointInterface element, then the interface referred by 
> this element is for all purposes the SEI associated with the 
> class.". I.e., if you have @WebService(endpointInterface = 
> "xyz") specified correctly in your impl class, the annotation 
> defined in interface will be used, otherwise it is the impl 
> class being used.
> 
> 
> Cheers,
> Jervis
> 
> 
> > -Original Message-
> > From: kevin.shen [mailto:[EMAIL PROTECTED]
> > Sent: 2007?8?13? 0:49
> > To: cxf-user@incubator.apache.org
> > Subject: Re: JRAStrategry work incorrectly?
> > 
> > 
> > 
> > willem, i can export the web service successful when i wrote 
> > the anotations
> > in implement class.
> > but i am confused that why those factories have different 
> > ways to proccess
> > the service class.
> > i think the factory must get all anntations from the 
> interface class.
> > 
> > Jiang, Ning (Willem) wrote:
> > > 
> > > Hi Kevin,
> > > 
> > > I think you just make sure the service class which you 
> > passed to the 
> > > JaxWsserviceFactoryBean get the right jra annotation.
> > > That can address your concern :)
> > > 
> > > Willem.
> > > kevin.shen wrote:
> > >> if i write the jra annotations in interface , and 
> > JaxWsserviceFactoryBean
> > >> use
> > >> implementor to get annotations' meta data, it can not 
> recognize the
> > >> method
> > >> correctly.
> > >> if i write the the jra annotation in implementor, and
> > >> JaxWsServerFactorybean
> > >> use interface  to get annotations' meta data, it can not 
> > recognize the
> > >> method correctly too.
> > >>
> > >>  so i need to write jra annotations in both interface and 
> > implementor, 
> > >> but
> > >> it is so ugly.
> > >>  who can tell me the correct way to write the jra 
> > annotations? Thanks
> > >> very
> > >> much.
> > >>
> > >>   
> > > 
> > > 
> > 
> > -- 
> > View this message in context: 
> > http://www.nabble.com/JRAStrategry-work-incorrectly--tf4224578
> .html#a12115813
> Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> 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: returning xml from REST based web service

[Liu, Jervis]

Hi Dave, please note your XML snippet that is defined as XSD:string will always 
be encoded no matter with JAXB binding or Aegis binding. A string within an XML 
document has to be encoded. One workaround is to redesign your schema, give 
your xml snippet a concrete schema type instead of xsd:string, or use xsd:any. 
But to be honest, I havent tried xsd:any by myself, not sure if it works or 
not. If you are 100% sure you do want to use xsd:string to represent your xml 
document, you should do the decoding on the client side, there are many utils 
can do this trivial task for you.

Cheers,
Jervis

> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?14? 3:20
> To: cxf-user@incubator.apache.org
> Subject: Re: returning xml from REST based web service
> 
> 
> However with wrappedmode="false" my incoming parameter is null.
> Back to square one.
> 
> On 8/13/07, Dave Kallstrom <[EMAIL PROTECTED]> wrote:
> >
> > Me and my feeble mind just got it working... Dumped the wrapped
> > mode="false"
> > Now my xml is returns without any markup.
> >  > bindingUri=" http://apache.org/cxf/binding/http"; address="/hello" >
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > On 8/13/07, Dave Kallstrom <[EMAIL PROTECTED]> wrote:
> > >
> > > Okay,
> > > Now I am getting a NPE before my method gets called.
> > > INFO: Interceptor has thrown exception, unwinding now
> > > java.lang.NullPointerException
> > > at 
> org.apache.cxf.binding.http.IriDecoderHelper.buildDocument (
> > > IriDecoderHelper.java:222)
> > > I noticed someone else has had similar problems. Is there 
> a resolution?
> > > 
> http://mail-archives.apache.org/mod_mbox/incubator-cxf-user/20
0707.mbox/[EMAIL PROTECTED]
> > >
> > > Here are the particulars.
> > > @Get
> > > @HttpResource(location="/greetings/{hello}")
> > > @WebMethod(operationName="GetHello")
> > > public abstract 
> org.w3c.dom.DocumentgetHello(@WebParam(name="GetHello")GetHell
> o getHello);
> > > and my cxf.xml file looks like this
> > > http://www.springframework.org/schema/beans "
> > >   xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance";
> > >   xmlns:jaxws="http://cxf.apache.org/jaxws";
> > > xmlns:xsd=" http://www.w3.org/2001/XMLSchema";
> > >   xsi:schemaLocation="
> > > http://www.springframework.org/schema/beans 
> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> > > http://cxf.apache.org/jaxws 
> http://cxf.apache.org/schemas/jaxws.xsd ">
> > >
> > > 
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > > 
> > >
> > >  implementor="com.widen.HelloWorldImpl"
> > > bindingUri=" http://apache.org/cxf/binding/http"; 
> address="/hello" >
> > > 
> > > 
> > >  
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > On 8/10/07, Dan Diephouse <[EMAIL PROTECTED] > wrote:
> > > >
> > > > JAXB will encode any strings that you return. If you 
> want to return an
> > > > xml
> > > > document directly from a RESTful service you'd have to 
> use a different
> > > > databinding. If you use the Aegis databinding you can return
> > > > javax.xml.transform.Source objects or or org.w3c.dom.Documents.
> > > > 
> http://cwiki.apache.org/CXF20DOC/aegis-databinding.html. Strings will
> > > > still
> > > > be encoded.
> > > >
> > > > Hope that helps,
> > > > - Dan
> > > >
> > > > On 8/10/07, Dave Kallstrom < [EMAIL PROTECTED] > wrote:
> > > > >
> > > > > I am tring to return a snippet of xml as a string 
> from a cxf/rest
> > > > based
> > > > > web
> > > > > service method. How do I prevent cxf from marking it up.
> > > > > Here is what is supposed to be returned
> > > > > 
> > > > > 
> > > > > 1
> > > > > filename.psd 
> > > > > 2007-08-10T10:00:20:070Z
> > > > > 2007-08-10T10:00:20:070Z
> > > > > 2007-08-10T10:00:20:070Z
> > > > > 
> > > > > Here is the response from cxf
> > > > >
> > > > >  > > > > xmlns:ns2=" http://myservice.webservices";> version=" 1.0"
> > > > > encoding="UTF-8" ?>
> > > > > 
> > > > > 1
> > > > >  beaver.psd
> > > > >  > > > name="releaseDate">2007-08-10T10:00:20:070Z
> > > > >  name="dateAdded">2007-08-10T10:00:20:070Z
> > > > >
> > > > >  > > > name="dateUpdated">2007-08-10T10:00:20:070Z
> > > > > 
> > > > > 
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Dave Kallstrom
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Dan Diephouse
> > > > Envoi Solutions
> > > > http://envoi

RE: AJAX -> [JSON] -> REST service

[Liu, Jervis]

You have to set your REST service to unwrapped mode if you want URL template 
/employees/{id} maps to a simple type "long id". Otherwise CXF HTTP binding 
will marshal the request (the URL in the case of HTTP GET) into a wrapper class 
GetEmployee.

Cheers,
Jervis

> -Original Message-
> From: Jean-Sebastien Bournival 
> [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?17? 7:04
> To: cxf-user@incubator.apache.org
> Subject: RE: AJAX -> [JSON] -> REST service
> 
> 
> Thanx for your answer Glen.
> 
> I tried to develop, based on one of the samples, a small REST 
> web service.  It works.  But there is a small thing I can't 
> understand: It's the parameter mapping in the REST uri.
> 
> I have a method in my service interface declared in a way 
> that it expects an employee id:
> 
> @Get 
> @HttpResource(location="/employees/{id}") 
> Employee getEmployee(long id);
> 
> BTW, this doesn't work.  I can't understand why.  Maybe I 
> don't get what CXF is doing with the ID in the uri.  It's 
> throwing me this exception when I try to access the URL:
> 
> http://localhost:8080/cfx-web/services/employeeService/employees/33
> 
> Thanx for your time.
> 
> JS.
> 
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract
Invoker.java:92)
>   at 
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvo
> ker.java:82)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract
Invoker.java:62)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(Ser
viceInvokerInterceptor.java:56)
>   at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(Synchrono
usExecutor.java:37)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMes
> sage(ServiceInvokerInterceptor.java:92)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
terceptorChain.java:207)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
inInitiationObserver.java:73)
>   at 
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
ServletDestination.java:78)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:231)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(Serv
letController.java:105)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.
java:271)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.doGet(CXFServlet.java:253)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
cationFilterChain.java:173)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
rapperValve.java:213)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
ontextValve.java:178)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
Valve.java:126)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
Valve.java:105)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
gineValve.java:107)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
ter.java:148)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Process
or.java:869)
>   at 
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHa
ndler.processConnection(Http11BaseProtocol.java:664)
>   at 
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolT
cpEndpoint.java:527)
>   at 
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(Le
aderFollowerWorkerThread.java:80)
>   at 
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:684)
>   at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.IllegalArgumentException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
orImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
odAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.performInvocati
> on(AbstractInvoker.java:99)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract
Invoker.java:73)
>   ... 28 more
> 
>  
> 
> 
> 
> -Message d'origine-
> De : Glen Mazza [mailto:[EMAIL PROTECTED] 
> Envoyé : 15 août 2007 16:54
> À : cxf-user@incubator.apache.org
> Objet : Re: AJAX -> [JSON] -> REST service
> 
> Am Mittwoch, den 15.08.2007, 13:48 -0400 schrieb Jean-Sebastien
> Bournival:
> > Hi guys,
> > 
> > I am in the process 

RE: Unable to create message factory for SOAP

[Liu, Jervis]

Not familiar with JBOSS, look likes JBOSS has its own SAAJ impl, and the 
exception was caused by initializing the MessageFactory. I suggest you try 
following code in your JBOSS env to see what happens:

MessageFactory factory = MessageFactory.newInstance();

Cheers,
Jervis


> -Original Message-
> From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月16日 23:06
> To: cxf-user@incubator.apache.org
> Cc: [EMAIL PROTECTED]
> Subject: Unable to create message factory for SOAP
> 
> 
> Hello people,
> 
> I'm writing an interceptor to do some custom WS-Secutity integration
> to our single sign-on system, and my interceptor is based on the
> WSS4JInInterceptor.
> 
> But alas, I'm having some trouble getting it to work.
> 
> In the constructor for my interceptor, I specify my phase and a
> dependency on the SAAJInInterceptor like this:
> 
> setPhase(Phase.PRE_PROTOCOL);
> getAfter().add(SAAJInInterceptor.class.getName());
> 
> And my jaxws:endpoint in my beans.xml (in an example web service)
> looks like this:
> 
>  id="webStatServiceEndpoint"
> implementor="#webStatService"
> address="/WebStat"
> wsdlLocation="classpath:WebStat1.0.wsdl">
> 
> 
>  class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
> 
> 
> 
> That is all dandy, so I built my project (the demo web service) with
> maven and deploy it on my jboss, but when I try to invoke the web
> service, this happens:
> 
> 16:30:39,692 ERROR [STDERR] Aug 16, 2007 4:30:39 PM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: 
> SOAPHANDLERINTERCEPTOR_EXCEPTION
>   at 
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessa
> ge(SAAJInInterceptor.java:114)
>   at 
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessa
> ge(SAAJInInterceptor.java:63)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
> terceptorChain.java:207)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
> inInitiationObserver.java:73)
>   at 
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
> ServletDestination.java:78)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:231)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invoke(Serv
> letController.java:139)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.
> java:271)
>   at 
> org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.
> java:249)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:290)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilterChain.java:206)
>   at 
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyH
> eaderFilter.java:96)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:235)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilterChain.java:206)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.java:230)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.java:175)
>   at 
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
> SecurityAssociationValve.java:179)
>   at 
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccCont
> extValve.java:84)
>   at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:128)
>   at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:104)
>   at 
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(
> CachedConnectionValve.java:156)
>   at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java:109)
>   at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
> ter.java:241)
>   at 
> org.apache.coyote.http11.Http11Processor.process(Http11Process
> or.java:844)
>   at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle
> r.process(Http11Protocol.java:580)
>   at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.
> java:447)
>   at java.lang.Thread.run(Thread.java:613)
> Caused by: javax.xml.soap.SOAPException: Unable to create message
> factory for SOAP: org.jboss.ws.core.soap.MessageFactoryImpl
>   at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
>   at 
> org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessa
> ge(SAAJInInterceptor.java:77)
>   ... 28 more
> 
> 
> 
> So, an

RE: Unable to create message factory for SOAP

[Liu, Jervis]

Sun's SAAJ impl should be ok. CXF has been using Sun's SAAJ as default since 
CXF's inception.

> -Original Message-
> From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月17日 17:12
> To: cxf-user@incubator.apache.org
> Subject: Re: Unable to create message factory for SOAP
> 
> 
> I stuck that in a JSP file and added an import.
> 
> When I run that it gives a root complaint much like the one 
> in my previous mail:
> 
> javax.xml.soap.SOAPException: Unable to create message factory for
> SOAP: org.jboss.ws.core.soap.MessageFactoryImpl
>   javax.xml.soap.MessageFactory.newInstance(Unknown Source)
>   org.apache.jsp.index_jsp._jspService(index_jsp.java:59)
>   
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   
> org.apache.jasper.servlet.JspServletWrapper.service(JspServlet
> Wrapper.java:387)
>   
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet
> .java:320)
>   
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>   
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyH
> eaderFilter.java:96)
> 
> 
> 
> Another thing worth noting is that I've come upon the ability to
> change which implementation class should be used by
> MessageFactory.getInstance() using a systems property, for instance:
> 
> System.setProperty("javax.xml.soap.MessageFactory",
> "com.sun.xml.messaging.saaj.soap.MessageFactoryImpl");
> 
> Since I write the interceptor myself, I could do some hacky magic to
> make sure that the SAAJ interceptor got initialized with the correct
> MessageFactory, but in that case, which MessageFactory should I use?
> The SUN one above dosn't seem to quite cut it either.
> 
> 
> 2007/8/17, Liu, Jervis <[EMAIL PROTECTED]>:
> > Not familiar with JBOSS, look likes JBOSS has its own SAAJ 
> impl, and the exception was caused by initializing the 
> MessageFactory. I suggest you try following code in your 
> JBOSS env to see what happens:
> >
> > MessageFactory factory = MessageFactory.newInstance();
> >
> > Cheers,
> > Jervis
> >
> >
> > > -Original Message-
> > > From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> > > Sent: 2007年8月16日 23:06
> > > To: cxf-user@incubator.apache.org
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Unable to create message factory for SOAP
> > >
> > >
> > > Hello people,
> > >
> > > I'm writing an interceptor to do some custom WS-Secutity 
> integration
> > > to our single sign-on system, and my interceptor is based on the
> > > WSS4JInInterceptor.
> > >
> > > But alas, I'm having some trouble getting it to work.
> > >
> > > In the constructor for my interceptor, I specify my phase and a
> > > dependency on the SAAJInInterceptor like this:
> > >
> > > setPhase(Phase.PRE_PROTOCOL);
> > > getAfter().add(SAAJInInterceptor.class.getName());
> > >
> > > And my jaxws:endpoint in my beans.xml (in an example web service)
> > > looks like this:
> > >
> > >  > > id="webStatServiceEndpoint"
> > > implementor="#webStatService"
> > > address="/WebStat"
> > > wsdlLocation="classpath:WebStat1.0.wsdl">
> > > 
> > > 
> > >  > > class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
> > > 
> > > 
> > >
> > > That is all dandy, so I built my project (the demo web 
> service) with
> > > maven and deploy it on my jboss, but when I try to invoke the web
> > > service, this happens:
> > >
> > > 16:30:39,692 ERROR [STDERR] Aug 16, 2007 4:30:39 PM
> > > org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> > > INFO: Interceptor has thrown exception, unwinding now
> > > org.apache.cxf.binding.soap.SoapFault:
> > > SOAPHANDLERINTERCEPTOR_EXCEPTION
> > >   at
> > > org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessa
> > > ge(SAAJInInterceptor.java:114)
> > >   at
> > > org.apache.cxf.binding.soap.saaj.SAAJInInterceptor.handleMessa
> > > ge(SAAJInInterceptor.java:63)
> > >   at
> > > org.apache.cxf.phase.Ph

RE: DataBinding problems (Timestamp and HashMap) using JAXB

[Liu, Jervis]

Neither java.sql.Timestamp nor HashMap are supported by JAXB. A common practice 
is abstracting data from unsupported types to a supported JAVA types or to user 
defined POJOs. For example, Timestamp can be represented as a String, and if 
you know HashMap is used as HashMap, you can write a class 
like below:

 public class MyHashMapType {
 List entry;
 }

 public class MyHashMapEntryType {
 @XmlAttribute
 public Integer key; 

 @XmlValue
 public String value;
 }

> -Original Message-
> From: suiaing [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?17? 12:31
> To: cxf-user@incubator.apache.org
> Subject: DataBinding problems (Timestamp and HashMap) using JAXB
> 
> 
> 
> Does the JAXB using in the CXF 2.0.1 support the 
> java.sql.Timestamp and
> java.util.HashMap?:-(
> 
> i have a web method like this:
> public void echo(java.util.Date date, java.sql.Timestamp timestamp);
> Howerver, i find this message defination in the wsdl which is 
> generated by
> cxf
>  
> 
> 
> 
> 
>   
> 
> I also have a web method like this
> public void echo2(HashMap map);
> Howerver, i find these in the wsdl which is generated by cxf:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   
> 
> how can i use java.util.Map datatype with JAXB in CXF ?
> -- 
> View this message in context: 
> http://www.nabble.com/DataBinding-problems-%28Timestamp-and-Ha
shMap%29-using-JAXB-tf4283645.html#a12193877
Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: AJAX -> [JSON] -> REST service

[Liu, Jervis]

Sorry, it is my bad. What I really meant to say is: You have to set your REST 
service to WRAPPED mode if you want URL template /employees/{id} maps to a 
simple type "long id". In the UNWRAPPED mode CXF HTTP binding marshals the 
request (the URL in the case of HTTP GET) into a wrapper class, i.e., 
GetEmployee. If you have access to svn, a system test located under 
\trunk\systests\src\test\java\org\apache\cxf\systest\rest\BookServer.java tells 
everything. 

BTW, in the wrapped mode, argument type long instead of Long (Employee 
getEmployee(@WebParam(name="id") long id) should also work. What happens is in 
the interceptor chain, wrapper element is getting striped off, i.e., 
somevalue turns into somevalue, 
then somevalue is being feed into JAXB, both long or Long are valid 
output from JAXB.

Cheers,
Jervis

> -Original Message-
> From: Jean-Sebastien Bournival 
> [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?17? 21:07
> To: cxf-user@incubator.apache.org; [EMAIL PROTECTED]
> Subject: RE: AJAX -> [JSON] -> REST service
> 
> 
> Ok now it works, but here's the thing:
> 
> I switched to unwrapped mode.  This time it's throwing me this:
> 
> INFO: URIParameterInterceptor handle message on path 
> [/employees/33] with content-type [null]
> 2007-08-17 08:46:25 
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: You can not map a URI 
> parameter to a simple type when in unwrapped mode!
>   at 
> org.apache.cxf.binding.http.IriDecoderHelper.buildDocument(Iri
DecoderHelper.java:216)
>   at 
> org.apache.cxf.binding.http.interceptor.URIParameterInIntercep
> tor.mergeParams(URIParameterInInterceptor.java:129)
>   at 
> org.apache.cxf.binding.http.interceptor.URIParameterInIntercep
> tor.handleMessage(URIParameterInInterceptor.java:105)
>   ... (more)
> 
> 
> I changed back my service to wrapped mode (just doing what 
> the stack trace told me!).  And then I had the idea to change 
> my method argument to Long (the wrapper type).  It works ...
> 
> What is it with primitive types?  Is there a problem using 
> them against a REST service?
> 
> Thanx a lot guys!
> 
> JS.
> 
> 
> 
> 
> 
> 
> 
> De : Dale Peakall [mailto:[EMAIL PROTECTED] 
> Envoyé : 17 août 2007 02:44
> À : cxf-user@incubator.apache.org
> Objet : Re: AJAX -> [JSON] -> REST service
> 
> 
> I think you also need to associate some meta-data with the id 
> parameter in your method signature since Java doesn't 
> maintain any information about parameter names.  You can do 
> this with the @WebParam annotation, e.g.
> 
> @Get
> @HttpResource(location="/employees/{id}")
> Employee getEmployee(@WebParam(name="id") long id);
> 
> I think you also need to annotate your implementation class, 
> not just the interface.
> 
> Jean-Sebastien Bournival wrote: 
> 
>   Thanx for your answer Glen.
>   
>   I tried to develop, based on one of the samples, a 
> small REST web service.  It works.  But there is a small 
> thing I can't understand: It's the parameter mapping in the REST uri.
>   
>   I have a method in my service interface declared in a 
> way that it expects an employee id:
>   
>   @Get 
>   @HttpResource(location="/employees/{id}") 
>   Employee getEmployee(long id);
>   
>   BTW, this doesn't work.  I can't understand why.  Maybe 
> I don't get what CXF is doing with the ID in the uri.  It's 
> throwing me this exception when I try to access the URL:
>   
>   
> http://localhost:8080/cfx-web/services/employeeService/employees/33
>   
>   Thanx for your time.
>   
>   JS.
>   
>   INFO: Interceptor has thrown exception, unwinding now
>   org.apache.cxf.interceptor.Fault
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract
Invoker.java:92)
>   at 
> org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvo
> ker.java:82)
>   at 
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(Abstract
Invoker.java:62)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(Ser
viceInvokerInterceptor.java:56)
>   at 
> org.apache.cxf.workqueue.SynchronousExecutor.execute(Synchrono
usExecutor.java:37)
>   at 
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMes
> sage(ServiceInvokerInterceptor.java:92)
>   at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
terceptorChain.java:207)
>   at 
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
inInitiationObserver.java:73)
>   at 
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
ServletDestination.java:78)
>   at 
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:231)
>   at 
> org.apache.cxf.transport.servlet.ServletContro

RE: Generic Provider server and WSDL metadata

[Liu, Jervis]

Hi Dhiraj, it looks like sth wrong in your WSDL, most likely the service name 
defined in your WSDL does not match with the service name specificed in your 
spring cfg file. 

BTW, I don't really get the reason why you want to access to the WSDL metadata 
like wsdlLocation, serviceName, portName, operation name etc. JAX-WS SEI is 
WSDL-centric, there is always a direct mapping between SEI's java types/method 
and WSDL's types/operations, i.e., you look at the WSDL, then you know what 
kind of request is a valid request that can be sent to server. JAX-WS 
Provider/Dispatch interface however, is not WSDL-centric, you do not need a 
wsdl at all to work with a Provider server. The only thing a client who wants 
to invoke a Provider service need to know is the service publishing address. Of 
course, you can still specify a WSDL through @WebServiceProvider() or spring 
configuration, but your Provider service is not bound by this WSDL. In another 
word, WSDL metadata info like wsdlLocation, serviceName, portName, operation 
name for Provider are no use and should not be used.

Cheers,
Jervis

> -Original Message-
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?19? 12:31
> To: cxf-user@incubator.apache.org
> Subject: Re: Generic Provider server and WSDL metadata
> 
> 
> Hmmm I have no idea how that's occurring... Any chance your 
> wsdl has zero
> operations in it?
> 
> - Dan
> 
> On 8/17/07, Bokde, Dhiraj <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I am trying to build a generic server using 
> Provider. But I
> > want to make the WSDL metadata, wsdlLocation, serviceName, portName,
> > etc. to be user configurable, without having to re-compile 
> the Provider
> > with new WebServiceProvider annotations for every new WSDL.
> >
> > I thought I'd be able to do this with an empty WebServiceProvider
> > annotation for my Provider like below:
> >
> > 
> > @WebServiceProvider()
> > @ServiceMode(value = Service.Mode.MESSAGE)
> > public final class GenericMessageProvider implements 
> Provider
> > {
> > 
> >
> > And the jaxws:endpoint element in a spring container 
> cxf-beans.xml, like
> > below:
> >
> > 
> >  implementor="#genericProvider"
> > address="/myLocation/" serviceName="msp:MyService"
> > wsdlLocation="classpath:wsdl/MyWSDL.wsdl"
> > xmlns:msp="http://my.service";>
> > 
> > 
> >
> > But this throws an NPE when I load the cxf-beans.xml using 
> Tomcat. The
> > relevant log4j logs are attached.
> >
> > Any ideas what's causing this?
> >
> > Thanks,
> > Dhiraj.
> >
> >
> 
> 
> -- 
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Generic Provider server and WSDL metadata

[Liu, Jervis]

Comment in-line.

> -Original Message-
> From: Bokde, Dhiraj [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?22? 10:17
> To: cxf-user@incubator.apache.org
> Subject: RE: Generic Provider server and WSDL metadata
> 
> 
> Hi Liu,
> 
> Find my response inline:
> 
> > -----Original Message-
> > From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> > Sent: Sunday, August 19, 2007 8:35 PM
> > To: cxf-user@incubator.apache.org
> > Subject: RE: Generic Provider server and WSDL metadata
> > 
> > Hi Dhiraj, it looks like sth wrong in your WSDL, most likely the
> service
> > name defined in your WSDL does not match with the service name
> specificed
> > in your spring cfg file.
> > 
> 
> [Bokde, Dhiraj] I added the metadata parameters to the
> @WebServiceProvider annotation and the application worked as 
> I expected.
> In other words, when the WSDL information is compiled in the 
> annotation,
> the published WSDL is the original WSDL being referenced and 
> the JAX-WS
> properties WSDL_SERVICE, etc. point to the application's WSDL. 
> When the annotation does not have the WSDL information, I see the
> exception I had attached before. If the JAX-WS 'endpoint' element does
> not have the service name and port name and the annotation is empty
> (@WebServiceProvider()), CXF looks for a Service named
> 'GenericMessageProviderService' with a WSDL operation 'invoke' in the
> WSDL provided in wsdlLocation in the 'endpoint' element. 
> 
> In other words, if the annotation does not have any WSDL 
> meta-data, CXF
> assumes that the application is SEI and not Provider based 
> (despite the
> fact that 'GenericMessageProvider' implements Provider).
> 

Internally in CXF, the service model is populated from WSDL file if 
wsdlLocation is specified in annotation or in spring config file otherwise the 
service model is populated from Java class (code-first approache). The service  
model does not distingush SEI or Provider. In your case, if you use an empty 
@WebServiceProvider() annotation, the corresponding service model is created 
from GenericMessageProvider, thus the service name is 
'GenericMessageProviderService' (mapped from java class name by default) and 
only operation available in this model is invoke, as invoke is the only public 
java method in GenericMessageProvider class. The WSDL metadata stuff 
wsdlLocation, serviceName, portName etc is retrieved from the service model.


> > BTW, I don't really get the reason why you want to access 
> to the WSDL
> > metadata like wsdlLocation, serviceName, portName, 
> operation name etc.
> > JAX-WS SEI is WSDL-centric, there is always a direct mapping between
> SEI's
> > java types/method and WSDL's types/operations, i.e., you look at the
> WSDL,
> > then you know what kind of request is a valid request that 
> can be sent
> to
> > server. JAX-WS Provider/Dispatch interface however, is not
> WSDL-centric,
> > you do not need a wsdl at all to work with a Provider 
> server. The only
> > thing a client who wants to invoke a Provider service need 
> to know is
> the
> > service publishing address. Of course, you can still specify a WSDL
> > through @WebServiceProvider() or spring configuration, but your
> Provider
> > service is not bound by this WSDL. In another word, WSDL 
> metadata info
> > like wsdlLocation, serviceName, portName, operation name 
> for Provider
> are
> > no use and should not be used.
> > 
> 
> [Bokde, Dhiraj] This is needed in generic XML oriented 
> frameworks where
> the user needs the ability to use the Provider interface to 
> avoid having
> to generate Java code from WSDL, but still needs the ability to work
> with a WSDL. For example, it may need to verify compliance of messages
> with the underlying WSDL, basically use Service meta-data 
> that can only
> come from a WSDL. 
> 
> I don't believe the use case is the real issue here. My questions are:
> 
> Is the annotation supposed to be the only source of WSDL 
> metadata for a
> JAX-WS Provider based server? Or, is the JAX-WS endpoint element in
> Spring XML configuration supposed to substitute/override the 
> metadata in
> the annotation? If so, why isn't it working? 
> 
> If the JAX-WS 'endpoint' element in Spring XML configuration cannot
> provide/override the info in the annotation, 
> @WebServiceProvider must be
> one of those poor 'compile time only' configuration mechanisms of the
> JAX-WS framework. 
> 
the JAX-WS 'endpoint' element in Spring XML configuration does indeed 
provide/override the info in the annotati

RE: Generic Provider server and WSDL metadata

[Liu, Jervis]

Hi Dhiraj, I just filed CXF-935 for this. So the problem is that when 
Provider's WSDL is supplied from spring configuration (so it is still 
WSDL-first, build service model from WSDL), the endpoint point should be from 
WSDL instead of from Provider class name.

Cheers,
Jervis

> -Original Message-
> From: Bokde, Dhiraj [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?23? 2:55
> To: cxf-user@incubator.apache.org
> Subject: RE: Generic Provider server and WSDL metadata
> 
> 
> > >
> > the JAX-WS 'endpoint' element in Spring XML configuration 
> does indeed
> > provide/override the info in the annotation. The reason why it does
> not
> > work? It might be a bug. If you have access to CXF source code, in
> > ReflectionServiceFactoryBean.java line 956, method 
> getEndpointInfo():
> > 
> > public EndpointInfo getEndpointInfo() {
> > return getService().getEndpointInfo(getEndpointName());
> > }
> > 
> > the getService() returns the service model built from WSDL file, but
> > somehow it does not contain an endpoint whose name is
> getEndpointName()
> > which might come from java class. Could you please report a Jira for
> this.
> > 
> > BTW, you may want to try to add an endpointname attribute into your
> spring
> > config, just a wild guess, not sure if it works. ;-)
> > 
> > 
> >  > endpointName="endpointName is the port qname in wsdl"
> > address="/myLocation/" serviceName="msp:MyService"
> > wsdlLocation="classpath:wsdl/MyWSDL.wsdl"
> > xmlns:msp="http://my.service";>
> > 
> > 
> > 
> [Bokde, Dhiraj] I debugged it a little, and the 
> getEndpointName() method
> returns GenericProviderService instead of the serviceName in the
> endpoint. 
> I have tried adding the endpointName attribute as well and it didn't
> make any difference. 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: JSON output

[Liu, Jervis]

Hi Kaleb, I am really not sure if it makes sense to convert SOAP message to 
JSON. But if the payload is Plain-old--XML(POX), it should be doable in CXF. At 
the moment, CXF HTTP binding can serve RESTful service in both POX and JSON 
payload. Details can be found from 
http://cwiki.apache.org/CXF20DOC/http-binding.html and 
samples\restful_http_binding. If this is what you are looking for, we can spend 
more time to figure what the spring configuration would look like for JSON.

Cheers,
Jervis


> -Original Message-
> From: Kaleb Walton [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?22? 22:42
> To: cxf-user@incubator.apache.org
> Subject: JSON output
> 
> 
> 
> 
> Is there an easy way to use JSON as the transport protocol 
> when configuring
> a Service in Spring? I have a SOAP service working quite 
> nicely but would
> like to expose the same service using JSON with minimal additional
> configuration. I looked at the instructions on the wiki but 
> they only show
> the programmatic way and I'd prefer to use Spring.
> 
> The pertinent parts of my current configuration are as follows:
> 
>  script-source="classpath:a/b/c/webservices/GroovyServiceImpl.groovy"/>
>  serviceClass="a.b.c.webservices.GroovyService"
> serviceBean="#groovyService" address="/Groovy"/>
> 
> It'd be great to be able to create another service that 
> outputs JSON with
> only a few extra lines of configuration. Please excuse me if 
> this seems a
> simple problem,  I admit I'm having trouble figuring out the 
> correlation
> between the Spring server config and the programmatic 
> ServerFactoryBean.
> 
> Regards,
> Kaleb
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Restful Service client exception

[Liu, Jervis]

Could you please paste out your com.fm.services.ServiceImpl and 
com.fm.services.IService code? I noticed that client.doService("foo") returns a 
List. Not sure what your code looks like, but this might be the place 
where the problem comes from.

Cheers,
Jervis

> -Original Message-
> From: Sric [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月23日 7:43
> To: cxf-user@incubator.apache.org
> Subject: Restful Service client exception
> 
> 
> 
> I have successfully deployed a Restful service using CXF. 
> I couldn’t use the jaxws Spring schema extension tags to 
> define my services
> owing to the http://cxf.apache.org/schemas/jaxws.xsd schema 
> not found error.
> I declared the service with standard Spring bean tags using 
> the following
> snippet:
> 
>
> class="org.apache.cxf.jaxws.JaxWsServerFactoryBean"
>   init-method="create">
>value="http://apache.org/cxf/binding/http"; />
>   
>value="com.fm.services.IService" />
>   
>   
>   
>   
> 
> The service deploys fine and I can verify that it works from 
> a browser.
> 
> I am attempting to develop a client for this service along 
> the lines of the
> MainClient in the restful_http_binding example with the 2.0.1 
> distribution.
> My client looks like the following:
> 
>JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean(); 
> factory.setServiceClass(IService.class); 
>
> factory.getClientFactoryBean().setBindingId(HttpBindingFactory
> .HTTP_BINDING_ID);
>
> factory.setAddress("http://server:8080/myapp/services/xml/myse
> rvice/");
> IServiceclient = (IService)factory.create();
> List retVals = client.doService("foo");
> 
> The client proxy is getting created fine, however at the 
> invocation of the
> service I see the following exception. The problem seems to 
> arise from the
> fact that the verb returned from the 
> URIMapper/BindingOperationInfo is null.
> Ulimately, I wish to be able to inject this client via Spring. I’d
> appreciate your ideas/information on overcoming this issue.
> 
> Thanks
> Sriram
> 
> 
> Aug 22, 2007 3:48:47 PM
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://search.services.fm.com/} 
> IServicefrom class
> com.fm.services.IService
> Aug 22, 2007 3:48:47 PM 
> org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method doService to resource 
> /images/{searchString} and verb
> GET
> Aug 22, 2007 3:48:49 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> java.lang.NullPointerException
>   at
> org.apache.cxf.binding.http.interceptor.DatabindingOutSetupInt
> erceptor.handleMessage(DatabindingOutSetupInterceptor.java:77)
>   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
> terceptorChain.java:207)
>   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:254)
>   at 
> org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:205)
>   at 
> org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
>   at 
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.
> java:135)
>   at $Proxy22.doService(Unknown Source)
>   at 
> com.fm.search.service.ClientTest.plainTest(ClientTest.java:49)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
> orImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
> odAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(
> TestMethodRunner.java:99)
>   at
> org.junit.internal.runners.TestMethodRunner.runUnprotected(Tes
> tMethodRunner.java:81)
>   at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(B
> eforeAndAfterRunner.java:34)
>   at
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMeth
> odRunner.java:75)
>   at
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunn
> er.java:45)
>   at
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMe
> thod(TestClassMethodsRunner.java:66)
>   at
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClas
> sMethodsRunner.java:35)
>   at
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(Te
> stClassRunner.java:42)
>   at
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(B
> eforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner
> .java:52)
>   at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
> (JUnit4TestReference.java:38)
>   at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestEx
> ecution.java:38)
>   

RE: Restful Service client exception

[Liu, Jervis]

Ok, I see the problem. Your service is using wrapped mode, unfortunately 
URIMapper did not handle Wrapped/Unwrapped operation correctly. I have filed 
JIRA cxf-938 for this.

Thanks,
Jervis

> -Original Message-
> From: Sric [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月23日 23:22
> To: cxf-user@incubator.apache.org
> Subject: RE: Restful Service client exception
> 
> 
> 
> Jervis,
> Thanks for your reply.
> 
> The interface code is as follows:
> 
> package com.fm.services;
>   
>   import javax.jws.WebParam;
>   import javax.jws.WebService;
>   import javax.jws.WebResult;
>   
>   import org.codehaus.jra.Get;
>   import org.codehaus.jra.HttpResource;
>   
>   import java.util.List;
>   
>   @WebService
>   public interface IService  
>   { 
>   @Get
>   @HttpResource(location="/images/{searchString}")
>   @WebResult(name = "result")
>   public List 
> doService(@WebParam(name="searchString") String
> searchString);
> }
> 
> The implementation class is as follows:
> 
> package com.fm.services;  
>   
>   public class ServiceImpl  implements IService
>   {   
>   public List doSearch(String searchString)
>   {
>   List results = new ArrayList();
>   // Populate the results
>   return results;
>   }
>   }
> 
> If I change the List to a List, I see the same 
> exception from
> my client. The rest invocation from a browser returns the 
> correct values
> though.  
> 
> Thanks
> Sriram
> 
> 
> Liu, Jervis wrote:
> > 
> > Could you please paste out your com.fm.services.ServiceImpl and
> > com.fm.services.IService code? I noticed that 
> client.doService("foo")
> > returns a List. Not sure what your code looks like, 
> but this might
> > be the place where the problem comes from.
> > 
> > Cheers,
> > Jervis
> > 
> >> -Original Message-
> >> From: Sric [mailto:[EMAIL PROTECTED]
> >> Sent: 2007年8月23日 7:43
> >> To: cxf-user@incubator.apache.org
> >> Subject: Restful Service client exception
> >> 
> >> 
> >> 
> >> I have successfully deployed a Restful service using CXF. 
> >> I couldn’t use the jaxws Spring schema extension tags to 
> >> define my services
> >> owing to the http://cxf.apache.org/schemas/jaxws.xsd schema 
> >> not found error.
> >> I declared the service with standard Spring bean tags using 
> >> the following
> >> snippet:
> >> 
> >>  >>
> >> class="org.apache.cxf.jaxws.JaxWsServerFactoryBean"
> >>init-method="create">
> >> >> value="http://apache.org/cxf/binding/http"; />
> >>
> >> >> value="com.fm.services.IService" />
> >>
> >>
> >>
> >>
> >> 
> >> The service deploys fine and I can verify that it works from 
> >> a browser.
> >> 
> >> I am attempting to develop a client for this service along 
> >> the lines of the
> >> MainClient in the restful_http_binding example with the 2.0.1 
> >> distribution.
> >> My client looks like the following:
> >> 
> >>JaxWsProxyFactoryBean factory = new 
> JaxWsProxyFactoryBean(); 
> >> factory.setServiceClass(IService.class); 
> >>
> >> factory.getClientFactoryBean().setBindingId(HttpBindingFactory
> >> .HTTP_BINDING_ID);
> >>
> >> factory.setAddress("http://server:8080/myapp/services/xml/myse
> >> rvice/");
> >> IServiceclient = (IService)factory.create();
> >> List retVals = client.doService("foo");
> >> 
> >> The client proxy is getting created fine, however at the 
> >> invocation of the
> >> service I see the following exception. The problem seems to 
> >> arise from the
> >> fact that the verb returned from the 
> >> URIMapper/BindingOperationInfo is null.
> >> Ulimately, I wish to be able to inject this client via Spring. I’d
> >> appreciate your ideas/information on overcoming this issue.
> >> 
> >> Thanks
> >> Sriram
> >> 
> >> 
> >> Aug 22, 2007 3:48

RE: Restful Service client exception

[Liu, Jervis]

Sriram, the fix for this problem has been committed into the latest trunk, you 
shall see the fix either by building a snapshot from the latest trunk by 
yourself or waiting for 2.0.2 release. The fix only impacts the client side.

Cheers,
Jervis


> -Original Message-
> From: Sric [mailto:[EMAIL PROTECTED]
> Sent: 2007年8月29日 2:35
> To: cxf-user@incubator.apache.org
> Subject: RE: Restful Service client exception
> 
> 
> 
> Jervis,
> I see that you have closed this JIRA issue. How can I obtain 
> the fix? Does
> it impact the client or the server or both? Can you please update?
> 
> Thanks
> Sriram
> 
> Liu, Jervis wrote:
> > 
> > Ok, I see the problem. Your service is using wrapped mode, 
> unfortunately
> > URIMapper did not handle Wrapped/Unwrapped operation 
> correctly. I have
> > filed JIRA cxf-938 for this.
> > 
> > Thanks,
> > Jervis
> > 
> >> -Original Message-
> >> From: Sric [mailto:[EMAIL PROTECTED]
> >> Sent: 2007年8月23日 23:22
> >> To: cxf-user@incubator.apache.org
> >> Subject: RE: Restful Service client exception
> >> 
> >> 
> >> 
> >> Jervis,
> >> Thanks for your reply.
> >> 
> >> The interface code is as follows:
> >> 
> >> package com.fm.services;
> >>
> >>import javax.jws.WebParam;
> >>import javax.jws.WebService;
> >>import javax.jws.WebResult;
> >>
> >>import org.codehaus.jra.Get;
> >>import org.codehaus.jra.HttpResource;
> >>
> >>import java.util.List;
> >>
> >>@WebService
> >>public interface IService  
> >>{ 
> >>@Get
> >>@HttpResource(location="/images/{searchString}")
> >>@WebResult(name = "result")
> >>public List 
> >> doService(@WebParam(name="searchString") String
> >> searchString);
> >> }
> >> 
> >> The implementation class is as follows:
> >> 
> >> package com.fm.services;   
> >>
> >>    public class ServiceImpl  implements IService
> >>   {
> >>   public List doSearch(String searchString)
> >>{
> >>List results = new ArrayList();
> >>// Populate the results
> >>return results;
> >>}
> >>   }
> >> 
> >> If I change the List to a List, I see the same 
> >> exception from
> >> my client. The rest invocation from a browser returns the 
> >> correct values
> >> though.  
> >> 
> >> Thanks
> >> Sriram
> >> 
> >> 
> >> Liu, Jervis wrote:
> >> > 
> >> > Could you please paste out your com.fm.services.ServiceImpl and
> >> > com.fm.services.IService code? I noticed that 
> >> client.doService("foo")
> >> > returns a List. Not sure what your code looks like, 
> >> but this might
> >> > be the place where the problem comes from.
> >> > 
> >> > Cheers,
> >> > Jervis
> >> > 
> >> >> -Original Message-
> >> >> From: Sric [mailto:[EMAIL PROTECTED]
> >> >> Sent: 2007年8月23日 7:43
> >> >> To: cxf-user@incubator.apache.org
> >> >> Subject: Restful Service client exception
> >> >> 
> >> >> 
> >> >> 
> >> >> I have successfully deployed a Restful service using CXF. 
> >> >> I couldn’t use the jaxws Spring schema extension tags to 
> >> >> define my services
> >> >> owing to the http://cxf.apache.org/schemas/jaxws.xsd schema 
> >> >> not found error.
> >> >> I declared the service with standard Spring bean tags using 
> >> >> the following
> >> >> snippet:
> >> >> 
> >> >>  >> >> 
> >> >> class="org.apache.cxf.jaxws.JaxWsServerFactoryBean"
> >> >> init-method="create">
> >> >>  >> >> value="http://apache.org/cxf/binding/http"; />
> >> >>  value="/xml/myservice/" />
> >> >>  >> >> value="com.fm.services.IService" />
> >> >> 
> >> >>   

RE: Bus Features [was: Logging ...]

[Liu, Jervis]

Hi Fred, I recalled we had a similar discussion before. In your code snippet 
below, the logging interceptors will be installed twice. I wont say  
is a root scope configuration as there is no hierarchy relationships among bus, 
endpoints and bindings. Bus, endpoints and bindings are just individual 
components that can contribute interceptors, some times a same bus instance can 
be shared by multiple services but this wont necessarily make it a root 
configuration. Bindings can be shared by multiple services as well. What you 
required, "if a  feature is defined at endpoint granularity, that feature is 
the  effective feature in config, whereas if there is no such config at  
endpoint granularity, the runtime would fall back to the Bus config", is really 
a scope-based configuration. This is no such thing existing yet in CXF. I 
wonder can this be done through WS-Policy? I.e., I can make some assertions 
like this: " I want to apply this feature to endpoint A and B" or "I want this 
feature applied to all my endpoints by default if there is no overridden 
feature defined for the individual endpoint". Thoughts?

Jervis

> -Original Message-
> From: Fred Dushin [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?29? 2:52
> To: cxf-user@incubator.apache.org
> Subject: Bus Features [was: Logging ...]
> 
> 
> 
> On Aug 24, 2007, at 11:36 AM, Daniel Kulp wrote:
> 
> > 
> > 
> > 
> > 
> > 
> 
> How do Bus-level features interact with endpoint- or client-level  
> features?  For example, if I have
> 
> {{{
> 
>  
>  
>  
> 
> 
> http://foo.bar.com}FUBAR";>
>  
>  
>  
> 
> }}}
> 
> and a servant is instantiated under the WSDL Port 
> {http://foo.bar.com} 
> FUBAR, is a feature instantiated twice, once for the Bus, qua  
> InterceptorProvider, and once for the Endpoint, qua 
> InterceptorProvider?
> 
> If it's instantiated twice, is there any way a feature 
> implementor to  
> traverse the interceptors on each InterceptorProvider, to see if a  
> feature has been installed, or are these interceptor lists  
> independent of one another?
> 
> (The reason I ask is, there might be a tendency to think of the  
> feature config on the Bus as a kind of default, such that if a  
> feature is defined at endpoint granularity, that feature is the  
> effective feature in config, whereas if there is no such config at  
> endpoint granularity, the runtime would fall back to the Bus 
> config.   
> But I'm guessing that's really not the behavior here, is it?)
> 
> Thanks!
> -Fred
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Obtaining source address and operation name

[Liu, Jervis]

Hi What code did you use to retrieve WSDL_OPERATION, WSDL_PORT etc?

Thanks,
Jervis

> -Original Message-
> From: James Royalty [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?31? 8:28
> To: cxf-user@incubator.apache.org
> Subject: Obtaining source address and operation name
> 
> 
> Hi,
> 
> I'm trying to write an "in" interceptor, using 
> org.apache.cxf.interceptor.LoggingInInterceptor as a starting point.  
> I'm trying to log
> 
> - the source (IP) address that originate the (SOAP) Message;
> - the SOAP operation that was invoked.
> 
> Any hints on how I can obtain either of these? 
> 
> I've tried adding the interceptor at various phases (RECEIVE, 
> PRE_INVOKE, INVOKE) and getting several values from the Messsage:  
> WSDL_OPERATION, WSDL_PORT, WSDL_SERVICE, INVOCATION_CONTEXT, 
> ENDPOINT_ADDRESS.  All these end up being null.
> 
> Thanks!
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Obtaining source address and operation name

[Liu, Jervis]

these properties are stored in Exchange, not in Message. following should work 
for you:

Object operation = message.getExchange().get( Message.WSDL_OPERATION );
Object port = message.getExchange().get( Message.WSDL_PORT );
Object service = message.getExchange().get( Message.WSDL_SERVICE );
Object context = message.getExchange().get( Message.INVOCATION_CONTEXT );
Object endpointAddress = message.getExchange().get( Message.ENDPOINT_ADDRESS );

Their types are defined in JAX-WS spec, section 9.4.1. 

.description URI
.service QName 
.port QName 
.interface QName 
.operation QName

Jervis

> -Original Message-
> From: James Royalty [mailto:[EMAIL PROTECTED]
> Sent: 2007?8?31? 10:07
> To: cxf-user@incubator.apache.org
> Subject: Re: Obtaining source address and operation name
> 
> 
> Hi Jervis,
> 
> As I test, I was doing:
> 
> Object operation = message.get( Message.WSDL_OPERATION );
> Object port = message.get( Message.WSDL_PORT );
> Object service = message.get( Message.WSDL_SERVICE );
> Object context = message.get( Message.INVOCATION_CONTEXT );
> Object endpointAddress = message.get( Message.ENDPOINT_ADDRESS );
> 
> ... as I didn't know what type would be returned.  All ended up being 
> null.  The services are using a servlet transport, btw.
> 
> Thanks!
> --
> James
> 
> 
> 
> Liu, Jervis wrote:
> > Hi What code did you use to retrieve WSDL_OPERATION, WSDL_PORT etc?
> >
> > Thanks,
> > Jervis
> >
> >   
> >> -Original Message-
> >> From: James Royalty [mailto:[EMAIL PROTECTED]
> >> Sent: 2007?8?31? 8:28
> >> To: cxf-user@incubator.apache.org
> >> Subject: Obtaining source address and operation name
> >>
> >>
> >> Hi,
> >>
> >> I'm trying to write an "in" interceptor, using 
> >> org.apache.cxf.interceptor.LoggingInInterceptor as a 
> starting point.  
> >> I'm trying to log
> >>
> >> - the source (IP) address that originate the (SOAP) Message;
> >> - the SOAP operation that was invoked.
> >>
> >> Any hints on how I can obtain either of these? 
> >>
> >> I've tried adding the interceptor at various phases (RECEIVE, 
> >> PRE_INVOKE, INVOKE) and getting several values from the Messsage:  
> >> WSDL_OPERATION, WSDL_PORT, WSDL_SERVICE, INVOCATION_CONTEXT, 
> >> ENDPOINT_ADDRESS.  All these end up being null.
> >>
> >> Thanks!
> >>
> >> 
> >
> > 
> > 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: Obtaining source address and operation name

[Liu, Jervis]

So it seems that we did some duplicate work in the code. In 
org.apache.cxf.transport.ChainInitiationObserver we already set most properties 
into the Exchange except the operation name, the operation name wont be 
available until the interceptor who knows how to parse the operation name info 
from the incoming message payload. In RPCInInterceptor/DocLitInInterceptor we 
set these properties again, which is duplicate.  
RPCInInterceptor/DocLitInInterceptor only need to set operation name.

Cheers,
Jervis



> -Original Message-
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?1? 0:09
> To: cxf-user@incubator.apache.org
> Cc: Liu, Jervis
> Subject: Re: Obtaining source address and operation name
> 
> 
> 
> Jervis,
> 
> Those properties are on the message, not the exchange.   I 
> just checked 
> both the DocLitInInterceptor and RPCInInterceptor and they 
> put them on 
> the message.
> 
> That said, I just added the code to the RPCInInterceptor earlier this 
> week.   If the service is RPC, that information won't be there unless 
> you are using a SNAPSHOT version.  (even then, I'm not sure.  I don't 
> remember when I did the last snapshot)
> 
> Dan
>  
> 
> 
> On Thursday 30 August 2007, Liu, Jervis wrote:
> > these properties are stored in Exchange, not in Message. following
> > should work for you:
> >
> > Object operation = message.getExchange().get( Message.WSDL_OPERATION
> > ); Object port = message.getExchange().get( Message.WSDL_PORT );
> > Object service = message.getExchange().get( Message.WSDL_SERVICE );
> > Object context = message.getExchange().get( 
> Message.INVOCATION_CONTEXT
> > ); Object endpointAddress = message.getExchange().get(
> > Message.ENDPOINT_ADDRESS );
> >
> > Their types are defined in JAX-WS spec, section 9.4.1.
> >
> > .description URI
> > .service QName
> > .port QName
> > .interface QName
> > .operation QName
> >
> > Jervis
> >
> > > -Original Message-
> > > From: James Royalty [mailto:[EMAIL PROTECTED]
> > > Sent: 2007?8?31? 10:07
> > > To: cxf-user@incubator.apache.org
> > > Subject: Re: Obtaining source address and operation name
> > >
> > >
> > > Hi Jervis,
> > >
> > > As I test, I was doing:
> > >
> > > Object operation = message.get( Message.WSDL_OPERATION );
> > > Object port = message.get( Message.WSDL_PORT );
> > > Object service = message.get( Message.WSDL_SERVICE );
> > > Object context = message.get( Message.INVOCATION_CONTEXT );
> > > Object endpointAddress = message.get( Message.ENDPOINT_ADDRESS );
> > >
> > > ... as I didn't know what type would be returned.  All ended up
> > > being null.  The services are using a servlet transport, btw.
> > >
> > > Thanks!
> > > --
> > > James
> > >
> > > Liu, Jervis wrote:
> > > > Hi What code did you use to retrieve WSDL_OPERATION, WSDL_PORT
> > > > etc?
> > > >
> > > > Thanks,
> > > > Jervis
> > > >
> > > >> -Original Message-
> > > >> From: James Royalty [mailto:[EMAIL PROTECTED]
> > > >> Sent: 2007?8?31? 8:28
> > > >> To: cxf-user@incubator.apache.org
> > > >> Subject: Obtaining source address and operation name
> > > >>
> > > >>
> > > >> Hi,
> > > >>
> > > >> I'm trying to write an "in" interceptor, using
> > > >> org.apache.cxf.interceptor.LoggingInInterceptor as a
> > >
> > > starting point.
> > >
> > > >> I'm trying to log
> > > >>
> > > >> - the source (IP) address that originate the (SOAP) Message;
> > > >> - the SOAP operation that was invoked.
> > > >>
> > > >> Any hints on how I can obtain either of these?
> > > >>
> > > >> I've tried adding the interceptor at various phases (RECEIVE,
> > > >> PRE_INVOKE, INVOKE) and getting several values from 
> the Messsage:
> > > >> WSDL_OPERATION, WSDL_PORT, WSDL_SERVICE, INVOCATION_CONTEXT,
> > > >> ENDPOINT_ADDRESS.  All these end up being null.
> > > >>
> > > >> Thanks!
> > > >
> > > > 
> > > > 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
> 
> 
> 
> -- 
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727C: 508-380-7194
> [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: Memory leak in client?

[Liu, Jervis]

Hi Joe, based on the information you supplied, I wont necessarily say there is 
a memory leak. Internally CXF runtime maintains a service model which is built 
either from WSDL or from POJO, both on the client side and server side. And 
this service model will keep alive until the server or client gets shut down. 
It can happen that a service model takes about 20MB for a WSDL of 1 MB. Having 
this said, we did fix several memory leaks before, for example, if you start a 
CXF client and invoke an operation several times then you find the memory usage 
increases steadily, then it is likely that you run into a memory leak problem.

Cheers,
Jervis


> -Original Message-
> From: Joe Sunday [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?5? 2:06
> To: cxf-user@incubator.apache.org
> Subject: Memory leak in client?
> 
> 
> Using 2.0.1, creating a client from a large wsdl (~1 MB) in my  
> classpath using generated stubs increases memory usage by about 20  
> MB, which never gets garbage collected. Later clients created from  
> the same WSDL url cause similar increases until I get an out of  
> memory condition.
> 
> static {
>  WSDL_URL = MyService.class.getClassLoader().getResource 
> ("myService.wsdl");
>SERVICE_QNAME = new QName("urn:myService", "MyService");
> }
> 
> MyService service = new MyService(WSDL_URL, SERVICE_QNAME);
> MyPort client = service.getMyPort();
> BindingProvider provider = (BindingProvider)client;
> provider.getRequestContext().put 
> (BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint.getURL());
> Client c = ClientProxy.getClient(client);
> HTTPConduit conduit = (HTTPConduit)c.getConduit();
> conduit.getClient().setAllowChunking(false);
> // ... SSL setup too ...
> 
> Working through a heap dump now, but does this look familiar 
> to anyone?
> 
> --Joe
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Memory leak in client?

[Liu, Jervis]

> -Original Message-
> From: Joe Sunday [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?5? 12:11
> To: cxf-user@incubator.apache.org
> Subject: Re: Memory leak in client?
> 
> 
> I changed it so I only create the service object once and then each  
> time I need a new client use getMyPort and set it up.. The docs  
> aren't exactly clear, but it looks like I get distinct proxies back  
> on each call, so I'm assuming that's safe? If I then call  
> service.getMyPort() across multiple threads?
> 

As you already noticed, getMyPort(which calls 
org.apache.cxf.jaxws.ServiceImpl.createPort(QName, EndpointReferenceType, 
Class) indeed creates a new proxy object every time, thus a new 
ServiceFactoryBean, a new service model etc for every new proxy. If what you 
are trying to do is invoking a same web service several times, you should try 
to use the same proxy instead.

> It still leaks about 6 megs each time I call getMyPort() and make a  
> few remote requests. After any references I have to the new port  
> object are gone and I've forced a few GCs,it looks like a bunch of  
> data being left in a ThreadLocal. I'm still trying to unwind what  
> happens behind the scenes when I setup a client fully, but I see a  
> couple ThreadLocals in JaxWsClientProxy that might not be getting  
> cleared?
> 

If you are sure all references to the proxy object have gone, and there are 
still some objects not cleaned by GC, then it might be a memory leak on the 
client side. Would you be able to reproduce same symptoms using a very simple 
WSDL, for example, the hello_world sample in CXF distribution?

For example, following code snippet is modified based on hello_world sample to 
show a memory leak :


SOAPService ss = new SOAPService(wsdlURL, SERVICE_NAME);
try (int =0; i <1000; i++ ) {
Greeter port = ss.getSoapPort();
String resp; 

System.out.println("Invoking sayHi...");
resp = port.sayHi();
System.out.println("Server responded with: " + resp);
System.out.println();
}

If you run this, and you see the memory usage increased steadily after 1000 
loops, then its definitely a memory leak.

Jervis


> --Joe
> 
> On Sep 4, 2007, at 10:10 PM, Liu, Jervis wrote:
> 
> > Hi Joe, based on the information you supplied, I wont necessarily  
> > say there is a memory leak. Internally CXF runtime maintains a  
> > service model which is built either from WSDL or from POJO, 
> both on  
> > the client side and server side. And this service model will keep  
> > alive until the server or client gets shut down. It can 
> happen that  
> > a service model takes about 20MB for a WSDL of 1 MB. Having this  
> > said, we did fix several memory leaks before, for example, if you  
> > start a CXF client and invoke an operation several times then you  
> > find the memory usage increases steadily, then it is likely that  
> > you run into a memory leak problem.
> >
> > Cheers,
> > Jervis
> >
> >
> >> -Original Message-
> >> From: Joe Sunday [mailto:[EMAIL PROTECTED]
> >> Sent: 2007?9?5? 2:06
> >> To: cxf-user@incubator.apache.org
> >> Subject: Memory leak in client?
> >>
> >>
> >> Using 2.0.1, creating a client from a large wsdl (~1 MB) in my
> >> classpath using generated stubs increases memory usage by about 20
> >> MB, which never gets garbage collected. Later clients created from
> >> the same WSDL url cause similar increases until I get an out of
> >> memory condition.
> >>
> >> static {
> >>  WSDL_URL = MyService.class.getClassLoader().getResource
> >> ("myService.wsdl");
> >>SERVICE_QNAME = new QName("urn:myService", "MyService");
> >> }
> >>
> >> MyService service = new MyService(WSDL_URL, SERVICE_QNAME);
> >> MyPort client = service.getMyPort();
> >> BindingProvider provider = (BindingProvider)client;
> >> provider.getRequestContext().put
> >> (BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpoint.getURL());
> >> Client c = ClientProxy.getClient(client);
> >> HTTPConduit conduit = (HTTPConduit)c.getConduit();
> >> conduit.getClient().setAllowChunking(false);
> >> // ... SSL setup too ...
> >>
> >> Working through a heap dump now, but does this look familiar
> >> to anyone?
> >>
> >> --Joe
> >>
> >>
> >
> > 
> > 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: Elements and parts seem to default to "return" - which upsets WSDL2X as "return" is generally a reserved word

[Liu, Jervis]

Jon, the mapping name of "return" is per JAX-WS 2.0 spec. Section 3.6.1: 

"Conformance (Result naming): The javax.jws.WebResult annotation (see 7.10.4) 
MAY be used to 
specify the name of the wsdl:part or XML Schema element declaration 
corresponding to the Java method 
return type. If both the name and partName elements are used in the 
javax.jws.WebResult annota- 
tions then the partName MUST be used for the wsdl:part name attribute and the 
name elment from the 
annotation will be ignored. In the absence of customizations, the default name 
is return."

As far as the WSDL2JAVA tool is concerned, the return name is not significant 
as it is not needed by the language, only the return type is significant. Or 
you have specific WSDL2Language in your mind?

Cheers,
Jervis

> -Original Message-
> From: Jon Mountjoy [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?11? 4:46
> To: cxf-user@incubator.apache.org
> Subject: Elements and parts seem to default to "return" - 
> which upsets WSDL2X as "return" is generally a reserved word
> 
> 
> Hi,
> 
> I'm new to CXF, so forgive this newb question.  For almost 
> all simple  
> web services that I create using Java, such as those described here:
> http://cwiki.apache.org/CXF20DOC/a-simple-jax-ws-service.html
> I get parts or elements automatically named "return" in the 
> resulting  
> auto-generated WSDL (see example below).
> 
> As you'll see below, the argument is given a nice name like "arg0",  
> but the return is called "return".  Unfortunately, return is a  
> reserved keyword in many languages, so this forces many  
> WSDL2LanguageX converters to rename.
> 
> Can you change the default return name for elements/parts to  
> something like "return0" ?  Right now, I can't use CXF web services  
> from salesforce.com without hacking all my WSDL files (or, when I  
> have access to source, adding an annotation).
> 
> LMK if I've got this wrong!
> 
> Thanks!
> Jon
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Elements and parts seem to default to "return" - which upsets WSDL2X as "return" is generally a reserved word

[Liu, Jervis]

One thing to add. If your WSDL is doc-lit wrapped (this type of WSDL is 
generated by java2wsdl by default unless your java class has annotations to 
customize this),  a Response Bean is required to be generated by WSDL2JAVA 
tool. In this case, the WSDL2JAVA tool is also required to resolve any name 
collisions in response bean. In CXF, when JAXB is the databinding used by 
WSDL2JAVA, the name mapping is handled by JAXB, detailed can be found in JAXB 
2.0 spec Appendix D "BINDING XML NAMES TO JAVA IDENTIFIERS".

Cheers,
Jervis

> -Original Message-----
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?11? 10:47
> To: cxf-user@incubator.apache.org
> Subject: RE: Elements and parts seem to default to "return" - 
> which upsets WSDL2X as "return" is generally a reserved word
> 
> 
> Jon, the mapping name of "return" is per JAX-WS 2.0 spec. 
> Section 3.6.1: 
> 
> "Conformance (Result naming): The javax.jws.WebResult 
> annotation (see 7.10.4) MAY be used to 
> specify the name of the wsdl:part or XML Schema element 
> declaration corresponding to the Java method 
> return type. If both the name and partName elements are used 
> in the javax.jws.WebResult annota- 
> tions then the partName MUST be used for the wsdl:part name 
> attribute and the name elment from the 
> annotation will be ignored. In the absence of customizations, 
> the default name is return."
> 
> As far as the WSDL2JAVA tool is concerned, the return name is 
> not significant as it is not needed by the language, only the 
> return type is significant. Or you have specific 
> WSDL2Language in your mind?
> 
> Cheers,
> Jervis
> 
> > -Original Message-
> > From: Jon Mountjoy [mailto:[EMAIL PROTECTED]
> > Sent: 2007?9?11? 4:46
> > To: cxf-user@incubator.apache.org
> > Subject: Elements and parts seem to default to "return" - 
> > which upsets WSDL2X as "return" is generally a reserved word
> > 
> > 
> > Hi,
> > 
> > I'm new to CXF, so forgive this newb question.  For almost 
> > all simple  
> > web services that I create using Java, such as those described here:
> > http://cwiki.apache.org/CXF20DOC/a-simple-jax-ws-service.html
> > I get parts or elements automatically named "return" in the 
> > resulting  
> > auto-generated WSDL (see example below).
> > 
> > As you'll see below, the argument is given a nice name like 
> "arg0",  
> > but the return is called "return".  Unfortunately, return is a  
> > reserved keyword in many languages, so this forces many  
> > WSDL2LanguageX converters to rename.
> > 
> > Can you change the default return name for elements/parts to  
> > something like "return0" ?  Right now, I can't use CXF web 
> services  
> > from salesforce.com without hacking all my WSDL files (or, when I  
> > have access to source, adding an annotation).
> > 
> > LMK if I've got this wrong!
> > 
> > Thanks!
> > Jon
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 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: Not able to catch desired Fault type

[Liu, Jervis]

Your WSDL snippet and the response message look ok. You may want to send out 
your WSDL file and client/server code (or paste them in a JIRA), so that we can 
have a quick debug to see whats going wrong there.

Thanks,
Jervis

> -Original Message-
> From: Richard Mixon [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?13? 11:16
> To: cxf-user@incubator.apache.org
> Subject: Not able to catch desired Fault type
> 
> 
> I would appreciate some help trying to understand how to 
> catch faults that
> are defined in my WSDL in a Java client.
> 
> My web service appears to be correctly throwing a specific Fault -
> MemberExistsFault - when trying to add a record and the member already
> exists. 
> 
> However when I catch it on the client, I am not able to catch a
> MemberExistsFault. Instead the exception can be caught as a
> javax.xml.ws.soap.SOAPFaultException
> which in turn has a cause of
> org.apache.cxf.binding.soap.SoapFault.
> 
> 
> Here is what the log shows on the server:
> INFO: Outbound Message 
> --
> http://www.w3.org/2003/05/soap-envelope";>
>   
> 
>   
> soap:Receiver
>   
>   
> 
>   Member cannot be added, it is already in the database
> 
>   
>   
>  xmlns:ns2="http://service.webservice.acme.com/";>
>   [EMAIL PROTECTED]
>   myLastName
>   myFirstName3
> 
>   
> 
>   
> 
> --
> 
> Below are the key parts of the WSDL (I can send the whole thing if
> necessary).
> 
> Thanks in advance - Richard
> 
> 
>targetNamespace="http://service.webservice.acme.com/";
>   xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/";
>   xmlns:ns1="http://service.webservice.acme.com/";
>   xmlns:tns="http://types.webservice.firedrum.com/";
>   xmlns:xsd="http://www.w3.org/2001/XMLSchema";
>   xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";>
>   
> http://www.w3.org/2001/XMLSchema";
>   xmlns:tns="http://types.webservice.acme.com/";
>   attributeFormDefault="unqualified" 
> elementFormDefault="unqualified"
>   targetNamespace="http://types.webservice.acme.com/";>
>  ...
>type="tns:MemberIdInfoType">
>   
>   
> 
>type="xs:string">
>   
>   
> 
>   
> 
>   
> 
>  ...
>   
>
> 
>   
> 
>  ...
>  
> 
>
>  
>  
>  message="ns1:addMemberResponse">
>  
>  message="ns1:InvalidClientFault">
>  
>  message="ns1:MemberExistsFault">
>  
>  message="ns1:InvalidEmailAddressFault">
>  
>  message="ns1:CategoryNotFoundFault">
>  
>  message="ns1:CustomFieldTypeNotFoundFault">
>  
>   message="ns1:AddMemberUnknownFault">
>  
>   
>
> type="ns1:MemberService">
>
> transport="http://www.w3.org/2003/05/soap/bindings/HTTP/"; />  
>   
> 
> 
>   
>   
> 
>   
>   
> 
>   
>   
>   
>   
>   
>   
> 
> 
> 
>
> binding="ns1:MemberServiceServiceSoapBinding">
>location="http://localhost:8080/services/MemberService"; />
>  
>
> 
> 
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Wsdl Versioning

[Liu, Jervis]

Hi Dave, we've had a very basic versioning implementation. Basically how it 
works is an interceptor sitting at the beginning of in-bound interceptor chain 
as a mediator to inspect then dispatch the coming request to different 
endpoints. An example can be found from a system test sample: 
\trunk\systests\src\test\java\org\apache\cxf\systest\versioning. Let me know if 
you have any further questions. Willem Jiang is currently working on adding a 
much more powerful routing support using Apache Camel, hopefully this will 
provide a better foundation for implementing versioning in CXF once it is done. 

Cheers,
Jervis


> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?14? 2:53
> To: cxf-user@incubator.apache.org
> Subject: Wsdl Versioning
> 
> 
> We have recently migrated our web services offering from 
> xfire to cxf and
> everything is going well. Now the issue is that we have 
> several clients who
> would like different features and I am wondering how best to 
> accomplish
> this. The changes being requested will likely result in a 
> different wsdl so
> I would like to be able to version our wsdls with different 
> namespaces. The
> question is where do I inspect the wsdl namespace and then 
> how do I provide
> different functionality depending on the incoming namespace? 
> I am using
> aegis bindings and cxf.xml with the cxf servlet.
> Any ideas would be appreciated.
> 
> -- 
> Dave Kallstrom
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Wsdl Versioning

[Liu, Jervis]

Hi, your interceptor needs to extend from AbstractEndpointSelectionInterceptor. 
Also make sure you have registered your routing interceptor with the 
MultipleEndpointObserver, please refer to 
\trunk\systests\src\test\java\org\apache\cxf\systest\versioning\Server.java

Cheers,
Jervis

> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?15? 2:39
> To: cxf-user@incubator.apache.org
> Subject: Re: Wsdl Versioning
> 
> 
> Thanks for the response. I tried adding an incoming 
> interceptor that extends
> AbstractEndpointInterceptor very similar to the example. The 
> only problem I
> see is
> that the incoming set of endpoints to my selectEndpoint 
> methid is always
> null. My no arg constructor is calling 
> super(Phase.POST_STREAM) and then
> addBefore(StaxInterceptor.class.getName())
> Am I doing this correctly? Or could it be because I only have 
> one endpoint?
> 
> On 9/14/07, Jean-François Daune <[EMAIL PROTECTED]> wrote:
> >
> >
> > This document is quite interesting about this subject:
> >
> > http://blogs.iona.com/sos/20070410-WSDL-Versioning-Best-Practise.pdf
> >
> > Cheers,
> >
> > J-F
> >
> > -Message d'origine-
> > De : Liu, Jervis [mailto:[EMAIL PROTECTED]
> > Envoyé : vendredi 14 septembre 2007 3:55
> > À : cxf-user@incubator.apache.org
> > Objet : RE: Wsdl Versioning
> >
> >
> > Hi Dave, we've had a very basic versioning implementation. 
> Basically how
> > it works is an interceptor sitting at the beginning of 
> in-bound interceptor
> > chain as a mediator to inspect then dispatch the coming 
> request to different
> > endpoints. An example can be found from a system test sample:
> > 
> \trunk\systests\src\test\java\org\apache\cxf\systest\versionin
> g. Let me know
> > if you have any further questions. Willem Jiang is 
> currently working on
> > adding a much more powerful routing support using Apache 
> Camel, hopefully
> > this will provide a better foundation for implementing 
> versioning in CXF
> > once it is done.
> >
> > Cheers,
> > Jervis
> >
> >
> > > -Original Message-
> > > From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> > > Sent: 2007?9?14? 2:53
> > > To: cxf-user@incubator.apache.org
> > > Subject: Wsdl Versioning
> > >
> > >
> > > We have recently migrated our web services offering from
> > > xfire to cxf and
> > > everything is going well. Now the issue is that we have
> > > several clients who
> > > would like different features and I am wondering how best to
> > > accomplish
> > > this. The changes being requested will likely result in a
> > > different wsdl so
> > > I would like to be able to version our wsdls with different
> > > namespaces. The
> > > question is where do I inspect the wsdl namespace and then
> > > how do I provide
> > > different functionality depending on the incoming namespace?
> > > I am using
> > > aegis bindings and cxf.xml with the cxf servlet.
> > > Any ideas would be appreciated.
> > >
> > > --
> > > Dave Kallstrom
> > >
> >
> > 
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, 
> Dublin 4, Ireland
> >
> 
> 
> 
> -- 
> Dave Kallstrom
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Wsdl Versioning

[Liu, Jervis]

Hi Dave, Firstly you need to make sure you are using SOAP binding, at the 
moment only the SOAP binding is using MultipleEndpointObserver. Then you can 
add your interceptor (that extends from AbstractEndpointSelectionInterceptor) 
into the chain using spring configuration similar to the way how logging 
interceptor is added, see [1]. Please pay attention to the phase of your 
interceptor, your interceptor needs to be the very first one that being invoked 
in the inbound interceptor chain. You might see AttachmentInInterceptor is 
invoked before your interceptor, but that is ok. I believe using 
Phase.POST_STREAM and addBefore(StaxInterceptor.class.getName()) should give 
you the right phase.
 

[1]. http://cwiki.apache.org/CXF20DOC/configuration.html

Cheers,
Jervis

> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?17? 23:58
> To: cxf-user@incubator.apache.org
> Subject: Re: Wsdl Versioning
> 
> 
> It looks like I might not be able to set this up through 
> cxf.xml? I don't
> see a way to get the MultipleEndpointObserver from the
> JaxWsServiceFactoryBean so that I can add a routingInterceptor to it.
> 
> On 9/15/07, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> >
> > Hi, your interceptor needs to extend from
> > AbstractEndpointSelectionInterceptor. Also make sure you 
> have registered
> > your routing interceptor with the MultipleEndpointObserver, 
> please refer to
> > 
> \trunk\systests\src\test\java\org\apache\cxf\systest\versionin
> g\Server.java
> >
> > Cheers,
> > Jervis
> >
> > > -Original Message-
> > > From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> > > Sent: 2007?9?15? 2:39
> > > To: cxf-user@incubator.apache.org
> > > Subject: Re: Wsdl Versioning
> > >
> > >
> > > Thanks for the response. I tried adding an incoming
> > > interceptor that extends
> > > AbstractEndpointInterceptor very similar to the example. The
> > > only problem I
> > > see is
> > > that the incoming set of endpoints to my selectEndpoint
> > > methid is always
> > > null. My no arg constructor is calling
> > > super(Phase.POST_STREAM) and then
> > > addBefore(StaxInterceptor.class.getName())
> > > Am I doing this correctly? Or could it be because I only have
> > > one endpoint?
> > >
> > > On 9/14/07, Jean-François Daune <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > > This document is quite interesting about this subject:
> > > >
> > > > 
> http://blogs.iona.com/sos/20070410-WSDL-Versioning-Best-Practise.pdf
> > > >
> > > > Cheers,
> > > >
> > > > J-F
> > > >
> > > > -Message d'origine-
> > > > De : Liu, Jervis [mailto:[EMAIL PROTECTED]
> > > > Envoyé : vendredi 14 septembre 2007 3:55
> > > > À : cxf-user@incubator.apache.org
> > > > Objet : RE: Wsdl Versioning
> > > >
> > > >
> > > > Hi Dave, we've had a very basic versioning implementation.
> > > Basically how
> > > > it works is an interceptor sitting at the beginning of
> > > in-bound interceptor
> > > > chain as a mediator to inspect then dispatch the coming
> > > request to different
> > > > endpoints. An example can be found from a system test sample:
> > > >
> > > \trunk\systests\src\test\java\org\apache\cxf\systest\versionin
> > > g. Let me know
> > > > if you have any further questions. Willem Jiang is
> > > currently working on
> > > > adding a much more powerful routing support using Apache
> > > Camel, hopefully
> > > > this will provide a better foundation for implementing
> > > versioning in CXF
> > > > once it is done.
> > > >
> > > > Cheers,
> > > > Jervis
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> > > > > Sent: 2007?9?14? 2:53
> > > > > To: cxf-user@incubator.apache.org
> > > > > Subject: Wsdl Versioning
> > > > >
> > > > >
> > > > > We have recently migrated our web services offering from
> > > > > xfire to cxf and
> > > > > everything is going well. Now the issue is that we have
> > > > > several clients who
> > > > > would like different features and I am wondering how best to
> > &

RE: HashMap as parameter for web service call

[Liu, Jervis]

HashMap is not supported by JAXB binding. More discussions about this can be 
found from 
http://www.nabble.com/DataBinding-problems-%28Timestamp-and-HashMap%29-using-JAXB-tf4283645.html#a12193877

Cheers,
Jervis

> -Original Message-
> From: Kaleb Walton [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?19? 5:59
> To: cxf-user@incubator.apache.org
> Subject: HashMap as parameter for web service call
> 
> 
> 
> I cannot seem to get a HashMap to work as a parameter when 
> making a web
> service call via PHP. Has anyone else experienced this? I want to
> encapsulate my parameters in a more complex object that 
> extends HashMap.
> 
> Regards,
> Kaleb
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Wsdl Versioning

[Liu, Jervis]

Ok, I see the tricks. MultipleEndpointObserver only steps in when there are 
more than one endpoint registered on the same address. MultipleEndpointObserver 
is the one who initializes the endpoint set. So the config below works:
















































 
 
 
 
 

> -Original Message-
> From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?19? 3:05
> To: cxf-user@incubator.apache.org
> Subject: Re: Wsdl Versioning
> 
> 
> And here is my cxf.xml file
> 
> 
> 
>  class="collective.webservices.VersionInterceptor
> "/>
> 
> 
> 
> 
> 
> 
> 
> 
>  ref="assetFactoryBean">
> 
> 
> 
> 
>  address="/CollectiveServices" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
>  
>  
>  
>  
> 
> 
> On 9/18/07, Dave Kallstrom <[EMAIL PROTECTED]> wrote:
> >
> > It is most likely my as I am not all that smart.
> > Here is my cxf.xml file and my version interceptor..
> > I know that my interceptor is being called however the 
> endpoint set is
> > always null.
> >
> > public class VersionInterceptor extends
> > AbstractEndpointSelectionInterceptor
> > {
> >
> > public VersionInterceptor()
> > {
> > super(Phase.POST_STREAM);
> > addBefore(StaxInInterceptor.class.getName());
> > System.out.println("VersionInterceptor#init()");
> > }
> >
> > @Override
> > protected Endpoint selectEndpoint(Message message, 
> Set eps)
> > {
> > InputStream is = message.getContent(InputStream.class);
> > System.out.println ("Message " + message);
> > System.out.println("EndpointSet " + eps);
> > }
> > }
> >
> > On 9/17/07, Liu, Jervis < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi Dave, Firstly you need to make sure you are using SOAP 
> binding, at
> > > the moment only the SOAP binding is using 
> MultipleEndpointObserver. Then you
> > > can add your interceptor (that extends from
> > > AbstractEndpointSelectionInterceptor) into the chain using spring
> > > configuration similar to the way how logging interceptor 
> is added, see [1].
> > > Please pay attention to the phase of your interceptor, 
> your interceptor
> > > needs to be the very first one that being invoked in the 
> inbound interceptor
> > > chain. You might see AttachmentInInterceptor is invoked 
> before your
> > > interceptor, but that is ok. I believe using Phase.POST_STREAM and
> > > addBefore(StaxInterceptor.class.getName()) should give 
> you the right
> > > phase.
> > >
> > >
> > > [1]. http://cwiki.apache.org/CXF20DOC/configuration.html
> > >
> > > Cheers,
> > > Jervis
> > >
> > > > -Original Message-
> > > > From: Dave Kallstrom [mailto:[EMAIL PROTECTED]
> > > > Sent: 2007?9?17? 23:58
> > > > To: cxf-user@incubator.apache.org
> > > > Subject: Re: Wsdl Versioning
> > > >
> > > >
> > > > It looks like I might not be able to set this up through
> > > > cxf.xml? I don't
> > > > see a way to get the MultipleEndpointObserver from the
> > > > JaxWsServiceFactoryBean so that I can add a 
> routingInterceptor to it.
> > > >
> > > > On 9/15/07, Liu, Jervis <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > Hi, your interceptor needs to extend from
> > > > > AbstractEndpointSelectionInterceptor. Also make sure you
> > > > have registered
> > > > > your routing interceptor with the MultipleEndpointObserver,
> > > > please refer to
> > > > >
> > > > \trunk\systes

RE: JAX-WS Handlers conflict with JBoss client?

[Liu, Jervis]

Hi you need to set messageFactory like this:

java.lang.System.setProperty("javax.xml.soap.MessageFactory","com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl");

Also see this discussion: 
http://www.nabble.com/Unable-to-create-message-factory-for-SOAP-tf4280273.html#a12196539

Cheers,
Jervis




> -Original Message-
> From: Yeroc [mailto:[EMAIL PROTECTED]
> Sent: 2007?9?22? 6:45
> To: cxf-user@incubator.apache.org
> Subject: JAX-WS Handlers conflict with JBoss client?
> 
> 
> 
> All...
> 
> I'm trying to get handlers working on my JAX-WS service 
> without success.  I
> based my work off of the logging example that ships with CXF 
> v2.0.1.  My
> handler is registering fine and get called but I get the 
> following errors
> showing up in my Tomcat logs as soon as I call
> SOAPMessageContext.getMessage():
> 
> 2007-09-21 16:09:01,832 DEBUG [http-8081-Processor23]
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:
101): Cannot
> load factory: org.jboss.axis.soap.MessageFactoryImpl
> 2007-09-21 16:09:01,862 DEBUG [http-8081-Processor23]
> javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:
101): Cannot
> load factory: org.jboss.axis.soap.MessageFactoryImpl
> 
> Unfortunately, it doesn't print out a stack trace so I can't 
> really find the
> source of the problem.  I did notice though that the factory 
> it's using is
> org.jboss.axis.soap.MessageFactoryImpl rather than a CXF 
> factory which is
> likely the root of the problem.  My service accesses a remote 
> JBoss server
> so it has the jboss-client.jar included which contains this class.
> 
> Has anyone else run into this problem?  Does anyone know of a 
> solution?
> 
> Thanks,
> Corey
> -- 
> View this message in context: 
> http://www.nabble.com/JAX-WS-Handlers-conflict-with-JBoss-clie
> nt--tf4499015.html#a12831143
> Sent from the cxf-user mailing list archive at Nabble.com.
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Message level service

[Liu, Jervis]

JAX-WS Dispatch/Provider API should give you what you want. There is a sample 
named jaxws_dispatch_provider in CXF distribution demonstrates how to write 
dispatch/provider in CXF. The reason why you got that exception is because you 
are using CXF HTTP binding in your configuration, which is the wrong. CXF HTTP 
binding is supposed to be used for REST style services, not for SOAP services.  
A configuration snippet like below should do the trick for you:



Cheers,
Jervis

> -Original Message-
> From: Cencio [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?11? 23:13
> To: cxf-user@incubator.apache.org
> Subject: Message level service
> 
> 
> 
> Hi all,
> 
> i have an old service in axis that uses saaj to work on 
> messages. Now i want
> to migrate on CFX but i encounter some problems...
> 
> First step is make a service that works at message level with 
> saaj. So i
> need that avery message that point to
> http://localhost:8080/CFX/myService/and/some/moreis catch 
> by myService
> service and some method handle it (something like 
> handleMessage(SOAPMessage
> message) )
> 
> To work at Message level i read something about 
> @ServiceProvider but i don't
> reach the goal... 
> 
> i tryed with:
> 
> package org.openspcoop.pdd.services;
> import java.rmi.RemoteException;
> import java.util.Map;
> import javax.xml.soap.SOAPMessage;
> import javax.xml.ws.*;
> 
> @WebServiceProvider
> @ServiceMode(value=javax.xml.ws.Service.Mode.MESSAGE)
> 
> public class RicezioneContenutiApplicativiWS {
>   public SOAPMessage invoke(SOAPMessage msg, Map Object> ctxt) throws
> RemoteException { 
>   return msg;
> }
> }
> 
> but it doesn't work, it gives this exception when invoking:
> 
> 17:06:10,341 ERROR [STDERR] 11-ott-2007 17.06.10
> org.apache.cxf.binding.http.interceptor.DispatchInterceptor 
> handleMessage
> INFO: Invoking POST on 
> 17:06:10,344 ERROR [STDERR] 11-ott-2007 17.06.10
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Invalid URL/Verb 
> combination. Verb: POST
> Path: 
> at
> org.apache.cxf.binding.http.interceptor.DispatchInterceptor.ha
> ndleMessage(DispatchInterceptor.java:74)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
terceptorChain.java:207)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
inInitiationObserver.java:73)
> at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
ServletDestination.java:79)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:235)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(Serv
letController.java:140)
> at
> org.apache.cxf.transport.servlet.CXFServlet.invoke(CXFServlet.
java:278)
> at
> org.apache.cxf.transport.servlet.CXFServlet.doPost(CXFServlet.
java:256)
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
cationFilterChain.java:173)
> at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyH
eaderFilter.java:96)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
cationFilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
rapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
ontextValve.java:178)
> at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
SecurityAssociationValve.java:175)
> at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccCont
extValve.java:74)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
Valve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
Valve.java:105)
> at
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(Cach
edConnectionValve.java:156)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
gineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
ter.java:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Process
or.java:869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHa
ndler.processConnection(Http11BaseProtocol.java:664)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolT
cpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterS
laveWorkerThread.java:112)
>   

RE: Configuring Interceptors

[Liu, Jervis]

If I understand your question correctly, you want to dispatch incoming request 
to two different instances of WSSInInterceptor which are configured 
differently, and the dispatch criteria is based on some information in the 
incoming request. If this is case, what you are really looking for is a 
content-based-routing, i.e., you route incoming messages to different 
endpoints. For example, you can have two endpoints that are configured using 
different interceptors. A system test located under 
trunk\systests\src\test\java\org\apache\cxf\systest\versioning shows you to do 
a basic routing in CXF. 

Hope this helps,
Jervis 



> -Original Message-
> From: Mayank Mishra [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?16? 21:03
> To: cxf-user@incubator.apache.org
> Subject: Configuring Interceptors
> 
> 
> Hi all,
> 
> I understand the way of plugging in In and Out Interceptors 
> to CXF bus like,
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  ...
> 
> We can specify a set of configuration inside each of WSS4J In and Out 
> interceptors.
> 
> My requirement is to specify an alternative configuration also along 
> with this configuration. So, if service configured for 
> configuration A 
> and B. If the incoming message adheres to Configuration B 
> rather than A, 
> CXFBus can pass the message to WSSInInterceptor configured for B 
> configuration, without WSSInInterceptor A giving Security Failure.
> 
> Is it somehow feasible using CXF Spring Configuration or the way we 
> specify Interceptors to CXFBus?
> 
> With Regards,
> Mayank
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Serialization of XML attributes to Java Types

[Liu, Jervis]

CXF HTTP REST binding uses JAXB data binding as the underlying 
marshal/unmarshal mechanism. I have not tried this by myself, but your case 
should be a matter of tuning JAXB to do a customized mapping for you. For 
example, if you want to map  to 
MyObject java class, annotating "private String myVar1" with @XmlAttribute 
annotation should do the job. 

Cheers,
Jervis

> -Original Message-
> From: Brad O'Hearne [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?24? 8:54
> To: cxf-user@incubator.apache.org
> Subject: Serialization of XML attributes to Java Types
> 
> 
> Hello,
> 
> I am using CXF HTTP RESTful invocations, and I have been successfully 
> using the default serialization in CXF to convert XML such as 
> the following:
> 
> 
> value 1
> value 2
> 
> 
> to a Java object such as:
> 
> public class MyObject {
> 
> private String myVar1;
> private String myVar2;
> 
> //  ...
> }
> 
> What I would like to do, is change the serialization so that 
> attributes 
> map to Java properties, so that using the same Java object above, the 
> following XML would properly map using CXF:
> 
> 
> 
> Can someone enlighten me as to how this is done? That is step 1. The 
> second step is to map other object types to properties, as in:
> 
> 
> 
> value 1
> value 2
> 
> 
> 
> 
> mapping to these Java classes:
> 
> 
> public class MyObject {
> 
> private MyChildObject myChildObject;
> 
> //  ...
> }
> 
> public class MyChildObject {
> 
> private String myVar1;
> private String myVar2;
> 
> //  ...
> }
> 
> Any help would be greatly appreciated!
> 
> Thanks,
> 
> Brad
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Unintended Consequences...

[Liu, Jervis]

This indeed looks like a bug to me. I vaguely recalled that I once ran into a 
weird problem with SAAJ impl, which is that in some cases SOAPBody() wont be 
not properly initialized until SOAPMessage.writeTo() or some other similar 
methods are called. I guess what might happen is that CXF creates a STAX 
XMLStreamReader on top of a DOMSource which is in turn created from SOAPBody, 
this STAX wont have valid data to read until someone called 
SOAPMessage.writeTo(). Anyway, just a guess, could you please log a JIRA with 
your test case attached, I will take a deep look into this.

Thanks,
Jervis

> -Original Message-
> From: Yeroc [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?25? 5:37
> To: cxf-user@incubator.apache.org
> Subject: Unintended Consequences...
> 
> 
> 
> All...
> 
> I've got a very puzzling problem issue with CXF v2.0.1.  I 
> implemented a
> SOAPHandler that logs all the SOAP messages being sent over 
> the wire.  It's
> very similar to the one that ships as an example in the CXF 
> distribution
> except that I'm logging to a log4j Logger.
> 
> What's strange is that in one case the behavior of my SOAP 
> service changes
> depending on whether the logging is enabled or not! (The 
> SOAPHandler itself
> is enabled always, just the logging of the messages is 
> enabled/disabled at
> runtime.)  Even stranger, is that when the logging is enabled 
> the service is
> working fine, but when the logging is disabled, the service 
> errors with an
> unmarshalling error (see below).
> 
> Logging a SOAP message shouldn't be affecting the parsing of 
> a message in
> any way.  Here's the relevant code:
> 
>   private void log(SOAPMessageContext smc)
>   {
> if (!log.isTraceEnabled()) return;
> 
> Boolean outbound =
> (Boolean)smc.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
> 
> SOAPMessage msg = smc.getMessage();
> 
> try
> {
>   if (outbound.booleanValue())
>   { los.write(">\n".getBytes()); }
>   else
>   { los.write("<\n".getBytes()); }
>   msg.writeTo(los); 
>   los.flush();
> }
> catch (Exception e)
> { log.error(e.getMessage(), e); }
>   }
> 
> It seems to me that either SOAPMessageContext.getMessage() or
> SOAPMessage.writeTo() must have some sort of sideaffect?!?  
> Surely this
> can't be intended?
> 
> Here's the error I'm getting when logging is NOT enabled (the 
> code above
> returns on the initial if condition check):
> 
> Oct 23, 2007 5:02:51 PM org.apache.cxf.phase.PhaseInterceptorChain
> doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Unmarshalling Error : 
> Current state not
> START_ELEMENT or END_ELEMENT
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshallArray(JAXBEnc
> oderDecoder.java:443)
> at
> org.apache.cxf.jaxb.JAXBEncoderDecoder.unmarshall(JAXBEncoderD
> ecoder.java:256)
> at
> org.apache.cxf.jaxb.io.DataReaderImpl.read(DataReaderImpl.java:40)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.getPara(Doc
> LiteralInInterceptor.java:235)
> at
> org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessa
> ge(DocLiteralInInterceptor.java:121)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
> terceptorChain.java:207)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(Cha
> inInitiationObserver.java:73)
> at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(
> ServletDestination.java:78)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDesti
> nation(ServletController.java:231)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(Serv
> letController.java:139)
> at com.kelman.kws.v2.CXFServlet.invoke(CXFServlet.java:121)
> at com.kelman.kws.v2.CXFServlet.doPost(CXFServlet.java:92)
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
> at 
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.java:178)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:105)
> at
> org.apache.catalina.valves.FastCommonAccessLogValve.invoke(Fas
> tCommonAccessLogValve.java:495)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> gineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
> ter.java:148)
> at
> org.apache.c

RE: empty response object

[Liu, Jervis]

Looks like you need to post a complete test case (at least the WSDL file and 
client side code) in order to fully understand what the problem is. 

Thanks,
Jervis

> -Original Message-
> From: tirtza [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?29? 3:24
> To: cxf-user@incubator.apache.org
> Subject: Re: empty response object
> 
> 
> 
> I get an empty response object when using 
> JaxWsProxyFactoryBean  as well.
> 
> -- 
> View this message in context: 
> http://www.nabble.com/empty-response-object-tf4706733.html#a13456805
> Sent from the cxf-user mailing list archive at Nabble.com.
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Dispatch Client + JaxB

[Liu, Jervis]

It would be nice if we can catch the HTTP 500 error and throw this to the 
client as a ProtocolException instead of failed silently.  I will file a JIRA 
if this sounds a reasable solution.

Cheers,
Jervis

> -Original Message-
> From: tirtza [mailto:[EMAIL PROTECTED]
> Sent: 2007?10?30? 18:19
> To: cxf-user@incubator.apache.org
> Subject: Re: Dispatch Client + JaxB
> 
> 
> 
> I see the problem-  I was passing JAXBContext.class instead 
> of a JAXBContext
> object.
> My current problem is when using the dispatch method, if the 
> service returns
> a bad response such as a 500 instead of a SoapFaultException 
> being thrown I
> get an Unmarshalling Error since it could not create the 
> response object. 
> Is there a way around this?
> 
> 
> 
> tirtza wrote:
> > 
> > I created a dispatch client since I am invoking a service 
> that returns the
> > soap message as rpc/encoded.
> > I am using PAYLOAD mode since I want a JaxB object returned.
> > My client generates this exception
> > 
> > org.apache.cxf.interceptor.Fault: Exception occurred while 
> marshalling
> > Dispatch object to stream
> > at
> > 
> org.apache.cxf.jaxws.interceptors.DispatchOutDatabindingInterc
> eptor.handleMessage(DispatchOutDatabindingInterceptor.java:116)
> > at
> > 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIn
terceptorChain.java:207)
> > at 
> org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:172)
> > at 
> org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:121)
> > at
> > 
> net.idt.svp.Nomad.client.BalanceEnquiryClient.main(BalanceEnqu
iryClient.java:38)
> > Caused by: java.lang.ClassCastException:
> > net.idt.svp.Nomad.client.communication.BalanceEnquiryRqstInfo
> > at
> > 
> org.apache.cxf.databinding.source.NodeDataWriter.write(NodeDat
aWriter.java:52)
> > at
> > 
> org.apache.cxf.databinding.source.NodeDataWriter.write(NodeDat
aWriter.java:43)
> > at
> > 
> org.apache.cxf.jaxws.interceptors.DispatchOutDatabindingInterc
> eptor.handleMessage(DispatchOutDatabindingInterceptor.java:112)
> > ... 4 more
> > Exception in thread "main" 
> javax.xml.ws.soap.SOAPFaultException: Exception
> > occurred while marshalling Dispatch object to stream
> > at 
> org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:183)
> > at 
> org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:121)
> > at
> > 
> net.idt.svp.Nomad.client.BalanceEnquiryClient.main(BalanceEnqu
iryClient.java:38)
> > 
> > What am I doing wrong?
> > Here is my client code.
> > 
> > URL wsdlURL =  new
> > 
> URL("http://someurl:20903/webservices/services/BalanceEnquiry?wsdl";);
> > QName qName=new QName("urn:BalanceEnquiry", 
> "BalanceEnquiryService");
> > QName portName=new QName("urn:BalanceEnquiry", "BalanceEnquiry");
> > BalanceEnquiryService ss = new 
> BalanceEnquiryService(wsdlURL, qName);
> > 
> > Dispatch dispatch = ss.createDispatch(portName, JAXBContext.class ,
> > Service.Mode.PAYLOAD);
> > BalanceEnquiryRspsInfo resp= (BalanceEnquiryRspsInfo)
> > dispatch.invoke(getRequest());
> > 
> > My request and response object were generated using wsdl2java
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Dispatch-Client-%2B-JaxB-tf4717372.html#
a13485745
Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Client returns empty string!

[Liu, Jervis]

Hi, using JAX-WS Dispatch APIs should be easier than using SAAJ directly. 
Actually, the problem you ran into has been discussed in thread [1] [2]. Note, 
if you use Dispatch, make sure you set the mode to MESSAGE.  In this case it is 
very similar to using SAAJ directly, once you get back the SoapMessage object, 
it is up to you how to parse the response message from Soap body. I found 
Article [3] is very helpful to understand what kind of response you can expect 
from SOAP encoded. I would say it is unlikely that you can convert the payload 
wrapped inside Soap body to a JAXB element. For example, not sure how a 
response payload like below can be handled by JAXB:


http://schemas.xmlsoap .org/soap/encoding/"
xmlns:ns1="urn:BalanceEnquiry">


http://schemas.xmlsoap.org/soap/encoding/";
xsi:type="ns2:BalanceEnquiryRspsInfo"
xmlns:soapenc="http://schemas.xmlsoap.org/so ap/encoding/"
xmlns:ns2="http://wsvalueobj.BalanceEnquiry.prepaid.webservices.cortex.com";>
235894
IDT
3
5274421040719276
2007-09-28
134206
9.0
0.0
GBP

2007-10-18
000



This is also the reason why PAYLOAD mode might not work well with SOAP encoded, 
 CXF dispatch client wont know how to convert the content wrapped in soapbody 
to a DOMSource or JAXB element appropriately if the soap body contains more 
than one child elements.

[1]. http://www.nabble.com/Dispatch-Client-%2B-JaxB-tf4717372.html
[2]. http://www.nabble.com/empty-response-object-tf4706733.html
[3]. http://msdn2.microsoft.com/en-us/library/ms995710.aspx

Jervis

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?1? 6:42
> To: cxf-user@incubator.apache.org
> Subject: Re: Client returns empty string!
> 
> 
> Yes.  I'm doing so right now.
> 
> (Truth be told, you don't even need CXF or any other web 
> services stack
> if you use SAAJ -- it has a SOAPConnection object that will 
> do what you
> want.  But we try to keep that fact a secret so people keep using our
> product.)
> 
> Glen
> 
> Am Mittwoch, den 31.10.2007, 15:31 -0700 schrieb Bashar Jawad:
> > I found this article:
> > 
> > http://www.ibm.com/developerworks/xml/library/x-jaxmsoap/
> > 
> > However this doesn't use cxf. Is it possible to use cxf to 
> receive SOAP 
> > messages with SAAJ ?
> > 
> > Thanks,
> > 
> > Bashar
> > 
> > Glen Mazza wrote:
> > > Am Mittwoch, den 31.10.2007, 14:35 -0700 schrieb Bashar Jawad:
> > >   
> > >> I have been banging my head against the wall on this 
> problem, so I will 
> > >> really appreciate any help.  I am going to simplify the 
> problem as much 
> > >> as possible.
> > >> 
> > >
> > >   
> > >> 
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > >> xmlns="http://iiws.vmsinfo.com/WSVDMStationInfo/";> > >> 
> xsi:type="xsd:string">216.169.138.213
> > >> 
> > >   
> > >
> > > I think you're using an rpc/encoded web service (if it 
> were a phonograph
> > > record, it would be a 78), which is not JAX-WS supported. 
>  No big deal,
> > > you'll just need to use Dispatch objects and SAAJ to get 
> your service to
> > > work.  Googling a bit may help.
> > >
> > > Glen
> > >
> > >
> > >   
> > 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Gzip encoding

[Liu, Jervis]

Hi Shaw, you can configure your client side interceptors using feature. An 
example can be found from dispatch system test: 
\trunk\systests\src\test\java\org\apache\cxf\systest\dispatch\TestDispatchFeature.java
 and client-config.xml.

Cheers,
Jervis

> -Original Message-
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?3? 1:43
> To: cxf-user@incubator.apache.org
> Cc: Shaw, Richard A
> Subject: Re: Gzip encoding
> 
> 
> 
> Hmm...   not really sure how to add it to the dispatch style suff via 
> spring.   Interesting.   
> 
> That said, bus level might make sense if the interceptor was 
> updated to 
> handle the case where it's not gzip as well.   
> Basically, "Accept-Encoding" is a hint and the server may not 
> respond in 
> gzip form.   Thus, the interceptor should check the request 
> header and 
> if the headers don't say it's gzipped, skip it. 
> 
> The interceptor may also need to reset the Message.CONTENT_TYPE and 
> Message.ENCODING properties.   Not really sure though.
> 
> Dan
> 
> 
> On Friday 02 November 2007, Shaw, Richard A wrote:
> > In reply to my previous message I can see that there is an example
> > interceptor to GZIP. I've copied this but now I don't know 
> how to add
> > it to my dispatch call.
> >
> > The example adds it to the bus, but I have other services on the bus
> > which are not using GZIP.
> >
> > I've found an example that adds it to a jaxws:client but it needs a
> > serviceClass and I don't have one because I'm using the dispatch
> > interface.
> >
> > Can anybody help. Ideally I'd like to add it to my spring 
> config. But
> > if I have to add it to my code I can live with that to get 
> it working.
> >
> > Thanks
> >
> >
> > Richard Shaw
> >
> > ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤
> ø,¸¸,ø¤
> >
> > Richard Shaw
> > Technical Design Authority - Information Solutions Consultancy
> > Intelligent Transport Systems
> >
> > Atkins Highways and Transportation
> > Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW
> >
> > Tel: +44 (0) 1372 756407
> > Fax: +44 (0) 1372 740055
> > Mob: 07740 817586
> > E-mail: [EMAIL PROTECTED]
> >
> > www.atkinsglobal.com/its
> >
> > -Original Message-
> > From: Shaw, Richard A [mailto:[EMAIL PROTECTED]
> > Sent: 02 November 2007 11:23
> > To: cxf-user@incubator.apache.org
> > Subject: Gzip encoding
> >
> > I'm using the dispatch interface to request data from a web service
> > which returns the data in gzip format.
> >
> > Can CXF handle this ? I've set the Accept-Encoding to gzip 
> and can see
> > the compressed data being received (using Ethereal) but I get the
> > following error -
> >
> > org.apache.cxf.interceptor.Fault: Unable to create envelope 
> from given
> > source: at
> > 
> org.apache.cxf.jaxws.interceptors.DispatchInInterceptor.handleMessage(
> >DispatchInInterceptor.java:114) at
> > 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >rChain.java:147) at
> > 
> org.apache.cxf.jaxws.DispatchImpl.onMessage(DispatchImpl.java:259) at
> > 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleRe
> >sponse(HTTPConduit.java:1825) at
> > 
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.doClose(
> >HTTPConduit.java:1690) at
> > 
> org.apache.cxf.io.AbstractCachedOutputStream.close(AbstractCachedOutpu
> >tStream.java:114) at
> > 
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66
> >) at
> > 
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin
> >gInterceptor.handleMessage(MessageSenderInterceptor.java:62) at
> > 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
> >rChain.java:147) at
> > org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:146) at
> > org.apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.java:104) at
> > 
> com.atkinsglobal.mosaic.datafetch.DataFetchUtils.test(DataFetchUtils.j
> >ava:120) at
> > 
> com.atkinsglobal.mosaic.datafetch.PollDataFetchServer.main(PollDataFet
> >chServer.java:24) Caused by:
> > com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable to create
> > envelope from given source: at
> > 
> com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(Envelop
> >eFactory.java:114) at
> > 
> com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelopeF
> >romSource(SOAPPart1_1Impl.java:71) at
> > 
> com.sun.xml.messaging.saaj.soap.SOAPPartImpl.getEnvelope(SOAPPartImpl.
> >java:125) at
> > 
> com.sun.xml.messaging.saaj.soap.MessageImpl.getSOAPBody(MessageImpl.ja
> >va:1237) at
> > 
> org.apache.cxf.jaxws.interceptors.DispatchInInterceptor.handleMessage(
> >DispatchInInterceptor.java:89) ... 12 more
> > Caused by: javax.xml.transform.TransformerException:
> > org.xml.sax.SAXParseException: Content is not allowed in prolog. at
> > 
> org.apache.xalan.transformer.TransformerIdentityImpl.transform(Transfo
> >rmerIdentityImpl.java:501) at
> > 
> com.sun.xml.messaging.saaj.util.transform.EfficientStreamingTransforme
> >r.transfo

RE: ClientFactoryBean AbstractMethodError

[Liu, Jervis]

I probabaly should remove JAX-WS style client codes from restful_http_binding 
demo, as it constantly causes confusions. In theory, JAX-WS style client APIs 
should work with RESTful services that published using CXF HTTP binding, as 
this is symmetric to what the server side has to do to marshal/unmarshal 
request/response. But in reality, this does not work because a). This JAX-WS 
style client APIs support is not completed yet. b). I don't think there will be 
much value added by supporting JAX-WS style client APIs. This JAX-WS style 
client APIs wont work without a WSDL, most RESTful services wont have a WSDL. 
More comments about client side REST API support can be found in [1].

[1].  
http://www.nabble.com/Using-verbs-other-than-GET-from-a-RESTful-client-application-tf4628659.html

Cheers,
Jervis

> -Original Message-
> From: Todd Orr [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?5? 10:41
> To: cxf-user@incubator.apache.org
> Subject: ClientFactoryBean AbstractMethodError
> 
> 
> I have been trying to get a REST service up and running. I believe the
> server is up. However, creating the client is problematic. Using the
> following code borrowed from the bundled rest sample:
> 
> JaxWsProxyFactoryBean sf = new JaxWsProxyFactoryBean();
> sf.setServiceClass(MyServiceInterface.class);
> 
> // Turn off wrapped mode to make our xml prettier
> sf.getServiceFactory().setWrapped(false);
> 
> // Use the HTTP Binding which understands the Java Rest Annotations
> sf.getClientFactoryBean().setBindingId(HttpBindingFactory.HTTP
_BINDING_ID);
> sf.setAddress("http://localhost:8080/rest/";);
> this.service = (MyServiceInterface) sf.create();
> 
> 
> I receive the following exception:
> 
> java.lang.AbstractMethodError:
> org.apache.xerces.dom.DocumentImpl.getInputEncoding()Ljava/lan
g/String;
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
orImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMeth
odAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.ws.commons.schema.utils.DOMUtil.getInputEncoding(DO
> MUtil.java:594)
>   at 
> org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchem
> aCollection.java:348)
>   at 
> org.apache.cxf.databinding.source.AbstractDataBinding.addSchem
> aDocument(AbstractDataBinding.java:73)
>   at 
> org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding
.java:224)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.bu
> ildServiceFromClass(ReflectionServiceFactoryBean.java:293)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.in
> itializeServiceModel(ReflectionServiceFactoryBean.java:333)
>   at 
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean.cr
> eate(ReflectionServiceFactoryBean.java:151)
>   at 
> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(Ja
xWsServiceFactoryBean.java:93)
>   at 
> org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.creat
> eEndpoint(AbstractWSDLBasedEndpointFactory.java:74)
>   at 
> org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactory
Bean.java:51)
>   at 
> org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientPr
oxyFactoryBean.java:89)
>   at com.foo.bar.RestTest.injectDependencies(RestTest.java:30)
>   at 
> org.springframework.test.AbstractDependencyInjectionSpringCont
> extTests.prepareTestInstance(AbstractDependencyInjectionSpring
ContextTests.java:158)
>   at 
> org.springframework.test.AbstractSingleSpringContextTests.setU
> p(AbstractSingleSpringContextTests.java:88)
>   at junit.framework.TestCase.runBare(TestCase.java:125)
>   at 
> org.springframework.test.ConditionalTestCase.runBare(Condition
alTestCase.java:69)
>   at junit.framework.TestResult$1.protect(TestResult.java:106)
>   at junit.framework.TestResult.runProtected(TestResult.java:124)
>   at junit.framework.TestResult.run(TestResult.java:109)
>   at junit.framework.TestCase.run(TestCase.java:118)
>   at junit.framework.TestSuite.runTest(TestSuite.java:208)
>   at junit.framework.TestSuite.run(TestSuite.java:203)
>   at 
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReferen
> ce.run(JUnit3TestReference.java:130)
>   at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestEx
ecution.java:38)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTest
> s(RemoteTestRunner.java:460)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTest
> s(RemoteTestRunner.java:673)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(Rem
oteTestRunner.java:386)
>   at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(Re
moteTestRunner.java:196)
> 
> 
> I read a post regarding a similar error due to the XmlSchema version.
> However,

RE: ClientFactoryBean AbstractMethodError

[Liu, Jervis]

Glad to see you have your problem resolved. What I am suggesting is that do not 
write your RESTful service client using JAX-WS style API (eg, 
JaxWsProxyFactoryBean etc), we do not support that and have no plan to support 
it. Instead, you may find most of time you are just fine to access your RESTful 
services by using HttpURLConnection or Apache HttpClient or even a browser.

Cheers,
Jervis

> -Original Message-
> From: Todd Orr [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?6? 2:06
> To: cxf-user@incubator.apache.org
> Subject: Re: ClientFactoryBean AbstractMethodError
> 
> 
> That seems to have worked. Thanks!
> 
> On 11/5/07, Willem Jiang <[EMAIL PROTECTED]> wrote:
> > Hi ,
> >
> > Can you check xercesImpl-2.8.1.jar is in the class path of your test
> > with JUnit?
> > I can find the method
> >
> > org.apache.xerces.dom.DocumentImpl.getInputEncoding() in that jar.
> >
> > Willem.
> >
> > Todd Orr wrote:
> > > hanks. That doesn't really explain, to me, why the server 
> starts up
> > > fine when deployed but fails with the error shown when 
> run in a JUnit
> > > test. The demo is able to create a service in JUnit 
> without problem.
> > > In this particular JUnit, rather than relying on Spring 
> configuration,
> > > I was attempting to create the server myself using the 
> following code:
> > >
> > > private Server createRestServer(SessionFactory sessionFactory) {
> > >   MyServiceImpl service = new MyServiceImpl();
> > >   service.setSessionFactory(sessionFactory);
> > >
> > > JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
> > > sf.setServiceClass(MyServiceInterface.class);
> > > sf.setBindingId(HttpBindingFactory.HTTP_BINDING_ID);
> > > sf.setAddress("http://localhost:8080/rest/";);
> > > sf.getServiceFactory().setInvoker(new 
> BeanInvoker(service));
> > > sf.getServiceFactory().setWrapped(true);
> > >
> > > return sf.create();
> > > }
> > >
> > > This is almost exactly the same as the server code from 
> the demo - the
> > > code that works. However, in my example I receive the 
> stack trace from
> > > above on the sf.create() method.
> > >
> > > On 11/4/07, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> > >
> > >> I probabaly should remove JAX-WS style client codes from 
> restful_http_binding demo, as it constantly causes 
> confusions. In theory, JAX-WS style client APIs should work 
> with RESTful services that published using CXF HTTP binding, 
> as this is symmetric to what the server side has to do to 
> marshal/unmarshal request/response. But in reality, this does 
> not work because a). This JAX-WS style client APIs support is 
> not completed yet. b). I don't think there will be much value 
> added by supporting JAX-WS style client APIs. This JAX-WS 
> style client APIs wont work without a WSDL, most RESTful 
> services wont have a WSDL. More comments about client side 
> REST API support can be found in [1].
> > >>
> > >> [1].  
> http://www.nabble.com/Using-verbs-other-than-GET-from-a-RESTfu
> l-client-application-tf4628659.html
> > >>
> > >> Cheers,
> > >> Jervis
> > >>
> > >>
> > >>> -Original Message-
> > >>> From: Todd Orr [mailto:[EMAIL PROTECTED]
> > >>> Sent: 2007?11?5? 10:41
> > >>> To: cxf-user@incubator.apache.org
> > >>> Subject: ClientFactoryBean AbstractMethodError
> > >>>
> > >>>
> > >>> I have been trying to get a REST service up and 
> running. I believe the
> > >>> server is up. However, creating the client is 
> problematic. Using the
> > >>> following code borrowed from the bundled rest sample:
> > >>>
> > >>> JaxWsProxyFactoryBean sf = new JaxWsProxyFactoryBean();
> > >>> sf.setServiceClass(MyServiceInterface.class);
> > >>>
> > >>> // Turn off wrapped mode to make our xml prettier
> > >>> sf.getServiceFactory().setWrapped(false);
> > >>>
> > >>> // Use the HTTP Binding which understands the Java Rest 
> Annotations
> > >>> sf.getClientFactoryBean().setBindingId(HttpBindingFactory.HTTP
> > >>>
> > >> _BINDING_ID);
> > >>
> > >>> sf.setAddress("http://localhost:8080/rest/";);
> > >>> this.service = (

RE: Return direct XML

[Liu, Jervis]

In your case, looks like the easiest way is to use JAX-WS Provider API with XML 
Binding. You will find a bunch of different type of Provider implementations 
under system test: 
https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/provider/.
 Of course the limitation is that the input of your function has to be in XML 
format as well (can be Source/SOAPMessage/DataSource, depend on your mode and 
binding), in some cases you may find its hard to parse input from XML by 
yourself.

Cheers,
Jervis

> -Original Message-
> From: Roshan A. Punnoose [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?7? 4:08
> To: cxf-user@incubator.apache.org
> Subject: Return direct XML
> 
> 
> Hi,
> 
>  
> 
> What is the easiest way to return XML directly? For example, in my
> function, if I create XML, I want to be able to send that object
> directly back to the calling client. Is this possible?
> 
>  
> 
> Roshan
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Programmatically publishing a REST endpoint

[Liu, Jervis]

Currently there are three ways to build a RESTful service in CXF. [1] and [2] 
should give you enough information on how to use CXF HTTP binding and JAX-WS 
Dispatch/Provider to build a RESTful service. Now we have a third option - 
using JSR-311. You are very welcome to try this new feature out, any feedbacks 
would be hightly appreciated. This has not been documented yet, but I will do 
this soon. At the same time, there are couple of examples under system test 
directory [3], which hopefully will help you out. 

To answer your specific question, if you want to use CXF HTTP binding, you need 
to write your server mainline as below: 

JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
sf.setServiceClass(PeopleService.class);
sf.getServiceFactory().setWrapped(true);
sf.setBindingId(HttpBindingFactory.HTTP_BINDING_ID);
sf.setAddress("http://localhost:9001/";);

PeopleService peopleService = new PeopleServiceImpl();
sf.getServiceFactory().setInvoker(new BeanInvoker(peopleService));

Server svr = sf.create();

Your RestReviewService.class suggests that you are actually using JSR-311, in 
this case, your server main line is as below:

JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(RestReviewService.class);
//default lifecycle is per-request, change it to singleton
sf.setResourceProvider(RestReviewService.class, new 
SingletonResourceProvider());
sf.setAddress("http://localhost:9001/";);

sf.create();  


[1]. http://cwiki.apache.org/CXF20DOC/http-binding.html
[2]. 
http://cwiki.apache.org/CXF20DOC/rest-with-jax-ws-provider-and-dispatch.html
[3]. 
https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs

Hope this helps,
Jervis



> -Original Message-
> From: Tom Davies [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?8? 9:03
> To: cxf-user@incubator.apache.org
> Subject: Programmatically publishing a REST endpoint
> 
> 
> Hi,
> 
> I have a SOAP services working fine, using the servlet 
> transport. The  
> servlet is configured in web.xml, and the end point 
> publishing happens  
> in the init method of the servlet (which is a subclass of CXFServlet:
> 
> public void init(ServletConfig servletConfig) throws 
> ServletException {
>  super.init(servletConfig);
>  Bus bus = this.getBus();
>  BusFactory.setDefaultBus(bus);
>  Endpoint.publish("/review",  
> SpringContext.getComponent("rpcReviewService"));
>   Endpoint e = Endpoint.create(HTTPBinding.HTTP_BINDING,  
> SpringContext.getComponent("restReviewService"));
>  e.publish("/rest");
>  Endpoint.publish("/auth",  
> SpringContext.getComponent("rpcAuthService"));
>  }
> 
> My RestReviewService class (based on the CustomerService example)  
> looks like:
> 
> @Component("restReviewService")
> @WebService
> @UriTemplate("/review/")
> public class RestReviewService {
>  @Autowired
>  private ReviewService reviewService;
> 
>  @HttpContext
>  UriInfo uriInfo;
> 
>  @HttpMethod("GET")
>  @UriTemplate("/all/")
>  public List getAllReviews() {
>  return reviewService.getAllReviews();
>  }
> }
> 
> When I start my server the log says:
> ...
> [java] Nov 8, 2007 11:34:53 AM  
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean  
> buildServiceFromClass
>   [java] INFO: Creating Service 
> {http://rpc.spi.crucible.atlassian.com/ 
> }RestReviewServiceService from class  
> com.atlassian.crucible.spi.rpc.RestReviewService
>   [java] Nov 8, 2007 11:34:53 AM  
> org.apache.cxf.endpoint.ServerImpl initDestination
>   [java] INFO: Setting the server's publish address to be /rest
>   [java] Nov 8, 2007 11:34:53 AM  
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean  
> buildServiceFromClass
> ...
> 
> But the service endpoint seems to be another SOAP service, as when I  
> go to http://localhost:6060/foo/services/rest/review/all I get:
> 
> http://schemas.xmlsoap.org/soap/ 
> envelope/">soap:Server faultcode>No such operation: review soap:Fault>
> 
> Thanks for any tips or pointers to documentation other than 
> http://cwiki.apache.org/CXF20DOC/rest-with-jax-ws-provider-and
> -dispatch.html
> 
> I suspect I need to set the JAXRS binding for the endpoint, but I  
> don't know how to do it...
> 
> Tom
> 
> --
> ATLASSIAN - http://www.atlassian.com
> Our products help over 8,500 customers in more than 95 countries to  
> collaborate
> 
> 
> 
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Programmatically publishing a REST endpoint

[Liu, Jervis]

Here you go, a brief document on how to build RESTful services in CXF using 
JAX-RS (JSR-311): 
http://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+%28JSR-311%29

BTW,  at the moment we do not support the return of a List in JAX-RS (e.g., 
List getAllReviews() ), I am even not sure whether or not this 
should be supported. The main problem is a direct mapping from List to XML 
would result in an invalid XML as it has multiple root elements, thus can not 
be displayed on browsers. You will need a wrapper object, i.e., ReviewDataList 
getAllReviews(), where ReviewDataList is defined as:

@XmlRootElement(name = "ReviewDataList")
public class ReviewDataList {
private Collection rds;

public Collection getReviewData() {
return rds;
}

public void setReviewData(Collection r) {
this.rds= r;
}
}


Jervis

> -Original Message-----
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?8? 15:06
> To: cxf-user@incubator.apache.org
> Subject: RE: Programmatically publishing a REST endpoint
> 
> 
> Currently there are three ways to build a RESTful service in 
> CXF. [1] and [2] should give you enough information on how to 
> use CXF HTTP binding and JAX-WS Dispatch/Provider to build a 
> RESTful service. Now we have a third option - using JSR-311. 
> You are very welcome to try this new feature out, any 
> feedbacks would be hightly appreciated. This has not been 
> documented yet, but I will do this soon. At the same time, 
> there are couple of examples under system test directory [3], 
> which hopefully will help you out. 
> 
> To answer your specific question, if you want to use CXF HTTP 
> binding, you need to write your server mainline as below: 
> 
> JaxWsServerFactoryBean sf = new JaxWsServerFactoryBean();
> sf.setServiceClass(PeopleService.class);
> sf.getServiceFactory().setWrapped(true);
> sf.setBindingId(HttpBindingFactory.HTTP_BINDING_ID);
> sf.setAddress("http://localhost:9001/";);
> 
> PeopleService peopleService = new PeopleServiceImpl();
> sf.getServiceFactory().setInvoker(new BeanInvoker(peopleService));
> 
> Server svr = sf.create();
> 
> Your RestReviewService.class suggests that you are actually 
> using JSR-311, in this case, your server main line is as below:
> 
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(RestReviewService.class);
> //default lifecycle is per-request, change it to singleton
> sf.setResourceProvider(RestReviewService.class, new 
> SingletonResourceProvider());
> sf.setAddress("http://localhost:9001/";);
> 
> sf.create();  
> 
> 
> [1]. http://cwiki.apache.org/CXF20DOC/http-binding.html
> [2]. 
> http://cwiki.apache.org/CXF20DOC/rest-with-jax-ws-provider-and
> -dispatch.html
> [3]. 
> https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/
> src/test/java/org/apache/cxf/systest/jaxrs
> 
> Hope this helps,
> Jervis
> 
> 
> 
> > -Original Message-
> > From: Tom Davies [mailto:[EMAIL PROTECTED]
> > Sent: 2007?11?8? 9:03
> > To: cxf-user@incubator.apache.org
> > Subject: Programmatically publishing a REST endpoint
> > 
> > 
> > Hi,
> > 
> > I have a SOAP services working fine, using the servlet 
> > transport. The  
> > servlet is configured in web.xml, and the end point 
> > publishing happens  
> > in the init method of the servlet (which is a subclass of 
> CXFServlet:
> > 
> > public void init(ServletConfig servletConfig) throws 
> > ServletException {
> >  super.init(servletConfig);
> >  Bus bus = this.getBus();
> >  BusFactory.setDefaultBus(bus);
> >  Endpoint.publish("/review",  
> > SpringContext.getComponent("rpcReviewService"));
> > Endpoint e = Endpoint.create(HTTPBinding.HTTP_BINDING,  
> > SpringContext.getComponent("restReviewService"));
> >  e.publish("/rest");
> >  Endpoint.publish("/auth",  
> > SpringContext.getComponent("rpcAuthService"));
> >  }
> > 
> > My RestReviewService class (based on the CustomerService example)  
> > looks like:
> > 
> > @Component("restReviewService")
> > @WebService
> > @UriTemplate("/review/")
> > public class RestReviewService {
> >  @Autowired
> >  private ReviewService reviewService;
> > 
> >  @HttpContext
> >  UriInfo uriInfo;
> > 
> >  @HttpMethod("GET")
> >  @UriTemplate("/all/")
> >  public List getA

RE: Programmatically publishing a REST endpoint

[Liu, Jervis]

> -Original Message-
> From: Tom Davies [mailto:[EMAIL PROTECTED]
> Sent: 2007?11?12? 6:23
> To: cxf-user@incubator.apache.org
> Subject: Re: Programmatically publishing a REST endpoint
> 
> 
> 
> On 08/11/2007, at 7:37 PM, Liu, Jervis wrote:
> 
> > Here you go, a brief document on how to build RESTful services in  
> > CXF using JAX-RS (JSR-311): 
> http://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+%28
JSR-311%29
> >
> 
> Hi Jervis,
> 
> Thanks for the information.
> 
> One clarification: as I'm using the servlet transport, I 
> don't want to  
> set an explicit address, just a path component, so that the REST API  
> is under the URL my CXFServlet maps to.
> 
> So given that I have this code to publish my SOAP services:
> 
> public void init(ServletConfig servletConfig) throws 
> ServletException {
> super.init(servletConfig);
> Bus bus = this.getBus();
> BusFactory.setDefaultBus(bus);
> Endpoint.publish("/review",  
> SpringContext.getComponent("rpcReviewService"));
> Endpoint.publish("/auth",  
> SpringContext.getComponent("rpcAuthService"));
>   ... REST publishing goes here ...
> }
> 
> Can I use something like:
> JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
> sf.setResourceClasses(RestReviewService.class);
> //default lifecycle is per-request, change it to singleton
> sf.setResourceProvider(RestReviewService.class, new  
> SingletonResourceProvider());
> sf.setBus(bus);
>   sf.setAddress("/rest"); // will this work?
> 
> sf.create();
> 
This should work. Willem Jiang had done some work on this part recently to make 
it possible to publish an endpoint using servlet transport both from spring 
configuration and API. 

> A more general question: What are the pros and cons of using 
> CXF HTTP  
> binding vs. JSR-311 for REST?
> 

If you take a closer look into JSR-311 and CXF HTTP binding, you may find that 
they have a lot of things in common, such as the URITemplate, HTTP Method 
annotation etc. Maybe the annotation names are different, but the basic ideas 
are same. So I would say you can view JSR-311 as an evolved and more standard 
version of CXF HTTP binding. 


> Thanks again,
>Tom
> 
> --
> ATLASSIAN - http://www.atlassian.com
> Our products help over 8,500 customers in more than 95 countries to  
> collaborate
> 
> 
> 
> 
> 


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: when are interceptor chains created?

[Liu, Jervis]

Hi Glen, this applies to both client side and server side. Incoming and 
outgoing refer to inbound and outbound. If this is still not clear, on the 
client side, incoming refers to receiving response from the server, outgoing 
refers to sending request to the server.

Cheers,
Jervis

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月14日 8:42
> To: cxf-user@incubator.apache.org
> Subject: when are interceptor chains created?
> 
> Hello,
> 
> I'm slightly confused on when interceptor chains[1] are created.  The
> text gives sections on "On the incoming chains, you'll have the
> following phases" and "On the outgoing chain there are the following
> phases", but I'm unsure what incoming and outgoing refer to.
> 
> Is it:
> 
> 1.) Only with respect to the client (outgoing chain = SOAP request,
> incoming chain = SOAP Response, for a total of two chains per
> request/response).
> 
> 2.) Only with respect to the server (incoming = SOAP request, outgoing =
> SOAP Response, for a total of two chains per request/response).
> 
> 3.) Two sets of chains, one set each for client's perspective and from
> the server's:  (four chains total)
> 
> Thanks,
> Glen
> 
> [1] http://cwiki.apache.org/CXF20DOC/interceptors.html


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: when are interceptor chains created?

[Liu, Jervis]

And yes, there are four chains, the outgoing chain and the incoming chain for 
the same client can be totally different.

Jervis

> -Original Message-
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月14日 8:42
> To: cxf-user@incubator.apache.org
> Subject: when are interceptor chains created?
> 
> Hello,
> 
> I'm slightly confused on when interceptor chains[1] are created.  The
> text gives sections on "On the incoming chains, you'll have the
> following phases" and "On the outgoing chain there are the following
> phases", but I'm unsure what incoming and outgoing refer to.
> 
> Is it:
> 
> 1.) Only with respect to the client (outgoing chain = SOAP request,
> incoming chain = SOAP Response, for a total of two chains per
> request/response).
> 
> 2.) Only with respect to the server (incoming = SOAP request, outgoing =
> SOAP Response, for a total of two chains per request/response).
> 
> 3.) Two sets of chains, one set each for client's perspective and from
> the server's:  (four chains total)
> 
> Thanks,
> Glen
> 
> [1] http://cwiki.apache.org/CXF20DOC/interceptors.html


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Access to SOAPMessage object within the service implementation class

[Liu, Jervis]

Hi, You won't be able to access SOAPMessage unless you use JAX-WS provider as 
your service implementation. Another way to get around this is using SOAP 
handlers, you can simply return false in your soap handler. Let's say you 
return false in your soap handler in the inbound direction, in this case the 
incoming message will become the response and the response will be sent back to 
the client. More details can be found in JAX-WS2.0 spec section 9.3.2.1.

Cheers,
Jervis





> -Original Message-
> From: Wulff, Oliver [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月17日 20:38
> To: cxf-user@incubator.apache.org
> Subject: Access to SOAPMessage object within the service implementation
> class
> 
> Hi there
> How can I access the SOAPMessage of the request within a service
> implementation class?
> Is it also possible to update the SOAPMessage for the response within a
> service implementation class?
> Thanks
> Oliver


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Interceptors pulling values out of requests

[Liu, Jervis]

I just updated the wiki page [1], hopefully it is more clear now how to write 
and configure user interceptors. Please let me know if there is anything 
missing or still not clear on this page. I am not sure what type of parameters 
you want to access through interceptors, lets presume you want to access the 
java parameter objects that are used to invoke the SEI operations. For example, 
for an operation whose signature is "String sayHi(String input)", you may want 
to access the value of input before sayHi is invoked. In this case, basically 
what you need to do is:

1. Write an interceptor according to the instruction [1]. 

2. The java parameter objects are only available after a certain interceptor. 
To figure out exactly what phase your interceptor need to sit in, you need to 
understand what happens along the interceptor chain. Basically when the request 
comes in, it is available as an InputStream, then a StaxReader is created in 
StaxInInterceptor to read this InputStream. The flow in the interceptor chain 
keeps moving. If the incoming request is a soap message, the soap headers will 
be stripped off by some intercetors, then the soap body. The content of soap 
body will be marshaled into java objects by either JAXB data binding or Aegis 
data binding by data binding interceptors. Finally the 
ServiceInvokerInterceptor is invoked which will in turn dispatch the request to 
"sayHi". 

In your case, I believe adding your interceptor before 
ServiceInvokerInterceptor should do the trick.

3. The java parameter objects can be accessed from Message. Eg:

public class MyInterceptor extends AbstractPhaseInterceptor {   

public MyInterceptor () {
super(Phase.INVOKE);
}

public void handleMessage(final Message message) {
Object invokee = message.getContent(List.class);
if (invokee == null) {
invokee = message.getContent(Object.class);
}
.
}

} 

To understand more about CXF interceptor chain, I would suggest you do a quick 
debugging to see how the message flows along the interceptor chain. 

[1]. http://cwiki.apache.org/confluence/display/CXF20DOC/Interceptors

Cheers,
Jervis

> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月20日 3:55
> To: cxf-user@incubator.apache.org
> Subject: Interceptors pulling values out of requests
> 
> Hello,
> 
> I'm writing a webservice with Aegis Bindings and would like to write an
> interceptor to collect certain information - eg I want to look for
> specific values in the incoming XML (the paramter values to the
> functions in the SEI) - though I have followed some of the examples we
> can't quite get at what we need.
> 
> Has anyone tried this before?
> 
> What is the best phase to use to get this info?
> 
> What objects can I grab and traverse to get me what I need?
> 
> Thanks!


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Interceptors pulling values out of requests

[Liu, Jervis]

What does your SEI operation look like? Sth like "void getChannel(Session s, 
long channelD)" ? This should work. The List object you get by using "List body 
= msg.getContent(List.class)" contains Session object and the channelD, they 
are ordered, i.e., body.get(0) always return the Session object and body.get(1) 
returns whatever the second parameter of is. 

If it does not work, most likely it is because you did not put your interceptor 
at the right position: when your interceptor is invoked, the List has not been 
populated yet. You may want to have a quick debug to see if your interceptor is 
invoked right before ServiceInvokerInterceptor.

BTW, you get can method name using following code (take a look at 
org.apache.cxf.interceptor. ServiceInvokerInterceptor and 
org.apache.cxf.service.invoker. AbstractInvoker)

public class MyInterceptor extends AbstractPhaseInterceptor {
  public MyInterceptor () {
super(Phase.INVOKE);
addBefore(ServiceInvokerInterceptor.class.getName());  
  }

  public void handleMessage(final Message message) {
final Exchange exchange = message.getExchange();
BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
MethodDispatcher md = (MethodDispatcher) 
exchange.get(Service.class).get(MethodDispatcher.class.getName());
Method m = md.getMethod(bop);
.
  }

}

Hope this helps,
Jervis


> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月21日 0:41
> To: cxf-user@incubator.apache.org; Liu, Jervis
> Subject: RE: Interceptors pulling values out of requests
> 
> 
> Thank you for the information.  It isn't quite solving my issue though.
> 
> What I am trying to do is to log the values in my request stream.  My
> request looks like this:
> 
> 
> http://www.w3.org/2001/XMLSchema-instance";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> 
> 
> 
> 123
> ABC123DEF456
> 
> 1
> 
> 
> 
> 
> 
> The inputs are a custom session class I created, and a long
> 
> I want my interceptor to get out
> 
> -The name of the service
> -The name of the method
> -The session as an object
> -The channel id as an object
> 
> I want to be able to do this all in one interceptor, and I do not want to make
> it a high
> Impact operation as it would be done in every call and written to a log.  I
> tried your example and the body comes through as null always.
> 
> I have been doing this:
> 
> List body = msg.getContent(List.class);
> mySession sess = (mySession)body.get(0);
> 
> 
> Which is not ideal.
> 
> I would like to access the input generically - in so much that I want to pull
> named parameters from a variety of different calls (some called channelId,
> some userId, etc) and I am looking to be able to either sniff for these items
> trivially (they are not always in there) if possible.  There will always be a
> mySession type object that has two fields in it, but I don't know if it will
> always be first.
> 
> So, with this in mind, can you provide more guidence.  I am doing this
> currently in the invoke phase.
> 
> Thanks!
> 
> -Tony
> 
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 12:36 AM
> To: cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
> 
> I just updated the wiki page [1], hopefully it is more clear now how to write
> and configure user interceptors. Please let me know if there is anything
> missing or still not clear on this page. I am not sure what type of parameters
> you want to access through interceptors, lets presume you want to access
> the java parameter objects that are used to invoke the SEI operations. For
> example, for an operation whose signature is "String sayHi(String input)",
> you may want to access the value of input before sayHi is invoked. In this
> case, basically what you need to do is:
> 
> 1. Write an interceptor according to the instruction [1].
> 
> 2. The java parameter objects are only available after a certain interceptor.
> To figure out exactly what phase your interceptor need to sit in, you need to
> understand what happens along the interceptor chain. Basically when the
> request comes in, it is available as an InputStream, then a StaxReader is
> created in StaxInInterceptor to read this InputStream. The flow in the
> interceptor chain keeps moving. If the incoming request is a soap message,
> the soap headers will be stripped off by some intercetors, then the soap
> body. The content of soap body will be marshaled into java objects by either
> JAXB data bin

RE: Interceptors pulling values out of requests

[Liu, Jervis]

Did you really mean the names of parameters or what you want to get is instead 
the value of incoming parameters? If it is the later, I would say it is only 
possible to get the parameter values after the data binding marshaling stage. 
The exact point various depending on the protocol binding (eg, SOAP binding or 
XML binding etc) and data binding being used. The safest bet to make is before 
the ServiceInvokerInterceptor. If it is the former, normally a list of 
parameter names is available as soon as the name of the method to invoke has 
been determined, as you can always get parameter names using reflection from 
the Method object. Unfortunately to know exactly when this happens is more 
complex than knowing parameter values. If you do a search for 
"put(BindingOperationInfo.class" throughout the CXF workspace, you may find 
what interceptors are responsible for determining which method to dispatch to 
based on different criteria (eg, RPC or Doc lit wrapped or REST HTTP binding..).

Cheers,
Jervis
 

> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月21日 22:19
> To: Liu, Jervis; cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
> 
> This has nudged me along, thanks. =)
> 
> The only question I have remaining is, is there a way to get a list at any 
> point
> that actually has the paramter names?  Basically a map.  Ideally I would
> like to be able to, for any present or future function call, to get the named
> paramters so I could drop those directly into the log.
> 
> Thanks for your help!
> 
> -Tony
> 
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 20, 2007 10:00 PM
> To: Vespa, Anthony J; cxf-user@incubator.apache.org
> Subject: RE: Interceptors pulling values out of requests
> 
> What does your SEI operation look like? Sth like "void getChannel(Session s,
> long channelD)" ? This should work. The List object you get by using "List
> body = msg.getContent(List.class)" contains Session object and the channelD,
> they are ordered, i.e., body.get(0) always return the Session object and
> body.get(1) returns whatever the second parameter of is.
> 
> If it does not work, most likely it is because you did not put your 
> interceptor
> at the right position: when your interceptor is invoked, the List has not been
> populated yet. You may want to have a quick debug to see if your
> interceptor is invoked right before ServiceInvokerInterceptor.
> 
> BTW, you get can method name using following code (take a look at
> org.apache.cxf.interceptor. ServiceInvokerInterceptor and
> org.apache.cxf.service.invoker. AbstractInvoker)
> 
> public class MyInterceptor extends AbstractPhaseInterceptor {
>   public MyInterceptor () {
> super(Phase.INVOKE);
> addBefore(ServiceInvokerInterceptor.class.getName());
>   }
> 
>   public void handleMessage(final Message message) {
> final Exchange exchange = message.getExchange();
> BindingOperationInfo bop = exchange.get(BindingOperationInfo.class);
> MethodDispatcher md = (MethodDispatcher)
> exchange.get(Service.class).get(MethodDispatcher.class.getName());
> Method m = md.getMethod(bop);
> .
>   }
> 
> }
> 
> Hope this helps,
> Jervis
> 
> 
> > -Original Message-
> > From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> > Sent: 2007年11月21日 0:41
> > To: cxf-user@incubator.apache.org; Liu, Jervis
> > Subject: RE: Interceptors pulling values out of requests
> >
> >
> > Thank you for the information.  It isn't quite solving my issue though.
> >
> > What I am trying to do is to log the values in my request stream.  My
> > request looks like this:
> >
> > 
> >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
> > 
> > 
> > 
> > 123
> > ABC123DEF456
> > 
> > 1
> > 
> > 
> > 
> >
> >
> > The inputs are a custom session class I created, and a long
> >
> > I want my interceptor to get out
> >
> > -The name of the service
> > -The name of the method
> > -The session as an object
> > -The channel id as an object
> >
> > I want to be able to do this all in one interceptor, and I do not want to
> make
> > it a high
> > Impact operation as it would be done in every call and written to a log.  I
> > tried your example and the body comes through as null always.
> >
> > I have been doing this:
&g

RE: How to get wsdl for java_first_jaxws on Tomcat

[Liu, Jervis]

All CXF demos can be deployed into a Servlet container. Please refer to samples 
directory README for building demos in a servlet container. 

Cheers,
Jervis

> -Original Message-
> From: Bruce Z [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月23日 1:01
> To: cxf-user@incubator.apache.org
> Subject: How to get wsdl for java_first_jaxws on Tomcat
> 
> Hi Guys,
> I deployed java_first_jaxws from cxf-2.0.3\samples to Tomcat using "ant
> deploy-tomcat", and helloworld.war is deployed to my Tomcat webapp
> folder.
> However, when I tried to get it's wsdl from by browser using:
>   http://localhost:8080/helloworld/services/helloWorld?WSDL
> from Tomcat console I got:
>   WARNING: Can't find the the request for
> http://localhost:8080/helloworld/services/HelloWorld's Observer
> 
> After I put cxf-servlet.xml to helloworld\WEB-INF folder, I got the wsdl.
> 
> Do I need this cxf-servlet.xml to get it work?
> If this file is mandatory, then why it's not included in this
> java_first_jaxws sample?
> 
> Any feedback is appreciated. Thanks.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: what would be the best place to introduce xslt transformer for response message

[Liu, Jervis]

I presume you are using SOAP binding. The best place to look at is the 
SAAJOutInterceptor . What this interceptor does is very similar to what you 
want to achieve. SAAJOutInterceptor firstly replaces the output stream that 
writes the output to socket with its own output stream that writes output to a 
DOM tree. At the SAAJOutEndingInterceptor, once all interceptors that may have 
impacts on the SOAP Message have finished their job, the DOM is made available 
for access. What you need to do is in your own XSLTInterceptor, you replace the 
original output stream with a cached output stream (you can use 
org.apache.cxf.io. CachedOutputStream), then at your XSLTEndingInterceptro, do 
an XSLT transformation then write the transformed result back to the original 
output XSLTInterceptro stream.

Cheers,
Jervis



> -Original Message-
> From: mule1 [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月24日 1:46
> To: cxf-user@incubator.apache.org
> Subject: Re: what would be the best place to introduce xslt transformer for
> response message
> 
> 
> yes after the response XML is geneated, but before it is sent out.
> 
> --
> View this message in context:
> http://www.nabble.com/what-would-be-the-best-place-to-introduce-xslt-tr
> ansformer-for-response-message-tf4862565.html#a13916324
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Throwing faults from within an Interceptor

[Liu, Jervis]

Hi, it is possible to throw a checked Exception from CXF interceptors. Make 
sure the exception thrown from your interceptor is declared as an exception on 
the operation being invoked, otherwise this exception will not be recognized as 
a checked Exception. Also was the MyFault class generated by wsdltojava? does 
it have the WebFault annotation? The checked exception is unmarshalled by 
WebFaultOutInterceptor and its super class FaultOutInterceptor. If the 
exception is not recognized as checked exception by WebFaultOutInterceptor, the 
exception will be handled by the default protocol binding fault interceptors 
such as Soap11FaultOutInterceptor and Soap12FaultOutInterceptor. Take a look 
into WebFaultOutInterceptor. handleMessage(), the code might tell you why 
WebFaultOutInterceptor did not recognize your exception as a checked exception.

Let me know if you have any further questions,

Jervis

> -Original Message-
> From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月23日 17:56
> To: cxf-user@incubator.apache.org
> Subject: Throwing faults from within an Interceptor
> 
> I have a WSDL that defines MyFault and all of my operations can
> potentially throw this fault. This fault has some custom elements and
> stuff, so it is not an ordinary SoapFault, and it got its own
> Exception class when I generated my Java code.
> 
> When I throw this fault from within an operation in my WebServiceImpl
> class, all of the custom cruft I put in this fault gets marshalled
> correctly.
> 
> However, I also have an Interceptor (that operates in the
> Phase.PRE_PROTOCOL phase) that want to throw faults as well, and
> preferably faults defined in my WSDL. So in the Interceptors
> handleMessage() I do something like this:
> 
> throw new Fault(new MyFault("Bad stuff"));
> 
> When I do this, I only get an ordinary soap fault with a "Bad stuff"
> fault string, but all of the things that are custom to the MyFault
> dosn't get marshalled properly.
> 
> So, is there any way that I can remedy this? Can I make an interceptor
> throw a properly marshalled custom soap fault?
> 
> CXF version 2.0.3.
> 
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Throwing faults from within an Interceptor

[Liu, Jervis]

> -Original Message-
> From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月26日 18:36
> To: cxf-user@incubator.apache.org
> Subject: Re: Throwing faults from within an Interceptor
> 
> Hello Jervis.
> 
> > Make sure the exception thrown from your interceptor is declared as an
> exception on the operation being invoked
> 
> It is. It is declared to be thrown in the WSDL and on my implementation
> methods.
> 
> > was the MyFault class generated by wsdltojava? does it have the WebFault
> annotation?
> 
> Yes and yes.
> 
> > Take a look into WebFaultOutInterceptor. handleMessage(), the code might
> tell you why WebFaultOutInterceptor did not recognize your exception as a
> checked exception.
> 
> Looks like it should work, but I can't help thinking that it might be
> because my interceptor runs PRE_PROTOCOL. Are we certain that faults
> always go through this WebFaultOutInterceptor?
> 

It should, if you are using JAX-WS frontend. Where your interceptor sits does 
not really matter, as when the exception is thrown from the outbound 
interceptor chain, CXF will start a new interceptor chain to deal with 
exceptions (fault out interceptor chain). Can you set your log level to FINE to 
see what interceptors you have in your fault out chain. 

Thanks,
Jervis

> 
> 2007/11/26, Liu, Jervis <[EMAIL PROTECTED]>:
> > Hi, it is possible to throw a checked Exception from CXF interceptors. Make
> sure the exception thrown from your interceptor is declared as an exception
> on the operation being invoked, otherwise this exception will not be
> recognized as a checked Exception. Also was the MyFault class generated by
> wsdltojava? does it have the WebFault annotation? The checked exception is
> unmarshalled by WebFaultOutInterceptor and its super class
> FaultOutInterceptor. If the exception is not recognized as checked exception
> by WebFaultOutInterceptor, the exception will be handled by the default
> protocol binding fault interceptors such as Soap11FaultOutInterceptor and
> Soap12FaultOutInterceptor. Take a look into WebFaultOutInterceptor.
> handleMessage(), the code might tell you why WebFaultOutInterceptor did
> not recognize your exception as a checked exception.
> >
> > Let me know if you have any further questions,
> >
> > Jervis
> >
> > > -Original Message-
> > > From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> > > Sent: 2007年11月23日 17:56
> > > To: cxf-user@incubator.apache.org
> > > Subject: Throwing faults from within an Interceptor
> > >
> > > I have a WSDL that defines MyFault and all of my operations can
> > > potentially throw this fault. This fault has some custom elements and
> > > stuff, so it is not an ordinary SoapFault, and it got its own
> > > Exception class when I generated my Java code.
> > >
> > > When I throw this fault from within an operation in my WebServiceImpl
> > > class, all of the custom cruft I put in this fault gets marshalled
> > > correctly.
> > >
> > > However, I also have an Interceptor (that operates in the
> > > Phase.PRE_PROTOCOL phase) that want to throw faults as well, and
> > > preferably faults defined in my WSDL. So in the Interceptors
> > > handleMessage() I do something like this:
> > >
> > > throw new Fault(new MyFault("Bad stuff"));
> > >
> > > When I do this, I only get an ordinary soap fault with a "Bad stuff"
> > > fault string, but all of the things that are custom to the MyFault
> > > dosn't get marshalled properly.
> > >
> > > So, is there any way that I can remedy this? Can I make an interceptor
> > > throw a properly marshalled custom soap fault?
> > >
> > > CXF version 2.0.3.
> > >
> > > --
> > > Venlig hilsen / Kind regards,
> > > Christian Vest Hansen.
> >
> > 
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> >
> 
> 
> --
> Venlig hilsen / Kind regards,
> Christian Vest Hansen.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: what would be the best place to introduce xslt transformer for response message

[Liu, Jervis]

Here you go. It looks like below (roughly):

import java.io.IOException;
import java.io.OutputStream;

import javax.xml.transform.Transformer;
import javax.xml.transform.stream.StreamResult;
import javax.xml.transform.stream.StreamSource;

import org.apache.cxf.binding.soap.SoapMessage;
import org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.io.CachedOutputStream;
import org.apache.cxf.phase.Phase;


public class XSLTOutInterceptor extends AbstractSoapInterceptor {
private OutputStream originalOs;

public XSLTOutInterceptor() {
super(Phase.PRE_PROTOCOL);
}

public void handleMessage(SoapMessage message) throws Fault {
boolean isOutbound = false;
isOutbound = message == message.getExchange().getOutMessage()
   || message == message.getExchange().getOutFaultMessage();

if (isOutbound) {
//replace the original output stream with our own outputstream,
//so that the output can be cached for xslt transformation, 
otherwise
//the output might be flushed to socket before xslt.
originalOs = message.getContent(OutputStream.class);
CachedOutputStream cos = new CachedOutputStream();
message.setContent(OutputStream.class, cos);

// Add an ending interceptor to read the cached output and do xslt
message.getInterceptorChain().add(new XSLTOutEndingInterceptor());
}
}

public class XSLTOutEndingInterceptor extends AbstractSoapInterceptor {
public XSLTOutEndingInterceptor() {
super(Phase.PRE_PROTOCOL_ENDING);
}

public void handleMessage(SoapMessage message) throws Fault {
try {
CachedOutputStream cos = 
(CachedOutputStream)message.getContent(OutputStream.class);
//the output is cached in CachedOutputStream, now lets do xslt. 
   
Transformer trans =m ...  

// write the transformed result back to the original output 
stream 
trans.transform(new StreamSource(cos.getInputStream()), new 
StreamResult(originalOs));

//set the original output stream back
message.setContent(OutputStream.class, originalOs);
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
}
}
> -Original Message-
> From: mule1 [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月26日 22:29
> To: cxf-user@incubator.apache.org
> Subject: RE: what would be the best place to introduce xslt transformer for
> response message
> 
> 
> Hello,
> 
> I am not clear exactly what you said. I looked at the SAAJOutInterceptor,
> but didn't clearly understand how I can get the message content - either
> bytes or something that I can use to tranform with an xslt transfomer. If
> possible, can you provide me some sample lines of code? Thanks.
> --
> View this message in context:
> http://www.nabble.com/what-would-be-the-best-place-to-introduce-xslt-tr
> ansformer-for-response-message-tf4862565.html#a13950419
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Throwing faults from within an Interceptor

[Liu, Jervis]

HttpServlet.service(HttpServlet.java:803)
>   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:290)
>   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:206)
>   at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.jav
> a:96)
>   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:235)
>   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:206)
>   at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> lve.java:230)
>   at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:175)
>   at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAsso
> ciationValve.java:179)
>   at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.ja
> va:84)
>   at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :128)
>   at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
> 04)
>   at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedCo
> nnectionValve.java:156)
>   at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j
> ava:109)
>   at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 41)
>   at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
> 4)
>   at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:580)
>   at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>   at java.lang.Thread.run(Thread.java:613)
> 09:11:54,691 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> [EMAIL PROTECTED]
> 09:11:54,695 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain add
> FINE: Adding interceptor
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndin
> [EMAIL PROTECTED]
> to phase write-ending
> 09:11:54,695 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain outputChainToLog
> FINE: Chain [EMAIL PROTECTED] was
> modified. Current flow:
>   prepare-send [MessageSenderInterceptor]
>   pre-stream [StaxOutInterceptor]
>   pre-protocol [SOAPHandlerFaultOutInterceptor, WebFaultOutInterceptor]
>   write [SoapOutInterceptor]
>   pre-marshal [LogicalHandlerFaultOutInterceptor]
>   marshal [Soap11FaultOutInterceptor]
>   write-ending [SoapOutEndingInterceptor]
>   pre-stream-ending [StaxOutEndingInterceptor]
>   prepare-send-ending [MessageSenderEndingInterceptor]
> 09:11:54,695 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> [EMAIL PROTECTED]
> 24f7
> 09:11:54,695 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> [EMAIL PROTECTED]
> d
> 09:11:54,697 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndin
> [EMAIL PROTECTED]
> 09:11:54,697 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> org.apache.cxf.interceptor.StaxOutInterceptor$StaxOutEndingInterceptor@
> 1b48a
> 09:11:54,697 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> FINE: Invoking handleMessage on interceptor
> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndin
> [EMAIL PROTECTED]
> 09:11:54,704 ERROR [STDERR] Nov 27, 2007 9:11:54 AM
> org.apache.cxf.transport.servlet.ServletDestination doMessage
> FINE: Finished servicing http request on thread:
> Thread[http-127.0.0.1-8080-1,5,jboss]
> 
> 
> 
> 
> 2007/11/27, Liu, Jervis <[EMAIL PROTECTED]>:
> >
> >
> > > -Original Message-
> > > From: Christian Vest Hansen [mailto:[EMAIL PROTECTED]
> > > Sent: 2007年11月26日 18:36
> > > To: cxf-user@incubator.apache.org
> > > Subject: Re: Throwing faults from within an Interceptor
> > >
> > > Hello Jervis.
> > >
> > > > Make sure the exception thrown from your interceptor is declared as
> an
> >

RE: Custom Fault in Interceptor

[Liu, Jervis]

See this email thread:

http://www.nabble.com/Throwing-faults-from-within-an-Interceptor-tf4860623.html


> -Original Message-
> From: Mustafa Egilmezbilek [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月27日 17:20
> To: cxf-user@incubator.apache.org
> Subject: Custom Fault in Interceptor
> 
> Hello,
> 
> Is it possible to generate a custom fault in an interceptor and informing
> client about the fault ? In other words we have a security interceptor where
> we check rights for the services, if there is no right for the called
> service we want to generate a fault with a meaningful message and send it
> back to the client. We wanted to do this in one place, in the interceptor ,
> before any service gets called.
> 
> Thanks
> 
> Mustafa


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: differences between Interceptors and Handlers

[Liu, Jervis]

CXF interceptor API is the core of CXF runtime to process message flows, 
internally JAX-WS handlers are implemented as CXF interceptors. If you want to 
stick to the spec, you would avoid using CXF interceptors directly if possible. 
However there are circumstances that CXF interceptors give you more flexibility 
and better performance. One concrete example is writing a security interceptor 
to check the permission based on information in soap headers, this can be done 
using JAX-WS SOAP handlers or using CXF interceptors. Most CXF interceptors are 
STAX based designed to achieve smaller footprint, but JAX-WS handlers (eg, SOAP 
handlers) require creating DOM tree in the memory which definitely has impact 
on the performance.

Cheers,
Jervis

> -Original Message-
> From: Davide Gesino [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月28日 1:25
> To: cxf-user@incubator.apache.org
> Subject: differences between Interceptors and Handlers
> 
> 
> what is the differences between a CXF interceptor and a JAX-WS
> LogicalHandler
> (an implementation of javax.xml.ws.handler.LogicalHandler)???
> I guess the functionality is the same, but the usage is different.
> Can I use an approach in which I have both a series of intercetpors
> (configured with Spring) and and Handler Chain defined in a
> handler-chain.xml file???
> 
> Thanks
> 
> Davide
> --
> View this message in context:
> http://www.nabble.com/differences-between-Interceptors-and-Handlers-tf
> 4883199.html#a13975552
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Empty string namespace mapping with JSON and HTTP Post

[Liu, Jervis]

> -Original Message-
> From: mgibble [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月28日 4:29
> To: cxf-user@incubator.apache.org
> Subject: Empty string namespace mapping with JSON and HTTP Post
> 
> 
> I am using the restful_http_binding sample and I have changed the following
> lines:
> 
> // Set up the JSON StAX implementation
> Map nstojns = new HashMap();
> nstojns.put("http://customer.acme.com";, "acme");
> 
> to:
> 
> // Set up the JSON StAX implementation
> Map nstojns = new HashMap();
> nstojns.put("http://customer.acme.com";, "");
> 
> I do an HTTP Post according to the README using wget with the following
> add.json file:
> 
> {
>   "Customer" : {
> "name" : "Jim Bob"
>   }
> }
> 
> I would have thought that this would have worked, but the Customer
> parameter
> of the addCustomer method is not populated with any data.  However, if I
> change the add.json file to:
> 
> {
>   ".Customer" : {
> ".name" : "Jim Bob"
>   }
> }
> 
> the Customer parameter is populated appropriately.  I would have thought
> that with the mapping of "customer.acme.com" to "" that my original JSON
> would have worked and not required a period ('.') before each field name.
> Am I misunderstanding or is this a bug?  If so, is there a way that I can
> achieve the functionality that I desire?

This is expected behavior. CXF HTTP binding is using Jettison to do the 
JSON/XML mappings. [1] explaines how the default mapping works. You can also 
try the BadgerFish convention. 

[1]. http://jettison.codehaus.org/User%27s+Guide

> 
> Thanks.
> --
> View this message in context:
> http://www.nabble.com/Empty-string-namespace-mapping-with-JSON-and-
> HTTP-Post-tf4884221.html#a13979132
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: restful_jaxrs sample

[Liu, Jervis]

> -Original Message-
> From: Eric Le Goff [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月28日 17:26
> To: cxf-user@incubator.apache.org
> Subject: restful_jaxrs sample
> 
> I was trying to understand to jaxrs frontend provided by CXF and the
> restful_jaxrs demo helped a lot.
> 
> Then I tried to write my own demo using the following ressource class :
> 
> 
> @javax.ws.rs.UriTemplate("/helloworld/{section}")
> public class HelloWorldRessource {
> 
> @javax.ws.rs.HttpMethod("GET")
> @javax.ws.rs.UriTemplate("/{id}")
> public String findBySectionAndId(@javax.ws.rs.UriParam("section")
> String section, @javax.ws.rs.UriParam("id")
> int id) {
> return "Hello World - section is " + section + ", id is " + id + "\n";
> }
> 
> }
> ===
> 
> 
> If I hit the following url :  http://localhost:9000/helloworld/main/23
> I get
> 
> java.lang.NullPointerException
> 
> 
> as a response.
> 
> Here is the stack from the console :
> 
> [java] Nov 28, 2007 10:01:47 AM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
>  [java] INFO: Interceptor has thrown exception, unwinding now
>  [java] java.lang.NullPointerException
>  [java]   at
> org.apache.cxf.jaxrs.interceptor.JAXRSDispatchInterceptor.handleMessage(J
> AXRSDispatchInterceptor.java:101)
>  [java]   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
>  [java]   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> Observer.java:74)
>  [java]   at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
> tyHTTPDestination.java:284)
>  [java]   at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHT
> TPDestination.java:240)
>  [java]   at
> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHand
> ler.java:54)
>  [java]   at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722)
>  [java]   at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandler
> Collection.java:206)
>  [java]   at
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
>  [java]   at org.mortbay.jetty.Server.handle(Server.java:324)
> [...]
> 
> 
> After a look at the source code, the class
> org.apache.cxf.jaxrs.interceptor.JAXRSDispatchInterceptor doesn't
> throw a Fault in its handleMessage method when no
> OperationResourceInfo  could be found
> (the line is actually commented )
> 
> [...]
> OperationResourceInfo ori = findTargetResource(resources, path,
> httpMethod, values);
> 
> if (ori == null) {
> //throw new Fault(new
> org.apache.cxf.common.i18n.Message("NO_OP", BUNDLE, method, path));
> }
> [...]
> 
> So my questions are :
> 
> - Why is the handleMessage() method not  controlling whether the
> findTargetResource() returns null and give the newbie user like me an
> explicit explanation of the problem  ? ;)

There is still a lot of on-going work on the JAX-RS frontend. I started the 
exception part, but have not got this finished yet. See JIRA: 
http://issues.apache.org/jira/browse/CXF-1012


> - Why in my specific demo  the findTargetResource had returned null ?
> (I guess I will have to investigate with a step by step debug) ?
> 

I believe this is because you don’t have following lines in your demo:

//FIXME: wont work if remove this method, has to set hasSubResource to true
@UriTemplate("/anyURLWilldo")
public String anyMethodNameWillDo() {
return null;
}

Actually this is a bug, just have not found time to fix it. Basically at the 
moment you need to have a resource method only marked with @UriTemplate (no 
@HttpMethod("") annotation). This tells jax-rs runtime this resource class has 
subResources. I hope I can have these hacks fixed next week.

> 
> In the restful_jaxrs examples (CustomerService class), we have the use
> of a JAXBElementProvider and of a JSONProvider.
> I wonder if my above problem is not related to a missing
> EntityProvider implementation since my method is returning a String ?
> 
String type can be handled by JAX-RS runtime by default. 

> Thanks for your help
> 
> 
> 
> 
> 
> --
> Eric Le Goff


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: restful_jaxrs sample

[Liu, Jervis]

> -Original Message-
> From: Eric Le Goff [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月28日 20:31
> To: cxf-user@incubator.apache.org
> Subject: Re: restful_jaxrs sample
> 
> On Nov 28, 2007 10:53 AM, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> >
> > I believe this is because you don't have following lines in your demo:
> >
> > //FIXME: wont work if remove this method, has to set
> hasSubResource to true
> > @UriTemplate("/anyURLWilldo")
> > public String anyMethodNameWillDo() {
> > return null;
> > }
> 
> DONE
> 
> >
> > Actually this is a bug, just have not found time to fix it. Basically at the
> moment you need to have a resource method only marked with
> @UriTemplate (no @HttpMethod("") annotation). This tells jax-rs
> runtime this resource class has subResources. I hope I can have these hacks
> fixed next week.
> >
> 
> Cool I will check it when it is done
> 
> > String type can be handled by JAX-RS runtime by default.
> 
> Now my demo class looks like
> 
> =
> @javax.ws.rs.UriTemplate("/helloworld/")
> public class HelloWorldRessource {
> 
>@javax.ws.rs.HttpMethod("GET")
>@javax.ws.rs.UriTemplate("{section}/{id}")
>public String findBySectionAndId(@javax.ws.rs.UriParam("section")
>String section, @javax.ws.rs.UriParam("id")
>String id) {
>return "Hello World - section is " + section + ", id is " + id + "\n";
>}
> 
> 
>//FIXME: wont work if remove this method, has to set hasSubResource
> to true
>@UriTemplate("/foo")
>public String foobar() {
>return null;
>}
> }
> ==
> 
> FWIW I had to change type of the "Id" parameter from an int to a
> String not to throw a IllegalArgumentException
> 

This is a bug. I've filed JIRA https://issues.apache.org/jira/browse/CXF-1240 
for this. 

> Still my response is a NPE
> but the stack trace on console is a bit different :
> 
> <
> java] java.lang.NullPointerException
> [java] at
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRS
> OutInterceptor.java:94)
> [java] at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
> [java] at
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
> ingChainInterceptor.java:74)
> [java] at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
> [java] at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> Observer.java:74)
> [java] at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
> tyHTTPDestination.java:284)
> [java] at
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHT
> TPDestination.java:240)
> [...]
> 
> 
> >
> 
> By looking at the code, it shows that in
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage()
> method, the provider variable is set to null
> 
> <
> [...]
>  EntityProvider provider =
> ((ProviderFactoryImpl)ProviderFactory.getInstance())
>.createEntityProvider(targetType, methodMimeTypes,
> false);   ///  < getting a null provider here !!!
> 
>try {
>if (!"*/*".equals(methodMimeTypes[0])) {
>message.put(Message.CONTENT_TYPE,
> methodMimeTypes[0]);
>}
> 
>provider.writeTo(responseObj, null, null, out);
> [...]
> >
> 
> 
> the
> org.apache.cxf.jaxrs.provider.ProviderFactoryImpl.createEntityProvider(Clas
> s
> type, String[] requestedMineTypes, boolean isConsumeMime)  returns
> null because the test
> 
> <===
> [...]
> if (matchMineTypes(supportedMimeTypes, requestedMineTypes) &&
> ep.supports(type)) {
>return ep;
>}
> [...]
> ===>
> 
> always fails.
> 
> Actually the "ep.supports(type) " is trying to check if my method
> return type (java.lang.String) has been annotated with @XmlRootElement
> which is of course never true...
> 
> What could I be missing here ?
> 

Bug. JIRA https://issues.apache.org/jira/browse/CXF-1240.

> --
> Eric Le Goff


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: restful_jaxrs sample

[Liu, Jervis]

Fixed. To return a String using text/plain content type, you need a 
@ProduceMime annotation as below:

@HttpMethod("GET")
@UriTemplate("/booknames/{bookId}/")
@ProduceMime("text/plain")
public String getBookName(@UriParam("bookId") int id) throws 
BookNotFoundFault {
...
}

> -----Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007年11月29日 11:48
> To: cxf-user@incubator.apache.org
> Subject: RE: restful_jaxrs sample
> 
> 
> 
> > -Original Message-
> > From: Eric Le Goff [mailto:[EMAIL PROTECTED]
> > Sent: 2007年11月28日 20:31
> > To: cxf-user@incubator.apache.org
> > Subject: Re: restful_jaxrs sample
> >
> > On Nov 28, 2007 10:53 AM, Liu, Jervis <[EMAIL PROTECTED]> wrote:
> > >
> > > I believe this is because you don't have following lines in your demo:
> > >
> > > //FIXME: wont work if remove this method, has to set
> > hasSubResource to true
> > > @UriTemplate("/anyURLWilldo")
> > > public String anyMethodNameWillDo() {
> > > return null;
> > > }
> >
> > DONE
> >
> > >
> > > Actually this is a bug, just have not found time to fix it. Basically at 
> > > the
> > moment you need to have a resource method only marked with
> > @UriTemplate (no @HttpMethod("") annotation). This tells jax-rs
> > runtime this resource class has subResources. I hope I can have these
> hacks
> > fixed next week.
> > >
> >
> > Cool I will check it when it is done
> >
> > > String type can be handled by JAX-RS runtime by default.
> >
> > Now my demo class looks like
> >
> > =
> > @javax.ws.rs.UriTemplate("/helloworld/")
> > public class HelloWorldRessource {
> >
> >@javax.ws.rs.HttpMethod("GET")
> >@javax.ws.rs.UriTemplate("{section}/{id}")
> >public String findBySectionAndId(@javax.ws.rs.UriParam("section")
> >String section, @javax.ws.rs.UriParam("id")
> >String id) {
> >return "Hello World - section is " + section + ", id is " + id + 
> > "\n";
> >}
> >
> >
> >//FIXME: wont work if remove this method, has to set hasSubResource
> > to true
> >@UriTemplate("/foo")
> >public String foobar() {
> >return null;
> >}
> > }
> > ==
> >
> > FWIW I had to change type of the "Id" parameter from an int to a
> > String not to throw a IllegalArgumentException
> >
> 
> This is a bug. I've filed JIRA https://issues.apache.org/jira/browse/CXF-1240
> for this.
> 
> > Still my response is a NPE
> > but the stack trace on console is a bit different :
> >
> > <
> > java] java.lang.NullPointerException
> > [java] at
> >
> org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRS
> > OutInterceptor.java:94)
> > [java] at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> > hain.java:207)
> > [java] at
> >
> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
> > ingChainInterceptor.java:74)
> > [java] at
> >
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> > hain.java:207)
> > [java] at
> >
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> > Observer.java:74)
> > [java] at
> >
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(Jet
> > tyHTTPDestination.java:284)
> > [java] at
> >
> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHT
> > TPDestination.java:240)
> > [...]
> >
> >
> > >
> >
> > By looking at the code, it shows that in
> > org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage()
> > method, the provider variable is set to null
> >
> > <
> > [...]
> >  EntityProvider provider =
> > ((ProviderFactoryImpl)ProviderFactory.getInstance())
> >.createEntityProvider(targetType, methodMimeTypes,
> > false);   ///  < getting a null provider here !!!
> >
> >try {
> >if (!"*/*".equals(methodMimeTypes[0])) {
> >message.put(Message.CONTENT_TYPE,
> > methodMimeTypes[

RE: Cxf Issue

[Liu, Jervis]

Hi can you be more specific about the problem please? Some code snippets of 
your service implementation and configuration that can help us to reproduce the 
problem or a complete test case would be helpful.

Cheers,
Jervis

> -Original Message-
> From: priya j [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月6日 11:16
> To: cxf-user@incubator.apache.org
> Subject: Cxf Issue
> 
> 
> Hi all,
> 
> Im priya, i have used cxf to make my application(spring framework) a Web
> Service. The application works perfect when my Web Service implementing
> class inturn calls another class, but the issue arise when iam trying to
> call an interface.
> 
> Can anyone help me in solving this, its very urgent.
> Thanks inadvance.
> 
> Regards,
> priya
> --
> View this message in context:
> http://www.nabble.com/Cxf-Issue-tf4953753.html#a14185545
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Cxf Issue

[Liu, Jervis]

> -Original Message-
> From: priya j [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月6日 13:15
> To: cxf-user@incubator.apache.org
> Subject: RE: Cxf Issue
> 
> 
> Thanks for your reply,
> 
> this is my implementor class:
> 
> 
> @WebService(endpointInterface = "demo.webService.server.IWebService")
> public class WebService implements IWebService {
> 
>   //The service that perform the query
>   private FrontEndService service;
> 
> public String webService (String queryString) throws
> FrontEndServiceException {
> 
>   ResultData resultData=service.doSearch(queryString,
> SearchMode.MULTI, NameConstants.LWI_KEY);
> 
>   return "The result" +resultData;
>   }
> 
>   public FrontEndService getService() {
>   return service;
>   }
> 
>   public void setService(FrontEndService service) {
>   this.service = service;
>   }
> 
> }
> 
> Here the FrontEndService is another class, if it is an interface the
> execution fails in client side.
> Can you suggest me how to proceed.
> 
[Liu, Jervis] If I understand your problem correctly, your service fails to 
return a valid result (does the "String webService (String queryString)" method 
throw an exception?) when FrontEndService is implemented in a certain way. Not 
sure what you mean by "if FrontEndService is an interface". Anyway, this seems 
to be a problem in your application code rather than a problem in CXF. A simply 
way to find out is to write a standalone Java mainline to get WebService 
instance from spring context then invoke "String webService (String 
queryString)" from your java mainline to see how it goes. Most likely it is a 
problem in your application code or sth wrong with your spring configuration.

Cheers,
Jervis

> execution fails in client side.
> Liu, Jervis wrote:
> >
> > Hi can you be more specific about the problem please? Some code snippets
> > of your service implementation and configuration that can help us to
> > reproduce the problem or a complete test case would be helpful.
> >
> > Cheers,
> > Jervis
> >
> >> -Original Message-
> >> From: priya j [mailto:[EMAIL PROTECTED]
> >> Sent: 2007年12月6日 11:16
> >> To: cxf-user@incubator.apache.org
> >> Subject: Cxf Issue
> >>
> >>
> >> Hi all,
> >>
> >> Im priya, i have used cxf to make my application(spring framework) a Web
> >> Service. The application works perfect when my Web Service
> implementing
> >> class inturn calls another class, but the issue arise when iam trying to
> >> call an interface.
> >>
> >> Can anyone help me in solving this, its very urgent.
> >> Thanks inadvance.
> >>
> >> Regards,
> >> priya
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Cxf-Issue-tf4953753.html#a14185545
> >> Sent from the cxf-user mailing list archive at Nabble.com.
> >
> > 
> > IONA Technologies PLC (registered in Ireland)
> > Registered Number: 171387
> > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
> >
> >
> 
> --
> View this message in context:
> http://www.nabble.com/Cxf-Issue-tf4953753.html#a14186492
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: jaxws_dispatch_provider demo

[Liu, Jervis]

Hi Eric, it looks like your client did not sent out an valid request to the 
server. A quick way to verify this is using sth like tcpmon to sniff the 
message you send on wire. In your client code, did you change the service and 
port QName to reflect your own namespaces? I.e., following lines:

QName serviceName1 = new 
QName("http://apache.org/hello_world_soap_http";, "SOAPService1");
QName portName1 = new QName("http://apache.org/hello_world_soap_http";, 
"SoapPort1");

SOAPService1 service1 = new SOAPService1(wsdlURL, serviceName1);

Cheers,
Jervis


> -Original Message-
> From: Eric Le Goff [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月7日 23:47
> To: cxf-user@incubator.apache.org
> Subject: jaxws_dispatch_provider demo
> 
> I have playing with the jaxws_dispatch_provider demo sample after a
> recent svn checkout
> 
> Then I tried to update the source files to try and understand how this
> works ;)
> 
> 1 )  in wdsl/hello_world.wsdl
> 
> I replaced every occurence of
> "http://apache.org/hello_world_soap_http";
> to
> "http://foobar.com/my_soap_http";
> 
> 
> 2) In Client.java
> 
> I replaced the
> import org.java.hello_world_http.*;
> to
> import com.foobar.my_soap_http.*;
> 
> 
> 3) In each GreetMeDocLiteral*.xml  (server & client)
> I replaced every namespace occurence of
> "http://apache.org/hello_world_soap_http";
> to
> "http://foobar.com/my_soap_http";
> 
> 4) In GreeterSoapProvider
> I updated the targetNamespace to "http://foobar.com/my_soap_http";
> 
> 
> 
> 
> 
> Now I am certainly missing something because I get an Exception... I
> know I am a bad guy, and I should not have touched the nice demo ;)
> , but I am puzzled with the stack trace :
> 
> 
> [java] INFO: Interceptor has thrown exception, unwinding now
>  [java] org.apache.cxf.interceptor.Fault: Unable to create
> envelope from given source:
>  [java]   at
> org.apache.cxf.jaxws.interceptors.DispatchInDatabindingInterceptor$PostDi
> spatchSOAPHandlerInterceptor.handleMessage(DispatchInDatabindingInterc
> eptor.java:225)
>  [java]   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
>  [java]   at
> org.apache.cxf.jaxws.DispatchImpl.onMessage(DispatchImpl.java:312)
>  [java]   at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleR
> esponse(HTTPConduit.java:1948)
>  [java]   at
> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(H
> TTPConduit.java:1791)
>  [java]   at
> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>  [java]   at
> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
> [...]
> java] Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Unable
> to create envelope from given source:
>  [java]   at
> com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(Envelop
> eFactory.java:114)
>  [java]   at
> com.sun.xml.messaging.saaj.soap.ver1_1.SOAPPart1_1Impl.createEnvelope
> FromSource(SOAPPart1_1Impl.java:71)
> 
> [...]
>[java] Caused by: javax.xml.transform.TransformerException:
> org.xml.sax.SAXParseException: Premature end of file.
>  [java]   at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Tra
> nsformerImpl.java:673)
>  [java]   at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Tra
> nsformerImpl.java:300)
>  [java]   at
> com.sun.xml.messaging.saaj.util.transform.EfficientStreamingTransformer.tr
> ansform(EfficientStreamingTransformer.java:390)
>  [java]   at
> com.sun.xml.messaging.saaj.soap.EnvelopeFactory.createEnvelope(Envelop
> eFactory.java:102)
>  [java]   ... 15 more
>  [java] Caused by: org.xml.sax.SAXParseException: Premature end of
> file.
>  [java]   at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Abstra
> ctSAXParser.java:1269)
>  [java]   at
> org.xml.sax.helpers.XMLFilterImpl.parse(XMLFilterImpl.java:333)
>  [java]   at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transformIde
> ntity(TransformerImpl.java:607)
>  [java]   at
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Tra
> nsformerImpl.java:661)
>  [java]   ... 18 more
> 
> 
> This "premature end of file" is very strange to me. I guess I forgot
> to update another piece of code to make it run from an updated
> hello_world.wsdl file.
> 
> Any help to understand would be appreciated
> 
> 
> 
> --
> Eric Le Goff


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Configuring JAX-WS Handler in spring configuration file

[Liu, Jervis]

There is a standard way to configure JAX-WS handlers using configuration files, 
please refer to the jaxws_handlers demo 
(jaxws_handlers\src\demo\handlers\common\demo_handlers.xml) shipped with CXF 
distribution. The lifecycle of JAX-WS handlers has to be handled by JAX-WS 
runtime, not by anything outside. javax.annotation.Resource annotation can be 
used if you wish to perform any injection.

Cheers,
Jervis


> -Original Message-
> From: gjanjana [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月11日 7:03
> To: cxf-user@incubator.apache.org
> Subject: Configuring JAX-WS Handler in spring configuration file
> 
> 
> 
> I was trying to configure JAX-WS Handler as part of spring configuration
> file. I don't find any means to do that. Is it possible to register JAX-WS
> Handler at deploy time instead of using @HandlerChain annotation. I don't
> want every java class to declare this handler chain.
> 
> For example following descriptor markup registers jaxws service endpoint.
> This element accept CXF interceptors as part of "jaxws:inInterceptors"
> element. However I don't find any way to register JAX-WS Handlers.
> 
>  implementor="org.apache.cxf.jaxws.service.Hello"
> endpointName="e:HelloEndpointCustomized"
> serviceName="s:HelloServiceCustomized"
> address="http://localhost:8080/test";
> xmlns:e="http://service.jaxws.cxf.apache.org/endpoint";
> xmlns:s="http://service.jaxws.cxf.apache.org/service"/>
> 
> --
> View this message in context:
> http://www.nabble.com/Configuring-JAX-WS-Handler-in-spring-configuratio
> n-file-tp14263725p14263725.html
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Can't route REST calls to methods using CXF2.0.3 and JBoss

[Liu, Jervis]

Cannot spot any obvious error in your code. Could you copy me the log messages 
when your server starts up, it should look like sth below:

2007-12-11 11:49:25 org.apache.cxf.service.factory.ReflectionServiceFactoryBean 
buildServiceFromClass
INFO: Creating Service {http://book.acme.com}BookServiceService from class 
org.apache.cxf.customer.book.BookService
2007-12-11 11:49:26 org.apache.cxf.binding.http.strategy.ConventionStrategy map
INFO: Mapping method getBooks to resource /books and verb GET
2007-12-11 11:49:26 org.apache.cxf.binding.http.strategy.ConventionStrategy map
INFO: Mapping method getBook to resource /books and verb GET
2007-12-11 11:49:26 org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be http://localhost:9080/xml/
2007-12-11 11:49:26 sun.reflect.NativeMethodAccessorImpl invoke0
INFO: Logging to org.slf4j.impl.JDK14LoggerAdapter(org.mortbay.log) via 
org.mortbay.log.Slf4jLog
2007-12-11 11:49:26 sun.reflect.NativeMethodAccessorImpl invoke0
INFO: jetty-6.1.6
2007-12-11 11:49:26 sun.reflect.NativeMethodAccessorImpl invoke0
INFO: Started [EMAIL PROTECTED]:9080
signal ready
server ready

Basically this information tell you what methods map to what resources and what 
HTTP verbs.

Thanks,
Jervis

> -Original Message-
> From: rm-ramos [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月10日 20:07
> To: cxf-user@incubator.apache.org
> Subject: Can't route REST calls to methods using CXF2.0.3 and JBoss
> 
> 
> Hi all,
> 
> I'm trying to deploy a very simple REST Webservice, using two Get methods:
> 
> @WebService(name="GetWorkOrderServiceRest",
> targetNamespace="http://webservice.api.wow";)
> public class GetWorkOrderServiceRestImpl implements
> GetWorkOrderServiceRest
> {
> 
> @Get
> @HttpResource(location="/workorders")
> public String getWorkorders() {
> return "hello world!";
> }
> 
> @Get
> @HttpResource(location="/workorder/{id}")
> public String getWorkorder(@WebParam(name = "id")long id) {
> return "hello id:" + id;
> }
> 
> ..and though I *can* access the getWorkorders() method (via browser), I
> keep
> getting the same error when I try to access, for instance, /workorder/123:
> Invalid URL/Verb combination. Verb: GET Path: /workorder/123.
> 
> I've already tried to change the getWorkorder(id)'s HttpResource location to
> /workorders/{id}, but that didn't work either as the first method, with no
> arguments, was being called everytime I accessed the /workorders path.
> 
> Strange thing is I'm almost sure this was working, before I upgraded from
> v2.0.0.
> I would like to know if any of you guys understands what's going on. Am I
> missing something here?!
> 
> Thanks in advance,
> Rui Ramos
> 
> 
> My remaining config files follow:
> 
> ###
> # applicationContext.xml
> ###
>  
> implementor="com.criticalsoftware.wow.api.webservice.GetWorkOrderServi
> ceRestImpl"
>  address="/rest"
>  bindingUri="http://apache.org/cxf/binding/http";>
> 
>class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
>   
> 
> 
> 
> 
> 
> ###
> # beans.xml
> ###
> 
>   CXFServlet
>   CXF Servlet
>   
>   org.apache.cxf.transport.servlet.CXFServlet
>   
>   1
> 
> 
> 
>   CXFServlet
>   /webservice/*
> 
> 
> 
> ###
> # Interface (GetWorkOrderServiceRest)
> ###
> @WebService
> public interface GetWorkOrderServiceRest {
> 
> String getWorkorders();
> String getWorkorder(long id);
> void addWorkorder(String person);
> void updateWorkorder(long id, String person);
> void deleteWorkorder(long id);
> 
> }
> 
> 
> ###
> # The exception I get on the server
> ###
> INFO: Invoking GET on /workorder/453
> 11:49:48,768 ERROR [STDERR] 10/Dez/2007 11:49:48
> org.apache.cxf.phase.PhaseInterceptorChain doInterc
> ept
> INFO: Interceptor has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Invalid URL/Verb combination. Verb: GET
> Path: /workorder/453
>   at
> org.apache.cxf.binding.http.interceptor.DispatchInterceptor.handleMessage(
> DispatchInterceptor.ja
> va:74)
>   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
>   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> Observer.java:73)
>   at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDesti
> nation.java:79)
>   at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servlet
> Controller.java:256)
>   at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.ja
> va:123)
>   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServl
> et.java:170)
>   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServl
> et.java:152)
>   at javax.servlet

RE: Configuring JAX-WS Handler in spring configuration file

[Liu, Jervis]

> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月11日 10:48
> To: cxf-user@incubator.apache.org
> Subject: RE: Configuring JAX-WS Handler in spring configuration file
> 
> There is a standard way to configure JAX-WS handlers using configuration
> files, please refer to the jaxws_handlers demo
> (jaxws_handlers\src\demo\handlers\common\demo_handlers.xml) shipped
> with CXF distribution. The lifecycle of JAX-WS handlers has to be handled by
> JAX-WS runtime, not by anything outside. javax.annotation.Resource
> annotation can be used if you wish to perform any injection.
> 
[Liu, Jervis] 
Correct myself. The lifecycle of JAX-WS handlers can be handled by 
applications. AX-WS 2.0 spec 9.3.1:

"9.3.1 Handler Lifecycle 
In some cases, a JAX-WS implementation must instantiate handler classes 
directly, e.g. in a container 
environment or when using the HandlerChain annotation. When doing so, an 
implementation must invoke 
the handler lifecycle methods as prescribed in this section. 

If an application does its own instantiation of handlers, e.g. using a handler 
resolver, then the burden of
calling any handler lifecycle methods falls on the application itself. This 
should not be seen as inconsistent, 
because handlers are logically part of the application, so their contract will 
be known to the application 
developer."

To load JAX-WS handlers from Spring, on the client side, this can be done 
through JAX-WS HandlerResolver. Implement your own HandlerResolver that can 
load handlers using spring context, then call 
javax.xml.ws.Service.setHandlerResolver(HandlerResolver). However this 
HandlerResolver API only exists on the client side. Another way that can be 
applied to both client and server side is through 
javax.xml.ws.Binding.setHandlerChain(java.util.List
 chain) method. This requires some enhancement to CXF so that the setting of 
handlers configured in spring file is delegated to 
javax.xml.ws.Binding.setHandlerChain(). 

Jervis
> Cheers,
> Jervis
> 
> 
> > -Original Message-
> > From: gjanjana [mailto:[EMAIL PROTECTED]
> > Sent: 2007年12月11日 7:03
> > To: cxf-user@incubator.apache.org
> > Subject: Configuring JAX-WS Handler in spring configuration file
> >
> >
> >
> > I was trying to configure JAX-WS Handler as part of spring configuration
> > file. I don't find any means to do that. Is it possible to register JAX-WS
> > Handler at deploy time instead of using @HandlerChain annotation. I don't
> > want every java class to declare this handler chain.
> >
> > For example following descriptor markup registers jaxws service endpoint.
> > This element accept CXF interceptors as part of "jaxws:inInterceptors"
> > element. However I don't find any way to register JAX-WS Handlers.
> >
> >  > implementor="org.apache.cxf.jaxws.service.Hello"
> > endpointName="e:HelloEndpointCustomized"
> > serviceName="s:HelloServiceCustomized"
> > address="http://localhost:8080/test";
> > xmlns:e="http://service.jaxws.cxf.apache.org/endpoint";
> > xmlns:s="http://service.jaxws.cxf.apache.org/service"/>
> > 
> > --
> > View this message in context:
> >
> http://www.nabble.com/Configuring-JAX-WS-Handler-in-spring-configuratio
> > n-file-tp14263725p14263725.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> 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: sample failure: restfull_http_binding

[Liu, Jervis]

For your information, CXF-889 has been fixed in CXF2.0.3, though the "Get 
Customers!" button is still not working with IE (works with Firefox). I created 
https://issues.apache.org/jira/browse/CXF-1306 to track this.

Cheers,
Jervis


> -Original Message-
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月15日 4:20
> To: cxf-user@incubator.apache.org
> Cc: YI (William) ZHU
> Subject: Re: sample failure: restfull_http_binding
> 
> 
> 
> I think these are logged as:
> 
> https://issues.apache.org/jira/browse/CXF-873
> https://issues.apache.org/jira/browse/CXF-889
> 
> Patches are most welcome.
> 
> Dan
> 
> 
> On Friday 14 December 2007, YI (William) ZHU wrote:
> > Hi,
> >
> > I found that there two issues in the CXF 2.0.2 sample
> > "restfull_http_binding":
> >
> > 1) the "test.html" page to test the "Jettison/CXF AJAX Demo" is not
> > working, I found that the javascript has problem.
> >
> > 2) if I change the "CustomerServiceImpl.java" file to let the web
> > service to return two customers, not the  original 1 customer. Then
> > following links work fine:
> >http://localhost:8080/xml/customers
> >http://localhost:8080/xml/customers/123
> >http://localhost:8080/json/customers/123
> >
> > but this link "http://localhost:8080/json/customers"; return:
> >
> >
> {"acme.Customers":{"acme.customer":[{"acme.id":"789","acme.name":"Wil
> l
> >iam Zhu"},{"acme.id":"123","acme.name":"Dan Diephouse"}]}}
> >
> > I thought that's not correct, they should return two "acme.customer"
> > items.
> >
> > Can someone check the implementation of JSON on CXF is OK?
> >
> >
> > Thanks,
> > YI ZHU
> 
> 
> 
> --
> 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: wrapped mode false fails in IriDecoderHelper

[Liu, Jervis]

This looks like a bug. Could you create a jira for this with a complete test 
case please. At the same time, I would recommend you to give CXF JSR-311 
(JAX-RS) implementation a try, it has similar functionalities as CXF HTTP 
binding provides, but it is more standard based. CXF JAX-RS currently supports 
JAXB binding, not Aegis binding, but it should be straightforward to add Aegis 
binding by writing a new EntityProvider. File a feature request for Aegis 
binding if you find this useful for your project, and it will be handled.

CXF JSR-311 (JAX-RS) support: 
http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html

Cheers,
Jervis

> -Original Message-
> From: hohteri [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月16日 21:04
> To: cxf-user@incubator.apache.org
> Subject: wrapped mode false fails in IriDecoderHelper
> 
> 
> I have configured a working set for a service with aegis data binding, http
> binding and jettison for content formatting to JSON.
> 
> When changing wrapped = false in serviceFactory bean configuration (using
> Spring), the GET request fails with the exception below. When wrapped =
> true
> everything works as expected.
> 
> The service itself is wrapped with Spring proxy but implementorClass is
> defined for the endpoint.
> 
> Br,
> 
> Harri
> 
> The exception:
> 
> ERROR STDERR - Dec 16, 2007 5:52:25 PM
> org.apache.cxf.interceptor.AttachmentInInterceptor handleMessage
> INFO: AttachmentInInterceptor skipped in HTTP GET method
> ERROR STDERR - Dec 16, 2007 5:52:25 PM
> org.apache.cxf.binding.http.interceptor.DispatchInterceptor handleMessage
> INFO: Invoking GET on /domainByIds/0
> ERROR STDERR - Dec 16, 2007 5:52:25 PM
> org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor
> handleMessage
> INFO: URIParameterInterceptor handle message on path [/domainByIds/0]
> with
> content-type [null]
> ERROR STDERR - Dec 16, 2007 5:52:25 PM
> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
> INFO: Interceptor has thrown exception, unwinding now
> java.lang.IllegalStateException: Unexpected character '/' at index 0
>   at
> org.apache.cxf.binding.http.IriDecoderHelper.expect(IriDecoderHelper.java:1
> 54)
>   at
> org.apache.cxf.binding.http.IriDecoderHelper.decodeIri(IriDecoderHelper.jav
> a:86)
>   at
> org.apache.cxf.binding.http.interceptor.URIParameterInInterceptor.handleM
> essage(URIParameterInInterceptor.java:100)
>   at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
> hain.java:207)
>   at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
> Observer.java:73)
>   at
> org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDesti
> nation.java:79)
>   at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servlet
> Controller.java:256)
>   at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.ja
> va:123)
>   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServl
> et.java:170)
>   at
> org.apache.cxf.transport.servlet.AbstractCXFServlet.doGet(AbstractCXFServl
> et.java:152)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:290)
>   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:206)
>   at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.jav
> a:96)
>   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
> FilterChain.java:235)
>   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
> ain.java:206)
>   at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
> lve.java:230)
>   at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
> e.java:175)
>   at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAsso
> ciationValve.java:179)
>   at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.ja
> va:84)
>   at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
> :128)
>   at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
> 04)
>   at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedCo
> nnectionValve.java:157)
>   at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j
> ava:109)
>   at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2
> 41)
>   at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
> 4)
>   at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
> ss(Http11Protocol.java:580)
>   at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoi

RE: sample failure: restfull_http_binding

[Liu, Jervis]

Another Javascript problem. I hate Javascript. 

https://issues.apache.org/jira/browse/CXF-1308

Thanks,
Jervis

> -Original Message-
> From: YI (William) ZHU [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月18日 3:03
> To: cxf-user@incubator.apache.org
> Subject: RE: sample failure: restfull_http_binding
> 
> 
> Hi Jervis,
> 
> Thanks for your reply.
> 
> I have tested the sample with FireFox 2, it works but not in a correct way:
> 
> Everytime when I click the "Get Customers!" button, the same customers
> were
> appended to the page.
> I think they should be refreshed but not appended.
> 
> Regards,
> YI ZHU
> 
> 
> 
> 
> Liu, Jervis wrote:
> >
> > For your information, CXF-889 has been fixed in CXF2.0.3, though the "Get
> > Customers!" button is still not working with IE (works with Firefox). I
> > created https://issues.apache.org/jira/browse/CXF-1306 to track this.
> >
> > Cheers,
> > Jervis
> >
> >
> >> -Original Message-
> >> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> >> Sent: 2007年12月15日 4:20
> >> To: cxf-user@incubator.apache.org
> >> Cc: YI (William) ZHU
> >> Subject: Re: sample failure: restfull_http_binding
> >>
> >>
> >>
> >> I think these are logged as:
> >>
> >> https://issues.apache.org/jira/browse/CXF-873
> >> https://issues.apache.org/jira/browse/CXF-889
> >>
> >> Patches are most welcome.
> >>
> >> Dan
> >>
> >>
> >> On Friday 14 December 2007, YI (William) ZHU wrote:
> >> > Hi,
> >> >
> >> > I found that there two issues in the CXF 2.0.2 sample
> >> > "restfull_http_binding":
> >> >
> >> > 1) the "test.html" page to test the "Jettison/CXF AJAX Demo" is not
> >> > working, I found that the javascript has problem.
> >> >
> >> > 2) if I change the "CustomerServiceImpl.java" file to let the web
> >> > service to return two customers, not the  original 1 customer. Then
> >> > following links work fine:
> >> >http://localhost:8080/xml/customers
> >> >http://localhost:8080/xml/customers/123
> >> >http://localhost:8080/json/customers/123
> >> >
> >> > but this link "http://localhost:8080/json/customers"; return:
> >> >
> >> >
> >>
> {"acme.Customers":{"acme.customer":[{"acme.id":"789","acme.name":"Wil
> >> l
> >> >iam Zhu"},{"acme.id":"123","acme.name":"Dan Diephouse"}]}}
> >> >
> >> > I thought that's not correct, they should return two "acme.customer"
> >> > items.
> >> >
> >> > Can someone check the implementation of JSON on CXF is OK?
> >> >
> >> >
> >> > Thanks,
> >> > YI ZHU
> >>
> >>
> >>
> >> --
> >> 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
> >
> >
> 
> --
> View this message in context:
> http://www.nabble.com/sample-failure%3A-restfull_http_binding-tp143397
> 71p14373995.html
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: Queries in handling the exeception for Http binding for RESTful Service

[Liu, Jervis]

> -Original Message-
> From: priya j [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月18日 11:24
> To: cxf-user@incubator.apache.org
> Subject: Queries in handling the exeception for Http binding for RESTful
> Service
> 
> 
> Hi all,
> I am using the cxf - HTTP Binding for RESTful service to build a web Service
> application.
> i have two question in handling the exception :
> 
> 1) I get the error xml as
> 
> http://cxf.apache.org/bindings/xformat";>
>   http://cxf.apache.org/bindings/xformat";>
>   sg.sphsearch.sfe.webService.server.ErrorFault: dtgdtgd
>   
>   http://cxf.apache.org/bindings/xformat";>
>   http://sfe.sphsearch.sg";>
>   Invalid request parameter query.
> 
>   
>   
> 
> 
> is that any way i can remove the ns1 and faultstring from my output. So that
> the following output is
> 
> http://sfe.sphsearch.sg";>
>   Invalid request parameter query.
> 
> 
[Liu, Jervis] You got the output above probably because you throw 
RuntimeException or Exception from your implementation that is not declared on 
your method. What you can do is defining your own Exception types such as 
CustomerNotFoundException, so that your implementation only throws checked 
exceptions. 

> 2) Is that any way to handle all the HTTP status code exception, if so can
> anyone send me a sample of it.
> 
> Please do help me in doing this.
> Thanks inadvance.
> 
> Priya
> --
> View this message in context:
> http://www.nabble.com/Queries-in-handling-the-exeception-for-Http-bindin
> g-for-RESTful-Service-tp14375877p14375877.html
> Sent from the cxf-user mailing list archive at Nabble.com.


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: extending databinding

[Liu, Jervis]

Hi Mariano, what kind of data bindings are you looking for? Is it sth very 
simple such as marshaling an Inputstream to a Source object (in this case, you 
want look into SourceDataBinding.java) or sth a little bit more complex based 
on schemas, such as JAXB databinding or Aegis databinding. In the later case, 
you may want to look into how Aegis data binding is implemented. Benson has 
done a lot of work recently on Aegis binding. We also have a plan to support 
more data bindings ,such as XMLBeans, JiBX, JaxMe etc, not sure if one of them 
is what you are looking for. Anyway, we would be very happy to provide more 
helps if you can elaborate your requirement into more details.

Thanks,
Jervis




> -Original Message-
> From: Mariano Kohan [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月19日 2:21
> To: cxf-user@incubator.apache.org
> Subject: extending databinding
> 
> hello,
> 
> I want to use cxf to develop some web service, but I need to extend the
> databinding because the provided ones with cxf don't work with my
> application objects.
> 
> Can i do it with cxf? How?
> 
> I read the javadoc of
> org.apache.cxf.databinding.source.SourceDataBindingbut I don't
> understand well how to use it.
> Does it have a sample inside the distribution?
> 
> thanks,
> Mariano


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: JAXB Unmarshalling

[Liu, Jervis]

> -Original Message-
> From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月19日 22:40
> To: cxf-user@incubator.apache.org
> Subject: Re: JAXB Unmarshalling
> 
> By the way, can this approach (which uses JAXBContexts) work for you in
> CXF? :
> 
> http://weblogs.java.net/blog/mhadley/archive/2006/03/restful_web_ser_1.
> html
> 
[Liu, Jervis] You don’t have to use JAX-WS Dispatch API in this case. Once you 
grab the InputStream from HTTPClient (or other lightweight http client stack), 
you can call JAXB to marshal the response to your Customer object. There is no 
point to use a heavy stack like a JAX-WS runtime to do such a simple task. 
Following code snippet should do the job: 

public Object getObjectFromInputStream (Class type,  InputStream 
is) {
try {
JAXBContext context = getJAXBContext(type);
Unmarshaller unmarshaller = context.createUnmarshaller();
return unmarshaller.unmarshal(is);
} catch (JAXBException e) {
e.printStackTrace(); 
}

return null;
}

private JAXBContext getJAXBContext(Class type) throws JAXBException {
synchronized (jaxbContexts) {
JAXBContext context = jaxbContexts.get(type);
if (context == null) {
context = JAXBContext.newInstance(type);
jaxbContexts.put(type, context);
}
return context;
}
}

static Map jaxbContexts = new WeakHashMap();

> You'd still need a schema describing the data like Customer, etc...
> Cheers. Sergey
> 
> 
> 
> - Original Message -
> From: "Eric Le Goff" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, December 18, 2007 4:34 PM
> Subject: JAXB Unmarshalling
> 
> 
> >I am going on playing with the restful_jaxrs sample demo
> >
> >
> > In the Client.java there are these lines
> >
> > ...
> > URL url = new
> URL("http://localhost:9000/customerservice/customers/123";);
> >InputStream in = url.openStream();
> >System.out.println(getStringFromInputStream(in));
> > 
> >
> >
> > What if I did not want to display the XML content (ie the XML
> > representation of customer whose Id is 123)
> > But rather I would like to get the actual instance of Customer with id is 
> > 123
> >
> > Is there some Unmarshalling method to do that , something like
> >
> > ...
> > URL url = new
> URL("http://localhost:9000/customerservice/customers/123";);
> >InputStream in = url.openStream();
> >
> > // Hypothetic code
> > Customer customer = (Customer) getObjectFromInputStream(in);
> > ...
> >
> > How would I implement this
> >
> > Object getObjectFromInputStream(InputStream in)
> >
> > method ?
> >
> > I guess I would have to get a JaxbContext before I can get an
> Unmarshaller ?
> >
> >
> > Thanks for your help
> >
> > Eric
> >
> >
> >
> >
> > --
> > Eric Le Goff
> 
> 
> 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: JAXB Unmarshalling

[Liu, Jervis]

Well, if you REALLY want, you can hide the calling of JAXB in an util, for 
example you can extend HTTP Client to make it aware of a JAXBContext and be 
able to accept and return a JAXB object, for example following code:

String inputFile = 
client.getClass().getResource("update_customer.txt").getFile();
File input = new File(inputFile);
PutMethod put = new 
PutMethod("http://localhost:9000/customerservice/customers";);
RequestEntity entity = new FileRequestEntity(input, "text/xml; 
charset=ISO-8859-1");
put.setRequestEntity(entity);
HttpClient httpclient = new HttpClient();
int result = httpclient.executeMethod(put);
String response = put.getResponseBodyAsString()

Will become:

PutMethod put = new 
PutMethod("http://localhost:9000/customerservice/customers";);
Customer customer = new Customer();
RequestEntity entity = new JAXBRequestEntity(customer);
put.setRequestEntity(entity);
HttpClient httpclient = new JAXBHttpClient(jaxbcontext);
int result = httpclient.executeMethod(put);
Customer updatedCustomer = put.getResponseBodyAsJAXB()

Of course, you can also add some nice things such as handle checked exception 
in this HTTP Client extension, so that it becomes:
  try {
int result = httpclient.executeMethod(put);
Customer updatedCustomer = put.getResponseBodyAsJAXB()
   } catch (CustomerNotFoundException e) {
   } catch (WebServiceException e)  {
   }

Does this make sense?

Cheers,
Jervis
> -Original Message-
> From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月20日 17:54
> To: cxf-user@incubator.apache.org
> Subject: Re: JAXB Unmarshalling
> 
> That's pretty interesting all right.
> 
> I would say that there might not be much point in dealing directly with
> JAXBContext and pretend
> that your code is so light and free :-)
> 
> Cheers, Sergey
> 
> - Original Message -
> From: "Liu, Jervis" <[EMAIL PROTECTED]>
> To: 
> Sent: Thursday, December 20, 2007 7:18 AM
> Subject: RE: JAXB Unmarshalling
> 
> 
> >
> >> -Original Message-
> >> From: Sergey Beryozkin [mailto:[EMAIL PROTECTED]
> >> Sent: 2007年12月19日 22:40
> >> To: cxf-user@incubator.apache.org
> >> Subject: Re: JAXB Unmarshalling
> >>
> >> By the way, can this approach (which uses JAXBContexts) work for you in
> >> CXF? :
> >>
> >>
> http://weblogs.java.net/blog/mhadley/archive/2006/03/restful_web_ser_1.
> >> html
> >>
> > [Liu, Jervis] You don’t have to use JAX-WS Dispatch API in this case. Once
> you grab the InputStream from HTTPClient (or other lightweight http client
> stack), you can call JAXB to marshal the response to your Customer object.
> There is no point to use a heavy stack like a JAX-WS runtime to do such a
> simple task. Following code snippet should do the job:
> >
> >public Object getObjectFromInputStream (Class type,
> InputStream is) {
> >try {
> >JAXBContext context = getJAXBContext(type);
> >Unmarshaller unmarshaller = context.createUnmarshaller();
> >return unmarshaller.unmarshal(is);
> >} catch (JAXBException e) {
> >e.printStackTrace();
> >}
> >
> >return null;
> >}
> >
> >private JAXBContext getJAXBContext(Class type) throws
> JAXBException {
> >synchronized (jaxbContexts) {
> >JAXBContext context = jaxbContexts.get(type);
> >if (context == null) {
> >context = JAXBContext.newInstance(type);
> >jaxbContexts.put(type, context);
> >}
> >return context;
> >}
> >}
> >
> >static Map jaxbContexts = new
> WeakHashMap();
> >
> >> You'd still need a schema describing the data like Customer, etc...
> >> Cheers. Sergey
> >>
> >>
> >>
> >> - Original Message -
> >> From: "Eric Le Goff" <[EMAIL PROTECTED]>
> >> To: 
> >> Sent: Tuesday, December 18, 2007 4:34 PM
> >> Subject: JAXB Unmarshalling
> >>
> >>
> >> >I am going on playing with the restful_jaxrs sample demo
> >> >
> >> >
> >> > In the Client.java there are these lines
> >> >
> >> > ...
> >> > URL url = new
> >> URL("http://localhost:9000/customerservice/customers/123";);
> >> >InputStream in = url.openStream();
> >>

RE: CXF and JSON

[Liu, Jervis]

I would encourage you to try CXF JSR-311 (JAX-RS) implementation instead. It is 
standard based (CXF HTTP binding is not standard based), and the development 
activities around CXF JSR-311 are much more active. 

CXF JSR-311 (JAX-RS) demo: samples\restful_jaxrs
System test: 
http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/

And they all work! :-)

Docs: http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html

Let me know if you run into any problems.

Cheers,
Jervis

> -Original Message-
> From: Willem Jiang [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月21日 7:02
> To: cxf-user@incubator.apache.org
> Subject: Re: CXF and JSON
> 
> Hi ,
> You can find the example in the CXF_KIT/samples/restful_http_binding
> 
> Willem.
> Vespa, Anthony J wrote:
> > I'm considering implementing (or re-implementing) a service from
> > REST/SOAP to JSON.  I'm wondering if someone has a workable example
> (the
> > docs I've found are a bit sparse) in terms of how to configure my
> > beans.xml and how to set up the SEI.
> >
> > Thanks!
> >
> >


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

RE: CXF and JSON

[Liu, Jervis]

It should work with the latest snapshot. Make sure you set your request content 
type to "application/json". I have an example of this located under: 
http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java

What do you mean by outside CXF?

Cheers,
Jervis

> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2007年12月21日 22:57
> To: cxf-user@incubator.apache.org
> Subject: RE: CXF and JSON
> 
> Is it possible to actually use JSON as an input to a service vs forming a URL?
> Is that even possible outside of CXF?
> 
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 20, 2007 10:00 PM
> To: cxf-user@incubator.apache.org
> Subject: RE: CXF and JSON
> 
> I would encourage you to try CXF JSR-311 (JAX-RS) implementation instead.
> It is standard based (CXF HTTP binding is not standard based), and the
> development activities around CXF JSR-311 are much more active.
> 
> CXF JSR-311 (JAX-RS) demo: samples\restful_jaxrs
> System test:
> http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/or
> g/apache/cxf/systest/jaxrs/
> 
> And they all work! :-)
> 
> Docs: http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html
> 
> Let me know if you run into any problems.
> 
> Cheers,
> Jervis
> 
> > -Original Message-
> > From: Willem Jiang [mailto:[EMAIL PROTECTED]
> > Sent: 2007年12月21日 7:02
> > To: cxf-user@incubator.apache.org
> > Subject: Re: CXF and JSON
> >
> > Hi ,
> > You can find the example in the CXF_KIT/samples/restful_http_binding
> >
> > Willem.
> > Vespa, Anthony J wrote:
> > > I'm considering implementing (or re-implementing) a service from
> > > REST/SOAP to JSON.  I'm wondering if someone has a workable
> example
> > (the
> > > docs I've found are a bit sparse) in terms of how to configure my
> > > beans.xml and how to set up the SEI.
> > >
> > > Thanks!
> > >
> > >
> 
> 
> 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: JSON serialization not working for PUT requests

[Liu, Jervis]

This should work, we have a system test located under 
http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java?view=markup&pathrev=606708,
 see the testUpdateBookWithJSON method. Make sure you set your request content 
type to "application/json". Let me know if this does not help.

Cheers,
Jervis

> -Original Message-
> From: ákos Maróy [mailto:[EMAIL PROTECTED]
> Sent: 2008年1月7日 21:38
> To: cxf-user@incubator.apache.org
> Subject: JSON serialization not working for PUT requests
> 
> I'm trying to create a JAX-RS web service using CXF, and it seems that
> JSON serialization would only work one way.
> 
> if I specify the following:
> 
> 
> @HttpMethod("PUT")
> @UriTemplate("/foo")
> @ConsumeMime("application/json")
> 
> 
> I still get an XML SAX exception, which sort of implies, that CXF tries
> to de-marshal the contens as if it was XML..
> 
> am I doing something wrong?
> 
> 
> Akos


IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland