Re: WebSecurity error when using Simple Frontend / Aegis binding
Hi ,
There are some difference between the simple front end and jaxws front
end to detail with the fault message.
The WebFault annotation will take effect when you are using the jaxws
front end ,
but when you using simple front you need let the exception class
inherit the org.apache.cxf.frontend.FaultInfoException class.
You can find some more information by digging the
RefactionServiceFactoryBean [1] 's initializeFaults() method.
[1]
https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/frontend/simple/src/main/java/org/apache/cxf/service/factory/ReflectionServiceFactoryBean.java
Willem.
yulinxp wrote:
Looking at src for FaultOutInterceptor.java, BindingOperationInfo op is null!
This only happens for Simple Frontend/Aegis binding, not for JAX-WS
Frontend/JAXB binding.
Is there a way to let it work? I am using cxf-2.0.3.
public FaultInfo getFaultForClass(BindingOperationInfo op, Class class1) {
for (BindingFaultInfo bfi : op.getFaults()) {
FaultInfo faultInfo = bfi.getFaultInfo();
Class c =
(Class)faultInfo.getProperty(Class.class.getName());
if (c.isAssignableFrom(class1)) {
return faultInfo;
}
}
return null;
}
---
///tomcat CXF server exception
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.interceptor.FaultOutInterceptor.getFaultForClass(FaultOutInterceptor.java:
128)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInterceptor.java:61)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultCha
inInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:7
3)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
va:256)
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:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
What's working for JAX-WS Frontend / JAXB binding does not work for Simple
Frontend / Aegis binding.
Is there anything wrong with my xml? How to fix it?
Re: Issue with CXF: Marshalling Error: Error writing request body to server
Hi, Did you enable the MTOM feature? Please refer the below link for more information. http://cwiki.apache.org/CXF20DOC/mtom.html Willem. Tor Arne Kvaløy wrote: Hello! I have ran into a serious problem with CXF on the client side. I have tried quite a few things but I am right now quite stuck, and I hope that you guys have any suggestions. The full stacktrace is in this mail. I get the same error both with 2.0.3 and 2.0.4. Can it be an issue with JAXB, I am using jaxb-impl 2.0.5 from the sun-site. The following error is given when I invoke the web service method. SubmitDataService service = new SubmitDataService(); ISubmitData port = service.getSubmitDataPort(); boolean ret = port.submitData(setId, setName, fileName, getData(fileName), list); INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:207) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:63) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:84) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by: javax.xml.bind.MarshalException - with linked exception: [java.io.IOException: Error writing request body to server] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:297) at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:221) at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:70) at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:360) at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:187) ... 10 more Caused by: java.io.IOException: Error writing request body to server at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2261) at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2244) at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:45) at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:64) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.flushBuffer(UTF8XmlOutput.java:351) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:304) at com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Data.java:263) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:251) at com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.java:312) at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:140) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:214) at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:62) at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:286) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:619) at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:113) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:98) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 14 more Exception in thread "Main Thread" javax.xml.ws.soap.SOAPFaultException: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsC
Re: Query About Request Context
This link [1] may help your to get the whole story.
[1]http://www.nabble.com/Request-ResponseContext-of-JaxWsClientProxy-td10327781.html#a10335673
Willem.
Sky-Tiger wrote:
See this:
public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
implements
InvocationHandler, BindingProvider {
private static final Logger LOG =
LogUtils.getL7dLogger(JaxWsClientProxy.class);
protected Map requestContext = new
ConcurrentHashMap();
protected ThreadLocal > responseContext =
new ThreadLocal>();
Anybody can tell me why responseContext is threadlocal but requestContext
is not? That means BindingProvider is not thread-safe!
Is it a bug?
Re: Query About Request Context
FYI, currently we have some a JIRA[1] for tracing this issue. https://issues.apache.org/jira/browse/CXF-1410 Willem. SantoshAkhilesh wrote: Hi, So far I had an idea that request context is put in thread local but I realized it is not. Why the request context is not threadlocal ? If I want to send multiple client requests and each request having different JMS header using same BindingProvider instance then do I need to synchronize the context or not ? I think now it needs to synchronized else it is overwritten by subsequent calls. Can anyone shed a light on this. Regards, Santosh
Re: Query About Request Context
See this:
public class JaxWsClientProxy extends org.apache.cxf.frontend.ClientProxy
implements
InvocationHandler, BindingProvider {
private static final Logger LOG =
LogUtils.getL7dLogger(JaxWsClientProxy.class);
protected Map requestContext = new
ConcurrentHashMap();
protected ThreadLocal > responseContext =
new ThreadLocal>();
Anybody can tell me why responseContext is threadlocal but requestContext
is not? That means BindingProvider is not thread-safe!
Is it a bug?
--
View this message in context:
http://www.nabble.com/Query-About-Request-Context-tp15282233p15282508.html
Sent from the cxf-user mailing list archive at Nabble.com.
Query About Request Context
Hi, So far I had an idea that request context is put in thread local but I realized it is not. Why the request context is not threadlocal ? If I want to send multiple client requests and each request having different JMS header using same BindingProvider instance then do I need to synchronize the context or not ? I think now it needs to synchronized else it is overwritten by subsequent calls. Can anyone shed a light on this. Regards, Santosh -- View this message in context: http://www.nabble.com/Query-About-Request-Context-tp15282233p15282233.html Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXFServlet
Thanks Willem, This is a super tuesday, it works ;-) Cheers Guillaume
Fwd: Different bevaviour in 2.0.4
Hi
So any idea why this could be failing on 2.0.4 and not 2.0.3?
Thx.
Begin forwarded message:
From: Frederic Soulier <[EMAIL PROTECTED]>
Date: 3 February 2008 11:22:29 GMT
To: cxf-user@incubator.apache.org
Subject: Re: Different bevaviour in 2.0.4
Reply-To: cxf-user@incubator.apache.org
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.lookupU
K
(com.surgex.commons.remoting.model.Credential,java.lang.String,java.ut
il.Map,boolean) throws
com.surgex.commons.remoting.exceptions.RemotingException,com.surgex.co
mmons.remoting.exceptions.InvalidArgumentException,com.surgex.commons.
remoting.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
Re: WebSecurity error when using Simple Frontend / Aegis binding
Looking at src for FaultOutInterceptor.java, BindingOperationInfo op is null!
This only happens for Simple Frontend/Aegis binding, not for JAX-WS
Frontend/JAXB binding.
Is there a way to let it work? I am using cxf-2.0.3.
public FaultInfo getFaultForClass(BindingOperationInfo op, Class class1) {
for (BindingFaultInfo bfi : op.getFaults()) {
FaultInfo faultInfo = bfi.getFaultInfo();
Class c =
(Class)faultInfo.getProperty(Class.class.getName());
if (c.isAssignableFrom(class1)) {
return faultInfo;
}
}
return null;
}
---
///tomcat CXF server exception
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.interceptor.FaultOutInterceptor.getFaultForClass(FaultOutInterceptor.java:
128)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInterceptor.java:61)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultCha
inInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:7
3)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
va:256)
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:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
What's working for JAX-WS Frontend / JAXB binding does not work for Simple
Frontend / Aegis binding.
Is there anything wrong with my xml? How to fix it?
--
View this message in context:
http://www.nabble.com/WebSecurity-error-when-using-Simple-Frontend---Aegis-binding-tp15277618p15278251.html
Sent from the cxf-user mailing list archive at Nabble.com.
WebSecurity error when using Simple Frontend / Aegis binding
Web Security works for my example A, using JAX-WS Frontend / JAXB binding.
If client sets the wrong password, server will return "Security processing
failed." to the client.
Now I want to add WebSecurity to another example B, using Simple Frontend /
Aegis binding.
I use the same ServerPasswordCallback & ClientPasswordCallback as in example
A.
My xml is like this:
If client sets the password right, everything is fine. But if client sets
the wrong password,
server tomcat will have the following exception. And because of it, the
client doesn't receive any response,
and the client will have something like
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
///tomcat CXF server exception
INFO: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.cxf.interceptor.FaultOutInterceptor.getFaultForClass(FaultOutInterceptor.java:
128)
at
org.apache.cxf.interceptor.FaultOutInterceptor.handleMessage(FaultOutInterceptor.java:61)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:207)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultCha
inInitiatorObserver.java:90)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:224)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:7
3)
at
org.apache.cxf.transport.servlet.ServletDestination.doMessage(ServletDestination.java:79)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
va:256)
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:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.j
ava:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.ja
va:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
What's working for JAX-WS Frontend / JAXB binding does not work for Simple
Frontend / Aegis binding.
Is there anything wrong with my xml? How to fix it?
--
View this message in context:
http://www.nabble.com/WebSecurity-error-when-using-Simple-Frontend---Aegis-binding-tp15277618p15277618.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: HttpSession and Endpoints
Chris, That should be fine as long as your SessionManager is properly re-entrant/thread safe. Dan On Sunday 03 February 2008, 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
Fast Infoset
Hi,
Has anyone had any luck plugging in the java.net Fast Infoset reference
implementation into CXF? I tried doing something like the following:
import javax.xml.stream.XMLInputFactory;
import javax.xml.stream.XMLOutputFactory;
import com.sun.xml.fastinfoset.stax.factory.StAXInputFactory;
import com.sun.xml.fastinfoset.stax.factory.StAXOutputFactory;
...
// Server setup
JaxWsServerFactoryBean serverFactory = new JaxWsServerFactoryBean();
serverFactory.setAddress("http://localhost:12345/MyService";);
serverFactory.setServiceClass(MyService.class);
serverFactory.setServiceBean(new MyServiceImpl());
Map properties = new HashMap();
properties.put(XMLInputFactory.class.getName(), new MyXmlInputFactory());
properties.put(XMLOutputFactory.class.getName(), new MyXmlOutputFactory());
serverFactory.setProperties(properties);
serverFactory.create();
// Client setup
JaxWsProxyFactoryBean clientFactory = new JaxWsProxyFactoryBean();
clientFactory.setAddress("http://localhost:12345/MyService";);
clientFactory.setServiceClass(MyService.class);
Map properties = new HashMap();
properties.put(XMLInputFactory.class.getName(), new StAXInputFactory());
properties.put(XMLOutputFactory.class.getName(), new StAXOutputFactory());
clientFactory.setProperties(properties);
MyService service = (MyService)clientFactory.create();
Unfortunately invoking any methods on client proxy results in the following
exception because the Fast Infoset vocabulary has not been setup:
Caused by: java.lang.NullPointerException
at
com.sun.xml.fastinfoset.Encoder.encodeNamespaceAttribute(Encoder.java:558)
at
com.sun.xml.fastinfoset.stax.StAXDocumentSerializer.encodeTerminationAndCurrentElement(StAXDocumentSerializer.java:581)
at
com.sun.xml.fastinfoset.stax.StAXDocumentSerializer.writeStartElement(StAXDocumentSerializer.java:215)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:130)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
... 2 more
Setting up an empty vocabulary on the StAXDocumentSerializer seems to cause an
infinite loop in
org.apache.cxf.interceptor.WrappedOutInterceptor.handleMessage(). Anyone have
any suggestions before I dig much deeper?
Thanks,
Joel
Help please
Hi, I'm new to cxf, coming from xfire. I'm using wsdl2java to generate the client for a WS. It works almost fine (in the generated code one webmethod that has 3 params it's generated with one, but I saw this is a bug). The thing is I have this generated class: package com.btsincusa.gp; import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlRootElement; import javax.xml.bind.annotation.XmlType; /** * Java class for ExecTR element declaration. * * The following schema fragment specifies the expected content contained within this class. * * ** * * * */ @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "ExecTR") @XmlRootElement public class ExecTR { protected Object request; /** * Gets the value of the request property. * * @return * possible object is * [EMAIL PROTECTED] Object } * */ public Object getREQUEST() { return request; } /** * Sets the value of the request property. * * @param value * allowed object is * [EMAIL PROTECTED] Object } * */ public void setREQUEST(Object value) { this.request = value; } } This REQUEST object I've created: package com.btsincusa.gp; import java.util.HashMap; import java.util.Map; import javax.xml.bind.annotation.XmlAccessType; import javax.xml.bind.annotation.XmlAccessorType; import javax.xml.bind.annotation.XmlAnyAttribute; import javax.xml.bind.annotation.XmlElement; import javax.xml.bind.annotation.XmlType; import javax.xml.namespace.QName; /** * * Java class for ADDRESSING complex type. * * * The following schema fragment specifies the expected content contained within * this class. * * ** ** ** ** ** * * * * */ @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "REQUEST", propOrder = { "AGENT_CD", "AGENT_TRANS_TYPE_CODE" }) public class REQUEST { @XmlElement(name = "AGENT_CD") protected String AGENT_CD; @XmlElement(name = "AGENT_TRANS_TYPE_CODE") protected String AGENT_TRANS_TYPE_CODE; @XmlAnyAttribute private Map otherAttributes = new HashMap(); /** * Gets the value of the AGENT_CD property. * * @return possible object is [EMAIL PROTECTED] String } * */ public String getAGENT_CD() { return AGENT_CD; } /** * Sets the value of the AGENT_CD property. * * @param value *allowed object is [EMAIL PROTECTED] String } * */ public void setAGENT_CD(String value) { this.AGENT_CD = value; } /** * Gets the value of the AGENT_TRANS_TYPE_CODE property. * * @return possible object is [EMAIL PROTECTED] String } * */ public String getAGENT_TRANS_TYPE_CODE() { return AGENT_TRANS_TYPE_CODE; } /** * Sets the value of the AGENT_TRANS_TYPE_CODE property. * * @param value *allowed object is [EMAIL PROTECTED] String } * */ public void setAGENT_TRANS_TYPE_CODE(String value) { this.AGENT_TRANS_TYPE_CODE = value; } public Map getOtherAttributes() { return otherAttributes; } } And this WSDL: http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:tm="http://microsoft.com/wsdl/mime/* *; * ** ** *
SOAPHeader and MustUnderstand
Hi all, i configure mu CXF with soap binding : this should add the needed interceptor for MustUnderstand check. But if i send i message like this: [java] http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> [java] [java] http://www.prova.it"; soapenv:mustUnderstand="1" >prova [java] prova2 [java] [java] [java] 234 [java] [java] to a simple echo service no MustUnderstood exception is raised.. What i missed?? After that, what i have to do in a jaxws handler to set an header as understood ? Thx for any help, /Lorenzo -- View this message in context: http://www.nabble.com/SOAPHeader-and-MustUnderstand-tp15269063p15269063.html Sent from the cxf-user mailing list archive at Nabble.com.
SOAPFaultException, maybe a bug in the framework?
I am trying to throw a SOAPFaultException from an handler. Anyway I have some
weird error in what I get back.
I have tried the same code on java 6 without CXF and the handler chain works
differently (with java 1.6 works fine)
This is the handleMessage on my custom SOAPHandler (the way I fill the
SOAPFault is taken from the SUN tutorial):
1) WITH JAVA 6:
public boolean handleMessage(SOAPMessageContext ctx) {
Boolean outboundProperty = (Boolean) ctx
.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);
if (!outboundProperty) {
SOAPMessage msg = ctx.getMessage();
SOAPBody body;
try {
body = msg.getSOAPBody();
SOAPFault fault = body.addFault();
QName faultName = new
QName(SOAPConstants.URI_NS_SOAP_ENVELOPE,
"Server");
fault.setFaultCode(faultName);
fault.setFaultActor("http://gizmos.com/orders";);
fault.setFaultString("Server not responding");
Detail detail = fault.addDetail();
QName entryName = new
QName("http://gizmos.com/orders/";,
"order", "PO");
DetailEntry entry =
detail.addDetailEntry(entryName);
entry.addTextNode("Quantity element does not
have a value");
QName entryName2 = new
QName("http://gizmos.com/orders/";,
"order", "PO");
DetailEntry entry2 =
detail.addDetailEntry(entryName2);
entry2.addTextNode("Incomplete address: no zip
code");
throw new SOAPFaultException(fault);
} catch (SOAPException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
return true;
}
and here is the log of the message sent back to the client. The SOAPFault is
populated correctly.
soapenv:Server
Server not responding
http://gizmos.com/orders
http://gizmos.com/orders/";>Quantity element does
not have a value
http://gizmos.com/orders/";>Incomplete address:
no zip code
2) WITH CXF + Java 5:
I have the same handler doing the same work. debugging the SOAPFault seems
to be populated correctly:
Anyway logging the answer here is what I get.
soap:Server
Server not responding
The actor and expecially the details are missing.
I have tried debugging the org.apache.cxf.jaxws.handler.HandlerChainInvoker,
but I was not abel to figure out if there is some error somewhere.
Do you think it is a bug or an hidden error of mine?
Thanks a lot.
Davide
--
View this message in context:
http://www.nabble.com/SOAPFaultException%2C-maybe-a-bug-in-the-framework--tp15269025p15269025.html
Sent from the cxf-user mailing list archive at Nabble.com.
Issue with CXF: Marshalling Error: Error writing request body to server
Hello! I have ran into a serious problem with CXF on the client side. I have tried quite a few things but I am right now quite stuck, and I hope that you guys have any suggestions. The full stacktrace is in this mail. I get the same error both with 2.0.3 and 2.0.4. Can it be an issue with JAXB, I am using jaxb-impl 2.0.5 from the sun-site. The following error is given when I invoke the web service method. SubmitDataService service = new SubmitDataService(); ISubmitData port = service.getSubmitDataPort(); boolean ret = port.submitData(setId, setName, fileName, getData(fileName), list); INFO: Interceptor has thrown exception, unwinding now org.apache.cxf.interceptor.Fault: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:207) at org.apache.cxf.jaxb.io.DataWriterImpl.write(DataWriterImpl.java:63) at org.apache.cxf.interceptor.AbstractOutDatabindingInterceptor.writeParts(AbstractOutDatabindingInterceptor.java:84) at org.apache.cxf.interceptor.BareOutInterceptor.handleMessage(BareOutInterceptor.java:68) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by: javax.xml.bind.MarshalException - with linked exception: [java.io.IOException: Error writing request body to server] at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:297) at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:221) at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:70) at org.apache.cxf.jaxb.JAXBEncoderDecoder.writeObject(JAXBEncoderDecoder.java:360) at org.apache.cxf.jaxb.JAXBEncoderDecoder.marshall(JAXBEncoderDecoder.java:187) ... 10 more Caused by: java.io.IOException: Error writing request body to server at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(HttpURLConnection.java:2261) at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:2244) at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:45) at org.apache.cxf.io.CacheAndWriteOutputStream.write(CacheAndWriteOutputStream.java:64) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.flushBuffer(UTF8XmlOutput.java:351) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:304) at com.sun.xml.bind.v2.runtime.unmarshaller.Base64Data.writeTo(Base64Data.java:263) at com.sun.xml.bind.v2.runtime.output.UTF8XmlOutput.text(UTF8XmlOutput.java:251) at com.sun.xml.bind.v2.runtime.XMLSerializer.leafElement(XMLSerializer.java:312) at com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl$PcdataImpl.writeLeafElement(RuntimeBuiltinLeafInfoImpl.java:140) at com.sun.xml.bind.v2.runtime.reflect.TransducedAccessor$CompositeTransducedAccessorImpl.writeLeafElement(TransducedAccessor.java:214) at com.sun.xml.bind.v2.runtime.property.SingleElementLeafProperty.serializeBody(SingleElementLeafProperty.java:62) at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:286) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:619) at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:113) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:98) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl$1.serializeBody(ElementBeanInfoImpl.java:127) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeBody(ElementBeanInfoImpl.java:244) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:251) at com.sun.xml.bind.v2.runtime.ElementBeanInfoImpl.serializeRoot(ElementBeanInfoImpl.java:33) at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:461) at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:292) ... 14 more Exception in thread "Main Thread" javax.xml.ws.soap.SOAPFaultException: Marshalling Error: Error writing request body to server at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:175) at $Proxy26.submitData(Unknown Source) at com.pointcarbon.mule.SubmitDataClient.main(SubmitDataClient.java:85) Caused by: org.a
FailoverFeature
Hi, Can anyone provide me a sample about utilizing FailoverFeature of CXF ? Thanks, -- View this message in context: http://www.nabble.com/FailoverFeature-tp15269002p15269002.html Sent from the cxf-user mailing list archive at Nabble.com.
Deploy my service implementation separately from my security configuration?
Hello, I am working with CXF 2.0.4 with javaFirst/Spring/CXF Servlet. I have the jaxws setup using Timestamp, Signature, and Encypt. I have some customized interceptors and a handler. This is all included in one war file (just like the demos) that I deploy to JBoss (and eventually Websphere). I was wondering if its possible to: - separate out my service implementation as one war file and my security configuration as another war file or - have my service endpoint be external from the same JVM that CXF is under (the internal endpoint is different from the published external endpoint). The goal is to keep the security settings "untouchable" when further maintenance/enhancements of the service methods goes forward. We don't want to have to worry about the security getting broken once we know that its working correctly. I believe that this is called "hardening" the security. Any suggestions/readings would really be appreciated.
RE: JSON and JAX-RS
Is it working for you now? I just added a system test testGetCDsJSON() in http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSClientServerBookTest.java?view=log. In this test, a CDs object is returned to the client side in JSON format. The CDs object contains a list of CD object. It works, not sure if this is similar to what you want to achieve. Cheers, Jervis > -Original Message- > From: Vespa, Anthony J [mailto:[EMAIL PROTECTED] > Sent: 2008年1月24日 0:33 > To: Daniel Kulp; cxf-user@incubator.apache.org > Subject: RE: JSON and JAX-RS > > Well it turned out that I had too many jaxb jars in my classpath so now > the xmlseealso works, but I get this odd exception as an invalid > namespace - I'm not quite sure why I'm getting it though, do I need to > specify another namespace somewhere? At this point, I'm not specifying > it anywhere - my bean.xml looks like... > > (for this service> > > > > > > > > > And the exception > > > INFO: Interceptor has thrown exception, unwinding now > java.lang.IllegalStateException: Invalid JSON namespace: > http://www.w3.org/2001/XMLSchema-instance > at > org.codehaus.jettison.mapped.MappedNamespaceConvention.getJSONNam > espace( > MappedNamespaceConvention.java:148) > at > org.codehaus.jettison.mapped.MappedNamespaceConvention.createAttribu > teKe > y(MappedNamespaceConvention.java:136) > at > org.codehaus.jettison.mapped.MappedXMLStreamWriter.writeAttribute(Ma > pped > XMLStreamWriter.java:89) > at > com.sun.xml.bind.v2.runtime.output.XMLStreamWriterOutput.attribute(XML > St > reamWriterOutput.java:133) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.attribute(XMLSerializer.java:4 > 31) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.j > ava:676) > at > com.sun.xml.bind.v2.runtime.property.ArrayElementNodeProperty.serializeI > tem(ArrayElementNodeProperty.java:65) > at > com.sun.xml.bind.v2.runtime.property.ArrayElementProperty.serializeListB > ody(ArrayElementProperty.java:168) > at > com.sun.xml.bind.v2.runtime.property.ArrayERProperty.serializeBody(Array > ERProperty.java:152) > at > com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInf > oImpl.java:322) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializ > er.java:589) > at > com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInf > oImpl.java:312) > at > com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java > :490) > at > com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:328 > ) > at > com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:1 > 75) > at > org.apache.cxf.jaxrs.provider.JSONProvider.writeTo(JSONProvider.java:90) > at > org.apache.cxf.jaxrs.interceptor.JAXRSOutInterceptor.handleMessage(JAXRS > OutInterceptor. > > -Original Message- > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 23, 2008 10:28 AM > To: cxf-user@incubator.apache.org > Cc: Vespa, Anthony J > Subject: Re: JSON and JAX-RS > > On Tuesday 22 January 2008, Vespa, Anthony J wrote: > > Interesting. Would that mean I would have to use seekAlso and list > > all of the objects that could possibly be returned - I have currently > > about six types of custom objects. What if I was returning a type > > like a boolean or just a string? > > You should be fine. (although, you probably need to wrapper them with a > JAXBElement to get the element name) I think all the stuff that maps > to straight xsd schema types are always part of the created JAXBContext. > > The stuff you need to be careful of are the things that would be > generated from the xjc. > > Dan > > > > > > > > > > From: Daniel Kulp [mailto:[EMAIL PROTECTED] > > Sent: Tue 1/22/2008 5:31 PM > > To: cxf-user@incubator.apache.org > > Cc: Vespa, Anthony J > > Subject: Re: JSON and JAX-RS > > > > > > > > > > Well, looking at the code, it seems to create a new JAXBContext for > > each top level type, which really sucks. IMO, it should use our > > JAXBDatabinding in some way which would allow it/you to configure > > things via spring or something so one one JAXBContext is created/used > > that would have all the required types in it. Actually, checking if > > there is an ObjectFactory in the package and creating the context > > based on that would also go a long way to helping. > > > > That said, with JAXB 2.1, you can probably add an @XmlSeeAlso > > annation on the wsResponse that points to the wsMessage to make the > > JAXBContext for the wsResponse be able to marshal the wsMessage as > > well. > > > > Dan > > > > On Tuesday 22 January 2008, Vespa, Anthony J wrote: > > > So I spent some time playing with JAX-RS and I seem to have
Re: CXFServlet
Hi Guillaume,
You could take a look at the CXFNonSpringServlet[1] for loading the bus
without spring library.
Now you just need to read the endpoint information for XML or some where.
Here is an example [you could also set the WSDL url, service and port
name as you like]:
public void buildEndpoint( Node node) throws ServletException {
Element el = (Element)node;
String implName = el.getAttribute("implementation");
String urlPat = el.getAttribute("url-pattern");
buildEndpoint(implName, urlPat);
}
public void buildEndpoint(String implName, String urlPat) throws
ServletException {
try {
Class cls = ClassLoaderUtils.loadClass(implName,
getClass());
ServerFactoryBean sf = new ServerFactoryBean();
sf.setBus(this.getBus());
sf.setServiceClass(serviceClass);
sf.setAddress("urlpat");
sf.getServiceFactory().setDataBinding(new AegisDatabinding());
sf.create();
} catch (Exception ex) {
throw new ServletException(ex);
}
}
[1]https://svn.apache.org/repos/asf/incubator/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/servlet/CXFNonSpringServlet.java
Willem.
tog wrote:
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: WSS4J - Protection Order
Hi Fred, Yes, making some changes in WSSecEncrypt, EncryptionAction and SignatureAction to process WSEncryptionPart instance allow us to process Signature over EncryptedData elements. Hence, in the message ReferenceList in Signature element refers to the wsu:id of the right EncryptedData element. I tested it with a sample which Encrypts and then Sign a Timestamp. This helps to process both Action="Signature Encrypt" and Action="Encrypt Signature" configuration options, when both EncryptParts and SignParts are referring to the same element. In context of WS-Security Policy, thus above change make us support "ProtectionOrder - SignBeforeEncrypting and EncryptBeforeSigning". With Regards, Mayank Mayank Mishra wrote: Hi Fred, Yes, sounds interesting. But consider a scenario when I have Sign-Encrypt-Sign or Encrypt-Sign-Encrypt to be done, then the same interceptor need to added twice (before and after the other one). A solution to this will be to see all Actions beforehand and then repeat adding interceptors for repeated Actions accordingly. Also since, we are seeking a generic solution, IMO this will be a bit overhead. Also, each designated WSS4JInterceptors will have their own data structures (cryptos, etc) leading to high memory overhead. The trade-off in the other solution (tweaking SecurityAction, EncryptionAction) is that we have to change WSS4J code. But, a solution to this issue will provide support for ProtectionOrder (SignBeforeEncrypting and EncryptBeforeSigning in WS-Security Policy spec), though not a concern right now. What are you thoughts? With Regards, Mayank Fred Dushin wrote: I see, interesting. In order to do this in a way that does not require a change to CXF, perhaps what you could do is split your encryption and signature actions into 2 separate interceptors, and add a third in between, which peeks at the result of the encryption action (the results object will be on the message), and then programatically configures the WS4JOutInterceptor, which will do the signature action for you. -Fred On Jan 23, 2008, at 12:41 AM, Mayank Mishra wrote: Hi Fred, Yes, you are right. I am talking about the scenario when we have multiple EncryptedData elements and I want to sign only one of them. Yes, I agree XPath would have been much better to handle such scenario. But AFAIK, we can specify parts (WSEncryptionPart) during SignatureAction by initializing part structure with element Id (I guess it is wsu:id, which we can get from map populated during encryptionAction). I am yet to test it. I will let you know about it. With Regards, Mayank Fred Dushin wrote: Hi Mayank, When you say "one way to achieve this is to specify the URI of the EncryptedData", do you mean QName, instead of URI? I get the sense from what you are saying that your message may have multiple EncryptedData elements in it, and you want to sign one, but not others. Is that right? If you have only one EncryptedData, then you should be able to direct the WSS4J toolkit to sign it, by specifying the EncryptedData QName, in configuration of the interceptor. Unfortunately, WSS4J does not provide XPath support for protecting (signing/encrypting) message parts, so using QNames is inherently ambiguous. -Fred On Jan 18, 2008, at 2:24 AM, Mayank Mishra wrote: Any reply to this thread will be highly appreciated. Thanking in advance, With Regards, Mayank Mayank Mishra wrote: Hi, Usually we use, Sign and then Encrypt action for any particular xml element. If I want to use Encrypt and then Sign for a particular xml element, then SignatureAction fails to find the xml element. The reason is it has been encrypted and hence corresponding EncryptedData element will be there. One way to achieve this, is to specify, URI of EncryptedData itself in the signature parts. (It should work, though I haven't tested it). But this is not a full proof solution if I want only specific element only to be encrypted and eventually signed. *Is there any mechanism to achieve this?* The only way I can think of achieving this is to maintain a list of wsu:id's of corresponding EncryptedData elements and add URI of them to Signature Parts during .SignatureAction. This may be performed in adding another interceptor which handles the message after encryption has been done. Please let me know your views/suggestions about this. Thanking in advance. :) With Regards, Mayank
RE: Issues with JSON based Service and Jettison
> -Original Message-
> From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> Sent: 2008年1月18日 5:38
> To: cxf-user@incubator.apache.org
> Subject: RE: Issues with JSON based Service and Jettison
>
> Jervis, I actually got it working end to end - once I added the namespace as a
> property in my jettison settings of my beans.xml - it works quite nicely and
> even deals with my wrapper/anytypes.
>
> Out of curiousity, there have been some oblique mentions here and there of
> having the incoming JSON parsed out into mapped variables, eg I have a
> JSON object named message with message: { id:1, name=foo} and a web
> service that takes id and name as params and outputs JSON - it seems from
> your previous emails this is not possible? That only the jettison system will
> work with one argumenet? Is this true of jax-rs as well?
>
[Liu, Jervis] Hi Tony, you've got this almost right. When a JSON object comes
in, it is transferred to a XML document first, for example,
"{"acme.Book":{"acme.name":"CXF in Action ","acme.id":"123 "}}" is transferred
to an org.w3c.dom.Document of CXF in
Action123. Then the XML document will be parsed and
mapped to request parameters of the target method following the JAX-WS spec.
Whether or not the XML document of CXF in
Action123 is mapped to a Book object or mapped to two
separate parameters of id and name is depending on doc/lit bare style or
doc/lit wrapped style. The one argument limitation does nothing with Jettison,
it comes from the implementation of CXF HTTP binding. JAX-RS does not have this
limitation, you can have multiple parameters for your resource method, for
example, one parameter mapped from http header, one from URL path variable, one
from Http body. Note the Http body can only be mapped to one parameter. This is
defined by JSR-311 spec.
> Thanks again for your guidance - it helped me a lot with the issues I was
> having. Once I get things settled, I'll try to write up a workable example
> for
> inclusion.
>
> -Tony
>
> -Original Message-
> From: Liu, Jervis [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 16, 2008 10:25 PM
> To: cxf-user@incubator.apache.org
> Subject: RE: Issues with JSON based Service and Jettison
>
> You got 'Invalid URL/Verb combination. Verb: POST Path: /message'
> exception when the combination of "Verb: POST" and "Path: /message" did
> not find a method from your service. Not sure why though as your service
> looks alright. You may want to paste out the initialization information when
> your server is starting up, it normally says sth like below:
>
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method getBook to resource /books/{id} and verb GET
> 2008-1-17 11:23:08 org.apache.cxf.endpoint.ServerImpl initDestination
> INFO: Setting the server's publish address to be
> http://localhost:9080/xmlwrapped
> 2008-1-17 11:23:08
> org.apache.cxf.service.factory.ReflectionServiceFactoryBean
> buildServiceFromClass
> INFO: Creating Service {http://book.acme.com}BookServiceService from
> class org.apache.cxf.customer.book.BookService
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method updateBook to resource /books/{id} and verb PUT
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method getBooks to resource /books and verb GET
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method getAnotherBook to resource /books/another/{id}
> and verb GET
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method addBook to resource /books and verb POST
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method getBook to resource /books/{id} and verb GET
> 2008-1-17 11:23:08 org.apache.cxf.binding.http.strategy.JRAStrategy map
> INFO: Mapping method deleteBook to resource /books/{id} and verb DELETE
> 2008-1-17 11:23:08 org.apache.cxf.endpoint.ServerImpl initDestination
> INFO: Setting the server's publish address to be http://localhost:9080/json
>
>
> > -Original Message-
> > From: Vespa, Anthony J [mailto:[EMAIL PROTECTED]
> > Sent: 2008年1月17日 0:05
> > To: cxf-user@incubator.apache.org
> > Subject: RE: Issues with JSON based Service and Jettison
> >
> > So after some thought and tweaking I adjusted my JSON service, but I am
> > getting the 'Invalid URL/Verb combination. Verb: POST Path: /message'
> > exception.
> >
> > My service looks like this:
> >
> > @WebService(targetNamespace = "http://com.cbs.bos.ws.json";)
> > public interface BoardService {
> > @Post
> > @HttpResource(location = "/message")
> > public wsResponse getMessage(
> > @WebParam(name = "message")wsMessage message);
> >
> > }
> >
> > I am using this javascript:
> >
> > var json = {"wsMessage":{"messageId":"1"}};
> >
> > new Ajax.Request($F('url'), {
> > asynchronous: false,
>
