[jira] [Commented] (CXF-4241) Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
[ https://issues.apache.org/jira/browse/CXF-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255378#comment-13255378 ] Aki Yoshida commented on CXF-4241: -- Hi, are you saying the soap fault from a request-response service is not interpreted by the client? The soap fault in this case should be interpreted fully by the client. Could it be that your case is about a oneway service? Regards, aki > Http Conduit doesnt honor soap fault if server sends with 400 or 500 error > -- > > Key: CXF-4241 > URL: https://issues.apache.org/jira/browse/CXF-4241 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.4.6 > Environment: Linux;JDK 1.6.25 >Reporter: kanagamahendran Velusamy > Labels: conduit, http > > We have a situation where server sends Soap-fault with 400(http error) > however cxf throws exception saying that "400: Bad Request" without the > details of the message. > my point is, even though server sends 400 or 500, CXF should read the message > and if it is soap fault,it should construct soap fault not just the exception > . in this way we are not restricting server to send the soap fault in 200 OK > level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4126) Can override built-in action on WSS4JOutInterceptor but seems impossible to add a new custom action on WSS4JOutInterceptor
[ https://issues.apache.org/jira/browse/CXF-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255435#comment-13255435 ] Freeman Fang commented on CXF-4126: --- Hi, I just commit a testcase which demonstrate adding new custom action on WSS4JOutInterceptor also works. I guess the key part you MIGHT miss is that if you add a custom action with new key int number 12345, you must also put action name as string "12345". Take a look at the testAddCustomAction() to get more details. http://svn.apache.org/viewvc?rev=1326956&view=rev for trunk http://svn.apache.org/viewvc?rev=1326959&view=rev for 2.5.x branch http://svn.apache.org/viewvc?rev=1326963&view=rev for 2.4.x branch http://svn.apache.org/viewvc?rev=1326967&view=rev for 2.3.x branch Freeman > Can override built-in action on WSS4JOutInterceptor but seems impossible to > add a new custom action on WSS4JOutInterceptor > > > Key: CXF-4126 > URL: https://issues.apache.org/jira/browse/CXF-4126 > Project: CXF > Issue Type: Test > Components: WS-* Components > Environment: any >Reporter: isdor sobze >Assignee: Freeman Fang > Labels: patch > > CXF documentation at [http://cxf.apache.org/docs/ws-security.html (#Custom > Action)]claims that you can configure WSS4JOutInterceptor to override a > built-in action with a custom actions or add your own custom action. > Overriding built-in action works fine, but adding a new action does not. The > current WSS4JOutInterceptor Java code > probably need modifications to allow adding own custom actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4126) Can override built-in action on WSS4JOutInterceptor but seems impossible to add a new custom action on WSS4JOutInterceptor
[ https://issues.apache.org/jira/browse/CXF-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-4126. --- Resolution: Fixed Fix Version/s: 2.3.11 2.4.8 2.5.4 2.6.1 > Can override built-in action on WSS4JOutInterceptor but seems impossible to > add a new custom action on WSS4JOutInterceptor > > > Key: CXF-4126 > URL: https://issues.apache.org/jira/browse/CXF-4126 > Project: CXF > Issue Type: Test > Components: WS-* Components > Environment: any >Reporter: isdor sobze >Assignee: Freeman Fang > Labels: patch > Fix For: 2.6.1, 2.5.4, 2.4.8, 2.3.11 > > > CXF documentation at [http://cxf.apache.org/docs/ws-security.html (#Custom > Action)]claims that you can configure WSS4JOutInterceptor to override a > built-in action with a custom actions or add your own custom action. > Overriding built-in action works fine, but adding a new action does not. The > current WSS4JOutInterceptor Java code > probably need modifications to allow adding own custom actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4242) Add exception name to faultstring/detail/stackTrace
Add exception name to faultstring/detail/stackTrace --- Key: CXF-4242 URL: https://issues.apache.org/jira/browse/CXF-4242 Project: CXF Issue Type: Improvement Components: Soap Binding Reporter: Alessio Soldano When using faultStackTraceEnabled = true and exceptionMessageCauseEnabled = true, it's have the soap message enriched with the exception that caused a fault to be generated. The stackTrace element, though, does not include the (class) name of the exception that's been thrown. I tried a naive fix (i.e. adding sb.append(throwable.getClass().getCanonicalName() + " : " + throwable.getMessage() + "\n"); into the AbstractSoapInterceptor::prepareStackTrace(..) method), but it seems the whole fix for CXF-3445 should be revisited (including client side). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4191) RM broken in synchronous Mode
[ https://issues.apache.org/jira/browse/CXF-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4191. -- Resolution: Fixed Fix Version/s: 2.5.4 2.6.1 Fixed the issue for 2.6.1 and 2.5.4 and added a test case in systests/ws-rm//SequenceTest. This could be ported down to 2.4.x with some manual adjustment if necessary. > RM broken in synchronous Mode > - > > Key: CXF-4191 > URL: https://issues.apache.org/jira/browse/CXF-4191 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 2.4.6 > Environment: CXF 2.4.6, Jdk5 (Jrockit), spring 2.5, maven2, eclipse > 3.7, Win xp >Reporter: Ben Pezzei >Assignee: Aki Yoshida >Priority: Critical > Labels: Ws-RM, rm > Fix For: 2.6.1, 2.5.4 > > > RM-Setup without a decoupled endpoint (therefore: synchronous modus) > Client is configured with: > includeOffer=true, > SequenceTerminationPolicyType.maxLength=1 > AcknowledgementInterval=0 > Server accepts Offers, wsrm-policy:AcknowledgementInterval=0 > pseudo-Log: > Req 1: createSequence with offer 123 and > acksTo:http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous > Res 1: CreateSequenceResponse with seqid 456 > Req 2: Sequence with Id 456 & lastMessage-flag & actual content > Res 2: Sequence with Id 123 & lastMessage-flag & SequenceAcknowledgement for > Id 456 & actual content > Req 3: TerminateSequence for Id 456 > Res 3: standard rm header > Req 4: SequenceAck for 123 > Req 5: standard rm header > Res 5: standard rm header > Req 6 from Server: terminateSequence for 123 to w3c.org > There is another "feature": When the server PortImpl throws an Exception, > Request/Response goes as follows: > Req 1: createSequence with offer 123 and > acksTo:http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous > Res 1: CreateSequenceResponse with seqid 456 > Req 2: Sequence with Id 456 & lastMessage-flag & actual content > Res 2: Sequence with 456 & lastMessage, Action: NullpointerException, > soap:body contains FaulCode & faultstring > After receiving the response, client throws UnknownSequence: The value of > wsrm:Identifier is not a known Sequence identifier. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4126) Can override built-in action on WSS4JOutInterceptor but seems impossible to add a new custom action on WSS4JOutInterceptor
[ https://issues.apache.org/jira/browse/CXF-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255566#comment-13255566 ] Isdor Sobze/NYLIC commented on CXF-4126: It works. The key part as you said is that the key int number 12345 you must also put action name as string "1235". The apache cxf documentation at ( http://cxf.apache.org/docs/ws-security.html) probably needs to be updated with this information. Thanks for your help. Isdor Sobze AVP Architecture 212-576-5945 From: "Freeman Fang (Commented) (JIRA)" To: iso...@newyorklife.com Date: 04/17/2012 05:53 AM Subject:[jira] [Commented] (CXF-4126) Can override built-in action on WSS4JOutInterceptor but seems impossible to add a new custom action on WSS4JOutInterceptor [ https://issues.apache.org/jira/browse/CXF-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255435#comment-13255435 ] Freeman Fang commented on CXF-4126: --- Hi, I just commit a testcase which demonstrate adding new custom action on WSS4JOutInterceptor also works. I guess the key part you MIGHT miss is that if you add a custom action with new key int number 12345, you must also put action name as string "12345". Take a look at the testAddCustomAction() to get more details. http://svn.apache.org/viewvc?rev=1326956&view=rev for trunk http://svn.apache.org/viewvc?rev=1326959&view=rev for 2.5.x branch http://svn.apache.org/viewvc?rev=1326963&view=rev for 2.4.x branch http://svn.apache.org/viewvc?rev=1326967&view=rev for 2.3.x branch Freeman to add a new custom action on WSS4JOutInterceptor (#Custom Action)]claims that you can configure WSS4JOutInterceptor to override a built-in action with a custom actions or add your own custom action. The current WSS4JOutInterceptor Java code -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira > Can override built-in action on WSS4JOutInterceptor but seems impossible to > add a new custom action on WSS4JOutInterceptor > > > Key: CXF-4126 > URL: https://issues.apache.org/jira/browse/CXF-4126 > Project: CXF > Issue Type: Test > Components: WS-* Components > Environment: any >Reporter: isdor sobze >Assignee: Freeman Fang > Labels: patch > Fix For: 2.6.1, 2.5.4, 2.4.8, 2.3.11 > > > CXF documentation at [http://cxf.apache.org/docs/ws-security.html (#Custom > Action)]claims that you can configure WSS4JOutInterceptor to override a > built-in action with a custom actions or add your own custom action. > Overriding built-in action works fine, but adding a new action does not. The > current WSS4JOutInterceptor Java code > probably need modifications to allow adding own custom actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4241) Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
[ https://issues.apache.org/jira/browse/CXF-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255565#comment-13255565 ] kanagamahendran Velusamy commented on CXF-4241: --- This is request-response service: when the server sends the soap fault with 400 http code this is what the error we get from CXF javax.xml.ws.WebServiceException: Could not send Message. at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) at $Proxy41.updateUserProfile(Unknown Source) at com.payconnexion.ws.client.PConClient.main(PConClient.java:72) Caused by: org.apache.cxf.transport.http.HTTPException: HTTP response '400: Bad Request' when communicating with https://ws.vitechinc.com at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1502) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1448) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1356) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:614) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:484) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:414) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:269) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:124) ... 2 more What we receive is the perfect soap fault message,unfortunately CXF doesnt translate to soap fault instead of Exception. > Http Conduit doesnt honor soap fault if server sends with 400 or 500 error > -- > > Key: CXF-4241 > URL: https://issues.apache.org/jira/browse/CXF-4241 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.4.6 > Environment: Linux;JDK 1.6.25 >Reporter: kanagamahendran Velusamy > Labels: conduit, http > > We have a situation where server sends Soap-fault with 400(http error) > however cxf throws exception saying that "400: Bad Request" without the > details of the message. > my point is, even though server sends 400 or 500, CXF should read the message > and if it is soap fault,it should construct soap fault not just the exception > . in this way we are not restricting server to send the soap fault in 200 OK > level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4241) Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
[
https://issues.apache.org/jira/browse/CXF-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255601#comment-13255601
]
Aki Yoshida commented on CXF-4241:
--
Hi,
Okay. I suppose you have this problem for status 400 but not for 500.
Being aligned with Basic Profile[1], the soap fault is expected for status 500
in default by CXF.
To accept the soap fault for other error status like 400, you can set the
context property
org.apache.cxf.http.no_io_exceptions to true at your client endpoint.
In java, assuming port is your client proxy, you can get its request context
and set this property:
((BindingProvider)port).getRequestContext().put("org.apache.cxf.http.no_io_exceptions",
"true");
or in jaxws endpoint you can set the property within the jaxws:properties block.
...
regards, aki
1. http://www.ws-i.org/profiles/basicprofile-1.1-2004-08-24.html
> Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
> --
>
> Key: CXF-4241
> URL: https://issues.apache.org/jira/browse/CXF-4241
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 2.4.6
> Environment: Linux;JDK 1.6.25
>Reporter: kanagamahendran Velusamy
> Labels: conduit, http
>
> We have a situation where server sends Soap-fault with 400(http error)
> however cxf throws exception saying that "400: Bad Request" without the
> details of the message.
> my point is, even though server sends 400 or 500, CXF should read the message
> and if it is soap fault,it should construct soap fault not just the exception
> . in this way we are not restricting server to send the soap fault in 200 OK
> level.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CXF-4243) RequestImpl.selectVariant() using wrong headers
RequestImpl.selectVariant() using wrong headers
---
Key: CXF-4243
URL: https://issues.apache.org/jira/browse/CXF-4243
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 2.3.1
Environment: cxf-rt-frontend-jaxrs-2.3.1
Reporter: sharath p
Priority: Minor
org.apache.cxf.jaxrs.impl.RequestImpl
**
public Variant selectVariant(List vars) throws
IllegalArgumentException {
if (vars == null || vars.isEmpty()) {
throw new IllegalArgumentException("List of Variants is either null
or empty");
}
MediaType inMediaType = headers.getMediaType();
Locale inLang = headers.getLanguage();
String inEnc =
headers.getRequestHeaders().getFirst(HttpHeaders.CONTENT_ENCODING);
.
}
**
In order to select the correct variant (conneg), Accept-* headers should be
used, therefore headers.getAcceptableMediaTypes(),
headers.getAcceptableLanguages() and
headers.getRequestHeaders().getFirst(ACCEPT_ENCODING) should be used instead of
headers.getMediaType(), headers.getLanguage() and
headers.getRequestHeaders().getFirst(HttpHeaders.CONTENT_ENCODING).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (CXF-4240) CXF WSN cannot run offline in Karaf
Hmm... I kind of expect the catalog to work, but not completely surprised
that it doesn't. that involves classloader resource lookups which is
definitely an issue in OSGi.
I'll look more next week (on vacation this week) unless someone jumps on it
before then. However, if you're going through the trouble to rebuild the
bundles, you COULD try adding a wsdlLocation attribute to the impls (based
on a classpath: url) and see if that helps. Just something to try.
Dan
On Monday, April 16, 2012 10:27:55 PM Christoph Emmersberger wrote:
> Dear all,
>
> I tried to resolve this issue by doing the following:
>
> (1) Created a jax-ws-catalog file
>
>
> PUBLIC "-//OASIS/DTD Entity Resolution XML Catalog V1.0//EN"
>
> "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
> prefer="system"> systemIdStartString="http://www.w3.org/2006/03/addressing";
> rewritePrefix="classpath:/org/apache/cxf/wsn/wsdl"/> systemIdStartString="http://www.w3.org/2005/08/addressing";
> rewritePrefix="classpath:/org/apache/cxf/wsn/wsdl"/>
>
> (2) Adjusted the build pom of the wsn-core project
>
>
> org.apache.cxf.wsn.util.*;version=${project.version},
> !org.apache.cxf.wsn*,
> !org.apache.activemq*,
> javax.xml.bind*;version="[0.0,3)",
> javax.jws*;version="[0.0,3)",
> javax.xml.ws*;version="[0.0,3)",
> org.apache.cxf*;version=${project.version},
> org.apache.cxf.wsn.wsdl,
> *
>
>
> (3) Run a rebuild of wsn-core
>
> Unfortunately without success. Am I missing a point to resolve this issue?
>
> Many thanks and kind regards,
>
> Christoph
>
> On 16.04.2012, at 15:48, Zsolt Beothy-Elo (Created) (JIRA) wrote:
> > CXF WSN cannot run offline in Karaf
> > ---
> >
> > Key: CXF-4240
> > URL: https://issues.apache.org/jira/browse/CXF-4240
> >
> > Project: CXF
> >
> > Issue Type: Bug
> > Components: Services
> >
> >Affects Versions: 2.5.2, 2.6
> >
> > Environment: jdk 1.6, Karaf 2.2.5
> >
> >Reporter: Zsolt Beothy-Elo
> >
> > I am running cxf within Karaf. If am without connection to Maven Central
> > and try to install and start the feature cxf-wsn I get the following
> > exception:
> >
> > {noformat}
> > org.osgi.service.blueprint.container.ComponentDefinitionException:
> > Unable to intialize bean createPullPoint>
> > at
> > org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRe
> > cipe.java:638)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRec
> > ipe.java:724)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.jav
> > a:64)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.di.RefRecipe.internalCreate(RefRecipe.java:
> > 60)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.jav
> > a:64)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BlueprintRepository.createInstanc
> > es(BlueprintRepository.java:219)[10:org.apache.aries.blueprint:0.3.1]
> > at
> > org.apache.aries.blueprint.container.BlueprintRepository.createInstanc
> > e(BlueprintRepository.java:198)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BlueprintRepository.create(Bluepr
> > intRepository.java:137)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.ServiceRecipe.createRecipe(Servic
> > eRecipe.java:370)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.ServiceRecipe.createService(Servi
> > ceRecipe.java:278)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(
> > ServiceRecipe.java:248)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(Serv
> > iceRecipe.java:140)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.jav
> > a:64)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BlueprintRepository.createInstanc
> > es(BlueprintRepository.java:219)[10:org.apache.aries.blueprint:0.3.1]
> > at
> > org.apache.aries.blueprint.container.BlueprintRepository.createAll(Blu
> > eprintRepository.java:147)[10:org.apache.aries.blueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiat
> > eEagerComponents(BlueprintContainerImpl.java:640)[10:org.apache.aries.b
> > lueprint:0.3.1] at
> > org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(Blue
> > printContainerImpl.java:331)[10:org.apache.aries.bluepr
[jira] [Created] (CXF-4244) OutTransformWriter's defaultNamespace setting may not replace all default namespace declarations
OutTransformWriter's defaultNamespace setting may not replace all default namespace declarations Key: CXF-4244 URL: https://issues.apache.org/jira/browse/CXF-4244 Project: CXF Issue Type: Bug Components: Core Affects Versions: 2.5.3 Reporter: Aki Yoshida Assignee: Aki Yoshida Fix For: 2.6.1, 2.5.4 With CXF-4176, OutTransformWriter preserves the namespace prefixes except for the empty prefix (i.e., the default namespace) in a special case, namely when OutTransformWriter's defaultNamespace property is set to a non-null string to assign the empty prefix for a different namespace. Given an input XML: http://bar";>1 when the defaultNamespace property is set to e.g., "", the output should look like: http://bar";>1 However, the output XML instead resulted as: http://bar"; xmlns="http://bar";>1 Logically, this is still valid. However, the intention of this property is lost. Thus, it needs to be corrected to generate the expected output. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4244) OutTransformWriter's defaultNamespace setting may not replace all default namespace declarations
[ https://issues.apache.org/jira/browse/CXF-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4244. -- Resolution: Fixed > OutTransformWriter's defaultNamespace setting may not replace all default > namespace declarations > > > Key: CXF-4244 > URL: https://issues.apache.org/jira/browse/CXF-4244 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 2.5.3 >Reporter: Aki Yoshida >Assignee: Aki Yoshida > Fix For: 2.6.1, 2.5.4 > > > With CXF-4176, OutTransformWriter preserves the namespace prefixes except for > the empty prefix (i.e., the default namespace) in a special case, namely when > OutTransformWriter's defaultNamespace property is set to a non-null string to > assign the empty prefix for a different namespace. > Given an input XML: > http://bar";>1 > when the defaultNamespace property is set to e.g., "", the output should look > like: > http://bar";>1 > However, the output XML instead resulted as: > http://bar"; xmlns="http://bar";>1 > Logically, this is still valid. However, the intention of this property is > lost. Thus, it needs to be corrected to generate the expected output. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4241) Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
[ https://issues.apache.org/jira/browse/CXF-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255920#comment-13255920 ] kanagamahendran Velusamy commented on CXF-4241: --- This helps. Thank you...! > Http Conduit doesnt honor soap fault if server sends with 400 or 500 error > -- > > Key: CXF-4241 > URL: https://issues.apache.org/jira/browse/CXF-4241 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.4.6 > Environment: Linux;JDK 1.6.25 >Reporter: kanagamahendran Velusamy > Labels: conduit, http > > We have a situation where server sends Soap-fault with 400(http error) > however cxf throws exception saying that "400: Bad Request" without the > details of the message. > my point is, even though server sends 400 or 500, CXF should read the message > and if it is soap fault,it should construct soap fault not just the exception > . in this way we are not restricting server to send the soap fault in 200 OK > level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4241) Http Conduit doesnt honor soap fault if server sends with 400 or 500 error
[ https://issues.apache.org/jira/browse/CXF-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aki Yoshida resolved CXF-4241. -- Resolution: Not A Problem Assignee: Aki Yoshida explained how the client endpoint can be configured to process soap faults with http status other than 500. > Http Conduit doesnt honor soap fault if server sends with 400 or 500 error > -- > > Key: CXF-4241 > URL: https://issues.apache.org/jira/browse/CXF-4241 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 2.4.6 > Environment: Linux;JDK 1.6.25 >Reporter: kanagamahendran Velusamy >Assignee: Aki Yoshida > Labels: conduit, http > > We have a situation where server sends Soap-fault with 400(http error) > however cxf throws exception saying that "400: Bad Request" without the > details of the message. > my point is, even though server sends 400 or 500, CXF should read the message > and if it is soap fault,it should construct soap fault not just the exception > . in this way we are not restricting server to send the soap fault in 200 OK > level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-4126) Can override built-in action on WSS4JOutInterceptor but seems impossible to add a new custom action on WSS4JOutInterceptor
[ https://issues.apache.org/jira/browse/CXF-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256145#comment-13256145 ] Freeman Fang commented on CXF-4126: --- Sure, wiki get updated accordingly. > Can override built-in action on WSS4JOutInterceptor but seems impossible to > add a new custom action on WSS4JOutInterceptor > > > Key: CXF-4126 > URL: https://issues.apache.org/jira/browse/CXF-4126 > Project: CXF > Issue Type: Test > Components: WS-* Components > Environment: any >Reporter: isdor sobze >Assignee: Freeman Fang > Labels: patch > Fix For: 2.6.1, 2.5.4, 2.4.8, 2.3.11 > > > CXF documentation at [http://cxf.apache.org/docs/ws-security.html (#Custom > Action)]claims that you can configure WSS4JOutInterceptor to override a > built-in action with a custom actions or add your own custom action. > Overriding built-in action works fine, but adding a new action does not. The > current WSS4JOutInterceptor Java code > probably need modifications to allow adding own custom actions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
