Re: CXFServlet
Thanks > > With the spring version, you would just use the normal Spring config to > acomplish the same thing. > http://cwiki.apache.org/confluence/display/CXF20DOC/Aegis+Databinding > For some reason I cannot use the spring config, therefore I understand that I have to override loadbus. Having define a service factory (the reflectionServiceFactoryBean in my case), I am still wondering how to get from that stage to the publication of an Endpoint ? Thanks Guillaume
RE: Polymorphic dispatch, JAXB REST.
Sorry for the late response, I was having some personal emergencies in the past
two weeks. In REST, one URI must represent one concrete entity or a set of
concrete entities. So your question is whether or not it is possible to use one
URI to represent polymorphic entities? Very interesting. Though IMHO I don’t
think this works. For example, say I have three types for my online book store:
Book, CD and Item, Book and CD are extended from Item. Both book and CD are
concrete entities that are persisted in database. The Item on the contrary, is
only an abstract concept, itself is not a concrete entity in the database. Lets
exam whether or not the CRUD operations on the Item resource always make sense.
When you do a HTTP GET to query entities, you can do following:
http://localhost:9000/bookstore/books/123
http://localhost:9000/bookstore/cds/124
http://localhost:9000/bookstore/items/123
http://localhost:9000/bookstore/items/124
The items/123 and items/124 are the tricky ones, items/123 is actually equal to
books/123, items/124 is equal to cds/124. In this case, we can probably say
polymorphic URI works. But in the case of POST, I start to see problems:
POST http://localhost:9000/bookstore/items
What does this mean? Create an abstract type "Item"? But entity type Item does
not really exist, it is only an abstract concept. Create a concrete type? But
how? Well, if the server is smart enough, we might be able to detect the
concrete type by examining the content of POST body. If the content of POST
body is an on-wire representation of Book then we create a Book entity. As you
can probably agree, this might work in some cases but it is not a generic
enough solution, it goes too far. Actually, when you sent a HTTP POST to add an
entity on the client side, surely you already know the concrete type you want
to create. If you know you want to add a Book, why don’t simply call "POST
http://localhost:9000/bookstore/book";?
Same thing applies to HTTP PUT and HTTP DELETE.
Cheers,
Jervis
> -Original Message-
> From: TonyTheFish [mailto:[EMAIL PROTECTED]
> Sent: 2008年1月18日 2:43
> To: cxf-user@incubator.apache.org
> Subject: Polymorphic dispatch, JAXB REST.
>
>
> I have an r&d project on the go and I'm having difficulty getting a rest
> service to dispatch correctly.
>
> I have these two classes
> @XmlTransient
> public class Transaction implements Serializable { ... }
>
> @XmlRootElement(name = "transactionType1")
> public class TransactionType1 extends Transaction implements Serializable {
> .. }
>
> If I try to feed a TransactionType1 instance into this
>
> @HttpMethod("POST")
> @ProduceMime("application/xml")
> @UriTemplate("/transaction/")
> public Response addTransaction(Transaction transaction) { ... }
>
> I see
>
> java.lang.NullPointerException
> at
> org.apache.cxf.jaxrs.JAXRSUtils.readFromEntityBody(JAXRSUtils.java:224)
> at
> org.apache.cxf.jaxrs.JAXRSUtils.processParameter(JAXRSUtils.java:199)
>
>
>
> However if I change the method signature to accept TransactionType1 it
> works
> fine. What I'm really after, as you probably guessed, is to dispatch
> multiple transaction types through the same endpoint.
>
> Thanks in advance - TtF
> --
> View this message in context:
> http://www.nabble.com/Polymorphic-dispatch%2C-JAXB-REST.-tp14928185
> p14928185.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: cxf RESTful samples - addCustomer (by http POST) doesn't work
Hi, at the moment, there are two technologies one can use to build RESTful
services in CXF, namely CXF HTTP Binding and CXF JSR-311 (JAX-RS). Sedo is
actually using CXF HTTP Binding, while Barry is refering to CXF JSR-311
(because the @ConsumeMime annotation only exists in JSR-311). I know this is
a bit confusing, well the basic message we can send out is that people are
encouraged to move to CXF JSR-311, because it is standard based and the
development activities around CXF JSR-311 impl are much more active than CXF
Http binding.
Sedo, to answer your question, the stack trace shows that your server is not
responding. Check your server port number and address, or if there is any
exceptions in your server console.
Hope this helps,
Jervis
sedo wrote:
>
> Hmm, still doesn't works for me :-/
> using latest release 2.0.4
>
>
>
>
> Barry Fitzgerald wrote:
>>
>> Hi,
>>
>> I had this problem too with the latest snapshot. I added a
>> @ConsumeMime("text/xml") to the method and it seemed to fix it.
>>
>> Barry
>>
>> On Feb 1, 2008 11:37 AM, sedo <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> I write my own sample according to restful_http_binding
>>> But when using Client and addCustomer(Customer c) method, it throws
>>> something like this:
>>> (same thing when I add addCustomer method to the client in cxf sample):
>>> pls help :-/
>>>
>>> org.apache.cxf.phase.PhaseInterceptorChain doIntercept
>>> INFO: Interceptor has thrown exception, unwinding now
>>> org.apache.cxf.interceptor.Fault: Could not send Message.
>>>at
>>>
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage
>>> (MessageSenderInterceptor.java:64)
>>>at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>>> PhaseInterceptorChain.java:207)
>>>at
>>>
>>> org.apache.cxf.binding.http.interceptor.DatabindingOutSetupInterceptor.handleMessage
>>> (DatabindingOutSetupInterceptor.java:91)
>>>at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>>> PhaseInterceptorChain.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 $Proxy25.addPerson(Unknown Source)
>>>at sk.posam.ws.restwebservice.client.Client.main(Client.java:43)
>>> Caused by: java.net.SocketTimeoutException: Read timed out
>>>at java.net.SocketInputStream.socketRead0(Native Method)
>>>at java.net.SocketInputStream.read(Unknown Source)
>>>at java.io.BufferedInputStream.fill(Unknown Source)
>>>at java.io.BufferedInputStream.read1(Unknown Source)
>>>at java.io.BufferedInputStream.read(Unknown Source)
>>>at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
>>>at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
>>>at
>>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
>>> Source)
>>>at java.net.HttpURLConnection.getResponseCode(Unknown Source)
>>>at
>>>
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse
>>> (HTTPConduit.java:1863)
>>>at
>>> org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(
>>> HTTPConduit.java:1791)
>>>at
>>> org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:66)
>>>at
>>> org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:575)
>>>at
>>>
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage
>>> (MessageSenderInterceptor.java:62)
>>>... 9 more
>>> Exception in thread "main" javax.xml.ws.http.HTTPException
>>>at
>>> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:147)
>>>at $Proxy25.addPerson(Unknown Source)
>>>at sk.posam.ws.restwebservice.client.Client.main(Client.java:43)
>>> Caused by: org.apache.cxf.interceptor.Fault: Could not send Message.
>>>at
>>>
>>> org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage
>>> (MessageSenderInterceptor.java:64)
>>>at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>>> PhaseInterceptorChain.java:207)
>>>at
>>>
>>> org.apache.cxf.binding.http.interceptor.DatabindingOutSetupInterceptor.handleMessage
>>> (DatabindingOutSetupInterceptor.java:91)
>>>at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
>>> PhaseInterceptorChain.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(
Re: Different bevaviour in 2.0.4
Hi Dan
THere doesn't seem to be a difference in the messages.
CXF 2.0.4
=
02-Feb-2008 12:46:56 org.apache.cxf.interceptor.LoggingInInterceptor
logging
INFO: Inbound Message
Encoding: UTF-8
Headers: {Host=[192.168.10.61:9530], User-Agent=[Java/1.5.0_13],
connection=[keep-alive], SOAPAction=[""], transfer-encoding=
[chunked], Pragma=[no-cache], content-type=[text/xml; charset=UTF-8],
Cache-Control=[no-cache], Accept=[*]}
Messages:
Message:
Payload: http://schemas.xmlsoap.org/soap/
envelope/">xmlns:ns2="http://model.remoting.commons.surgex.com";>TESTns2:serviceName>passwordns1:credential>SW7 7ET>falsesoap:Body>
--
02-Feb-2008 12:46:56 org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Application has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: null while invoking public
com.surgex.addresslookup.model.UKAddress[]
com.surgex.addresslookup.service.impl.AddressLookupServiceImpl.lookupUK(
com.surgex.commons.remoting.model.Credential,java.lang.String,java.util.
Map,boolean) throws
com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.comm
ons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.remo
ting.exceptions.UnauthorisedAccessException with params [null, null,
null, null].
at org.apache.cxf.service.invoker.AbstractInvoker.createFault
(AbstractInvoker.java:109)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.createFault
(JAXWSMethodInvoker.java:76)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke
(AbstractInvoker.java:101)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke
(JAXWSMethodInvoker.java:100)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke
(AbstractInvoker.java:68)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run
(ServiceInvokerInterceptor.java:56)
at org.apache.cxf.workqueue.SynchronousExecutor.execute
(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage
(ServiceInvokerInterceptor.java:92)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept
(PhaseInterceptorChain.java:208)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage
(ChainInitiationObserver.java:77)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage
(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination
(ServletController.java:264)
at org.apache.cxf.transport.servlet.ServletController.invoke
(ServletController.java:160)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke
(AbstractCXFServlet.java:170)
at org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost
(AbstractCXFServlet.java:148)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:362)
at org.mortbay.jetty.servlet.SessionHandler.handle
(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle
(ContextHandler.java:726)
at org.mortbay.jetty.handler.HandlerWrapper.handle
(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest
(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content
(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:730)
at org.mortbay.jetty.HttpParser.parseAvailable
(HttpParser.java:205)
at org.mortbay.jetty.HttpConnection.handle
(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run
(SelectChannelEndPoint.java:395)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run
(BoundedThreadPool.java:450)
Caused by: java.lang.IllegalArgumentException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cxf.service.invoker.AbstractInvoker.performInvocation
(AbstractInvoker.java:124)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke
(AbstractInvoker.java:82)
... 27 more
02-Feb-2008 12:46:56 org.apache.cxf.interceptor.LoggingOutInterceptor
$LoggingCallback onClose
INFO: Outbound Message
---
Encoding: UTF-8
Headers: {}
Messages:
Payload: http://schemas.xmlsoap.org/soap/
envelope/">soap:Serverfaultcode>null while invoking public
com.surgex.addresslookup.model.UKAddre
Re: HttpSession and Endpoints
Basically we store the stateful information into the message context, and the interceptor get the stateful information from the message context. Maybe you can put your own SessionManager into the message context and pass it to the interceptor that you use. Willem. Chris Campbell wrote: If I understand the code correctly, the HttpConduit holds the session in a private field with no accessor method, and manages the session itself. So I think I have to use an interceptor to set the cookie on the other proxies. My current work around (I think similar to what you suggested) is to turn off the maintainSession on the conduit and have my own SessionManager that an inbound interceptor can access and set when the Set-Cookie comes back from the first request, and an outbound interceptor can access and set the cookie header for any other request, whichever proxy is making the request. So the SessionManager is stateful, but not the interceptors. But the interceptors do call into my application code, is that a bad practice? Willem Jiang wrote: It is not easy to share the http conduit between the different proxy, since you need to hack the HttpTransportFactory and handle theconfiguration of the http conduit. I don't think using the interceptor could resolve the problem that you met. Because when you using the interceptor to hold the first session cookie, you will make the interceptor stateful. We do not want the interceptor be stateful to avoid lock the multi thread calling. My suggestion is We could put the cookie into the message context for application code to access and reset. Then you can get the cookie from the first proxy in your application code and then set cookie to the second proxy to get around it. Thoughts? Willem. Chris Campbell wrote: That would have to be on the client side, correct? I think I would need to have a client side inInterceptor to do that. I tend to load the proxies as needed, is there a way to probe the bus to get any other loaded proxies so that a lazily instantiated proxy can get a previously acquired session cookie from another? Maybe the inInterceptor can just stash away the first session cookie acquired, and an outInterceptor can apply it to any request. Any thoughts as to what the best practice would be? I guess a feature request would be to be able to share an http-conduit between proxies. I kind of think of the http-conduit as an http client, is that bad analogy? Thanks for the insight, definitely narrowing in on a solution. Daniel Kulp wrote: Oh. Yea. That would definitely do it. Good catch. Each client proxy holds it's own conduit and thus the cookie for the session is stored there is unique for each proxy. Most likely, you will need to do some cookie management your self. Grab the protocol headers from the response headers and set them in the request headers for all the proxies. You can use the org.apache.cxf.transport.http.Cookie class to help with the parsing/setting. Dan On Friday 01 February 2008, Chris Campbell wrote: The problem is that I get a different session for different endpoints, maybe its how I set the client up? I do set the client up in java code rather than with xml config, so maybe I am doing something wrong there. Is it possible that each service interface is getting a different http-conduit? Daniel Kulp wrote: On Friday 01 February 2008, Chris Campbell wrote: I am using CXFServlet in tomcat, and intend to load balance instances of them with apache mod_jk, and want to use sticky sessions. I figure I have to create a session somewhere, as I do not see a session created (JSESSIONID ?) automatically. For reasons not worth going into, I do not need the session for state, beyond making sure that the sticky-ness works on the load-balancer. I have tried getting the HttpServletRequest in an interceptor (USER_LOGICAL phase) and creating an HttpSession if there is none, and it seems to work. The problem is that I have a few soap endpoints at different URLs, and the session seems to be created for each endpoint, so calls to Service /Foo gets on session and /Bar another. This causes my sticky session load balancer to send /Foo to one of the load balanced CXFServlet and /Bar to another . Is there some way to create the Session so that it is valid for all the service endpoints? Is setting the Session in an interceptor a bad idea? That should be completely fine assuming that works with tomcat. This really is a tomcat question which I don't really know much about. I would assume if all the endpoints are on the CXFServlet instance they would have properly shared the session. If they are in separate wars, maybe not. I don't know know enough about the servlet spec to know what the rules are around that.
