Re: Does anyone uses a wadl-to-java inheritResourceParams ?
Could we change the flag to: -inheritResourceParams[=first|last] where it would default to first on 3.x and last on 2.7.x, but the user could explicitly set it depending on their needs/compatibility requirements? Dan On Aug 14, 2014, at 7:01 AM, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi CXF WADL to Java generator supports an option for the parent resource parameters be added into the current method signature, it is called inheritResourceParams. It can help with minimizing the duplication across the whole WADL document. Alexey Markevich opened an enhancement request [1] to do with making the order in which the current and inherited parameters are generated, currently they are added to the end of the signature, I agree [1] makes sense for the inherited parameters to be in the top of the method parameter list. Ideally we'd have it fixed in CXF 2.7.x too but it may break some of the signatures if inheritResourceParams is used. So the question to the users who work with wadl-to-java, does anyone use this parameter ? We will merge to 3.0.2 and 3.1.0-SNAPSHOT for a start and push it down to 2.7.x if we do not get any confirmations about 2.7.x... Thanks, Sergey [1] https://issues.apache.org/jira/browse/CXF-5948 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache CXF with WS-Security
On Aug 14, 2014, at 4:58 PM, Dennis Sosnoski d...@sosnoski.com wrote: Hi Paul, I think I see what's going on here. Your AuthenticationDiacapEndpoint_policy which specifies the use of RM and AsymmetricBinding doesn't set anything to be signed, instead leaving that to the individual input and output policies (such as AuthenticationDiacapEndpoint_Activate_Input_policy). But because RM isn't using one of those specified inputs or outputs it doesn't get a policy that says the body should be signed. Dan, how do you think this should be handled? We obviously want to be compatible with WCF, but I'm not sure how it should be implemented. Hmm…. that’s a very good point. I’m not sure either. If it’s picking up policies from the Input, and with that wsdl, the CreateSequence call could have different security requirements depending on which was the first operation you were trying to call. I cannot imaging that being a good thing. Not even sure how we could implement that. On the client side, we could use the current operation to get the operation policy and use it. On the service side, no idea as we’d have NO idea which operation was the intended target. The simple workaround if you want to try something is to copy the wsdl locally and update the AuthenticationDiacapEndpoint_policy to move the sp:SignedParts and sp:EncryptedParts assertions directly into it. That SHOULD work. Dan - Dennis On 08/15/2014 04:30 AM, Longsine, Pohl wrote: On 8/13/14 4:32 PM, Daniel Kulp dk...@apache.org wrote: The policy has a sp:EncryptSignature/ assertion in it so I would have expected the signatures to be encrypted. The CXF request has two ncryptedData elements which MAY correspond to the two Signatures that the .NET client is sending. No really sure though as I don¹t know what is in the encrypted data. You could try removing that rom the policy and see if CXF does something different. At the very least, it may show the Signatures. That said, there is still an issue. I don¹t see a wsu:Id on the soap:Body. Thus, it doesn¹t look like CXF is signing the Body like it should be. Actully, I don¹t see the Id on the and of the WS-A headers either. It would be good to see what CXF is signing. Or at least hat is in the encrypted data. Dan Dan, I really appreciate your attention here. Thank you. I askd the .NET team to make the specific change that you requested (removing the EncryptSignature assertio from their WSDL). They must have not been able to do such a small, targeted change. Instead, the made the following change, which had the side-effect of the EncryptSignature no longer beng there. That said, a few other small things in the WSDL also changed, perhaps not in a way that matters For reference, here's what they say they changed: I¹ve changed the message security versio to be an older version (WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecuity Policy11BasicSecurityProfile10 instead of WSSecurity11WSTrustFebruary2005WSScureConversationFebruary2005WSSecurityP olicy11) Now our soap request has Signature element in it, although the id attributes that you noted were absent ar still not there. The end result, from a soap fault perspective, is the same. Doe this help you analyze what is going wrong here? - CXF SOAP REQUEST - soap:Envelope xmlns:soap=http://www.w3.org/2003/05/soap-envelope; soap:Header Action xmlns=http://www.w3.org/2005/08/addressing; http:/docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence /Action MessageID xmlnshttp://www.w3.org/2005/08/addressing;urn:uuid:421e07a9-4fa4-4984-86 28-c4298b0fa3b1 /MessageID To xmlns=http://www.w3.org/2005/08/addressing;https://services.gallup.com/OM S/V2/Diacap/Autentication.svc /To ReplyTo xmlns=http://www.w3.org/2005/08/addressing; Addresshttp://www.w3.org/2005/08/addressing/anonymous/Address /ReplyTo wss:Security xmlns:wsse=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecur ity-secext-1.0.xsd xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri ty-utility-1.0.xsd soap:mustUnderstand=true wsu:Timestamp wsu:Id=TS-fd886f00-f83a-49cc-98e6-ed726c946b4f wsu:Created2014-08-14T6:12:04.392Z/wsu:Created wsu:Expires2014-08-14T16:17:04.392Z/wsu:Expires /wsu:Timestamp wsse:BinarySecurityToken EncodingType=http://dos.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- message-security-1.0#Base64Binary ValueType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-tok en-profle-1.0#X509v3 wsu:Id=X509-0bef70e2-c2fd-4f38-b91e-b69f19e02c12 MIGmzCCBgSgAwIBAgIKWp2aTQAEAAHP4DANBgkqhkiG9w0BAQUFADBYMRMwEQYKCZImiZPyLGQ
Re: returning exception from In AbstractPhaseInterceptor
You could likely just mimic what the AbstractInvoker does in your interceptor. Something like: message.put(FaultMode.class, FaultMode.CHECKED_APPLICATION_FAULT); throw new Fault(ex); Dan On Aug 13, 2014, at 2:04 PM, New Groovy newtogro...@gmail.com wrote: Hi, If the code in our SOAP services throw an exception, we get an exception returned. However, we have an In interceptor that runs in PRE_INVOKE, that needs to also return an exception. However, throwing it from there results in a SOAPFaultException for the caller, and there doesn't seem to be a way to retrieve the underlying exception. Is there a way to do this? Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: returning exception from In AbstractPhaseInterceptor
On Aug 13, 2014, at 4:02 PM, New Groovy newtogro...@gmail.com wrote: Is it supposed to work with a RuntimeException, setting UNCHECKED_APPLICATION_FAULT? If I do that, I see the SOAPFaultException… If what you throw is not a fault that’s declared on the operation, you will always get s SOAPFaultException on the client side. The information in the wsdl (and/or throws clauses of the operation) are the only things examined when mapping the fault from the soap message to an exception to be thrown. If they don’t match, the more generic SOAPFaultException is thrown. Dan On Wed, Aug 13, 2014 at 2:31 PM, Daniel Kulp dk...@apache.org wrote: You could likely just mimic what the AbstractInvoker does in your interceptor. Something like: message.put(FaultMode.class, FaultMode.CHECKED_APPLICATION_FAULT); throw new Fault(ex); Dan On Aug 13, 2014, at 2:04 PM, New Groovy newtogro...@gmail.com wrote: Hi, If the code in our SOAP services throw an exception, we get an exception returned. However, we have an In interceptor that runs in PRE_INVOKE, that needs to also return an exception. However, throwing it from there results in a SOAPFaultException for the caller, and there doesn't seem to be a way to retrieve the underlying exception. Is there a way to do this? Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Enquiry about xsd:import in WSDL
On Aug 12, 2014, at 11:22 PM, Yee Long ccyyll8...@yahoo.com wrote: Hi All, Currently am using java first approach for xfire to cxf migration. The WSDL generated by cxf is having the following: xsd:import namespace=some_name_space_1/ xsd:import namespace=some_name_space_2/ Any chance I may put all these imports in the wsdl:definitions tag like what XFire did? wsdl:definitions targetNamespace=some_target_namespace xmlns:ns1=some_name_space_1 xmlns:ns2=some_name_space_2 / I really don’t know what your trying to do here.The xsd:imports are required within the xsd:schema elements for each namespace that it uses within that schema. That has nothing to do with the namespace prefix declarations. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache CXF with WS-Security
On Aug 13, 2014, at 5:06 PM, Longsine, Pohl pohl_longs...@gallup.com wrote: I am replying to my own question to provide one more interesting piece of information, in hopes of helping someone read and interpret what is going on here. I asked the .NET team to capture the SOAP messag from their own test client (also written in .NET) that is able to hit their service. Their SOAP turns out to be very different from the SOAP that CXF is sending. I don't fully understand the significance of the difference. Does anybody else? The policy has a sp:EncryptSignature/ assertion in it so I would have expected the signatures to be encrypted. The CXF request has two EncryptedData elements which MAY correspond to the two Signatures that the .NET client is sending. Not really sure though as I don’t know what is in the encrypted data. You could try removing that from the policy and see if CXF does something different. At the very least, it may show the Signatures. That said, there is still an issue. I don’t see a wsu:Id on the soap:Body. Thus, it doesn’t look like CXF is signing the Body like it should be. Actually, I don’t see the Id on the and of the WS-A headers either. It would be good to see what CXF is signing. Or at least what is in the encrypted data. Dan SOAP request sent by the .NET test client -- ?xml version=1.0 encoding=utf-8? s:Envlope xmlns:s=http://www.w3.org/2003/05/soap-envelope; xmlns:a=http://www.w3.org/2005/08/addressing; xmlns:u=http://docs.oasis-open.org/ws/2004/01/oasis-200401-wss-wssecurity -utility-1.0.xsd s:Header a:Action s:mustUnderstand=1 u:Id=_2http://docs.oasis-open.org/ws-rx/wsrm/200702/CreateSequence/a:Ac tion a:MessageID u:Id=_3urn:uuid:884474d9-cd4d-4115-90f4-c71950dfe7a5/a:MessageID ActivityId xmlns=http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics; CorrelationId=6a2389dc-dfef-4471-b19c-a7efa267cfbf8aae0965-193d-44cb-919 1-e58c7bb7981a/ActivityId a:To s:mustUnderstand=1 u:Id=_4http://orfdinsjx75w7.noam.example.org/oms.wcfAuthentication.svc /a:To o:Security xmlns:o=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity -secext-1.0.xsd s:mustUnderstand=1 u:Timestamp u:Id=uuid-1d0f9d6b-d23b-4fc8-907c-5608e5790d1a-2 u:Created2014-08-13T20:41:28.877Z/u:Created u:Expires2014-08-13T20:46:28.877Z/u:Expires /u:Timestamp e:EncryptedKey xmlns:e=http://www.w3.org/2001/04/xmlenc#; Id=uuid-1d0f9d6b-d23b-4fc8-907c-5608e5790d1a-1 e:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p; DigestMethod xmlns=http://www.w3.org/2000/09/xmldsig#; Algorithm=http://www.w3.org/2000/09/xmldsig#sha1/ /e:EncryptionMethod KeyInfo xmlns=http://www.w3.org/2000/09/xmldsig#; o:SecurityTokenReference o:KeyIdentifier ValueType=http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1 .1#ThumbprintSHA1 EncodingType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- message-security-1.0#Base64BinaryZEZnwmqU/vov3xQpP6wQ97Up+lU=/o:KeyIdent ifier /o:SecurityTokenReference /KeyInfo e:CipherData e:CipherValueJPYB5r5XId/i7Zas89KUR2zdeMYWwjHKqaBHoGEE4mMwYD5FxnhfoU3 6z/s0kiavd89v6HmF6/gmiVnBANehhL4HI7OQXuVbqO2oV96i/5uVk+/6K1X0a+4Nh18GiMCA/3 wC0n/Sd+XIwL5zkhiCXxWPHtZC/v0Qqf5Q8PHS/AI=/e:CipherValue /e:CipherData /e:EncryptedKey o:BinarySecurityToken u:Id=uuidfbcbb4d7-e8b8-41fa-84ab-0f6639304603-1 ValueType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-tok en-profile-1.0#X509v3 EcodingType=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap- message-security-1.0#Base64BinaryMIIEtTCCBB6gAwIBAgIKYHwluwAEAAHQLTANBgkq hkiG9w0BAQUFADBYMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGZ2FsbHV wMRQwEgYKCZImiZPyLGQBGRYEbm9hbTETMBEGA1UEAxMKbm9hbXN1YmNhMTAeFw0xNDA0MDIyMD E4MDBaFw0xNTEyMTYxNzQ0MTRaMBgxFjAUBgNVBAMMDXdjZl9kZXZlbG9wZXIwgZ8wDQYJKoZIh vcNAQEBBQADgY0AMIGJAoGBAJRMLWEBneNo0RZ9gQADXtKN27H523sadm7uLA4HPKuSi2Ocld3f DFhb4OYnRRucjvrk1Ui5V5OOrOm7cWDrGF1IqCpOX+rJK5CgJsI8vAJgo8OinrFHWRhap9TaPrI 6b7nCuVqKww04fMNKCh8BX9+Oe82u6s1MmQBagH90BM9AgMBAAGjggLEMIICwDAhBgkrBgEEAY I3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMBMGA1UdJQQMMAoGCCsGAQUFBwMBMAsGA1UdDwQEA wIFoDAdBgNVHQ4EFgQUmth0i3QPZpXdMW2eCdZ6gfLQYBowHwYDVR0jBBgwFoAU35Hnqpq4WXm0
Re: [Cxf-Interceptor] @InInterceptor/@OutInterceptor annotations ignored (JBoss 5.1.0, not 6 or 7)
You would need to ask about this on the JBoss lists. They have their own
class loaders and integration things and such that can dictate some of the
behavior around this.
Dan
On Aug 11, 2014, at 3:18 PM, Aida ai.d...@gmail.com wrote:
Hi all,
I have been googling and reading threads of this forum in order to solve
this ...
I'm working with JBoss 5.1.0 GA, and I have EJBs as services (EJB 3.0). I'm
trying to use the @InInterceptor and @OutInterceptor annotations in order to
add a WSS4J interceptor (I want to sign and encrypt my messages).
I have read that in further versions of JBoss (as 6.X or 7.X) the
annotations are ignored as is commented in [1]. In [2] says that a
Dependency is needed in a Manifest file, but this is for JBoss AS 7 (not my
version, anyway adding the Manifest as specified doesn´t works).
I have checked that when I call to my web-service, the interceptor that I
add with the annotation isn´t called. I have also tried with other CXF
Interceptors (ReadHeadersInterceptor), but no interceptor (set by me) is
fired.
This is my service (I'm working with a proof of concept, but I'm not able to
make it work):
@InInterceptors(interceptors =
{mypackage.WSSWithCertificateInInterceptor})
@WebService( name = HelloWorldService,
serviceName = HelloWorldService,
targetNamespace = http://mydomain/service/samples/;)
@Stateless(name = HelloWorldService)
@BindingType(value = SOAPBinding.SOAP12HTTP_BINDING)
public class HelloWorldServiceImpl {
private static String HELLO_WORLD_MESSAGE = Hello world {0};
/**
* Hello World Operation
*/
@WebMethod
public String helloWorld(@WebParam(name = name) String name){
return MessageFormat.format(HELLO_WORLD_MESSAGE, name);
}
}
Where WSSWithCertificateInInterceptor is just an extension of
WSS4JInInterceptor:
public class WSSWithCertificateInInterceptor extends WSS4JInInterceptor{
private static MapString,Object inProps= new HashMapString,Object()
{
/** generated UUID */
private static final long serialVersionUID =
-7905172475428802888L;
{
put(WSHandlerConstants.ACTION, WSHandlerConstants.SIGNATURE);
put(WSHandlerConstants.SIG_PROP_FILE, server_sign.properties);
}
};
public WSSWithCertificateInInterceptor () {
super(inProps);
}
}
(I know this isn´t maybe the best way ... but with the annotations I didn´t
know how to set the props and I preferred to make the important work first).
If anyone could help (or give a clue about why the interceptors are not
firing) I would be thankful.
Thanks in advance.
KR,
Aida
[1]
http://cxf.547215.n5.nabble.com/CXF-WSS4J-Interceptors-not-working-td5727229.html#a5727488
[2] https://docs.jboss.org/author/display/JBWS/JBoss+Modules
--
View this message in context:
http://cxf.547215.n5.nabble.com/Cxf-Interceptor-InInterceptor-OutInterceptor-annotations-ignored-JBoss-5-1-0-not-6-or-7-tp5747625.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WS-SecureConversation not working with .NET client
I know on 3.0.x, this change was needed to support the new StAX based WS-Security processing. We needed to know up front which type of crypto’s and such we need to setup for the stax code to use. Not sure why this was needed on 2.7.x. Colm is on vacation this week so I’ll have to wait for him to get back to follow up about that. I just pushed some changes (to all three branches) that will detect this case and if the action isn’t there will add an additional interceptor to the chain to handle things later after the WS-Addressing stuff has been parsed. On 3.0.x, this will also then turn off the StAX based ws-security processing and use the DOM based processing. Not ideal, but it should at least allow this to work until I can chat with Colm about this a bit more. Dan On Aug 11, 2014, at 4:51 PM, Freddy Exposito expos...@gmail.com wrote: Hi, I have a .NET client trying to do WS-SecureConversation against a CXF Service and it is not working. It was working fine until this commit 8c40b37ab7fd41482ea4f1e42b4993703ee6be29 https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=commit;h=8c40b37ab7fd41482ea4f1e42b4993703ee6be29 where the SecureConversationInInterceptor was moved from PRE_PROTOCOL to PRE_STREAM phase. What is failing for me now is that the SecureConversationInInterceptor is not able to get the addressing properties JAXWSAConstants.SERVER_ADDRESSING_PROPERTIES_INBOUND required to 'get' the SoapAction when dealing with //MS/WCF. What I believe is happening is that this properties is set in the ContextUtils.storeMaps() ( exec ContextUtils.getMAPProperty() ) method invoked from the MAPCodec interceptor but this interceptor is still in PRE_PROTOCOL phase, so now it is not being triggered before the SecureConversationInInterceptor which is now in PRE_STREAM. Is it something wrong with .NET integration in CXF or I am missing something in the configuration? Thanks, Freddy -- View this message in context: http://cxf.547215.n5.nabble.com/WS-SecureConversation-not-working-with-NET-client-tp5747626.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: RPCOutInterceptor.java //WSI-BP R2211 - RPC/Lit parts are not allowed to be xsi:nil
On Aug 4, 2014, at 8:59 AM, neela neelambal.shankaralin...@aspect.com wrote:
Hi,
I am not a expert but by WSI-BP R2211 i think null is not allowed when its
boolean.
The WSI-BP R2211 is as below:
R2211 An ENVELOPE described with an rpc-literal binding MUST NOT have the
xsi:nil attribute with a value of 1 or true on the part accessors.
So throwing a Fault when any input is null is not correct. (I think for
string types we can have null)
Umm.. How? An empty part accessor (like myValue /) is still not null.
That’s an empty string.
This looks correct to me. There isn’t a way to send a null as a parameter
with RPC/Lit according to the WSI-BP spec. The exception is correct.
Dan
if (o == null) {
//WSI-BP R2211 - RPC/Lit parts are not allowed to be
xsi:nil
throw new Fault(
new
org.apache.cxf.common.i18n.Message(BP_2211_RPCLIT_CANNOT_BE_NULL,
LOG,
part.getConcreteName()));
}
Please verify and if this qualifies for a JIRA.
Thanks in advance.
Regards,
Neela
--
View this message in context:
http://cxf.547215.n5.nabble.com/RPCOutInterceptor-java-WSI-BP-R2211-RPC-Lit-parts-are-not-allowed-to-be-xsi-nil-tp5747317.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Must use JDK 7 to build 3.0.1?
On Aug 4, 2014, at 9:41 PM, Wei SD Zhang w...@cn.ibm.com wrote: When I tried to build 3.0.1 with JDK 6, I got an error from maven javac: invalid target release: 1.7. And I checked pom.xml, found targetJdk1.7/targetJdk. Does 3.0.1 use any JDK 7 specific feature? Are you sure you grabbed 3.0.1 and not the 3.1.0-SNAPSHOTs? I just checked the 3.0.x-fixes branch and it says: dkulp@macbook ~/working/cxf-git $ git grep targetJdk parent/pom.xml:targetJdk1.6/targetJdk 3.1.x will definitely require Java7. 3.0.x will be the last line to still support Java6. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Could not find conduit initiator for transport
On Jul 31, 2014, at 6:00 AM, axelF cale...@orange.fr wrote: Well we solved our problem. And I have to admit: shame on us! we just used the CXF-Bundle dependency (v2.7.12)... And everything works perfectly now. Sorry to have bothering you Daniel. Well, keep in mind that the cxf-bundle dependency is gone starting with 3.0.0. Thus, if you upgrade in the future, you will need to deal with the individual jars that provide the needed functionality. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Could not find conduit initiator for transport
Open up your jar and make sure the META-INF/cxf/bus-extensions.txt file has a BUNCH of things in it. If it only has a few things, then your shading isn’t working correctly. Dan On Jul 30, 2014, at 12:19 PM, axelF cale...@orange.fr wrote: Hi. We are using CXF in a maven assembly standalone Jar application (SWT) as client. When we are calling services from IDE, everything work properly. Although when we lauching the application from executable jar, we have this exception: We are using maven assembly for the build. here our pom.xml -- View this message in context: http://cxf.547215.n5.nabble.com/Could-not-find-conduit-initiator-for-transport-tp5747091.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: How to retrieve return value in out interceptor?
Move your interceptor up into the PRE_LOGICAL with a addBefore(WrapperClassOutInterceptor.class.getName()). The list should then just have the return value (and any holders for other outs). The WrapperClassOutInterceptor combines those into the asm generate object. Dan On Jul 27, 2014, at 10:47 PM, New Groovy newtogro...@gmail.com wrote: Hi, I want to filter some return values in an out interceptor, but am struggling to figure out how to retrieve it. I have tried this: MessageContentsList outObjects = MessageContentsList.getContentsList(message); Exchange exchange = message.getExchange(); OperationInfo op = exchange.getBindingOperationInfo() == null ? null : exchange.getBindingOperationInfo().getOperationInfo(); and see a lot of info...but can't figure out how to retrieve the _return value I see in the xxx.jaxws_asm Any pointers? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Message.INBOUND_MESSAGE in PREPARE_SEND_ENDING Interceptor
For this use case, I’d suggest using the MessageUtils.isRequestor(msg) call. Dan On Jul 27, 2014, at 4:56 PM, zsolt.szloboda zsolt.szlob...@gmail.com wrote: I have a CXF service, which is also a WS client of other services I have a PREPARE_SEND_ENDING Interceptor configured in my service (which is invoked both when sending a request as a client, and when returning a response as a server; so it is invoked twice) in the interceptor I would like to figure out which of these two invocations is the current invocation I thought I could use the Message's INBOUND_MESSAGE attribute (which is a Boolean); to my surprise, it returns NULL, when returning the response as server (and returns false, when sending the request as a client) isn't it a bug in CXF, that the Message's INBOUND_MESSAGE attribute is NULL? or am I missing something? -- View this message in context: http://cxf.547215.n5.nabble.com/Message-INBOUND-MESSAGE-in-PREPARE-SEND-ENDING-Interceptor-tp5746968.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Using CXF with Https Proxy
I think the HOST header might be set down deep in the URLConnection call someplace. Not really sure. Here’s my suggestion: Create an instance of org.apache.cxf.transport.https.HttpsURLConnectionFactory and call the createConnection method in it passing in a Proxy object and TLSClientParameters (if needed) and the URL. Use that HttpURLConnection to try and do a post of a sample message to the server. If you can get that to work via request properties or similar, then we may be able to get things updated to match whatever you get working. Dan On Jul 24, 2014, at 10:37 AM, Oliver Becherer i...@oliver-becherer.name wrote: hi, i assume this scenario is quite unusal (regarding answers), so i tried to find a valid workaround and currently i'm trying it like this : Client client = ClientProxy.getClient(MYWEBSERVICEPORT); client.getRequestContext().put(Message.ENDPOINT_ADDRESS, https://some-weird-https-proxy.com;) ; this is working fine so far, but to tell the proxy where he has to deliver the message to, i'd had to modify http protocol header, especially the Host variable. - unfortunately it seems, as if the Host Variable in http header is overwritten somewhere dep into the Interceptor Chain or at least in Transport layer - my custom interceptor is setting Host Variable, but within outgoing Request, its again overwritten from framework Could somebody please direct me , how i can avoid, that cxf is automatically setting http header Host variable? thanks a lot! kind regards O Am 23.07.2014 um 21:57 schrieb Oliver Becherer i...@oliver-becherer.name: hi all, i'm just stuck with a problem using cxf : i implemented a soap client to a webservice using cxf 2.6.1 and its working fine... now i have the challenge of sending one single service operation to the usual endpoint but over a proxy server that only accepts https. so these are the base facts : Service Endpoint : https://some-usual-soap-endpoint.com Proxy Server : https://some-weird-https-proxy.com Proxy Port : This is my approach : HTTPClientPolicy policy = new HTTPClientPolicy(); policy.setProxyServer(some-weird-https-proxy.com); policy.setProxyServerPort(); Client client = ClientProxy.getClient(awspt); HTTPConduit http = (HTTPConduit) client.getConduit(); http.setClient(policy); so far so good, but the requests are reaching the proxy not using https, but http and the proxy is not accepting this. can you help me, how to configure the Proxy Server within my Client, so Request is sent using https? any help is highly appreciated! kind regards O -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: cxf transformation feature - could code be ported and used in Camel?
On Jul 23, 2014, at 12:35 PM, Lowry lowry.cu...@gmail.com wrote: The CXF transformation feature provides a nice way to declaratively specifiy certain simple transformations, element names, adds elements, changes namespace, etc. It makes it easy to describe the transformation in a map in Spring XML. I haven't found anything similar to declare transformation with Apache Camel. I tried using CXF xformation feature with camel but found to be tightly tied to the CXF endpoint rather any arbitrary location within a camel route. So, would it be difficult to write a camel component that possibly re-uses CXF code org.apache.cxf.feature.StaxTransformFeature and underlying code ? It shouldn’t be too hard. In camel, you should be able to do a convertBodyTo(XMLStreamReader.class) or message.getBody(XMLStreamReader.class) or similar and then call the org.apache.cxf.staxutils.transform.InTransformReader constructor with the appropriate maps. I don’t think anything in org.apache.cfx.staxutils.transform has any dependency on any of the endpoint settings, annotations, etc… Simple thing might be to create a Processor in Camel that would do much the same as the transformationFeature stuff in CXF. Would take a couple Maps of properties and wrappers the XMLStreamReader/Writers. You could then easily configure that processor on the route. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF do not generate operation parameters
This is due to:
https://issues.apache.org/jira/browse/CXF-5888
which I fixed yesterday. Too late for 2.7.12/3.0.1 though.
Dan
On Jul 18, 2014, at 9:24 AM, Thomas Manson dev.mansontho...@gmail.com wrote:
Note :
Seems like a CXF issue, Work around provided by Daniel Kulp that did solve
the issue is to add a parameter : (bareMethods)
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
extraarg-bareMethods=executeQuery/extraarg
/extraargs
/wsdlOption
Thomas.
On Fri, Jul 11, 2014 at 4:37 PM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Hi CXF !
I'm using CXF 2.7.0 to generate the client for the attached WSDL (de.zip)
with the following options :
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
/extraargs
/wsdlOption
The generated client is missing argument on one operation, while if I use
SOAPUI or another priopriatery tool, I can see the arguments.
For example, with SOAPUI 4.5.2 :
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:res=http://resourcequery.api.de.n2.tibco.com;
soapenv:Header/
soapenv:Body
res:executeQuery model-version=-1 implementation=1
queryresource(name='tibco-admin')/query
/res:executeQuery
/soapenv:Body
/soapenv:Envelope
CXF generated client the following :
public interface ResourceQueryService {/**
* Execute a Resource Query Language (RQL) query to find a set of
resources that match specific criteria.
*/
@WebResult(name = resource, targetNamespace = )
@RequestWrapper(localName = executeQuery, targetNamespace =
http://resourcequery.api.de.n2.tibco.com;, className =
com.tibco.n2.common.organisation.api.XmlExecuteQuery)
@WebMethod(action = executeQuery)
@ResponseWrapper(localName = executeQueryResponse, targetNamespace
= http://resourcequery.api.de.n2.tibco.com;, className =
com.tibco.n2.de.api.resourcequery.ExecuteQueryResponse)
public
java.util.Listcom.tibco.n2.de.api.resourcequery.XmlSimpleResource
executeQuery() throws InvalidQueryFault, SecurityFault,
InvalidOrgModelVersionFault, NoSuchNamedEntityFault,
InvalidServiceRequestFault, InternalServiceFault;
}
where you can see that the executeQuery() has no argument.
Any idea what's going wrong ?
I would rather not touch the WSLD, so I wonder if there's some options
available on CXF that would allow the parameters to be generated.
What's weird is that there's other method signature quite more complexe
that are generated successfully.
I'll try to generated the client with the latest version of CXF, but last
time I tried, It failed... (expected another thread for me on this subject
then ;))
Thanks for your help,
Thomas.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF do not generate operation parameters
On Jul 18, 2014, at 10:12 AM, Thomas Manson dev.mansontho...@gmail.com wrote:
Thanks Daniel for the bug fix and feedback !
So it should be included in the following version right ? (2.7.13 and 3.0.2)
Yep. But with 3.0.1 being voted on now, it will likely be a little while.
Dan
Regards,
Thomas.
On Fri, Jul 18, 2014 at 3:59 PM, Daniel Kulp dk...@apache.org wrote:
This is due to:
https://issues.apache.org/jira/browse/CXF-5888
which I fixed yesterday. Too late for 2.7.12/3.0.1 though.
Dan
On Jul 18, 2014, at 9:24 AM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Note :
Seems like a CXF issue, Work around provided by Daniel Kulp that did
solve
the issue is to add a parameter : (bareMethods)
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
extraarg-bareMethods=executeQuery/extraarg
/extraargs
/wsdlOption
Thomas.
On Fri, Jul 11, 2014 at 4:37 PM, Thomas Manson
dev.mansontho...@gmail.com
wrote:
Hi CXF !
I'm using CXF 2.7.0 to generate the client for the attached WSDL
(de.zip)
with the following options :
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
/extraargs
/wsdlOption
The generated client is missing argument on one operation, while if I
use
SOAPUI or another priopriatery tool, I can see the arguments.
For example, with SOAPUI 4.5.2 :
soapenv:Envelope xmlns:soapenv=
http://schemas.xmlsoap.org/soap/envelope/;
xmlns:res=http://resourcequery.api.de.n2.tibco.com;
soapenv:Header/
soapenv:Body
res:executeQuery model-version=-1 implementation=1
queryresource(name='tibco-admin')/query
/res:executeQuery
/soapenv:Body
/soapenv:Envelope
CXF generated client the following :
public interface ResourceQueryService {/**
* Execute a Resource Query Language (RQL) query to find a set of
resources that match specific criteria.
*/
@WebResult(name = resource, targetNamespace = )
@RequestWrapper(localName = executeQuery, targetNamespace =
http://resourcequery.api.de.n2.tibco.com;, className =
com.tibco.n2.common.organisation.api.XmlExecuteQuery)
@WebMethod(action = executeQuery)
@ResponseWrapper(localName = executeQueryResponse, targetNamespace
= http://resourcequery.api.de.n2.tibco.com;, className =
com.tibco.n2.de.api.resourcequery.ExecuteQueryResponse)
public
java.util.Listcom.tibco.n2.de.api.resourcequery.XmlSimpleResource
executeQuery() throws InvalidQueryFault, SecurityFault,
InvalidOrgModelVersionFault, NoSuchNamedEntityFault,
InvalidServiceRequestFault, InternalServiceFault;
}
where you can see that the executeQuery() has no argument.
Any idea what's going wrong ?
I would rather not touch the WSLD, so I wonder if there's some options
available on CXF that would allow the parameters to be generated.
What's weird is that there's other method signature quite more complexe
that are generated successfully.
I'll try to generated the client with the latest version of CXF, but
last
time I tried, It failed... (expected another thread for me on this
subject
then ;))
Thanks for your help,
Thomas.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Need help to review a pom.xml to generate a client with CXF 2.7.11
We’d need to see the WSDL. Dan On Jul 15, 2014, at 9:06 AM, Thomas Manson dev.mansontho...@gmail.com wrote: Thanks Daniel, Removing this dependencies did solve the problem. However, going for CXF 2.7.11 didn't solve my original problem described in this post: CXF do not generate operation parameters where the arguments of a method is not generated with CXF while it's usable in SAOPUI and one other propriatary tool. Can you have a look ? Thanks, Thomas. On Fri, Jul 11, 2014 at 9:21 PM, Daniel Kulp dk...@apache.org wrote: Remove the cxf-common-utilities dependency entirely. That hasn’t existed for a long time. Dan On Jul 11, 2014, at 11:03 AM, Thomas Manson dev.mansontho...@gmail.com wrote: Hi, I'm trying to use a newer version of CXF to generate a client to see if it solves an issue that I have with 2.7.0. I don't know where to find the equivalent of the following library used in my pom.xml : groupIdorg.apache.cxf/groupId artifactIdcxf-codegen-plugin/artifactId dependencies dependency groupIdorg.apache.cxf.xjcplugins/groupId artifactIdcxf-xjc-ts/artifactId version2.6.1/version /dependency dependency groupIdorg.apache.cxf/groupId artifactIdcxf-common-utilities/artifactId version2.5.10/version /dependency dependency groupIdorg.apache.cxf/groupId artifactIdcxf-rt-databinding-jaxb/artifactId version2.7.5/version /dependency /dependencies I've checked cxf-common-utilities on maven repo, it's one year old in its last version 2.5.11, while CXF 2.7.11 has been released in April this year. Could you help me to sort out which version/maven artifact I should use to have a consistent configuration and use the very last version of the 2.7.X branch ? Thanks, Thomas. pom.xml -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Need help to review a pom.xml to generate a client with CXF 2.7.11
We’d need the full WSDL and all the imports what you have is missing some
stuff. The first missing one is comexception.xsd.
Dan
On Jul 15, 2014, at 11:20 AM, Thomas Manson dev.mansontho...@gmail.com wrote:
Hi Daniel,
it's attached to my first mail (on the other post), but maybe it has been
removed by the mailing list system.
You can get it here :
https://drive.google.com/file/d/0Bz-ZrfMHlBlHc3JIUVFqclBfcHZVSFFNQUxxMVR4SEFtWVJV/edit?usp=sharing
Here is the original email :
###
Hi CXF !
I'm using CXF 2.7.0 to generate the client for the attached WSDL (de.zip)
with the following options :
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
/extraargs
/wsdlOption
The generated client is missing argument on one operation, while if I use
SOAPUI or another priopriatery tool, I can see the arguments.
For example, with SOAPUI 4.5.2 :
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:res=http://resourcequery.api.de.n2.tibco.com;
soapenv:Header/
soapenv:Body
res:executeQuery model-version=-1 implementation=1
queryresource(name='tibco-admin')/query
/res:executeQuery
/soapenv:Body
/soapenv:Envelope
CXF generated client the following :
public interface ResourceQueryService {/**
* Execute a Resource Query Language (RQL) query to find a set of
resources that match specific criteria.
*/
@WebResult(name = resource, targetNamespace = )
@RequestWrapper(localName = executeQuery, targetNamespace =
http://resourcequery.api.de.n2.tibco.com;, className
= com.tibco.n2.common.organisation.api.XmlExecuteQuery)
@WebMethod(action = executeQuery)
@ResponseWrapper(localName = executeQueryResponse, targetNamespace =
http://resourcequery.api.de.n2.tibco.com;, className
=com.tibco.n2.de.api.resourcequery.ExecuteQueryResponse)
public java.util.Listcom.tibco.n2.de.api.resourcequery.XmlSimpleResource
executeQuery() throws InvalidQueryFault, SecurityFault,
InvalidOrgModelVersionFault, NoSuchNamedEntityFault,
InvalidServiceRequestFault, InternalServiceFault;
}
where you can see that the executeQuery() has no argument.
Any idea what's going wrong ?
I would rather not touch the WSLD, so I wonder if there's some options
available on CXF that would allow the parameters to be generated.
What's weird is that there's other method signature quite more complexe
that are generated successfully.
I'll try to generated the client with the latest version of CXF, but last
time I tried, It failed... (expected another thread for me on this subject
then ;))
Thanks for your help,
Thomas.
On Tue, Jul 15, 2014 at 3:13 PM, Daniel Kulp dk...@apache.org wrote:
We’d need to see the WSDL.
Dan
On Jul 15, 2014, at 9:06 AM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Thanks Daniel,
Removing this dependencies did solve the problem.
However, going for CXF 2.7.11 didn't solve my original problem described
in this post:
CXF do not generate operation parameters
where the arguments of a method is not generated with CXF while it's
usable
in SAOPUI and one other propriatary tool.
Can you have a look ?
Thanks,
Thomas.
On Fri, Jul 11, 2014 at 9:21 PM, Daniel Kulp dk...@apache.org wrote:
Remove the cxf-common-utilities dependency entirely. That hasn’t existed
for a long time.
Dan
On Jul 11, 2014, at 11:03 AM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Hi,
I'm trying to use a newer version of CXF to generate a client to see if
it solves an issue that I have with 2.7.0.
I don't know where to find the equivalent of the following library used
in my pom.xml :
groupIdorg.apache.cxf/groupId
artifactIdcxf-codegen-plugin/artifactId
dependencies
dependency
groupIdorg.apache.cxf.xjcplugins/groupId
artifactIdcxf-xjc-ts/artifactId
version2.6.1/version
/dependency
dependency
groupIdorg.apache.cxf/groupId
artifactIdcxf-common-utilities/artifactId
version2.5.10/version
/dependency
dependency
groupIdorg.apache.cxf/groupId
artifactIdcxf-rt-databinding-jaxb/artifactId
version2.7.5/version
/dependency
/dependencies
I've checked cxf-common-utilities on maven repo, it's one year old in
its last version 2.5.11, while CXF 2.7.11 has been released in April
this
year.
Could you help me to sort out which version/maven artifact I should use
to have a consistent configuration and use the very last version of the
2.7.X branch ?
Thanks,
Thomas.
pom.xml
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
Re: Need help to review a pom.xml to generate a client with CXF 2.7.11
I’m not really sure what’s “wrong” yet. That method SHOULD be detected as
having to be a “BARE” method and not unwrapped to individual params. For some
reason, that detection isn’t triggering so it’s trying to unwrap the
XmlExecuteQuery object, but since XmlExecuteQuery cannot be unwrapped, it’s not
ending up with anything.
The “simple” workaround for now would be to add
bareMethodsbareMethodexecuteQuery/bareMethod/bareMethods to the
configuration to force it into that mode. That shouldn’t be required as the
detection should detect it, but that should at least get you moving.
Dan
On Jul 15, 2014, at 12:36 PM, Thomas Manson dev.mansontho...@gmail.com wrote:
Sorry,
here is the full WSDL (and plenty of other ones)
https://drive.google.com/file/d/0Bz-ZrfMHlBlHWWhxOURDOFNISW8/edit?usp=sharing
Thanks,
Thomas.
On Tue, Jul 15, 2014 at 5:27 PM, Daniel Kulp dk...@apache.org wrote:
We’d need the full WSDL and all the imports what you have is missing some
stuff. The first missing one is comexception.xsd.
Dan
On Jul 15, 2014, at 11:20 AM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Hi Daniel,
it's attached to my first mail (on the other post), but maybe it has been
removed by the mailing list system.
You can get it here :
https://drive.google.com/file/d/0Bz-ZrfMHlBlHc3JIUVFqclBfcHZVSFFNQUxxMVR4SEFtWVJV/edit?usp=sharing
Here is the original email :
###
Hi CXF !
I'm using CXF 2.7.0 to generate the client for the attached WSDL (de.zip)
with the following options :
wsdlOption
wsdl${basedir}/src/main/resources/de.wsdl/wsdl
extraargs
extraarg-xjc-Xts/extraarg
extraarg-autoNameResolution/extraarg
/extraargs
/wsdlOption
The generated client is missing argument on one operation, while if I use
SOAPUI or another priopriatery tool, I can see the arguments.
For example, with SOAPUI 4.5.2 :
soapenv:Envelope xmlns:soapenv=
http://schemas.xmlsoap.org/soap/envelope/;
xmlns:res=http://resourcequery.api.de.n2.tibco.com;
soapenv:Header/
soapenv:Body
res:executeQuery model-version=-1 implementation=1
queryresource(name='tibco-admin')/query
/res:executeQuery
/soapenv:Body
/soapenv:Envelope
CXF generated client the following :
public interface ResourceQueryService {/**
* Execute a Resource Query Language (RQL) query to find a set of
resources that match specific criteria.
*/
@WebResult(name = resource, targetNamespace = )
@RequestWrapper(localName = executeQuery, targetNamespace =
http://resourcequery.api.de.n2.tibco.com;, className
= com.tibco.n2.common.organisation.api.XmlExecuteQuery)
@WebMethod(action = executeQuery)
@ResponseWrapper(localName = executeQueryResponse, targetNamespace
=
http://resourcequery.api.de.n2.tibco.com;, className
=com.tibco.n2.de.api.resourcequery.ExecuteQueryResponse)
public
java.util.Listcom.tibco.n2.de.api.resourcequery.XmlSimpleResource
executeQuery() throws InvalidQueryFault, SecurityFault,
InvalidOrgModelVersionFault, NoSuchNamedEntityFault,
InvalidServiceRequestFault, InternalServiceFault;
}
where you can see that the executeQuery() has no argument.
Any idea what's going wrong ?
I would rather not touch the WSLD, so I wonder if there's some options
available on CXF that would allow the parameters to be generated.
What's weird is that there's other method signature quite more complexe
that are generated successfully.
I'll try to generated the client with the latest version of CXF, but last
time I tried, It failed... (expected another thread for me on this
subject
then ;))
Thanks for your help,
Thomas.
On Tue, Jul 15, 2014 at 3:13 PM, Daniel Kulp dk...@apache.org wrote:
We’d need to see the WSDL.
Dan
On Jul 15, 2014, at 9:06 AM, Thomas Manson dev.mansontho...@gmail.com
wrote:
Thanks Daniel,
Removing this dependencies did solve the problem.
However, going for CXF 2.7.11 didn't solve my original problem
described
in this post:
CXF do not generate operation parameters
where the arguments of a method is not generated with CXF while it's
usable
in SAOPUI and one other propriatary tool.
Can you have a look ?
Thanks,
Thomas.
On Fri, Jul 11, 2014 at 9:21 PM, Daniel Kulp dk...@apache.org wrote:
Remove the cxf-common-utilities dependency entirely. That hasn’t
existed
for a long time.
Dan
On Jul 11, 2014, at 11:03 AM, Thomas Manson
dev.mansontho...@gmail.com
wrote:
Hi,
I'm trying to use a newer version of CXF to generate a client to see
if
it solves an issue that I have with 2.7.0.
I don't know where to find the equivalent of the following library
used
in my pom.xml :
groupIdorg.apache.cxf/groupId
artifactIdcxf-codegen-plugin
Re: web service with void method returning 202
On Jul 14, 2014, at 10:16 AM, sanjeevghimire gsanje...@gmail.com wrote: Yes, wsdl is being loaded. there is no such reference to one-way in the WSDL. If the operation has an input message but no output message, then, by definition, it’s a one-way operation. If you want a response other than a 202 Accepted to be sent back, you need to update the WSDL to have an output message. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WS-Addressing example from CXF 3.0.0
On Jul 10, 2014, at 5:17 PM, Iván Brencsics ivan.brencs...@gmail.com wrote: Hi Daniel, Please correct me if I am wrong, but one task of a web service stack is to route incoming SOAP requests to the right processing Java method. When using document style SOAP services, the basic solution is to do this routing based on the type of the message in the SOAP body. This is the concept of JAXWS too. Correct. After working with Spring WS I understood that the same routing can be done based on the wsa:Action value. In Spring WS a method can be annotated one of the following ways: 1) @PayloadRoot(localPart = orderRequest, namespace = http://samples;) or 2) @Action(http://samples/CreateOrder”) Same can be done with JAX-WS with the @javax.xml.ws.Action annotation and/or the @RequestWrapper (if using WRAPPED) or @WebParam if not. So in case of 1) if there is an incoming SOAP request where the body has the specified fully qualified name, the request is processed in this method. In 2) if there is an incoming SOAP request with this wsa:Action, it is routed to this method. For me this model makes more sense then the JAXWS approach, where we generate a SEI, implement it, and route the SOAP requests based on the SOAP body. In my opinion this is a very nice feature of Spring WS. The same can be done with JAX-WS. However, in general, it’s a ton easier to “get right” if you use the code generator to generate the SEI so that none of the actions and namespaces and such are typed in wrong.Things have to exactly match what the wsdl contains. Dont you think this has been one of the ideas of wsa:Action, to provide an alternative way of SOAP message routing? Digging through the code, we actually DO determine the operation to invoke based on the Action if it’s present and something else (like the SOAPAction) hasn’t already determined it. However, if we cannot find an operation based on the Action, we then continue and try and determine it based on the contents of the body. If the contents of the body don’t agree with the operation determined by the Action, then an exception is thrown. However, if we cannot determine the operation based on the Action and we are able to figure out an operation based on the payload, we don’t throw any sort of exception due to an invalid Action. I did just try adding an exception for this an all kinds of tests are failing. The main reason is that with JAX-WS, you can turn on WS-Addressing for any endpoint relatively easily (@Addressing annotation or feature), but if the methods don’t have @Action annotations, the action that is generated can vary depending on how the client was created and the setup of the WSDL. For example, even without the @Action, if the client is created with a wsdlLocation and the wsdl contains the appropriate wsam:Action attributes, it will use them. If they don’t contain the attributes, it will generate one, but the algorithm for the generated Action depends on if the wsdl:input contains a name attribute or not (it’s optional). If the client is NOT created from a WSDL, the it will also generate an Action, but again, the algorithm for that may result in something different than what the service expects. This applies to publishing a service as well. Thus, you can easily get a bit mix-matched between client/service depending on how they are created. Dan Regards, Ivan 2014-07-10 21:12 GMT+02:00 Daniel Kulp dk...@apache.org: On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza demablo...@gmail.com wrote: 2014-07-10 15:21 GMT+02:00 Daniel Kulp dk...@apache.org: In general, CXF routes requests based on the target URI/address, not the Action, although there are some exceptions to that…. In general, CXF only allows a single endpoint to be deployed on a specific address. Through the MultipleEndpointObserver stuff, it’s possible to do it, but it’s not exactly easy. So… where is the Action used? Under normal circumstances, the Action will be looked at by various interceptors on the chain that may be looking for a specific Action. For example, if WS-RM is configured, the RM interceptors will be looking for Actions that pertain to RM (CreateSequence, etc…) at which point they will re-route the request into the RM stuff. WS-SecureConversation is another example. It’s interceptor will look for Actions related to issue/renew/cancel tokens. WS-Mex is another. Basically, if it gets through the chain without something “intercepting” the request, the request just goes to the normal endpoint like a normal request and is handled via the contents of the soap body. We likely SHOULD have a check in there to make sure the Action matches like we do check to make sure the SOAPAction header (if specified) matches. Thanks Daniel. Good explanation What kind of checking is applied to SOAPAction ? SOAPAction == URI requested ? If there is a non-empty
Re: WS-Addressing example from CXF 3.0.0
Just to follow up on this… I just pushed some changes that allow a more strict checking of the WSA Action. If an contextual property of ws-addressing.strict.action.checking” is set to true, CXF will do a bit more validation of the Action to make sure it at least comes closer to matching the possible values. I don’t want to turn it on by default as it’s quite likely to break existing clients. Our own tests revealed a bunch of cases where the actions would not properly match. Kind of makes me expect that this would cause lots of problems for folks out there. Anyway, this will be available in 3.0.1/2.7.12. Dan On Jul 11, 2014, at 9:52 AM, Daniel Kulp dk...@apache.org wrote: On Jul 10, 2014, at 5:17 PM, Iván Brencsics ivan.brencs...@gmail.com wrote: Hi Daniel, Please correct me if I am wrong, but one task of a web service stack is to route incoming SOAP requests to the right processing Java method. When using document style SOAP services, the basic solution is to do this routing based on the type of the message in the SOAP body. This is the concept of JAXWS too. Correct. After working with Spring WS I understood that the same routing can be done based on the wsa:Action value. In Spring WS a method can be annotated one of the following ways: 1) @PayloadRoot(localPart = orderRequest, namespace = http://samples;) or 2) @Action(http://samples/CreateOrder”) Same can be done with JAX-WS with the @javax.xml.ws.Action annotation and/or the @RequestWrapper (if using WRAPPED) or @WebParam if not. So in case of 1) if there is an incoming SOAP request where the body has the specified fully qualified name, the request is processed in this method. In 2) if there is an incoming SOAP request with this wsa:Action, it is routed to this method. For me this model makes more sense then the JAXWS approach, where we generate a SEI, implement it, and route the SOAP requests based on the SOAP body. In my opinion this is a very nice feature of Spring WS. The same can be done with JAX-WS. However, in general, it’s a ton easier to “get right” if you use the code generator to generate the SEI so that none of the actions and namespaces and such are typed in wrong.Things have to exactly match what the wsdl contains. Dont you think this has been one of the ideas of wsa:Action, to provide an alternative way of SOAP message routing? Digging through the code, we actually DO determine the operation to invoke based on the Action if it’s present and something else (like the SOAPAction) hasn’t already determined it. However, if we cannot find an operation based on the Action, we then continue and try and determine it based on the contents of the body. If the contents of the body don’t agree with the operation determined by the Action, then an exception is thrown. However, if we cannot determine the operation based on the Action and we are able to figure out an operation based on the payload, we don’t throw any sort of exception due to an invalid Action. I did just try adding an exception for this an all kinds of tests are failing. The main reason is that with JAX-WS, you can turn on WS-Addressing for any endpoint relatively easily (@Addressing annotation or feature), but if the methods don’t have @Action annotations, the action that is generated can vary depending on how the client was created and the setup of the WSDL. For example, even without the @Action, if the client is created with a wsdlLocation and the wsdl contains the appropriate wsam:Action attributes, it will use them. If they don’t contain the attributes, it will generate one, but the algorithm for the generated Action depends on if the wsdl:input contains a name attribute or not (it’s optional). If the client is NOT created from a WSDL, the it will also generate an Action, but again, the algorithm for that may result in something different than what the service expects. This applies to publishing a service as well. Thus, you can easily get a bit mix-matched between client/service depending on how they are created. Dan Regards, Ivan 2014-07-10 21:12 GMT+02:00 Daniel Kulp dk...@apache.org: On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza demablo...@gmail.com wrote: 2014-07-10 15:21 GMT+02:00 Daniel Kulp dk...@apache.org: In general, CXF routes requests based on the target URI/address, not the Action, although there are some exceptions to that…. In general, CXF only allows a single endpoint to be deployed on a specific address. Through the MultipleEndpointObserver stuff, it’s possible to do it, but it’s not exactly easy. So… where is the Action used? Under normal circumstances, the Action will be looked at by various interceptors on the chain that may be looking for a specific Action. For example, if WS-RM is configured, the RM interceptors will be looking for Actions that pertain
Re: Need help to review a pom.xml to generate a client with CXF 2.7.11
Remove the cxf-common-utilities dependency entirely. That hasn’t existed for a long time. Dan On Jul 11, 2014, at 11:03 AM, Thomas Manson dev.mansontho...@gmail.com wrote: Hi, I'm trying to use a newer version of CXF to generate a client to see if it solves an issue that I have with 2.7.0. I don't know where to find the equivalent of the following library used in my pom.xml : groupIdorg.apache.cxf/groupId artifactIdcxf-codegen-plugin/artifactId dependencies dependency groupIdorg.apache.cxf.xjcplugins/groupId artifactIdcxf-xjc-ts/artifactId version2.6.1/version /dependency dependency groupIdorg.apache.cxf/groupId artifactIdcxf-common-utilities/artifactId version2.5.10/version /dependency dependency groupIdorg.apache.cxf/groupId artifactIdcxf-rt-databinding-jaxb/artifactId version2.7.5/version /dependency /dependencies I've checked cxf-common-utilities on maven repo, it's one year old in its last version 2.5.11, while CXF 2.7.11 has been released in April this year. Could you help me to sort out which version/maven artifact I should use to have a consistent configuration and use the very last version of the 2.7.X branch ? Thanks, Thomas. pom.xml -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Problem with @ResponseWrapper in authentication client CXF
there were people that had this failure response and they made implicit reference to the soap header. If you need to send you the wsdl, give me a contact email and I’ll pass, I need help please. -- View this message in context: http://cxf.547215.n5.nabble.com/Problem-with-ResponseWrapper-in-authentication-client-CXF-tp5746244.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WS-Addressing example from CXF 3.0.0
In general, CXF routes requests based on the target URI/address, not the Action, although there are some exceptions to that…. In general, CXF only allows a single endpoint to be deployed on a specific address. Through the MultipleEndpointObserver stuff, it’s possible to do it, but it’s not exactly easy. So… where is the Action used? Under normal circumstances, the Action will be looked at by various interceptors on the chain that may be looking for a specific Action. For example, if WS-RM is configured, the RM interceptors will be looking for Actions that pertain to RM (CreateSequence, etc…) at which point they will re-route the request into the RM stuff. WS-SecureConversation is another example. It’s interceptor will look for Actions related to issue/renew/cancel tokens. WS-Mex is another. Basically, if it gets through the chain without something “intercepting” the request, the request just goes to the normal endpoint like a normal request and is handled via the contents of the soap body. We likely SHOULD have a check in there to make sure the Action matches like we do check to make sure the SOAPAction header (if specified) matches. That said, writing this has kind of gotten me thinking….. Those three uses cases likely could be re-written in terms of the MulipleEndpointObserver stuff with an Observer that would route based on the Actions.Each of those three would just need to register an Endpoint with the Action based observer and it would handle the routing. That’s a lot of code to refactor though… Hmmm….. Dan On Jul 9, 2014, at 10:14 AM, Richard Snowden richard.t.snow...@gmail.com wrote: Hi, I'm working with the WS-Addressing example from CXF 3.0.0 found here: apache-cxf-3.0.0-src\distribution\src\main\release\samples\ws_addressing\ I captured one request, sent from client to server, and used Chromes Postman extension to modify it: - made sure there's no SOAPAction the HTTP-Header - set wsa:Action to some random value, like blablabla Surprisingly it still worked! It seems the WS-Addressing SOAP-Header field Action is not used at all in CXF. Is this a bug or a feature? ;-) Here is one of my requests: soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/; soap:Header Action xmlns=http://www.w3.org/2005/08/addressing blablabla/Action MessageID xmlns=http://www.w3.org/2005/08/addressing urn:uuid:fa46e01c-f5c7-4d5b-b653-0f79d59885e8/MessageID To xmlns=http://www.w3.org/2005/08/addressing; http://localhost:9000/SoapContext/SoapPort/To ReplyTo xmlns=http://www.w3.org/2005/08/addressing; Addresshttp://www.w3.org/2005/08/addressing/anonymous /Address /ReplyTo /soap:Header soap:Body greetMe xmlns=http://apache.org/hello_world_soap_http/types; requestTypersnowden/requestType /greetMe /soap:Body /soap:Envelope -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WS-Addressing example from CXF 3.0.0
On Jul 10, 2014, at 2:48 PM, Jose María Zaragoza demablo...@gmail.com wrote: 2014-07-10 15:21 GMT+02:00 Daniel Kulp dk...@apache.org: In general, CXF routes requests based on the target URI/address, not the Action, although there are some exceptions to that…. In general, CXF only allows a single endpoint to be deployed on a specific address. Through the MultipleEndpointObserver stuff, it’s possible to do it, but it’s not exactly easy. So… where is the Action used? Under normal circumstances, the Action will be looked at by various interceptors on the chain that may be looking for a specific Action. For example, if WS-RM is configured, the RM interceptors will be looking for Actions that pertain to RM (CreateSequence, etc…) at which point they will re-route the request into the RM stuff. WS-SecureConversation is another example. It’s interceptor will look for Actions related to issue/renew/cancel tokens. WS-Mex is another. Basically, if it gets through the chain without something “intercepting” the request, the request just goes to the normal endpoint like a normal request and is handled via the contents of the soap body. We likely SHOULD have a check in there to make sure the Action matches like we do check to make sure the SOAPAction header (if specified) matches. Thanks Daniel. Good explanation What kind of checking is applied to SOAPAction ? SOAPAction == URI requested ? If there is a non-empty SOAPAction header, we do double check that the action that is specified matches the action that is configured for the target operation that is determined from the contents of the soap:Body. There’s a series of spoofing attacks that this prevents by making sure the entire processing of the message is consistently targeting the correct operation. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [CXF 3.0.0.] Response with closed entity after client.invoke: could it be?
On Jul 9, 2014, at 5:16 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 09/07/2014 10:45, Francesco Chicchiriccò wrote: It seems I've over-simplified the snippet above: it should have been, actually WebClient client = ...; Response response = client.invoke(method, inputStream); client.close(); response.getEntity(); It seems that with CXF 3.0.0 closing a client implies also closing the response object, thus causing the exception above: correct? Even with Sergey’s change, I wouldn’t rely on this. Closing the client SHOULD result in the transport being shut down. For the default URLConnection based transport, that doesn’t really do anything so the InputStream would still be valid. For the async http clients, this could result in the thread pools and listeners and everything being shutdown and thus nothing would be listening for any more data to come in. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF 3.0.0 JavaToWS Error
On Jul 9, 2014, at 2:07 AM, virajn mayuravi...@gmail.com wrote: I'm using CXF 3.0.0 and tried to generate WSDL from java interface. My build is a ant build. I used org.apache.cxf.tools.java2ws.JavaToWS as following java classname=org.apache.cxf.tools.java2ws.JavaToWS fork=true failonerror=true arg value = -databinding/ arg value=aegis/ arg value = -wsdl/ arg value=-d/ arg value=target/src/generated-source/ arg value=com.sample.TestInterface/ classpath path refid=cxf.classpath/ /classpath /java cxf.classpath has all the jars from cxf 3.0.0 lib folder. TestInterface has annotated using @WebService and @WebParam I got following error. Error: java.lang.RuntimeException: java.lang.RuntimeException: No ASM ClassWriterFound You really should just only need the cxf-manifest.jar to be on the classpath. The rest should be grabbed via it’s manifest. That could simplify things a bit. In anycase, make sure asm-3.3.1.jar is on the classpath. HOWEVER, if you are using Java8, you may need to replace that with the latest asm-5.x version. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: cxf 3.0.0 issue
) at org.apache.cxf.jaxrs.model.AbstractResourceInfo.findContexts(AbstractResourceInfo.java:82) at org.apache.cxf.jaxrs.model.AbstractResourceInfo.init(AbstractResourceInfo.java:76) at org.apache.cxf.jaxrs.model.ProviderInfo.init(ProviderInfo.java:38) at org.apache.cxf.jaxrs.model.ProviderInfo.init(ProviderInfo.java:32) at org.apache.cxf.jaxrs.provider.ProviderFactory.prepareProviders(ProviderFactory.java:1242) at org.apache.cxf.jaxrs.provider.ServerProviderFactory.setProviders(ServerProviderFactory.java:216) at org.apache.cxf.jaxrs.provider.ProviderFactory.setUserProviders(ProviderFactory.java:766) at org.apache.cxf.jaxrs.AbstractJAXRSFactoryBean.setupFactory(AbstractJAXRSFactoryBean.java:322) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setupFactory(JAXRSServerFactoryBean.java:228) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.create(JAXRSServerFactoryBean.java:173) ... 21 more Thanks, Krzysztof Nowicki -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Cannot create URL for this address soap.udp://239.255.255.250:3702
) at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1518) at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:484) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119) at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200) at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247) at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52) at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119) at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27) at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:671) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212) at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:59) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79) at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:184) at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:361) at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:180) at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:96) at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256) at weblogic.work.ExecuteThread.run(ExecuteThread.java:221) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Apache CXF 2.7.12 release approximate date
Hopefully next week. New builds of WSS4J were just built today and vote started. If the vote for that goes fine, we should be able to build the next CXF builds next week. Dan On Jun 30, 2014, at 11:02 AM, Ariel Cassan arielcas...@gmail.com wrote: Hi everyone, I'm a member of the architecture team in charge of a software development project in Barcelona, Spain, that uses CXF 2.7.11 as its WS engine. During last weeks, we've been struggling against the CXF issue reported in https://issues.apache.org/jira/browse/CXF-5679. We know that the bug will be fixed on the new release 2.7.12, but just because we are ready for go into production, we'd like to know if someone knows the appoximate date of when it is going to be finally released. We've been testing our product successfully with the last CXF's night builds, but we cannot use a snapshot version in production environment. Hope someone can throw us some light into this. Thanks everyone in advance, AC, from Barcelona (Spain). -- View this message in context: http://cxf.547215.n5.nabble.com/Apache-CXF-2-7-12-release-approximate-date-tp5745764.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Outofmemory error in datahandler
Is there any way you could create a full test case for this? Maybe attach it
to a JIRA or as a github repo?
Thanks!
Dan
On Jun 28, 2014, at 12:27 PM, Shriram shri1984...@gmail.com wrote:
Thanks Dan
I've just tried uploading a image of more than 5gb size with local
transport.
This is just an example program having server and client in a same file .
The reason behind this is local transport is within a same jvm. If possible
can you verify this.
Also please confirm whether webservice.wsdl file is really needed for this
local transport or not.
package com.java.testupload;
import java.io.File;
import java.util.HashMap;
import java.util.Map;
import javax.activation.DataHandler;
import javax.activation.DataSource;
import javax.activation.FileDataSource;
import javax.xml.ws.Endpoint;
import javax.xml.ws.soap.SOAPBinding;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import com.sun.xml.internal.ws.developer.JAXWSProperties;
public class ServicePublisher {
private static final String FILENAME = winserver;
private static final String FILETYPE = vdi;
private static final String FILEPATH =
D:\\Windowsserver_VirtualDrive\\winserver.vdi;
/**
* @param args
*/
public static void main(String[] args) {
// Endpoint ep = Endpoint
// .publish(
//
http://localhost:8080/TestUploadServer/services/TestUploadServerImplPort;,
// new TestUploadServerImpl());
Endpoint ep =
Endpoint.publish(local://TestUploadServerImplPort,
new TestUploadServerImpl());
SOAPBinding binding = (SOAPBinding) ep.getBinding();
binding.setMTOMEnabled(true);
consumeServiceFromClient();
}
private static void consumeServiceFromClient() {
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
MapString, Object props = new HashMapString, Object();
props.put(mtom-enabled, Boolean.TRUE);
//props.put(JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE,
8192);
factory.setProperties(props);
factory.setServiceClass(TestUploadServer.class);
factory.setAddress(local://TestUploadServerImplPort);
TestUploadServer uploadWebservice = (TestUploadServer)
factory.create();
FileUploader file = new FileUploader();
file.setName(FILENAME);
file.setFileType(FILETYPE);
DataSource source = new FileDataSource(new File(FILEPATH));
file.setDfile(new DataHandler(source));
uploadWebservice.uploadFile(file);
System.out.println(Finished copying);
}
}
Thanks,
Shriram
--
View this message in context:
http://cxf.547215.n5.nabble.com/RE-Outofmemory-error-in-datahandler-tp5745554p5745732.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Classloader leak in ExtensionManagerBus (on tomee)
On Jun 26, 2014, at 12:50 PM, Sergey Beryozkin sberyoz...@gmail.com wrote: On 26/06/14 17:28, Sergey Beryozkin wrote: Hi On 26/06/14 13:11, pablo.a.saave...@gmail.com wrote: Hi Sergey, thanks for your prompt response. You are right, what I saw in the heap dump were links to the provider class, which prevented the classloader from being garbage collected. The provider in question is registered via the standard JAX-RS means, in the getSingletons method of javax.ws.rs.core.Application. This is done this way because we need to configure the JacksonJaxbJsonProvider. I've confirmed that the context info JAX-RS provider stored on the Bus contains the actual provider classes - this needs to be fixed. I'll look into it This is ok in itself but due to Tomee having a default bus shared between the endpoints it becomes a problem after redeployments. Hmm... I'll need to think how to overcome it… Personally, I think that’s a bug in Tomee. They shouldn’t have a Bus that’s shared across everything. There’s lots of various things (like token/nonce caches) and such that are sometimes cached on the Bus. Dan Cheers, Sergey Thanks, Sergey I'll check with the Tomee team to see if endpoint specific buses are possible. Thanks a lot. On 26 June 2014 07:10, Sergey Beryozkin sberyoz...@gmail.com wrote: Hi On 26/06/14 04:32, pablo.a.saave...@gmail.com wrote: Hi All, hope you are doing well. We've been using Tomee as our application server lately (we have some basic JAX-RS APIs), and after several redeployments we get a PermGen space error. I've been digging into the heap dump, and from what I see our custom JAX-RS provider (JacksonJaxbJsonProvider) is being referenced inside ExtensionManagerBus's properties and never unregistered. I'm pretty sure it's Tomee's fault, because it should be doing due cleanup on undeployment, but I was wondering whether the ExtensionManagerBus has any way of removing the registered providers. CXF JAX-RS checks provider context properties when it registers providers and stores reflection-specific information and proxies on the bus, it does not store the actual providers. Do you have some more info how Bus ends up linking to the provider ? We have a feature allowing providers registered directly on the bus via bus properties, is it what is being done in your case ? If not then I'm not sure. ProviderFactory holding providers is registered on the endpoint but I'm not seeing the code where the endpoint is registered on the bus. Either way, the problem appears to be originating from the fact that a single shared bus is used between multiple endpoints in Tomee. Is it possible in Tomee endpoint descriptors set up an endpoint specific bus ? For example, in Spring/Blueprint descriptors which can declare a new CXF Bus and have jaxrs/jaxws endpoints linking to it and this bus would be recycled on the redeployment. So, please let me know: - if you have more info about the link from Bus to providers - check if providers are registered directly on the bus (check its properties like javax.ws.rs.ext.MessageBodyReader) - check if Tomee allows creating endpoint specific buses Lets us know please how it goes Thanks, Sergey Any help would be appreaciated Thanks in advance. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF JaxWs Endpoint fail with 'The given SOAPAction does not match an operation' when the action contains accented characters
On Jun 22, 2014, at 8:12 AM, Younes Ouadi younes.ou...@gmail.com wrote:
Hello Dears,
I'm stuck with the Async Client and accented characters. Please help.
Sorry, wasn’t clear. You need to use the HTTP transport based on the Apache
HTTP Components async clients. Some docs at:
http://cxf.apache.org/docs/asynchronous-client-http-transport.html
Code would remain exactly the same as before except for the line:
bp.getRequestContext().put(use.async.http.conduit, Boolean.TRUE);
If the appropriate async libraries are found on the classpath (if using Maven,
add cxf-rt-transports-http-hc and it should handle everything else), that
should be all that’s needed.
Dan
As suggested by @Daniel, I have suitched to Async Client hoping to solve my
initial issue, that is: consuming a web service whose SOAPAction contains
an accented character.
To do so:
* I took the sample program that is distributed with CXF 2.7.11
(apache-cxf-2.7.11-src/distribution/src/main/release/samples/jaxws_async)
* I have add two interceptors one for the server and one for the client
(sorry, this is the first time I'm hooking into CXF and this is the only
way I found to add arbitrary headers to CXF request).
* When the header doesn't contain accented characters, every thing works
well. The client initiate the request with the arbitrary header, the server
receives the request along with the header, process it and sends back the
response to the client.
* When the header contains an accented character, the client fail to
initiate the request with the error:
java.util.concurrent.ExecutionException:
java.nio.charset.UnmappableCharacterException: Input length = 1
* Googling this error shows (in other context of course) that there is an
issue with the encoding.
* I tried to enforce the use of ISO-8859-1, but with no luck.
The interceptor at the client side is as follows:
public class ClientHttpHeaderInterceptor extends
AbstractPhaseInterceptorMessage{
public ClientHttpHeaderInterceptor() {
super(Phase.PREPARE_SEND);
}
@Override
public void handleMessage(Message message) throws Fault {
//message.put(Message.CONTENT_TYPE, text/xml; charset=ISO-8859-1);
//message.put(Message.ENCODING, ISO-8859-1);
@SuppressWarnings(unchecked)
MapString, ListString headers = (MapString,
ListString)message.get(Message.PROTOCOL_HEADERS);
if ( headers != null ) {
ListString header = new ArrayListString();
header.add(Héader);
System.out.println(= Adding My Header:
+ header);
headers.put(My Header, header);
message.put(Message.PROTOCOL_HEADERS, headers);
}
}
}
The interceptor at the server side is as follows:
public class ServerHttpHeaderInterceptor extends
AbstractPhaseInterceptorMessage{
public ServerHttpHeaderInterceptor() {
super(Phase.PRE_INVOKE);
}
@Override
public void handleMessage(Message message) throws Fault {
@SuppressWarnings(unchecked)
MapString, ListString headers = (MapString,
ListString)message.get(Message.PROTOCOL_HEADERS);
if ( headers != null ) {
if ( headers.get(My Header) != null ) {
System.out.println(= Received My
Header: + headers.get(My Header).toString());
}
else {
System.out.println(= Received My
Header: none);
}
}
}
}
Warm regards
Younes
On Sat, Jun 21, 2014 at 10:08 AM, Younes Ouadi younes.ou...@gmail.com
wrote:
Hi @Daniel,
I appreciate very much your help. Thank you for the time, effort and
attention you have devoted to this question.
For your recommendation, I can't do much. The WSDL in question is already
in production consumed by a BizTalk-base client (the server is also a
BizTalk based server, as you can see it in the WSDL).
I will give a try to the Async Client and let you know the outcome.
Warm regards
Younes
On Fri, Jun 20, 2014 at 5:29 PM, Daniel Kulp dk...@apache.org wrote:
Looking at the code for the JDK:
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding
I see they intentionally leave it in whatever encoding it find with the
“file.encoding” system property at startup providing all the ASCII
characters work. Kind of wrong if you ask me, but that does mean that you
really can only rely on the ASCII level character being transferred
properly.
Dan
On Jun 20, 2014, at 12:06 PM, Daniel Kulp dk...@apache.org wrote:
Some bad news…. with a little bit of good news.
The HttpURLConnection that CXF uses by default for sending requests to
the server always seems to use UTF-8. I checked with Java 6/7/8 and they
all do that. There doesn’t seem to be any way to make
Re: This mailing list seems broken to send replies from Nabble now [SEC=UNCLASSIFIED]
On Jun 25, 2014, at 12:52 AM, Joel Pearson joel.pear...@ipaustralia.gov.au wrote: This mailing list seems broken to send replies from Nabble now. Did some SPF checking get switched on in the last day or so? None that I’m aware of and I’m seeing reply’s from others coming from Nabble. Seems to be working. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Return SOAP Fault in CXF Interceptor
On Jun 25, 2014, at 12:44 PM, Frizz frizzthe...@googlemail.com wrote:
I have a custom interceptor. In case the SoapMessage is an Exception, I'd
like to skip all my other interceptors and return a SOAP Fault.
Where in the chain is your interceptor? If it’s on the incoming chain, just
throw a org.apache.cxf.interceptor.Fault (or
org.apache.cxf.binding.soap.SOAPFault). CXF would then run that through the
fault chain which would write it out. If it’s on the outgoing chain, you can
TRY doing the same thing. If nothing has been written out yet, that will
work. If something has been written, the behavior is kind of undefined.
Dan
public void handleMessage(SoapMessage message)
...
if (message.getContent(Exception.class)!=null) {
skip other interceptors and return SOAP Fault
}
...
Is this possible? Or do I have to put some logic in each and every one of
my interceptors?
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF String transport?
On Jun 24, 2014, at 3:33 AM, bimjoeipa joel.pear...@ipaustralia.gov.au wrote: What's the easiest way to get the string content of a message without actually sending it anywhere? Essentially what I want to do is use CXF to apply WS-Policy to a message, but I just want the string output from the transport. The reason I want to do this is that I want to give SoapUI some form of WS-Policy support, because our testers like using it for load testing and easy testing of endpoints, but SoapUI doesn't have good enough signature support, so I wanted to leverage CXF if I can, because we are using it in our applications. I realise I could use WSS4J directly, but I like the idea of having CXF automatically configure WSS4J. So would I just create a custom transport? http://cxf.apache.org/docs/custom-transport.html I don't care about the response, only about the request, so would I need configure the transport to be one-way? Hmm….. A custom transport is certainly one way to do it. Another option COULD be to create a MessageImpl object and an ExchangeImpl object, add in stub Endpoint, BindingOperationInfo, etc… and a StringWriter content (as Writer.class type), and build up a manual PhaseInterceptorChain with the interceptors you need and just call it. At the end of the chain, the StringWriter should have the contents you need. That said, I’d likely go with an OutputStream class of some sort (CachedOutputStream likely) instead of a writer so things like MTOM could be put in affect. For a starter, I’d put a custom interceptor on a client the just does System.out.println(message.getInterceptorChain().toString()) to see what interceptors are on there and use those as a starting point. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Outofmemory error in datahandler
(filename);
aResponse.setHeader(Pragma, dummy);
aResponse.setHeader(Cache-Control, private);
String contentType = text/plain;
aResponse.setContentType(contentType);
aResponse.setHeader(Content-Disposition,
attachment; filename=\ + name + .txt\);
if (theDataHandler != null)
{
downloadFile(inputStream from datahandler, response
OutputStream());
}
Using Datahandler to handle the download. i am getting null only for larger
files. The exception occurs only for large files. I have commented out
LoggingINInterceptor and LoggingOutInterceptor.
Note: I am using localtransport for publishing service. Please tell me MTOM
feature is applicable to localtransport or not? If it is applicable why the
code is not working ?
--
View this message in context:
http://cxf.547215.n5.nabble.com/RE-Outofmemory-error-in-datahandler-tp5745554.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Error after upgrade from 3.0.0-milestone2 to 3.0.0
This is likely due to CXF-5753 and/or CXF-5811. Both are fixes for the
3.0.1-SNAPSHOT, but it would be great if you could give the snapshot a try to
verify.
Dan
On Jun 20, 2014, at 9:10 AM, Flavio Campana flavio.camp...@maggioli.it wrote:
I've got an unexpected error after uprgading my dependencies to CXF-3.0.0.
This is the exception i get:
com.sun.istack.SAXParseException2:
(uri:http://wsmaggioliservice.informatica.maggioli.it/;, local:richiesta).
Expected elements are {}richiesta
The request sent is the following one, which worked fine before:
getClienteEnabled xmlns=http://wsmaggioliservice.informatica.maggioli.it/;
richiesta xmlns=
...
/richiesta
/getClienteEnabled
(i omitted a few parts to keep things short)
it seems like the empty xmlns is ignored.
What should i do?
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF JaxWs Endpoint fail with 'The given SOAPAction does not match an operation' when the action contains accented characters
Some bad news…. with a little bit of good news. The HttpURLConnection that CXF uses by default for sending requests to the server always seems to use UTF-8. I checked with Java 6/7/8 and they all do that. There doesn’t seem to be any way to make it behave correctly. :-( If you can try creating an HttpURLConnection and calling setRequestProperty(“SOAPAction”, “Héader”) or something and doing a wireshark or similar, you’ll see it’s sending as UTF-8 encoded. Seems to be a bug in the JDK. If you can figure out away to get it to properly send the header, I’d love to see it. Both of the async clients we have (Netty on 3.0 and the Async client on both 2.7 and 3.0) seem to handle ISO-8859-1 headers properly. Thus, you can add the appropriate dependencies and configure it to “aways” use the async transport and it should transfer fine. HOWEVER - neither of those will handle any characters outside of 8859-1. They don’t encode the header using the RFC that’s there for encoding headers outside of the 8859-1 code set. Thus, this still isn’t a full solution. That all said, I’d STRONGLY STRONGLY encourage you to change the Action to NOT have those characters. Any client that uses the JAX-WS reference implementation built into the JDK would also fail (due to them also using the HttpURLConnection). Dan On Jun 20, 2014, at 4:42 AM, Younes Ouadi younes.ou...@gmail.com wrote: Hello Dears, I have an issue with soap-actions that contains accented charaters. I'm sure that this is not something new and it is possible that I'm missing something. So, please help. My case is as follows: * I have received a WSDL of a third party system * I have used wsdl2java maven plugin to generate classes * I have setted up a client and a server using Spring method * When I try to consume a service, the server reject my request with: 'The given SOAPAction does not match an operation' * The logs shows that the SOAPAction header: ** at the client side contains the corrcet value which contain an accented character (the character 'é') ** at the server side, it contains a wrong value (the 'é' is replace by two other charaters) It looks like that CXF: * at the client side, it hase encoded the the header value using UTF-8 * while at the the server side, it has decoded the header value using ISO-8859-1 I have asked this question on SO and I have got a reply saying that as per HTTP Specs, headers should be in ISO-8859-1. My question here is: how I can ask CXF to encode headers, at the client side, using ISO-8859-1 instead of UTF-8? My config is: * OS: Fedora 19 * JDK: Java(TM) SE Runtime Environment (build 1.6.0_33-b03) | Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) * CXF: 2.7.11 I have put all the detail of thsi case on SO. Please see ' http://stackoverflow.com/questions/24305749/cxf-jaxws-endpoint-fail-with-the-given-soapaction-does-not-match-an-operation '. Warm regards. Younes Ouadi -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF JaxWs Endpoint fail with 'The given SOAPAction does not match an operation' when the action contains accented characters
Looking at the code for the JDK: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/net/NetworkClient.java#NetworkClient.0encoding I see they intentionally leave it in whatever encoding it find with the “file.encoding” system property at startup providing all the ASCII characters work. Kind of wrong if you ask me, but that does mean that you really can only rely on the ASCII level character being transferred properly. Dan On Jun 20, 2014, at 12:06 PM, Daniel Kulp dk...@apache.org wrote: Some bad news…. with a little bit of good news. The HttpURLConnection that CXF uses by default for sending requests to the server always seems to use UTF-8. I checked with Java 6/7/8 and they all do that. There doesn’t seem to be any way to make it behave correctly. :-( If you can try creating an HttpURLConnection and calling setRequestProperty(“SOAPAction”, “Héader”) or something and doing a wireshark or similar, you’ll see it’s sending as UTF-8 encoded. Seems to be a bug in the JDK. If you can figure out away to get it to properly send the header, I’d love to see it. Both of the async clients we have (Netty on 3.0 and the Async client on both 2.7 and 3.0) seem to handle ISO-8859-1 headers properly. Thus, you can add the appropriate dependencies and configure it to “aways” use the async transport and it should transfer fine. HOWEVER - neither of those will handle any characters outside of 8859-1. They don’t encode the header using the RFC that’s there for encoding headers outside of the 8859-1 code set. Thus, this still isn’t a full solution. That all said, I’d STRONGLY STRONGLY encourage you to change the Action to NOT have those characters. Any client that uses the JAX-WS reference implementation built into the JDK would also fail (due to them also using the HttpURLConnection). Dan On Jun 20, 2014, at 4:42 AM, Younes Ouadi younes.ou...@gmail.com wrote: Hello Dears, I have an issue with soap-actions that contains accented charaters. I'm sure that this is not something new and it is possible that I'm missing something. So, please help. My case is as follows: * I have received a WSDL of a third party system * I have used wsdl2java maven plugin to generate classes * I have setted up a client and a server using Spring method * When I try to consume a service, the server reject my request with: 'The given SOAPAction does not match an operation' * The logs shows that the SOAPAction header: ** at the client side contains the corrcet value which contain an accented character (the character 'é') ** at the server side, it contains a wrong value (the 'é' is replace by two other charaters) It looks like that CXF: * at the client side, it hase encoded the the header value using UTF-8 * while at the the server side, it has decoded the header value using ISO-8859-1 I have asked this question on SO and I have got a reply saying that as per HTTP Specs, headers should be in ISO-8859-1. My question here is: how I can ask CXF to encode headers, at the client side, using ISO-8859-1 instead of UTF-8? My config is: * OS: Fedora 19 * JDK: Java(TM) SE Runtime Environment (build 1.6.0_33-b03) | Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03, mixed mode) * CXF: 2.7.11 I have put all the detail of thsi case on SO. Please see ' http://stackoverflow.com/questions/24305749/cxf-jaxws-endpoint-fail-with-the-given-soapaction-does-not-match-an-operation '. Warm regards. Younes Ouadi -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: default behaviour of cxf on base64 encoded message
On Jun 14, 2014, at 2:40 PM, Ravindra Kondiparthi ravi.4in...@gmail.com wrote: I am trying to understand the behaviour of cxf for element xs:element name=Payload ns1:expectedContentTypes=application/octet-stream type=xs:base64Binary xmlns:ns1=http://www.w3.org/2005/05/xmlmime/ Payload element is unmarshalled to a DataHandlerObject . looks like cxf is decoding the base64 encoded message is this the default behaviour? Yes.From the application point of view, it’s just a stream of bytes (or byte[] or whatever the DataHandlerObject can deal with) and CXF does whatever is necessary to put that data on the wire. An important note is that if MTOM is turned on, the data would never actually be base64 encoded.A xop element is stuck in the SOAP part and the data is then attached via a mime attachment set to binary and no encoding is needed. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: NAMESPACE_ERR with DynamicClientFactory createClient
Anything related to the SOAP encoding stuff is pretty much completely untested
and not supported. There’s likely bugs in there related to that since it’s
not something we support at all.
Dan
On Jun 11, 2014, at 6:00 AM, Aki Yoshida elak...@gmail.com wrote:
This is a memo for me and others to investigate this problem.
there seems to be some issue in building up an internal schema model.
Concretely speaking, in this particular case, some namespace
attributes with their namespace URI part set to null instead of the
xmlns's namespace URI http://www.w3.org/2000/xmlns/;. As a result,
the serialization of this schema results in the above NAMESPACE_ERR.
The schema line hitting causing this error is:
xs:attribute d7p1:arrayType=xs:int[]
ref=soapenc:arrayType xmlns:d7p1=http://schemas.xmlsoap.org/wsdl/;
/
While processing this line, the two out of the bands extra attributes
xmlns:xs=http://www.w3.org/2001/XMLSchema; and
xmlns:http=xmlns:http=http://schemas.xmlsoap.org/wsdl/http/; are
present (injected earlier). And these attributes have their namespace
URI part bound to null as mentioned above.
If this line is modified to
xs:attribute ref=soapenc:arrayType /
This problem does not occur.
I suspect the problem is lying somewhere in the schema processing
library use by CXF. But I couldn't get a whole picture.
Maybe Dan or someone might have a quick idea?
2014-06-10 16:52 GMT+02:00 Aki Yoshida elak...@gmail.com:
hi Neela,
you are right. There seems to be some problem when the wsdl is fetched
over http.
I need to look at it.
thanks.
regards, aki
2014-06-10 16:07 GMT+02:00 neela neelambal.shankaralin...@aspect.com:
Hi Aki,
I was able to reproduce the success you are getting.
when we use local wsdl file to create client it works with the
schemaLocation specification.
And with out that schemaLocation when using local wsdl file it shows proper
error message like below.
java.lang.RuntimeException: Error compiling schema from WSDL at
{C:\Users\Documents\Neela\CXF-TestProjects\view-source 172.20.85.141
NetStubs RpcEncoded.asmx wsdl.xml}:
undefined simple or complex type 'soapenc:Array'
but when I create the SOAP UI project mock service using that proper wsdl
with schemaLocation defined and try to access it via http url, it throws the
NAMESPACE_ERR.
so in my case it goes in side the !file check and calls serializeSchema and
it fails inside that. when we use local wsdl file it will skip this part,
that's why it works fine.
*DynamicClientFactory.java Line#485*
* if (!key.startsWith(file:) !key.startsWith(jar:)) {*
XmlSchemaSerializer xser = new XmlSchemaSerializer();
xser.setExtReg(schemaCollection.getExtReg());
Document[] docs;
try {
*docs = xser.serializeSchema(schema, false);*
} catch (XmlSchemaSerializerException e) {
throw new RuntimeException(e);
}
.
.
.
I am not sure if I could provide a live wsdl url because the sample is a
.Net webservice.
I have attached the soapUI project with mock service. but the schemaLocation
shown in mockservice wsdl is auto generated and come different.
If you import the soapUI project to SoapUI and run the mockservice you can
access the service via
http://localhost:8080/?WSDL
Test-NameSpace-Err-soapui-project.xml
http://cxf.547215.n5.nabble.com/file/n5744932/Test-NameSpace-Err-soapui-project.xml
Thanks for your patience.
Thanks Regards,
Neela
--
View this message in context:
http://cxf.547215.n5.nabble.com/NAMESPACE-ERR-with-DynamicClientFactory-createClient-tp5744708p5744932.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: programmatic way to shutdown cxf jaxrs bus or endpoint?
On Jun 9, 2014, at 1:25 PM, Sonam Samdupkhangsar sonam.samdupkhang...@imail.org wrote: I have a cxf jaxrs application configured using java config similar to this post http://stackoverflow.com/questions/13520821/autodiscover-jax-rs-resources-with-cxf-in-a-spring-application. However, I have my code in a Maven based project that has Cobertura code coverage. The test cases are run twice and it seems the endpoints are not shutdown in the first test run and when running the code coverage the test case tries to standup the endpoints again. Is there a way to shutdown the endpoints or the cxf jaxrs server after the first test case run? If you have access to the Bus, just call bus.shutdown() and it should go through and shut down all the services and such that are registered on it. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Is @WebService annotation a must in service class?
On Jun 5, 2014, at 12:13 AM, virajn mayuravi...@gmail.com wrote: I have a SOAP web service. For experiment, I removed the @WebService annotation in service class and it's still working without any problem. So I think @WebService annotation is not a must in service class. Am i missing something here. ( I'm using CXF 2.7.7 ) CXF doesn’t mandate them, but other JAX-WS implementations may. Depends on how portable you want your code to be. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF 2.7.11 xfire compatibility.
I think you have to move the XFireCompatibilityServiceConfiguration bean to before the JaxWsServiceConfiguration. It’s a “first one to return a value wins” thing so you need to make sure the XFire version gets a chance to return the old xfire namespace before the JAX-WS algorithms kick in. Dan On Jun 2, 2014, at 8:22 AM, sachinverma sachin.ve...@oodlestechnologies.com wrote: I am upgrading my XFire web service logic to CXF 2.7.11 using simple frontend due to annotation-less structure of course. But CXF and XFire autogenerated namespaces (targetNamespace in wsdl) for web services are different as CXF add an extra '/' forward slash. As mentioned here http://cxf.apache.org/docs/aegis-databinding-20x.html , I updated my XML to : bean id=aegisCompatibilityFactoryBean class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean property name=serviceConfigurations list bean class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration / bean class=org.apache.cxf.aegis.databinding.XFireCompatibilityServiceConfiguration / bean class=org.apache.cxf.service.factory.DefaultServiceConfiguration / /list /property /bean simple:server id=scheduleService serviceClass=com.my.world.ScheduleWebService address=/ScheduleWebService simple:serviceBean bean class=com.my.world.impl.ScheduleWebServiceImpl /bean /simple:serviceBean simple:serviceFactory ref bean=aegisCompatibilityFactoryBean / /simple:serviceFactory simple:dataBinding bean class=org.apache.cxf.aegis.databinding.AegisDatabinding / /simple:dataBinding But still I am getting '/' in my namespace. Do CXF 2.7.11 still supports XFire namespace? Please help. -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-2-7-11-xfire-compatibility-tp5744595.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Adding SAAJInInterceptor breaks the RPCInInterceptor
On Jun 2, 2014, at 8:11 AM, Shankaralingam, Neelambal neelambal.shankaralin...@aspect.com wrote: Hi, In my client I am trying to return the SOAPMessage response. So I have added SAAJInInterceptor to the InInterceptors chain. If I enable SAAJInInterceptor it breaks the RPCInInterceptor at Line#170 where the expected Qname comes with namespace the part qname is without namespace. Breaks in below check and throws a fault. Can you create a test case for this?The QName from the SOAP message definitely should not have a namespace here. Thus, I’m kind of curious where the bug is coming from. Is there a namespace in the message transferred on the wire? Is the message on the wire using some sort of default namespace? Dan !qn.equals(part.getConcreteName()) Is it expected? How can I remove a particular interceptor from chain? Can anyone share your thoughts? Regards, Neela This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Is there going to be a cxf-bundle 3.0.0 release as well
On May 30, 2014, at 2:40 PM, wiz...@yahoo.com wrote: noticed the bundle is still at milestone 2 release on maven search central... since cxf-3.0.0 has been out for a while will we get a cxf-bundle 3.0.0 as well or was that discontinued as of 3 That was removed. It has worked “properly and completely” in OSGi since 2.5 and has been a pain to maintain. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Fediz IDP - implication of removing OGNL dependency?
On May 23, 2014, at 11:19 AM, chris snow chsnow...@gmail.com wrote: I'm currently evaluating Fediz 1.1 for my company, but noticed that the IDP has an OGNL dependency that in turn requires Javassist which is LGPL: According to: http://www.javassist.org http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/ This version is distributed under the triple license of the MPL, the LGPL, and the Apache License.” That’s at least for the 3.18.1 version. We likely should make sure we’re updated to grab the 3.18.1 version from: http://central.maven.org/maven2/org/javassist/javassist/3.18.1-GA/javassist-3.18.1-GA.pom to make sure that is clear. Dan I would have to jump through hoops to get LGPL approved, so I was wondering what the implications would be if I removed the OGNL dependency. The main reference to OGNL that I could find is: src/main/webapp/WEB-INF/idp-servlet.xml:bean id=expressionParser class=org.springframework.webflow.expression.WebFlowOgnlExpressionParser / Does anyone know the impact of replacing OGNL with SpringEL in the IDP? -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Exception in webservice-communication. How to get additional informations?
On May 23, 2014, at 8:23 AM, Tobse tobias.rott...@seetec.de wrote: Thanks for your suggestions. Since I don't have a fix endpoint and can't configure with xml-files I have to do everything in java souce code. Do you have any code examples for me? I don't know wether I did something wrong or it just didn't work for me. Thanks. ((BindingProvider)port).getRequestContext() .put(“org.apache.cxf.transport.no_io_exceptions”, Boolean.TRUE); port.setVideoSourceConfiguration(….); -- View this message in context: http://cxf.547215.n5.nabble.com/Re-Exception-in-webservice-communication-How-to-get-additional-informations-tp5744151p5744379.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: 3.0.0 release
On May 20, 2014, at 12:02 PM, Nordine Boussedra ext_boussedra.nord...@agora.msa.fr wrote: Hi Can you tell me when the 3.0.0 version of CXF will be released please ? I plan to migrate my 2.3.1 version to 2.7.11 but, i will migrate to 3.0.0 if it will be released soon. How about yesterday… :-) Seriously, it’s now available in Maven central and most of the download mirrors now have it. I’m waiting for the website to be updated and I have a few other minor things to update (xsd files) and then an announcement will get sent out. Dan Thank you Ce message est protégé par les règles relatives au secret des correspondances. Il est donc établi à destination exclusive de son destinataire. Celui-ci peut donc contenir des informations confidentielles. La divulgation de ces informations est à ce titre rigoureusement interdite. Si vous avez reçu ce message par erreur, merci de le renvoyer à l'expéditeur dont l'adresse e-mail figure ci-dessus et de détruire le message ainsi que toute pièce jointe. This message is protected by the secrecy of correspondence rules. Therefore, this message is intended solely for the attention of the addressee. This message may contain privileged or confidential information, as such the disclosure of these informations is strictly forbidden. If, by mistake, you have received this message, please return this message to the addressser whose e-mail address is written above and destroy this message and all files attached. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[ANNOUNCE] Apache CXF 3.0.0 released!
The Apache CXF community is proud to announce that CXF 3.0.0 has been released. After a very long development cycle, 2 “milestone” releases, and lots of testing efforts, we’re glad to say that 3.0.0 is now available. CXF 3.0.0 contains several new features: * JAX-RS 2.0 support * Bean Validation support * A completely re-written “spring free” JMS transport * New WebSocket based transport * New HTTP transports based on Net * Completely new WS-Security engine based on StAX (WSS4J 2.0) * WS-RM 1.1 updates * much much more……. In addition, much of the old deprecated code has been removed and cleaned up, the required third party dependencies have been reduced, several of the API’s have been simplified, etc… For a more complete list of changes required to migrate to CXF 3.0, see: http://cxf.apache.org/docs/30-migration-guide.html Downloads are available from: http://cxf.apache.org/download.html For more information see: * Website: http://cxf.apache.org/ * Mailing lists: http://cxf.apache.org/mailing-lists.html If you have feedback, questions or would like to get involved in the CXF project please join the mailing lists and let us know your thoughts. The Apache CXF Team http://cxf.apache.org/
Re: HTTP proxy problem with wsdl-first client
On May 19, 2014, at 7:15 AM, Michael michael.schae...@destatis.de wrote: Aki Yoshida-3 wrote I was wondering why you can't (or don't want to) configure the http.proxy setting once per VM. Some connections are with applications in external networks - here we need the proxy - and some with others in the same network. Also, our web app may invoke itself in certain scenarios. Our idea is to avoid the proxy (and the reverse proxy) as a means of optimization in cases were connections are rather internal. Leaving that aside, we could well configure the proxy setting per VM. As to your suggested solution, I'm wondering wether proxy settings take effect before or after the client stub is created. Setting the proxy using HTTPClientPolicy has never been a problem. It's only that accessing the WSDL when the client stub is instantiated (new EksService(wdslUrl)) fails and I've found no way to set the proxy on a per-instance basis to deal with that case. The only ways to do that are: 1) Via spring or blueprint xml config 2) Via the OSGi config admin service (in OSGi) 3) A custom Configurer object. For (3), you can grab the bus.getExtension(Configurer.class) and wrapper it with a new on that checks the bean passed in to see if it’s an HTTPConduit and if so, reconfigure based on whatever else you need. Set your wrapper back in via bus.setExtension(….) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue with WS-Trust using security tokens/SAML assertions
On May 19, 2014, at 4:04 AM, MichaelG michael.gustafs...@migrationsverket.se wrote: The scenario: Idp/STS: Microsoft ADFS 2.0 Service provider: Shibboleth SP CXF: 2.7.8 The client logs on (with a domain username/pwd) to the web site. Once logged on the user can call a webservice that is WS-trust configured. Using the ADFS policy/endpoint “../adfs/services/trust/13/usernamemixed” it works fine, although it is just a password set between the web service and the sts client. Using SoapUI and calling the STS directly (the usernamedmixed binding) but with the domain credentials will actually give me a proper SAML assertion. When I change the sts client to any one of these policies/endpoints …/issuedtokensymmetricbasic256 or …/issuedtokenassymetric256 the sts client doesn’t seem to be able or willing to connect to the STS to retrieve the security token/SAML assertion. So the soap message to the web service will not contain any security token, hence a Response-Code: 500” back from the web service. When I instead invoke the: stsClient.requestSecurityToken(); The client to ends up in a loop that will exhaust all of the memory = stack overflow. There is no apparent error message either. Seems like that the state machine is confused by, for me, some unknown reason. Nothing is ever sent towards the STS according to Fiddler at least. Could there be any issues with reading the WSDL from the ADFS (we have had to modify the KeyValueToken tags due to that CXF did not like to parse it straight out of the box) making the endpoint address of the STS is a problem? Should´nt we at least see a connection attempt or endpoint address error message? Should the Shibboleth SP in some way be invoked to request the token? Why the loop? A lot of questions but no solid leads to work with right now. No idea. We’d likely need to at least see the stack traces from the loop (on Unix, do a kill -3 on the process to dump the stack trace) to even see where the problem is. An example would be great. A simple wsdl with the policies in it and client that uses it is fine. Since you mention nothing is even being sent to the server, the server part is kind of irrelevant for a test case. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Exception in webservice-communication. How to get additional informations?
Interesting…. your camera isn’t properly implementing the soap spec that would require the SOAP fault to be a 500 error code, not a 400. You can TRY add a contextual property of “org.apache.cxf.transport.no_io_exceptions” to Boolean.TRUE or “true” and seeing if that helps. That would bypass the first place an exception is thrown, but I’m not sure how much further it would go for soap/jaxws. Dan On May 20, 2014, at 7:51 AM, Tobse tobias.rott...@seetec.de wrote: Hi, that didn't work for me. :( Is there any chance to get the soap message that caused the exception so that I can log it to my log-file or parse it for more detailed error-codes in my application? By the way, I don't have a fix endpoint. Kind Regards, Tobse -- View this message in context: http://cxf.547215.n5.nabble.com/Re-Exception-in-webservice-communication-How-to-get-additional-informations-tp5744151p5744209.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: wsdl2java - Encountered illegal extension attribute 'message'
According to the WSDL spec: http://www.w3.org/TR/wsdl#_bindings The wsdl:input/output elements in the binding can have a name attribute, but the message attribute is not allowed there. Thus, the wsdl is invalid. Dan On May 20, 2014, at 4:48 PM, Frizz frizzthe...@googlemail.com wrote: Hi there, I am using CXF 2.7.7. I have a WSDL that is correct and valid (imho). But when running wsdl2java it doesn't seem to like the 'message' attribute in my binding/operation definition. Here is the error message from wsdl2java: WSDLToJava Error: org.apache.cxf.wsdl11.WSDLRuntimeException: Fail to create wsdl definition from : file:/C:/ws/example/MyService.wsdl Caused by : WSDLException (at /wsdl:definitions/wsdl:binding/wsdl:operation/wsdl:input): faultCode=INVALID_WSDL: Encountered illegal extension attribute 'message'. Extension attributes must be in a namespace other than WSDL's. Here is the WSDL file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://example.com/MyService.wsdl; xmlns=http://schemas.xmlsoap.org/wsdl/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:tns=http://example.com/MyService.wsdl; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; wsdl:types xsd:schema targetNamespace=http://example.com/MyService.wsdl; xmlns=http://www.w3.org/2001/XMLSchema; xsd:element name=serviceRequest xsd:complexType xsd:sequence xsd:element maxOccurs=1 minOccurs=0 name=serviceDescription type=xsd:string/xsd:element /xsd:sequence /xsd:complexType /xsd:element xsd:element name=serviceResponse xsd:complexType xsd:sequence xsd:element maxOccurs=1 minOccurs=1 name=result type=xsd:int/ /xsd:sequence /xsd:complexType /xsd:element /xsd:schema /wsdl:types wsdl:message name=serviceRequestRequest wsdl:part element=tns:serviceRequest name=parameters/wsdl:part /wsdl:message wsdl:message name=serviceResponse wsdl:part element=tns:serviceResponse name=parameters/wsdl:part /wsdl:message wsdl:portType name=MyService wsdl:operation name=serviceRequest wsdl:input message=tns:serviceRequestRequest/wsdl:input wsdl:output message=tns:serviceResponse/wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=localhostBinding type=tns:MyService soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=serviceRequest wsdl:input message=tns:serviceRequestRequest/wsdl:input wsdl:output message=tns:serviceResponse/wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=MyServiceProvider wsdl:port binding=tns:localhostBinding name=localhost soap:address location= http://localhost:8080/services/MyServiceProvider// /wsdl:port /wsdl:service /wsdl:definitions -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Named Bus in jaxws endpoint not working
On May 13, 2014, at 4:21 PM, richard.w.han...@wellsfargo.com wrote:
Well adding an init-param to the servlet worked.
init-param
param-namebus/param-name
param-valueserver/param-value
/init-param
But it begs the question of how to have multiple buses in the same instance?
Our services are both providers and consumers of web services, so my goal is
to have separate client and server buses because they need different
configuration.
It depends on what you really are trying to do. You can have multiple
CXFServlets that are each configured for a different bus. Thus, services on
one bus are deployed in one context and services in the other are deployed
elsewhere. Or, you could have a “client” bus that the cxf:client things use
and another for the services. Etc….
You CAN also have multiple busses that share the same DestinationRegistry
(which is what the Servlet really needs) by adding a bean of interface
DestinationRegistry, implementation DestinationRegistryImpl to your context.
Dan
Rick
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Tuesday, May 13, 2014 3:01 PM
To: users@cxf.apache.org; Hansen, Richard W.
Subject: Re: Named Bus in jaxws endpoint not working
On May 13, 2014, at 3:50 PM, richard.w.han...@wellsfargo.com wrote:
None of that worked. I upgraded to 2.7.11 and even tried using the name
bus1 for all name attributes. I don't believe it is a matter of the bus
and the end point getting hooked together. It looks to me like an issue with
routing the request as if CXFServlet is not finding my named bus. Is there
some other bit of configuration required?
What does the configuration for the servlet look like? By default, it
searches for a bus named cxf. For a different bus name, you would need to
add a configuration of bus to the cxf servlet.
Dan
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Tuesday, May 13, 2014 10:13 AM
To: users@cxf.apache.org; Hansen, Richard W.
Subject: Re: Named Bus in jaxws endpoint not working
On May 8, 2014, at 10:16 AM, richard.w.han...@wellsfargo.com wrote:
I'm trying to associate an endpoint with a named cxf Bus but getting the
'Can't find the request for Observer' error. The service works fine if no
bus name is specified in the endpoint. From the server output it appears
the service is found and loaded. I'm currently using cxf 2.5.1.
Any chance of trying with a supported version of CXF? Preferably 2.7.11.
You could try specifying everything on the cxf:bus like:
cxf:bus name=server id=server bus=server
One of them might work. Again, old version of CXF so not really sure what
to look at. Our tests all use cxf:bus bus=bus1 so maybe just flipping
to that will work.
Dan
May 08, 2014 8:22:27 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service
{http://pingService.example.wmg.provider.service.wellsfargo.com/}Ping
S
oapBindingImplService from class
com.wellsfargo.service.provider.wmg.example.pingservice.PingPortType
May 08, 2014 8:22:28 AM org.apache.cxf.endpoint.ServerImpl
initDestination
INFO: Setting the server's publish address to be /ping May 08, 2014
8:23:46 AM org.apache.cxf.transport.servlet.ServletController invoke
WARNING: Can't find the the request for
http://localhost:7001/ExampleProject/services/ping's Observer
Here is the configuration -
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/core;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml /
bean id=pingWebService
class=com.wellsfargo.service.provider.wmg.example.pingService.PingSo
a
pBindingImpl/
cxf:bus name=server
/cxf:bus
jaxws:endpoint bus=server id=ping implementor=#pingWebService
address=/ping / /beans
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: GZIPInInterceptor throws EOFException for a GET Request
] at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:163)[:1.7.0_25] at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:78)[:1.7.0_25] at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:90)[:1.7.0_25] at org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:85)[151:org.apache.cxf.cxf-rt-core:2.7.3] ... 22 more Sample Request: -- View this message in context: http://cxf.547215.n5.nabble.com/GZIPInInterceptor-throws-EOFException-for-a-GET-Request-tp5743882.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Logging clear-text message
I think you would just need to move the phase to a later phase. Likely in the
Phase.USER_PROTOCOL phase.
Dan
On May 13, 2014, at 12:07 PM, Giriraj Bhojak girira...@gmail.com wrote:
Thank you Daniel and Andrei.
Here is new interceptor I just wrote for outgoing messages:
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.message.Message;
import org.apache.cxf.phase.AbstractPhaseInterceptor;
import org.apache.cxf.phase.Phase;
import org.w3c.dom.Document;
public class LoggingOutInterceptor extends
AbstractPhaseInterceptorMessage {
public LoggingOutInterceptor() {
super(Phase.PRE_PROTOCOL);
}
public void handleMessage(Message message) throws Fault {
Document document = message.getContent(Document.class);
}
}
The document is null. While debugging I see that the actual object I am
trying to send is in contents[] array of
org.apache.cxf.message.MessageImpl.
But I haven't been able to retrieve it yet. Any idea what I am doing wrong?
Thanks,
Giriraj.
On Tue, May 13, 2014 at 11:00 AM, Daniel Kulp dk...@apache.org wrote:
The Logging interceptors run at a byte stream level and only would see the
“secured” message. To log the unsecured message, you would need to write
a different interceptor to handle that. Unfortunately, its also going to
be different for CXF 2.7.x and CXF 3.x due to changes in the security
handling.
For 2.7.x, you can write an interceptor that would run after the
WSS4JInInterceptors that would do a:
message.getContent(Document.class)
and prints the DOM.For 3.x with the new streaming security
interceptors, it would be way more complex. You’d have to grab the
XMLStreamReader from the message, wrapper it with a new stream reader that
would then record the read events. (the wrapped stream reader method
would also work for 2.7.x, but like I said, a bit more complex to write)
Dan
On May 12, 2014, at 6:05 PM, Giriraj Bhojak girira...@gmail.com wrote:
Hi,
I am using cxf (2.7.8 )with wss4j(1.6.13).
For the sake of debugging I need to see the outgoing messages.
I have added cxf:inInterceptors and cxf:outInterceptors in the spring
config.
This helps me see the signed and encrypted message.
Is there a way to see the clear-text version of the message?
I have used JAXB marshaller to print the message but I am trying to avoid
writing any code to see the message.
Thanks,
Giriraj.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF - JAX-WS - Set HTTP Response Code
You could try doing a:
message.put(Message.RESPONSE_CODE, 401)
I’m not sure this will work though. Maybe doing that on the Fault chain
someplace would work better. Not sure.
This isn’t “easy” to achieve as the SOAP spec mandates that soap faults always
use a response code 500 so we may be overriding various settings if SOAP is
used.
Another option would be to make your AuthenticationException subclass CXF’s
Fault class. (or wrapper your AuthenticationException in a Fault). The Fault
class has a setStatusCode method on it to hold the status code that should be
sent back with that fault.
Dan
On May 8, 2014, at 9:15 PM, Paul Avijit paulavi...@yahoo.com wrote:
Hi,
I have a CXF JAX-WS service where custom authentication and authorization is
done using a class, SoapAuthInterceptor which extends
AbstractPhaseInterceptorMessage.
When authentication fails I want to set HTTP Response code 401 and when
authorization fails I want to set HTTP Response code 403.
In the method handleMessage(Message message) of SoapAuthInterceptor I have
tried the following but it still only send response code 500.
If (Authorization fails)
{
HttpServletResponse httpServletResponse =
(HttpServletResponse)message.get(HTTP.RESPONSE);
httpServletResponse.addHeader(Response-Code, 403);
message.put(HTTP.RESPONSE, httpServletResponse);
throw new AuthenticationException(Forbidden 403); // This goes as SOAP
Fault in the response
}
Is there a way to set HTTP response code in this case. Please help.
Thanks in advance.
Regards
Paul
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Empty target node with external binding file
Can you try with just:
//xsd:schema/xsd:complexType[@name='Verordnung’]
(note the double slash at the beginning)
I think we feed just the schemas into XJC for generation and thus the wsdl
parts in the path might not work. Not 100% sure on that.
Dan
On May 14, 2014, at 5:51 AM, Maurice bet...@x3.net wrote:
Dear readers,
i am trying, for several days now , to customize bindings of a WSDL to fit
into my local domain using Karaf 2.3.4 with Felix and CXF 2.7.10.
The Client gets created by
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(String
wsdlUrl, QName service, QName port, ListString bindingFiles).
Here i pass a binding file which generates the following exception:
/blueprint stuff...Caused by: java.lang.RuntimeException: Error compiling
schema from WSDL at
{https://le.zhp-online.de/static/wsdl/vo_handling_physiotherapy.wsdl}:
XPath evaluation of
wsdl:definitions/wsdl:types/xsd:schema/xsd:complexType[@name='Verordnung']
results in empty target node
at line 16 column 100 of schema
file:/C:/Users/x3.mbetzel/Development/karaf/apache-karaf-2.3.4-dms-2.0.0/etc/orchestrater-jaxb-bindings.xjb
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory$InnerErrorListener.throwException(DynamicClientFactory.java:733)
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:322)
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:236)
at
net.x3.webservice.dynamic.client.factories.JaxWsClientFactory.create(JaxWsClientFactory.java:95)
at
net.x3.webservice.dynamic.client.beans.JaxWsClientPool.getJaxWsClient(JaxWsClientPool.java:103)
at
net.x3.webservice.dynamic.client.beans.DynamicWsClient.getOutOfBandHeaderMessagePart(DynamicWsClient.java:98)
at
Proxycb5649db_0b18_443b_b957_3445857f5bab.getOutOfBandHeaderMessagePart(Unknown
Source)
at
net.x3.ehealth.hmm.dms.validaterorchestrater.beans.ValidaterOrchestrater.init(ValidaterOrchestrater.java:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)[7:org.apache.aries.blueprint.core:1.4.0]
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)[7:org.apache.aries.blueprint.core:1.4.0]
at
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)[7:org.apache.aries.blueprint.core:1.4.0]
... 38 more
Caused by: com.sun.istack.internal.SAXParseException2: XPath evaluation of
wsdl:definitions/wsdl:types/xsd:schema/xsd:complexType[@name='Verordnung']
results in empty target node
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:610)
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:604)
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:280)
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:376)
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:131)
at
com.sun.tools.internal.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:93)
at
com.sun.tools.internal.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:437)
at
com.sun.tools.internal.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.7.0_51]
at java.lang.reflect.Method.invoke(Method.java:606)[:1.7.0_51]
at
org.apache.cxf.common.util.ReflectionInvokationHandler.invoke(ReflectionInvokationHandler.java:54)
at com.sun.proxy.$Proxy21.bind(Unknown Source)
at
org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:320)
... 51 more/
Any xpath editor confirms my path to be correct though. What am i missing?
The binding file:
--
View this message in context:
http://cxf.547215.n5.nabble.com/Empty-target-node-with-external-binding-file-tp5743952.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: the given soapaction does not match an operation, cxf bug?
If you have the WSDL, why are you not deploying the service using the WSDL. I think for your case, make sure the @WebService annotation has an appropriate wsdlLocation attribute.If the WSDL is available, it should use it directly and not have to generate a new annotation. Can you check the generated code to make sure the @WebMethod annotations have the appropriate action parameter? It should be pulling the action from there so it’s either a code generation issue or possibly a runtime issue if it’s not finding it. Would like to see a test case. Dan On May 8, 2014, at 4:31 AM, Mailing List SVR li...@svrinformatica.it wrote: Hi, I'm generating a service from an existing wsdl (original.wsdl attached), after creating the service the generated wsdl has some small difference from the original one (cxf_generated.wsdl attached), if I create client methods (using for example soapui) from the cxf generated wsdl all is fine but if I use the original wsdl the requests they fail with the error: the given soapaction does not match an operation the problem is the SOAPAction http header, cxf expects no SOAPAction header or an empty one, if you look at the wsdl generated by cxf you can see a section not present in the original wsdl that define an empty soap action: soap:operation soapAction= style=document/ after this section there is also the original one that define: soap:operation soapAction=http://test.example.com//updateList/ I defined an interceptor that remove the SOAPAction http header if present and this workaround what seems a cxf bug to me. Obviously if someone give you a wsdl it use that wsdl to generate client methods and not redownload the wsdl from your service. What do you think about? Is this a cxf bug? Why cxf modify the original wsdl used to generate java code? thanks Nicola P.S. tested with both cxf 2.7.8 and 2.7.11 cxf_generated.wsdloriginal.wsdl -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: AbstractFeature/Interceptors in CXF 3.0
That should still work as is. Can you create a small test case? The feature itself looks OK. Not sure why the feature wouldn’t be applied. How is the feature being configured for the service? Dan On May 12, 2014, at 3:47 PM, Thorsten Höger li...@hoegernet.de wrote: Hi, In one of my projects I use a AbstractFeature to intercept REST calls and short circuit some invocations. [0] This worked in CXF 2.7.x but is ignored in CXF 3.0. What do I have to change? Regards, Thorsten PS: Sorry if I overlooked something obvious [0]: https://github.com/taimos/restdoc-cxf/blob/master/src/main/java/org/restdoc/cxf/RestDocFeature.java line 82 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Named Bus in jaxws endpoint not working
On May 8, 2014, at 10:16 AM, richard.w.han...@wellsfargo.com wrote:
I'm trying to associate an endpoint with a named cxf Bus but getting the
'Can't find the request for Observer' error. The service works fine if no bus
name is specified in the endpoint. From the server output it appears the
service is found and loaded. I'm currently using cxf 2.5.1.
Any chance of trying with a supported version of CXF? Preferably 2.7.11.
You could try specifying everything on the cxf:bus like:
cxf:bus name=“server” id=“server” bus=“server”
One of them might work. Again, old version of CXF so not really sure what to
look at. Our tests all use cxf:bus bus=“bus1” so maybe just flipping to
that will work.
Dan
May 08, 2014 8:22:27 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service
{http://pingService.example.wmg.provider.service.wellsfargo.com/}PingSoapBindingImplService
from class
com.wellsfargo.service.provider.wmg.example.pingservice.PingPortType
May 08, 2014 8:22:28 AM org.apache.cxf.endpoint.ServerImpl initDestination
INFO: Setting the server's publish address to be /ping
May 08, 2014 8:23:46 AM org.apache.cxf.transport.servlet.ServletController
invoke
WARNING: Can't find the the request for
http://localhost:7001/ExampleProject/services/ping's Observer
Here is the configuration -
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/core;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml /
bean id=pingWebService
class=com.wellsfargo.service.provider.wmg.example.pingService.PingSoapBindingImpl/
cxf:bus name=server
/cxf:bus
jaxws:endpoint bus=server id=ping implementor=#pingWebService
address=/ping /
/beans
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Logging clear-text message
The Logging interceptors run at a byte stream level and only would see the “secured” message. To log the unsecured message, you would need to write a different interceptor to handle that. Unfortunately, its also going to be different for CXF 2.7.x and CXF 3.x due to changes in the security handling. For 2.7.x, you can write an interceptor that would run after the WSS4JInInterceptors that would do a: message.getContent(Document.class) and prints the DOM.For 3.x with the new streaming security interceptors, it would be way more complex. You’d have to grab the XMLStreamReader from the message, wrapper it with a new stream reader that would then record the read events. (the wrapped stream reader method would also work for 2.7.x, but like I said, a bit more complex to write) Dan On May 12, 2014, at 6:05 PM, Giriraj Bhojak girira...@gmail.com wrote: Hi, I am using cxf (2.7.8 )with wss4j(1.6.13). For the sake of debugging I need to see the outgoing messages. I have added cxf:inInterceptors and cxf:outInterceptors in the spring config. This helps me see the signed and encrypted message. Is there a way to see the clear-text version of the message? I have used JAXB marshaller to print the message but I am trying to avoid writing any code to see the message. Thanks, Giriraj. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Named Bus in jaxws endpoint not working
On May 13, 2014, at 3:50 PM, richard.w.han...@wellsfargo.com wrote:
None of that worked. I upgraded to 2.7.11 and even tried using the name
bus1 for all name attributes. I don't believe it is a matter of the bus and
the end point getting hooked together. It looks to me like an issue with
routing the request as if CXFServlet is not finding my named bus. Is there
some other bit of configuration required?
What does the configuration for the servlet look like? By default, it searches
for a bus named “cxf”. For a different bus name, you would need to add a
configuration of “bus” to the cxf servlet.
Dan
-Original Message-
From: Daniel Kulp [mailto:dk...@apache.org]
Sent: Tuesday, May 13, 2014 10:13 AM
To: users@cxf.apache.org; Hansen, Richard W.
Subject: Re: Named Bus in jaxws endpoint not working
On May 8, 2014, at 10:16 AM, richard.w.han...@wellsfargo.com wrote:
I'm trying to associate an endpoint with a named cxf Bus but getting the
'Can't find the request for Observer' error. The service works fine if no
bus name is specified in the endpoint. From the server output it appears
the service is found and loaded. I'm currently using cxf 2.5.1.
Any chance of trying with a supported version of CXF? Preferably 2.7.11.
You could try specifying everything on the cxf:bus like:
cxf:bus name=server id=server bus=server
One of them might work. Again, old version of CXF so not really sure what
to look at. Our tests all use cxf:bus bus=bus1 so maybe just flipping
to that will work.
Dan
May 08, 2014 8:22:27 AM
org.apache.cxf.service.factory.ReflectionServiceFactoryBean
buildServiceFromClass
INFO: Creating Service
{http://pingService.example.wmg.provider.service.wellsfargo.com/}PingS
oapBindingImplService from class
com.wellsfargo.service.provider.wmg.example.pingservice.PingPortType
May 08, 2014 8:22:28 AM org.apache.cxf.endpoint.ServerImpl
initDestination
INFO: Setting the server's publish address to be /ping May 08, 2014
8:23:46 AM org.apache.cxf.transport.servlet.ServletController invoke
WARNING: Can't find the the request for
http://localhost:7001/ExampleProject/services/ping's Observer
Here is the configuration -
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/core;
xmlns:jaxws=http://cxf.apache.org/jaxws;
xsi:schemaLocation=http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd;
import resource=classpath:META-INF/cxf/cxf.xml /
bean id=pingWebService
class=com.wellsfargo.service.provider.wmg.example.pingService.PingSoa
pBindingImpl/
cxf:bus name=server
/cxf:bus
jaxws:endpoint bus=server id=ping implementor=#pingWebService
address=/ping / /beans
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog Talend Community Coder -
http://coders.talend.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: GZIPInInterceptor throws EOFException for a GET Request
On May 13, 2014, at 12:20 PM, Sanjeev Chopra sanjeevxcho...@gmail.com wrote: Hello Dan, there is no other Content* header in the request. (see http log from SOAPUI below). Do you think this behavior is worth safeguarding against in the Interceptor ? Yep. Just wanted to get the full header list and such to setup a decent test case for this. Thanks! Dan Mon May 12 23:07:25 PDT 2014:DEBUG: GET /restBaseUrl/IRestCustomerServiceBaseUrl/1.0/restservice/customer/1 HTTP/1.1[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Content-Encoding: gzip[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Accept-Encoding: gzip,deflate[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Host: localhost:9090[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Connection: Keep-Alive[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: User-Agent: Apache-HttpClient/4.1.1 (java 1.5)[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: [\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: HTTP/1.1 500 Server Error[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Content-Type: text/xml;charset=UTF-8[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Transfer-Encoding: chunked[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: Server: Jetty(7.6.8.v20121106)[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: [\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: BA[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: ns1:XMLFault xmlns:ns1= http://cxf.apache.org/bindings/xformat;ns1:faultstring xmlns:ns1= http://cxf.apache.org/bindings/xformat java.io.EOFException/ns1:faultstring/ns1:XMLFault Mon May 12 23:07:25 PDT 2014:DEBUG: [\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: 0[\r][\n] Mon May 12 23:07:25 PDT 2014:DEBUG: [\r][\n] On Tue, May 13, 2014 at 8:38 AM, Daniel Kulp dk...@apache.org wrote: On May 12, 2014, at 4:02 PM, Sanjeev Chopra sanjeevxcho...@gmail.com wrote: I am using GZIPInInterceptor (cxf-bundle-jaxrs-2.7.3.jar) on my service for decompressing gzip requests coming in from clients. If a client sends a GET request with a 'Content-Encoding: gzip' header, the interceptor throws an EOFException (at org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:85)[151:org.apache.cxf.cxf-rt-core:2.7.3] ) while trying to decompress a non-existent body in the GET request. Looking at the code, the problem seems to be that org.apache.cxf.transport.common.gzip.Message.getContent(InputStream.class) returns a non-null response for a request with no body. Granted that it does not make sense to be sending a Content-Encoding header in a GET request, I would expect the interceptor to tolerate this when there is no content in the incoming request. Is this a defect ? This definitely looks like a bug in SOAP UI. :-(That certainly doesn’t make much sense. Can you use wireshark or similar to capture the raw request with all the headers and such? I’m curious to see if they are also including a Content-Length or Content-Type header or similar. Dan I ran into this while doing some manual testing with SOAP UI, because the compression setting is at the project level. When I send a GET request (with compression enabled in Preferences), SOAPUI includes the Content-Encoding header in the request. Complete Stacktrace: org.apache.cxf.interceptor.Fault: Could not unzip compressed message. at org.apache.cxf.transport.common.gzip.GZIPInInterceptor.handleMessage(GZIPInInterceptor.java:103)[151:org.apache.cxf.cxf-rt-core:2.7.3] at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)[150:org.apache.cxf.cxf-api:2.7.3] at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[150:org.apache.cxf.cxf-api:2.7.3] at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(JettyHTTPDestination.java:355)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(JettyHTTPDestination.java:319)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] at org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHandler.java:72)[167:org.apache.cxf.cxf-rt-transports-http-jetty:2.7.3] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1040)[73:org.eclipse.jetty.server:7.6.8.v20121106] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:976)[73:org.eclipse.jetty.server:7.6.8.v20121106] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[73:org.eclipse.jetty.server:7.6.8.v20121106] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)[73:org.eclipse.jetty.server:7.6.8.v20121106] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[73:org.eclipse.jetty.server:7.6.8.v20121106
Re: integrate to wcf service using wsHttpBinding
) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1331) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:632) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:570)at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:479)at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:382)at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:335)at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135) ... 26 moreCaused by: java.net.SocketTimeoutException: Read timed outat java.net.SocketInputStream.socketRead0(Native Method)at java.net.SocketInputStream.read(SocketInputStream.java:150)at java.net.SocketInputStream.read(SocketInputStream.java:121)at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)at java.io.BufferedInputStream.read(BufferedInputStream.java:334)at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:633)at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:579)at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1322) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468) at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.getResponseCode(URLConnectionHTTPConduit.java:266) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1543) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1513) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1318) ... 36 more* -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF Inbound Interceptor - Access to POJO
PRE_INVOKE should do it for the inbound chain. That said, USER_LOGICAL is likely the correct phase for this. Dan On May 6, 2014, at 9:59 AM, Omey o...@rammey.com wrote: I am able to use :/final MessageContentsList objs = MessageContentsList.getContentsList(message.getExchange().getOutMessage());/to gain access to the outbound POJO.Is it possible to do the same on an Inbound Intercepter? I have tried inserting the intecepter at Phase.PRE_INVOKE, Phase.INVOKE Phase.POST_INVOKE. And using something similar to above:/final MessageContentsList objs = MessageContentsList.getContentsList(message.getExchange().getInMessage());/doesn't seem to do the trick.Is it possible to get access to the unmarshalled POJO before it is sent on it's way? -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Inbound-Interceptor-Access-to-POJO-tp5743766.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Removing WS-Addressing headers on faults in CXF
MARSHALL phase is definitely too late. This would likely need to be up around
the Phase.PRE_PROTOCOL phase for this to have an affect, definitely before the
WRITE phase. The headers should be added within the MAPCodec interceptor in the
PRE_PROTOCOL phase, but they are then written out during the WRITE phase.
Thus, you need to put your code in there someplace.
Dan
On May 5, 2014, at 12:03 PM, stephen.ctr.chapp...@faa.gov wrote:
Hi -
I have a requirement that when my service returns an InvalidSecurity
fault, that the fault includes as little information as possible.
Specifically, the fault shouldn't include any WS-Addressing headers, stack
traces, or a variety of other things. I have a CXF interceptor set up to
sanitize faults, which works great on the soap body. But no matter what I
do, my faults always end up with WS-Addressing headers.
The WS-Addressing headers are being added as a result of my output policy
in the WSDL. And for non-fault responses, or for faults that are not
InvalidSecurity, I need to include them. So for the InvalidSecurity case,
I'm attempting to remove them in a Fault Interceptor with code similar to:
if ( message.hasHeaders() ) {
if ( message.hasHeader(Names.WSA_TO_QNAME) ) {
log.info(Removing WS-A To);
Header hdr = message.getHeader(Names.WSA_TO_QNAME);
if ( message.getHeaders().remove(hdr) ) {
log.info(WS-A To successfully removed);
} else {
log.info(WS-A To NOT removed);
}
}
}
This code executes fine, and I see in my logs Removing WS-A To, followed
by WS-A To successfully removed. Then I see the fault, and it very
clearly has a wsa:To header in it.
I've tried playing around with the interceptor phase (it is currently in
Phase.MARSHALL) but that hasn't helped at all. Is there some other way to
remove headers during fault processing that anyone can recommend?
Thanx,
Stephen W. Chappell
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Karaf java.lang.IllegalArgumentException when using JaxWsDynamicClientFactory
There’s a problem with the DynamicClient with the in-JDK XJC things. In general, it works OK outside of karaf as the jaxb-xjc jar gets picked up and the in-jdk version isn’t used. In karaf, there’s an issue. I fixed this last week as part of commit cfda95f21681b4193ca9b8c3c5749b2c067aac15. Dan On May 4, 2014, at 11:56 PM, dchen dave.che...@gmail.com wrote: Hi, I am using JaxWsDynamicClientFactory to createWS client factory as follwing: JaxWsDynamicClientFactory wsClientFactory = JaxWsDynamicClientFactory.newInstance(); Client wsClient = wsClientFactory.createClient(wsAddress); It runs fine outside of karaf, but when running in side karaf (2.3.1), it throws the following error: java.lang.IllegalArgumentException: Can not set final com.sun.tools.internal.xjc.reader.internalizer.InternalizationLogic field com.sun.tools.internal.xjc.reader.internalizer.DOMForest.logic to org.apache.cxf.endpoint.dynamic.DynamicClientFactory$1 at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) at sun.reflect.UnsafeQualifiedObjectFieldAccessorImpl.set(UnsafeQualifiedObjectFieldAccessorImpl.java:83) at java.lang.reflect.Field.set(Field.java:680) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.hackInNewInternalizationLogic(DynamicClientFactory.java:817) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:314) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:235) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:228) at org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient(DynamicClientFactory.java:183) Does anyone know why? -- View this message in context: http://cxf.547215.n5.nabble.com/Karaf-java-lang-IllegalArgumentException-when-using-JaxWsDynamicClientFactory-tp5743682.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF Client Performance Issue: Service Invocation time increases Linearly over the period (.net WCF Webservice)
OK… this explains it.
I’ve been running one of our samples in a tight loop for the last 6 hours and
haven’t observed any increase in time. But your email definitely would
explain it.
Someplace in your code, you are doing something like:
ListHeader list = new ArrayListHeader();
list.add(…..);
port.getRequestContext().put(HEADER_LIST, list)
or similar. During processing, CXF may be adding stuff to that list (example:
WS-Addressing headers) or something else may be adding additional headers to
that list like an interceptor or similar. Before making your calls, try doing:
port.getRequestContext().remove(HEADER_LIST)
or make sure you start with a clean list for each request.
Dan
On May 5, 2014, at 2:11 PM, krish.karthi karthik2le...@gmail.com wrote:
Hi Dennis,
One more observation from debug log, In every RequestContext an element
org.apache.cxf.headers.Header.list is keep on growing
For first request only one SoapHeader is in the list
[org.apache.cxf.binding.soap.SoapHeader@4c0c2817]
2014-05-04 19:01:17,047 DEBUG: org.apache.cxf.endpoint.ClientImpl - set
requestContext to message be
{...org.apache.cxf.headers.Header.list=[org.apache.cxf.binding.soap.SoapHeader@4c0c2817]}
but at the end of test i see this list org.apache.cxf.headers.Header.list
contains N number objects which is equal to number of calls we made.
For example we made 1500 calls and last requestContext which gets printed
has 1500 SoapHeader is in the list.
2014-05-05 09:37:57,182 DEBUG: org.apache.cxf.endpoint.ClientImpl - set
requestContext to message be{
org.apache.cxf.headers.Header.list=[org.apache.cxf.binding.soap.SoapHeader@4c0c2817,
org.apache.cxf.binding.soap.SoapHeader@37bad16e,
org.apache.cxf.binding.soap.SoapHeader@21a06695,
org.apache.cxf.binding.soap.SoapHeader@7371deb9,
org.apache.cxf.binding.soap.SoapHeader@13a3eb8,
org.apache.cxf.binding.soap.SoapHeader@2f6e7a12,
org.apache.cxf.binding.soap.SoapHeader@79e9895d,
org.apache.cxf.binding.soap.SoapHeader@5c067f39,
org.apache.cxf.binding.soap.SoapHeader@6d7f7d2e,
org.apache.cxf.binding.soap.SoapHeader@20e6fd4f,
org.apache.cxf.binding.soap.SoapHeader@7efe31f3,
org.apache.cxf.binding.soap.SoapHeader@a493075,
org.apache.cxf.binding.soap.SoapHeader@fcf891c,
org.apache.cxf.binding.soap.SoapHeader@13ea9e11,
org.apache.cxf.binding.soap.SoapHeader@223a86ab,
org.apache.cxf.binding.soap.SoapHeader@310660df,
org.apache.cxf.binding.soap.SoapHeader@35cc8e03,
org.apache.cxf.binding.soap.SoapHeader@2b4c4158,
org.apache.cxf.binding.soap.SoapHeader@28e54c94,
org.apache.cxf.binding.soap.SoapHeader@7822bf50,
org.apache.cxf.binding.soap.SoapHeader@fc1448a,
org.apache.cxf.binding.soap.SoapHeader@7e8e0165,
org.apache.cxf.binding.soap.SoapHeader@30ff0885,
org.apache.cxf.binding.soap.SoapHeader@521dfe59,
org.apache.cxf.binding.soap.SoapHeader@16a74086,
org.apache.cxf.binding.soap.SoapHeader@1478ef9b,
org.apache.cxf.binding.soap.SoapHeader@34b7fb8c,
org.apache.cxf.binding.soap.SoapHeader@354d4454,
org.apache.cxf.binding.soap.SoapHeader@2d32c9e9,
...]}
I am not sure this is causing this kind of delay or any memory leak.
Could you please explain me why i am seeing this or how to config CXF to
remove headers.
Regards,
Karthik
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-Client-Performance-Issue-Service-Invocation-time-increases-Linearly-over-the-period-net-WCF-Webs-tp5743664p5743702.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF Client Performance Issue: Service Invocation time increases Linearly over the period (.net WCF Webservice)
On May 5, 2014, at 2:58 PM, krish.karthi karthik2le...@gmail.com wrote: Thanks for the instant reply, in our code we are not adding any headers as you mentioned below, it is all with CXF. Can you grep through and check to see what IS being set on the RequestContext? This definitely shouldn’t be an issue unless SOMETHING is setting a HEADER_LIST onto the RequestContext someplace (which CXF wouldn’t be doing). If there isn’t a List set on the request context, CXF would create a new one on the outgoing message, but that would then be immediately discarded at the end of the request/response. The issue should only be occurring if something actually sets it on the Request Context where we would be re-using the exact list each time. Dan But we do use the AddressingFeature to create the client. Code which creates client, OurHTTPPort client = service.getOurHTTPPort(AddressingFeature(true, ture)); I will give it a try by removing headers before every request and update you how it goes. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: How to deal with corrupted namespace
On Apr 30, 2014, at 8:56 AM, David Hoffer dhoff...@gmail.com wrote:
Also I should mention, I'm not using Spring. A lot of the CXF examples
I've seen assume Spring is being used, I'd like to see an example with just
CXF Maven.
How are you starting and creating the service? Are you sure you’re using the
JAX-WS frontend and not the simple frontend? The simple frontend wouldn’t look
at the @WebService annotation at all which would result in this behavior.
Dan
-Dave
On Wed, Apr 30, 2014 at 6:43 AM, David Hoffer dhoff...@gmail.com wrote:
In my case I don't think I need to transform the namespace but rather it's
being generated incorrectly by the server when it hosts the service.
Perhaps I'm got doing things incorrect for 'WSDL First' approach. I'm
using the Maven plugin's wsdl2java goal to generate the java code (for
client and server) but I need CXF to retain the original WSDL when it hosts
the service. Is there an example of this someplace?
-Dave
On Tue, Apr 29, 2014 at 11:35 PM, Jose María Zaragoza
demablo...@gmail.com wrote:
Hello:
You can have a look at
https://cxf.apache.org/docs/transformationfeature.html
Maybe it'ts not what you want, but it cold fix it
Regards
2014-04-30 6:15 GMT+02:00 David Hoffer dhoff...@gmail.com:
I'm getting the following exception calling a CXF hosed (WSDL first)
webservice with a CXF client. The namespace should be
http://soap.sforce.com/2005/09/outbound but is http://outbound._09._
2005.soap.sforce.com instead.
javax.xml.ws.soap.SOAPFaultException: Unexpected wrapper element {
http://outbound._09._2005.soap.sforce.com/}notificationsResponsehttp://2005.soap.sforce.com/%7DnotificationsResponsefound.
Expected {http://soap.sforce.com/2005/09/outbound}notificationsResponse
.
This seems to be happening because on the server when the code is
generated
from the WSDL, since the folders start with numbers underscores are
added.
Then when the server builds the service it seems to ignore the
following
specification of the namespace:
@WebService(targetNamespace = http://soap.sforce.com/2005/09/outbound
,
name = NotificationPort)
Instead it builds a new WSDL/namespace based on the package names there
were changed to handle the digits. So it changes it to http://outbound
.
_09._2005.soap.sforce.com/
How can I keep the original namespace and ignore what package names are
used?
-Dave
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Julian to Gregorian calendar Switch. CXF behavior managing dates before 15/10/1582
and not April 30*, with *9 days of difference*. I tried with several dates and noticed that this behavior occurs for dates prior then *15/10/1582*, that is the historical start date for the Gregorian Calendar. From 15/10/1582 onward the request bean is valorized with the exact date I enter in the soap request. So, I don't understand what is the logic used by Apache Cxf. Does it assume that the incoming request contains a date expressed in Gregorian calendar and then convert it into Julian date for dates prior that 15/10/1582? If it is so, why does such a conversion is performed? Thank you very much. -- View this message in context: http://cxf.547215.n5.nabble.com/Julian-to-Gregorian-calendar-Switch-CXF-behavior-managing-dates-before-15-10-1582-tp574.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Large data stream caching - Causing Truncated Response
We’ve been calling canWrite() on the File object representing the directory for a long time, so I’m a bit surprised. I guess in your case, it is writable, but there isn’t space. Interesting. I’ve just added a couple more checks in there. First, if there is less than 1MB of “usable space” (File.getUsableSpace()) it will now log a warning. Next, instead of looping indefinitely trying to create a new directory, we’ll just make 1 attempts (which seems high, but should be fairly quick) and if that fails, throw an exception. That said, with CXF 3.0, this particular case (Logging interceptors) wouldn’t result in anything being buffered on disk as the default for the caching is raised to 128K and default for message size logged is reduced to 32K and the interceptors have been further optimized to only load the 32K needed for logging. Dan On Apr 30, 2014, at 3:01 AM, Graeme Dougal gra...@tiderian.com wrote: Hi When a response payload is greater than the default 64k it will be cached to disk in a temp file in systems temp directory. Faced an issue for the above where logging was switched on via the cxf:bus spring config and our environments java.io.tmp dir had no space allocated to it due to locked down environment setup. The CXF code actually hangs in the *org.apache.cxf.helpers.FileUtils* class in the *public static File createTempFile(String prefix, String suffix, File parentDir,* * boolean deleteOnExit) throws IOException *method where it calls *getDefaultTempDir()* The thread itself just hangs and the client receives a truncated response from the REST service. With logging switched off or the *org.apache.cxf.io.CachedOutputStream.OutputDirectory* property overridden then everything works fine.. -- Regards Graeme Dougal Tiderian Consulting Office :+44(191) 215 16 50 Mobile : +44(0) 7860 950 815 Email : gra...@tiderian.com Web: www.tiderian.com Tiderian Consulting is the trading name of Tiderian Consulting Ltd registered in England No. 6024579 Registered Office Address : 31 Cloverdale Gardens, High Heaton, Newcastle Upon Tyne, NE7 7QJ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Possible to use arbitrary xml with a JAX-WS client and JAXB?
QzMjE5fDY2MDI1MDExMw== . NAMLhttp://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=ma cro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.na me spaces.BasicNamespace-nabble.view.web.template.NabbleNamespace- nabble. view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nab bl e%3Aemail.naml-instant_emails%21nabble%3Aemail.naml- send_instant_email %21nabble%3Aemail.naml -- View this message in context: http://cxf.547215.n5.nabble.com/Possible-to-use- arbitrary-xml-with-a-JAX-WS-client-and-JAXB-tp5743219p5743278.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: DynamicClientFactory ex.printStackTrace ignore
On Apr 28, 2014, at 5:45 AM, Maurice bet...@x3.net wrote: Dear community, i just deployed a Dynamic Web Service Client bundle using CXF 2.7.10 to Karaf 2.3.4 generating the following exception: As it turns out there is a comment in place (line 830 DynamicClientFactory) telling this can be ignored. Double checking if anybody confirm this can be ignored without further issues? If you aren’t using any XML catalogs, this is completely ignorable. That said, the logic around this is back words anyway. :-( It should only be setting the field if it’s NOT the internal JDK jaxb. Fixing….. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: WS-Discovery: Not working for a .net-WCF-Service
/dependencies /project -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Asynchronous http transport keep alive property query
Just logged:
https://issues.apache.org/jira/browse/CXF-5695
for this. Fairly easy fix which I’m testing now. Should be committed
shortly.
Dan
On Apr 15, 2014, at 3:02 PM, Mandy Warren mandys.in...@gmail.com wrote:
Hi,
I've knocked up a unit test to prove my settings for
org.apache.cxf.transport.http.async.MAX_PER_HOST_CONNECTIONS and
org.apache.cxf.transport.http.async.MAX_CONNECTIONS are getting set
correctly but not having much luck!
Here's the test:-
@Test
public void getClientUsingApacheCommonsAsync() throws Exception {
BusFactory.getDefaultBus().setProperty
(use.async.http.conduit, true);
BusFactory.getDefaultBus().setProperty
(org.apache.cxf.transport.http.async.MAX_PER_HOST_CONNECTIONS, 1);
BusFactory.getDefaultBus().setProperty
(org.apache.cxf.transport.http.async.MAX_CONNECTIONS, 1);
WebClient.create(adfmsDummyServer.getBaseURL(),
Lists.newArrayList(new JacksonJsonProvider()),
true).path(/delay).accept(application/json).get();
// TODO - add some asserts, no idea what yet!
}
I've grep'd the cxf source code and the only place I can see a ref to
either of the MAX_XXX properties is in AsyncHTTPConduitFactory. An instance
of this class is constructed when the bus is created and then the method
setProperties() is called passing in the bus properties to then set on the
connection:-
public AsyncHTTPConduitFactory(Bus b) {
this();
addListener(b);
config.setTcpNoDelay(true);
setProperties(b.getProperties());
}
BUT, when the bus is constructed and hence the AsyncHTTPConduitFactory
constructor is called, the bus has no properties hence the default values
of 5000 and 1000 are used. The setProperties() method is never called again
so I just can't work out how my actual properties get set on the
connection!
Any help much appreciated :-)
Many thanks
Mandy
Sent from a mobile device
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: The wsdl generated from cxf contains elements with minOccurs=0 instead of a choice
On Apr 16, 2014, at 7:55 AM, sfont stefano.fonta...@gmail.com wrote: Hi, we have solved introducing the wsdlLocation attribute in the jaws:endpoint configuration. We verified also that after that change if we enable the schema validation cxf validates the soap request and response against our original schema/wsdl :) Searching the web we found that the wsdl that cxf publish by default (without the wsdlLocation configuration) is generated from the jaxws/jaxb annotations of the classes generated from the wsdl2java tool..Is it correct? Yep. That’s correct. Not everything in schema is recorded in the JAXB generated classes. Things like facets and such are lost. Additionally, there are several schema constructs that map to the same JAXB structure so when you do the reverse, it may not be exactly the same. In general, if you have a wsdl/schema, it’s likely best to use it via the wsdlLocation. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Basic authorization in dynamic client
If you are getting a SOAP Fault back instead of a 401, that means the basic authentication has worked. It’s now trying to process the message on the server side and failing and thus returning a fault. You may need to check the logs on the server side to see what it thinks is wrong. Dan On Apr 15, 2014, at 5:37 PM, akaine cy387...@hotmail.com wrote: Hello, I have a dynamic client generated with DynamicClientFactory for a web service that required a Basic authorization: DynamicClientFactory dcf = DynamicClientFactory.newInstance(); Client client = dcf.createClient(wsdlLocation); client.getEndpoint().getEndpointInfo().setAddress(uri.toString()); HTTPConduit http = (HTTPConduit)sr.getClient().getConduit(); AuthorizationPolicy authPolicy = new AuthorizationPolicy(); authPolicy.setAuthorizationType(Basic); authPolicy.setUserName(username); authPolicy.setPassword(password); http.setAuthorization(authPolicy); Object[] response = client.invoke(operationQName, someArgs); On invoke I get an error: SEVERE: Server Error org.apache.cxf.binding.soap.SoapFault: Server Error at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84) at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51) at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69) at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:781) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1630) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1520) at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1326) at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:635) at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:502) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:411) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:314) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:267) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:287) at serviceinvoker.ServiceReader.invokeOperation(ServiceReader.java:164) at exec.Test_XI.main(Test_XI.java:65) Before I had the block altering HTTPConduit I was getting 401 error which was expected, but according to other cases I found in cxf mailing lists this block should have solved my problems. One thing I should mention though: The default endpoint (defined in wsdl) uri is different from the one I'm setting, though if I set everything as I have in my code in SoapUI for example it works as it should. Any ideas why is this happening? This is the first time I'm trying to connect to a service using Basic authorization so maybe I'm missing something... -- View this message in context: http://cxf.547215.n5.nabble.com/Basic-authorization-in-dynamic-client-tp5742882.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Please help me with HTTP authentication/XML message modification
The WSSConfig object that is used to pass configuration into WSS4J has a WSTimeSource object which can be used to provide a custom time source for use with creating timestamps in the UsernameToken. That’s what I’d look into doing. Dan On Apr 15, 2014, at 9:25 AM, Pampolini Matteo matteo.pampol...@selex-es.com wrote: Hello there, I'm developing an ONVIF client module that needs to make appropriate SOAP requests to some remote devices. Usually these devices accept HTTP text or digest authentication or both. Sometimes it happens that their date/time is not synchronized with the one of the client PC, thus authentication fails. However, ONVIF devices provide a method to retrieve their current date/time to calculate an offset and then set the right time inside the SOAP request. The only way I found to achieve this is through an out interceptor that takes the XML message and modifies the wsu:Created element accordingly. Googling a lot I came to this link: http://stackoverflow.com/questions/6915428/how-to-modify-the-raw-xml-message-of-an-outbound-cxf-request The problem is that adding this interceptor, I can modify the XML message, but I see no packet transmitted over the wire. If I just comment out the line: message.getInterceptorChain().doIntercept(message); the packet is transmitted, but my XML message to be modified is empty. Any ideas? I really don't know how to go further... Many thanks in advance, Matteo This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. Questa e-mail e tutti i suoi allegati sono da intendersi inviati in via riservata all'effettivo destinatario e possono essere soggetti a restrizioni legali. Se non siete l'effettivo destinatario o avete ricevuto il messaggio per errore siete pregati di cancellarlo dal vostro sistema e di avvisare il mittente. E' vietata la duplicazione, l'uso a qualsiasi titolo, la divulgazione o la distribuzione dei contenuti di questa e-mail a qualunque altro soggetto. Prima di stampare questa comunicazione consideratene, per favore, l'impatto ambientale Please consider the environment before printing this email -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: cxf-rt-transports-http-hc Maven dependency convergence error
CXF 3.0 has been updated to the latest versions. We cannot on 2.7 due to some API incompatibilities. Dan On Apr 15, 2014, at 1:59 PM, Mandy Warren mandys.in...@gmail.com wrote: Hi, When I bring in the cxf-rt-transports-http-hc Maven dependency I get the following dependency convergence errors (we use the maven-enforcer):- [ERROR] +-org.apache.httpcomponents:httpclient:4.2.5 [ERROR] +-org.apache.httpcomponents:httpcore:4.2.4 [ERROR] and [ERROR] +-org.apache.cxf:cxf-rt-transports-http-hc:2.7.11 [ERROR] +-org.apache.httpcomponents:httpcore-nio:4.2.4 [ERROR] +-org.apache.httpcomponents:httpcore:4.2.4 [ERROR] and [ERROR] +-org.apache.cxf:cxf-rt-transports-http-hc:2.7.11 [ERROR] +-org.apache.httpcomponents:httpasyncclient:4.0-beta3 [ERROR] +-org.apache.httpcomponents:httpcore:4.2.2 [ERROR] , [ERROR] +-org.apache.cxf:cxf-rt-transports-http-hc:2.7.11 [ERROR] +-org.apache.httpcomponents:httpcore-nio:4.2.4 [ERROR] and [ERROR] +-org.apache.cxf:cxf-rt-transports-http-hc:2.7.11 [ERROR] +-org.apache.httpcomponents:httpasyncclient:4.0-beta3 [ERROR] +-org.apache.httpcomponents:httpcore-nio:4.2.2 I fix this by adding the following exclusions:- exclusions exclusion groupIdorg.apache.httpcomponents/groupId artifactIdhttpcore-nio/artifactId /exclusion exclusion groupIdorg.apache.httpcomponents/groupId artifactIdhttpcore/artifactId /exclusion exclusion groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /exclusion /exclusions and then adding in the following explicit dependencies:- dependency groupIdorg.apache.httpcomponents/groupId artifactIdhttpcore/artifactId version4.2.4/version scopetest/scope /dependency dependency groupIdorg.apache.httpcomponents/groupId artifactIdhttpcore-nio/artifactId version4.2.4/version scopetest/scope /dependency I've raised Jirahttps://issues.apache.org/jira/browse/CXF-5690 to ask whether it's possible for you to depend on the latest release version of httpasyncclient in future releases which I think will solve the issue. Many thanks Mandy Sent from a mobile device -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[ANN] Apache CXF 2.6.14 and 2.7.11 are available!
The Apache CXF team is proud to announce the availability of the latest patches: 2.7.11, and 2.6.14. One very important note: there will only be one more planned 2.6.x release. If there are any important fixes needed, get them in ASAP. Users are strongly encouraged to start moving toward 2.7.11 or start testing with the latest 3.0.0 snapshots. Apache CXF is an open source services framework. CXF helps you build and develop services using front end programming APIs, like JAX-WS and JAX-RS. These services can speak a variety of protocols such as SOAP, XML/HTTP, RESTful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI. This is mostly a patch release to fix problems and issues that users have encountered. 2.7.11 fixes over 65 JIRA issues reported against 2.7.11.See: http://cxf.apache.org/cxf-2711-release-notes.html 2.6.14 fixes over 20 JIRA issues reported against 2.6.13.See: http://cxf.apache.org/cxf-2614-release-notes.html For more information see: * Download: http://cxf.apache.org/download.html * Website: http://cxf.apache.org/ * Mailing lists: http://cxf.apache.org/mailing-lists.html If you have feedback, questions or would like to get involved in the CXF project please join the mailing lists and let us know your thoughts. The Apache CXF Team http://cxf.apache.org/
Re: Set default package for objects generated by the dynamic client
On Apr 14, 2014, at 12:42 PM, akaine cy387...@hotmail.com wrote: I've seen both articles/threads you mention before though I really have no idea how to make CXF see the JAXB binding config xml. Any suggestions? For the DynamicClientFactory, there are createClient methods that have a ListString bindingFiles” parameter at the end that you can use to pass them to CXF. For code generation on the command line, there is the “-b bindingfile.xml” flag. Dan -- View this message in context: http://cxf.547215.n5.nabble.com/Set-default-package-for-objects-generated-by-the-dynamic-client-tp5742640p5742819.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Migrating to CXF with Jaxb from xfire with agesi
JAXB, by default, uses unqualified elements whereas Aegis/XFire by default used
qualified elements. Couple ways around that:
1) For every element, specify the namespace.
@XmlElement(name = tag, namespace = http:...)
likely easier:
2) Add a package-info.java with:
@javax.xml.bind.annotation.XmlSchema(namespace = http://..;,
elementFormDefault = XmlNsForm.QUALIFIED)
The best option, if you need to be completely wire compatible, is to take the
WSDL generated from the old service, run wsdl2java on it, and use the generated
types. A bit more migration effort, but it’s definitely the best way to make
sure it’s compatible.
Dan
On Apr 11, 2014, at 3:58 AM, virajn mayuravi...@gmail.com wrote:
I'm migrating my xfire soap project which uses aegis for databinding to cxf
with jaxb. I got the new cxf project working for old xfire requests with
aegis binding. But when i move the databinding to jaxb unmarshalling errror
occurs.
This is my cxf web service definition.
bean id=jaxbBean class=org.apache.cxf.jaxb.JAXBDataBinding
scope=prototype/
bean id=jaxws-and-aegis-service-factory
class=org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean
scope=prototype
property name=dataBinding ref=jaxbBean/
property name=serviceConfigurations
list
bean
class=org.apache.cxf.jaxws.support.JaxWsServiceConfiguration/
bean
class=org.apache.cxf.aegis.databinding.XFireCompatibilityServiceConfiguration/
bean
class=org.apache.cxf.service.factory.DefaultServiceConfiguration/
/list
/property
/bean
jaxws:endpoint id=trace address=/trace
implementor=#traceImplBean
jaxws:serviceFactory
ref bean=jaxws-and-aegis-service-factory/
/jaxws:serviceFactory
jaxws:inInterceptors
bean class=org.apache.cxf.interceptor.LoggingInInterceptor/
/jaxws:inInterceptors
jaxws:outInterceptors
bean class=org.apache.cxf.interceptor.LoggingOutInterceptor/
/jaxws:outInterceptors
/jaxws:endpoint
I used @XMLRootElement Annotaion on my DTOs as following.
@XmlRootElement(name = context )
public class Context implements Serializable {
private KeyValues keyValues;
.
}
@XmlRootElement(name = keyValues )
public class KeyValues implements Serializable {
private String tag;
private String value;
}
One method which i tested generated following soap request for cxf
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:pay=http://example.project.com;
soapenv:Header/
soapenv:Body
pay:trace
pay:context
keyValues
tagtag/tag
valuevalue/value
/keyValues
/pay:context
/pay:trace
/soapenv:Body
/soapenv:Envelope
**HOWEVER** old xfire generate following request, I have mark the
difference.
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:pay=http://example.project.com; xmlns:api=http://example.com;
soapenv:Header/
soapenv:Body
pay:trace
pay:context
api:keyValues
***api:KeyValues***
api:tagtag/api:tag
api:valuevalue/api:value
***/api:KeyValues***
/api:keyValues
/pay:context
/pay:trace
/soapenv:Body
/soapenv:Envelope
I got following exception when i tried to send xfire request to cxf service.
javax.xml.bind.UnmarshalException: unexpected element
(uri:http://example.project.com;, local:keyValues). Expected elements are
{}keyValues
So I think i need to add additional KeyValues/KeyValues tags to cxf
request inorder to compatible with xfire. Does anyone knows how to resolve
this ?
Thanks in advance.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Migrating-to-CXF-with-Jaxb-from-xfire-with-agesi-tp5742682.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Getting java.lang.ClassCast Exception: javax.xml.ws.Holder cannot be cast to java.lang.String
[mailto:david.wise...@telus.com] Sent: Donnerstag, 10. April 2014 19:59 To: users@cxf.apache.orgmailto:users@cxf.apache.org Subject: Getting java.lang.ClassCast Exception: javax.xml.ws.Holder cannot be cast to java.lang.String Hi CXF Community, I've been working with CXF for a several months now on a NonStop server. I've built sychronous demo clients and servlets with no problems. I'm now trying to build an asynchronous client but I can't seem to get past the following ClassCastException which occurs as soon as I call... AsyncDemoResponse0 reply = asyncDemoResp.get(); i.e., same point as GreetMeSometimeResponse reply = greetMeSomeTimeResp.get(); from example page. Just like in the Async Consumer example page, wsl2java generates 3 method in the web service interface class, i.e., synchronous, polling and callback. When I invoke the synchronous form everything works fine. My thought is this is a newbie error but if this description is not obvious, I can provide more information on advisement. Also note when I call my /ResponseGreetMeSometimeResponse greetMeSomeTimeResp = port.greetMeSometimeAsync(System.getProperty(user.name)); /*equivalent*, namely, (/ResponseAsyncDemoResponse0 asyncDemoResp = asyncDemoPort.asyncDemoAsync(_asyncDemo_clientNo, _asyncDemo_groupNo, _asyncDemo_certNo/); no activity is detected on the servlet (service) side, i.e., nothing appears in the web server's access.log. Any thought would be appreciated. =2014-04-10 13:50:18,485 ERROR [main] trace.event - Web Service invocation error (javax.xml.ws.WebServiceException: java.lang.ClassCastException: javax.xml.ws.Holder cannot be cast to java.lang.String). java.util.concurrent.ExecutionException: javax.xml.ws.WebServiceException: java.lang.ClassCastException: javax.xml.ws.Holder cannot be cast to java.lang.String at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at com.telus.health.pdd.business.RddsReqProcessor.processRequest(RddsReqP roc essor.java:691) at com.telus.health.pdd.access.DbRequestHandler.processRequest(DbRequestH an dler.java:391) at com.telus.health.pdd.access.DbRequestHandler.main(DbRequestHandler.jav a:1 39) Caused by: javax.xml.ws.WebServiceException: java.lang.ClassCastException: javax.xml.ws.Holder cannot be cast to java.lang.String at com.sun.xml.internal.ws.client.AsyncInvoker.run(AsyncInvoker.java:59) at com.sun.xml.internal.ws.client.AsyncResponseImpl.run(AsyncResponseImpl .java :73) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu tor.j ava:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java: 908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.ClassCastException: javax.xml.ws.Holder cannot be cast to java.lang.String at com.telus.health.pdd.asyncdemo.AsyncDemo$JaxbAccessorF_certNo.set(Fiel dA ccessor_Ref.java:45) at com.sun.xml.internal.bind.v2.runtime.reflect.Accessor.setUnadapted(Acc essor.j ava:155) at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$7.set(JAXBContextImpl. java:926) at com.sun.xml.internal.ws.client.sei.BodyBuilder$DocLit.build(BodyBuilde r.java:2 07) at com.sun.xml.internal.ws.client.sei.BodyBuilder$JAXB.createMessage(Body Build er.java:88) at com.sun.xml.internal.ws.client.sei.SEIMethodHandler.createRequestMessa ge(S EIMethodHandler.java:204) at com.sun.xml.internal.ws.client.sei.AsyncMethodHandler$SEIAsyncInvoker. do_ru n(AsyncMethodHandler.java:147) at com.sun.xml.internal.ws.client.AsyncInvoker.run(AsyncInvoker.java:54) ... 4 more Final note: the the only alteration I made to support asynchronous web service on the service (servlet) side was the inclusion of async-supportedtrue/async- supported in the deplyment descriptor (web.xml). David -- View this message in context: http://cxf.547215.n5.nabble.com/Getting-java- lang-ClassCast-Exception-javax-xml-ws-Holder-cannot-be-cast-to-java-la ng- String-tp5742667.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Force namespace prefix in request
My only suggestion is to upgrade to a newer version of CXF. If you grab the
latest CXF versions, there are several options such as the transform feature,
namespace mappings, etc… They wouldn’t be available with something that old.
Dan
On Apr 8, 2014, at 6:25 PM, Pablo Caballero pdcv...@gmail.com wrote:
Hi! I'm using cxf (2.2.10 version) as a WS client. The nasty server side
implementation (I can't change it nor suggest to change it to his owner)
requires:
blah:hola xmlns:blah=http://lalalala;
..
/blah:hola
and the (correct) payload generated by my client is
hola xmlns=http://lalalala;
..
/hola
(blah can be whatever I want)
I played with the package-info.java file adding:
@javax.xml.bind.annotation.XmlSchema(
namespace = http://lalalala;,
elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED,
xmlns = {
@javax.xml.bind.annotation.XmlNs(prefix = blah,
namespaceURI=http://lalalala;)}
)
but it does not seem to work.
Could someone help me?
Thank you very much
Best regards!
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: UnmarshallingExceptions after upgrading to cxf 2.7.10
Yea, this looks like a bug, but I also couldn’t reproduce it. Can you create
a small test case that shows the issue? I used one of our “hello world” type
examples and just send a soap message via curl with the default namespace set
that way and it worked fine.
Dan
On Apr 9, 2014, at 10:28 AM, Sven Haster sven.has...@topicus.nl wrote:
Hi all,
In our application we use CXF (among other things) to handle our webservices
based on our java classes. Since we upgraded to CXF 2.7.10 the exact same
request that worked in 2.7.7 now causes UnmarshallingErrors. This doesn't
exist when using (for example) soapui to generate the requests as soapui
handles explicit namespaces correctly but Axis 1.4 generates some funky (but
valid) XML that repeatedly redefines the default namespace, which causes CXF
to choke. I've been able to whittle the generating version down to 2.7.9 as
this problem doesn't exist in CXF 2.7.8 but does exist in CXF 2.7.9 but I
have unfortunately been unable to determine the exact cause.
The request SoapUI generates based on the wsdl and which works in every
version of CXF is:
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wis=http://wis.webservices.example.nl/;
soapenv:Header/
soapenv:Body
wis:getStudent
studentNumber?/studentNumber
/wis:getStudent
/soapenv:Body
/soapenv:Envelope
However, one of our larger third-party clients uses Axis 1.4 to generate
requests which look like:
soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:wis=http://wis.webservices.example.nl/;
soapenv:Header/
soapenv:Body
getStudent xmlns=http://wis.webservices.iridium.topicus.nl/;
studentNumber xmlns=115188/studentNumber
/getStudent
/soapenv:Body
/soapenv:Envelope
CXF 2.7.8 accepts this request and gives the correct response, however CXF
2.7.9 and 2.7.10 both give the following error:
Unmarshalling Error: unexpected element
(uri:http://wis.webservices.example.nl/;, local:studentNumber). Expected
elements are {}studentNumber
Both soapUI as well as http://www.w3schools.com/xml/xml_validator.asp and
http://www.xmlvalidation.com/ validate the XML so we believe the second
request is a correct request (though perhaps a bit unwieldy with redefining
the default namespace) and CXF shouldn't choke on it.
Do you agree? If so, is there already a bug for this? We haven't been able to
find one. Can you advise us on how best to create an issue for this (or can
you create an issue for us) and perhaps help define which issue is the cause
of this problem.
Regards,
Sven Haster
Topicus BV
Postbus 317
7400 AH Deventer
Leeuwenbrug 23 (bezoekadres)
T. +31 (0)6 3400 9545
T. +31 (0)570 662 662
E. sven.has...@topicus.nlmailto:sven.has...@topicus.nl
I. http://www.topicus.nl
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Detecting unmarshalling error with Oneway operations
If you set the property: “org.apache.cxf.oneway.robust” to “true” on the server side endpoint, then CXF will delay sending the 202 and if there is an error parsing, it will send back a fault. However, most clients won’t process the fault anyway if it’s a oneway. With 2.7.11 (due soon), if you set the same property on the client, it will process the fault in that case. Dan On Apr 7, 2014, at 6:02 AM, kupkaj jur...@gmx.com wrote: Hi, I have a problem with detecting unmarshalling exceptions (on server side) when invoking one-way operations on soap service built upon cxf. For example, when client sends enpty element with type xsd:date, or some invalid number in xsd:integer element, somewhere on chain DocLiteralInInterceptor.handleMessage() gets invoked, and from within this method DataReaderXMLStreamReader.read() is called. This call fails and message gets unwinded from within PhaseInterceptorChain.doIntercept(). Client receives HTTP 200 :OK status (instead of HTTP 202: Accepted) and on server side there is no way for service logic to detect there was some soap message sent at all. So messages with invalid content get practically lost, I can only find traces of them inside server log file. This is a problem, because I need to notify client side (which has its own service published with oneway method for processing async responses from server) that there was something wrong with request. Moreover, when I added reliable messaging feature on cxf bus (both client and server), client keeps resending the same message over and over again, because there is simply no reply from server other than http 200. I tried to reproduce similar problem with Metro web service: elements with invalid content are unmarshalled simply as null value. So what can be done with cxf service to enable me to process this invalid messages? Do I need to insert a custom interceptor somewhere on the chain, or is there some other solution? -- View this message in context: http://cxf.547215.n5.nabble.com/Detecting-unmarshalling-error-with-Oneway-operations-tp5742536.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Access to SOAP parameters and parameter names in interceptor
On Mar 31, 2014, at 3:49 PM, David Hay david@enstratius.com wrote:
Ok, yes, that's what I'm doing on the REST side.
I've added @WebParam for the SOAP calls, but can't figure out how to access
it by name. Where should I expect to see them?
On the SOAP side, if you grab the BindingOperationInfo from the exchange:
BindingOperationInfo bop = exchange.getBindingOperationInfo();
you can then do:
bop.getInput().getMessageParts()
to then iterate over the parts that it deserialized. Each part would have the
“name” as well as the index into the MessageContentsList as to where that part
was stored.
Dan
On Fri, Mar 28, 2014 at 12:37 PM, Sergey Beryozkin
sberyoz...@gmail.comwrote:
You probably refer to the names set in annotations like PathParam(id) ?
If so then Soap WebParam should give the same info...
Cheers, Sergey
On 28/03/14 16:34, David Hay wrote:
Thanks...
Unfortunately it looks like Method only gives you the param names if debug
is enabled during compilation...
CXF has that info for REST calls - it doesn't for SOAP?
On Fri, Mar 28, 2014 at 11:49 AM, Sergey Beryozkin sberyoz...@gmail.com
wrote:
This should give the list of parameters:
final List Object arguments = MessageContentsList.
getContentsList(message);
(the values are in the order the parameters are declared)
and given the Method you can get to the names.
By the way, check Bean Validation feature, it will work for JAXWS,
http://cxf.apache.org/docs/validationfeature.html#ValidationFeature-
Configuration
Andriy Redko has just blogged about it too:
http://aredko.blogspot.ie/2014/03/apache-cxf-30-jax-rs-20-and-bean.html
Sergey
On 28/03/14 15:38, David Hay wrote:
Hi,
Sorry if I wasn't clear - I'm trying to access the parameters passed to
the
backend SOAP Service methods, so x and y in this case...
public void doThis(String x, String y) {...}
On Fri, Mar 28, 2014 at 9:49 AM, Jose María Zaragoza
demablo...@gmail.comwrote:
2014-03-28 14:46 GMT+01:00 David Hay david@enstratius.com:
Hi,
I'm sure this has been asked before, but I can't seem to find the
answer.
I need to validate SOAP parameters, so need to access the incoming
parameter name/value in a Interceptor.
What kind of SOAP parameters ?
How would I do this?
cheers
David
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Signed/encrypted MTOM
-- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Is CXF 2.6.1 Compatible with Spring 3.2.8
2.6.x is really only tested with Spring 3.0.x. However, it should work fine with 3.2.8 as 3.2.x doesn’t remove any of the deprecated methods that we used. CXF 3.x will require Spring 3.2.6 or newer as we switched completely to the new methods (so CXF will work with Spring 4 which did remove them). Dan On Mar 24, 2014, at 10:46 AM, Bruce Bateman bruce.bate...@telus.com wrote: -- View this message in context: http://cxf.547215.n5.nabble.com/Is-CXF-2-6-1-Compatible-with-Spring-3-2-8-tp5741776.html Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Long delay before sending SOAP request
At that point, it’s establishing the connection, handling any HTTPs handshake,
and then writing the data to the connection. Thus, it could be anything from
the server side’s backlog being full and thus having to wait, the server side
being slow reading some data, the HTTPs hand shake trying to do DNS entries or
something to evaluate the certs, etc….
Do a “kill -3” on the process to get the stack trace, that may help narrow it
down some more.
Dan
On Mar 24, 2014, at 8:21 AM, Felix Ngaserin fe...@nusapro.com wrote:
I am using CXF 2.7.10 at the moment, however for the past few days I've been
experiencing a slowdown.
I'm using JaxWSProxyFactoryBean to create my service class as pointed out by
the user guide.
It works fine but however sometimes I do experience a slow down.
This is what I get from the log:
snipped
2014-03-24 19:01:14.365 [http-8989-1] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor
org.apache.cxf.interceptor.WrappedOutInterceptor@248a4156
2014-03-24 19:01:14.365 [http-8989-1] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor
org.apache.cxf.interceptor.BareOutInterceptor@70c787d7
2014-03-24 19:01:14.366 [http-8989-1] DEBUG
o.apache.cxf.transport.http.Headers - Accept: */*
2014-03-24 19:01:14.366 [http-8989-1] DEBUG
o.apache.cxf.transport.http.Headers - SOAPAction: urn:UMARKETSCWS/balance
2014-03-24 19:01:14.366 [http-8989-1] DEBUG
o.a.cxf.transport.http.HTTPConduit - No Trust Decider for Conduit
'{urn:UMARKETSCWS}UMarketSCPort.http-conduit'. An afirmative Trust Decision
is assumed.
2014-03-24 19:01:34.124 [http-8989-1] DEBUG
o.a.cxf.transport.http.HTTPConduit - Sending POST Message with Headers to
https://ipaddress:host/services/umarketsc Conduit
:{urn:UMARKETSCWS}UMarketSCPort.http-conduit
2014-03-24 19:01:34.125 [http-8989-1] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor$SoapOutEndingInterceptor@a92fe09
2014-03-24 19:01:34.125 [http-8989-1] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor
org.apache.cxf.interceptor.StaxOutEndingInterceptor@5df86e79
2014-03-24 19:01:34.125 [http-8989-1] DEBUG
o.a.cxf.phase.PhaseInterceptorChain - Invoking handleMessage on interceptor
org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor@3429dbb8
2014-03-24 19:01:34.126 [http-8989-1] INFO o.a.c.s.U.UMarketSCPort.UMarketSC
- Outbound Message
snipped
As we can see that sometimes it will need about 20 seconds before Sending
POST Message.
What I am trying to figure out is between No Trust Decider for Conduit and
Sending POST Message, what does it really do?
Is it waiting to open a connection before sending POST Message? We have been
trying to troubleshoot this issue by checking on the network side and at the
other end.
There seems to be no problem at all.
Other than that, we are also running concurrent request to the service. What
I don't understand is that if there's a request delayed, the rest of the
concurrent request will be blocked. After the response was received on the
first execution than the rest of threads will also receive response almost
instantly at the same time. Is this an expected behavior?
Regards,
Felix Ngaserin
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Runtime exception
On Mar 19, 2014, at 3:13 AM, SPB spatri...@hotmail.com wrote: Using the latest Apache CXF 2.7.10 (maven plugin) and getting runtime exception when calling generated code: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map at org.apache.cxf.binding.soap.interceptor.SoapPreProtocolOutInterceptor.setSoapAction(SoapPreProtocolOutInterceptor.java:111) Any ideas on how to work around this? Any chance you can create a sample project? The line there is: MapString, ListString reqHeaders = CastUtils.cast((Map?, ?)message.get(Message.PROTOCOL_HEADERS)); so something is setting the PROTOCOL_HEADERS to just a String, not a a Map like it would need to be. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: http-conduit timeout for long delay decoupled responses
org.apache.cxf.endpoint.ClientImpl waitResponse
ADVERTENCIA: Timed out waiting for response to operation
{http://addressing.test/}add.
Exception in thread main java.lang.NullPointerException
at com.sun.proxy.$Proxy40.add(Unknown Source)
at
test.addressing.cxf.clientsample.AddressingCXFClientSample.main(AddressingC
XFClientSample.java:46)
thanks in advance
Regards
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WSDL2JAVA question
This is one of the “issues” I have with JAX-WS. The “interface” that is generated is supposed to be completely generated from the portType. Thus, it does not know from the portType that this is 1.1 or 1.2. The SOAPBinding annotation should only go on the actual service object which would represent the service/port/binding which is normally something you create manually and thus up to you to add that annotation. (or provide the wsdlLocation so that we can pick up that information from the wsdl) Dan On Mar 14, 2014, at 10:40 AM, Michel Labarre michel.laba...@helicom.fr wrote: Hello We running CXF 1.6.7 version with SOAP 1.1 wsdl. All run fine. New services are required with SOAP 1.2. I run the Web Service generator under eclipse to generate all classes from WSDL. Generation works fine but when I test with SOAPUI on the newly installed server I obtain a fault with the famous message CXF A SOAP 1.2 message is not valid when sent to a SOAP 1.1 only endpoint When I analyze the service class I don't see the bindingtype concerning SOAP 1.2 (annotation @BindingType(javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING). If I add this annotation, server response is correct. Is this problem is a known problem ? Many thanks My WSDL: ?xml version=1.0 encoding=UTF-8 standalone=no? wsdl:definitions xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:srv=http://www.ws.test.com/TESTV1/; xmlns:xmime=http://www.w3.org/2005/05/xmlmime; xmlns:header=http://referentiel.test.fr/SoapHeaderV1; xmlns:erreurs=http://referentiel.test.fr/ErreursV1; xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd; xmlns:wsp=http://www.w3.org/ns/ws-policy; xmlns:sp=http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702; xmlns:soap=http://www.w3.org/2003/05/soap-envelope; xmlns:wsoap12=http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:wsoma=http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization; xmlns:model=http://model.ws.test.com/TESTV1/; name=test1 targetNamespace=http://www.ws.test.com/TESTV1/; wsdl:types xsd:schema xsd:import schemaLocation=test1.xsd namespace=http://model.ws.test.com/TESTV1/; / xsd:import schemaLocation=Header.xsd namespace=http://referentiel.test.fr/SoapHeaderV1; / xsd:import schemaLocation=Erreur.xsd namespace=http://referentiel.test.fr/ErreursV1; / /xsd:schema /wsdl:types wsdl:message name=TechnicalFault wsdl:part name=TechnicalException element=erreurs:TechnicalException / /wsdl:message wsdl:message name=myrequest wsdl:part name=parameters element=model:myrequest / wsdl:part name=myheader element=header:myheader / /wsdl:message wsdl:message name=myresponse wsdl:part name=parameters element=model:myresponse / /wsdl:message wsdl:portType name=Service wsdl:operation name=myrequest wsdl:input message=srv:myrequest name=myrequest / wsdl:output message=srv:myresponse name=myresponse / wsdl:fault message=srv:TechnicalFault name=TechnicalFault / /wsdl:operation /wsdl:portType wsdl:binding name=Service_Binding type=srv:Service wsoap12:binding style=document transport=http://schemas.xmlsoap.org/soap/http; / wsdl:operation name=myrequest wsoap12:operation soapAction=http://www.ws.test.com/TEST/V1/myrequest; / wsdl:input name=myrequest wsoap12:body use=literal parts=parameters / wsoap12:header message=srv:myrequest part=myheader use=literal / /wsdl:input wsdl:output name=myresponse wsoap12:body use=literal parts=parameters / /wsdl:output wsdl:fault name=TechnicalFault wsoap12:fault name=TechnicalFault use=literal / /wsdl:fault /wsdl:operation /wsdl:binding wsdl:service name=TEST1_Service wsdl:port binding=srv:Service_Binding name=TEST1 wsoap12:address location=https://localhost:8080/; / /wsdl:port /wsdl:service /wsdl:definitions -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
