date:20171018

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

This was the last hurdle... 

The api is addAllowedEncryptionMethod for the data not 
addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

The error message was correct that is not a key encryption algo.

With this change, the workaround was fully tested.

Thanks Colm!

-Original Message-
From: markfu...@yahoo.com.INVALID [mailto:markfu...@yahoo.com.INVALID] 
Sent: Wednesday, October 18, 2017 12:30 PM
To: users@cxf.apache.org; cohei...@apache.org
Subject: RE: Websphere 9 and CXF

Thank you.  Agreed.  I  fixed that on the websphere client to use RSA OAEP.  
Additionally had to configure the encryption key reference type in the 
websphere JAX-WS client to REF_ID to make it match what CXF expects.  Otherwise 
I was getting "ENC_KEY_INFO MUST have exactly one child element" error from CXF.

 

  X509GenerateCallbackHandler encryptionCallback1 = new 
X509GenerateCallbackHandler(...);

   SecurityToken encryptingToken= 
wssfactory.newSecurityToken(X509Token.class, encryptionCallback1);

   WSSEncryption encryption = 
wssfactory.newWSSEncryption(encryptingToken);

   encryption.setKeyEncryptionMethod(WSSEncryption.KW_RSA_OAEP);

   encryption.addEncryptPart(WSSEncryption.BODY_CONTENT);

   encryption.addEncryptPartByXPath(sbtimestamp.toString());

   encryption.addEncryptPart(WSSEncryption.SIGNATURE);

   encryption.setTokenReference(X509Token.REF_KEYID);

   

   generationContext.add(encryption); 

   generationContext.process(requestContext

 

The message makes it in and out of CXF from websphere but now the trick is that 
Axis (IBM Websphere) is having hard time decrypting the response...

 

WSSConsumingContext consumerContext = wssfactory.newWSSConsumingContext();

   X509ConsumeCallbackHandler decryptionCallback = new 
X509ConsumeCallbackHandler(…);

   WSSDecryption decryption = 
wssfactory.newWSSDecryption(X509Token.class, decryptionCallback);

   
decryption.addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

   
decryption.addRequiredDecryptPart(WSSDecryption.BODY_CONTENT);

   decryption.addRequiredDecryptPart(WSSDecryption.SIGNATURE);

   consumerContext.add(decryption);

 

This is the error on the websphere client side now…

 

“key encryption method is not valid.”

[10/18/17 12:04:21:575 EDT] 00a7 SystemOut O 
com.ibm.websphere.wssecurity.wssapi.WSSException: CWWSS5364E: The 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc key encryption method is not 
valid.

   at 
com.ibm.websphere.wssecurity.wssapi.WSSException.format(WSSException.java:75)

   at 
com.ibm.ws.wssecurity.wssapi.dec.impl.WSSDecryptionImpl.addAllowedKeyEncryptionMethod(WSSDecryptionImpl.java:210)

   

I do have the outbound configuration to use tripledes-cbc in cxf with spring

 







…





 

   
 

  
 



…

http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>







 

Interoperability not easy.

 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 10:22 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

 

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security policy 
requires RSA OAEP. For example, you might have "Basic128" in your policy, but 
it sounds like the sender is using "Basic128Rsa15".

 

Colm.

 

On Wed, Oct 18, 2017 at 3:17 PM, <  
markfu...@yahoo.com.invalid> wrote:

 

> Hi Colm,

> 

> 

> 

> I am still working on it, it looks like a different issue than the xml

> ordering. Maybe you can see the issue from this information?

> 

> 

> 

> Thanks!

> 

> 

> 

> Mark

> 

> 

> 

> From the logs:

> 

> 

> 

> 2017-10-18 10:09:33 - Found encrypted key element

> 

> 2017-10-18 10:09:38 - Sym Enc Algo:   
> http://www.w3.org/2001/04/

> xmlenc#rsa-1_5

> 

> ….

> 

> 2017-10-18 10:09:41 - The Key transport method does not match the 

> requirement

> 

> 

> 

> Stack trace:

> 

> 

> 

> org.apache.cxf.binding.soap.SoapFault: A security error was 

> encountered when verifying the message

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.

> createSoapFault(WSS4JUtils.java:234)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessageInternal(WSS4JInInterceptor.java:340)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:175)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:86)

> 

> at or

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

Thank you.  Agreed.  I  fixed that on the websphere client to use RSA OAEP.  
Additionally had to configure the encryption key reference type in the 
websphere JAX-WS client to REF_ID to make it match what CXF expects.  Otherwise 
I was getting "ENC_KEY_INFO MUST have exactly one child element" error from CXF.

 

  X509GenerateCallbackHandler encryptionCallback1 = new 
X509GenerateCallbackHandler(...);

   SecurityToken encryptingToken= 
wssfactory.newSecurityToken(X509Token.class, encryptionCallback1);

   WSSEncryption encryption = 
wssfactory.newWSSEncryption(encryptingToken);

   encryption.setKeyEncryptionMethod(WSSEncryption.KW_RSA_OAEP);

   encryption.addEncryptPart(WSSEncryption.BODY_CONTENT);

   encryption.addEncryptPartByXPath(sbtimestamp.toString());

   encryption.addEncryptPart(WSSEncryption.SIGNATURE);

   encryption.setTokenReference(X509Token.REF_KEYID);

   

   generationContext.add(encryption); 

   generationContext.process(requestContext

 

The message makes it in and out of CXF from websphere but now the trick is that 
Axis (IBM Websphere) is having hard time decrypting the response...

 

WSSConsumingContext consumerContext = wssfactory.newWSSConsumingContext();

   X509ConsumeCallbackHandler decryptionCallback = new 
X509ConsumeCallbackHandler(…);

   WSSDecryption decryption = 
wssfactory.newWSSDecryption(X509Token.class, decryptionCallback);

   
decryption.addAllowedKeyEncryptionMethod(WSSEncryption.TRIPLE_DES);

   
decryption.addRequiredDecryptPart(WSSDecryption.BODY_CONTENT);

   decryption.addRequiredDecryptPart(WSSDecryption.SIGNATURE);

   consumerContext.add(decryption);

 

This is the error on the websphere client side now…

 

“key encryption method is not valid.”

[10/18/17 12:04:21:575 EDT] 00a7 SystemOut O 
com.ibm.websphere.wssecurity.wssapi.WSSException: CWWSS5364E: The 
http://www.w3.org/2001/04/xmlenc#tripledes-cbc key encryption method is not 
valid.

   at 
com.ibm.websphere.wssecurity.wssapi.WSSException.format(WSSException.java:75)

   at 
com.ibm.ws.wssecurity.wssapi.dec.impl.WSSDecryptionImpl.addAllowedKeyEncryptionMethod(WSSDecryptionImpl.java:210)

   

I do have the outbound configuration to use tripledes-cbc in cxf with spring

 







…





 

   
 

  
 



…

http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>







 

Interoperability not easy.

 

-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 10:22 AM
To: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

 

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security policy 
requires RSA OAEP. For example, you might have "Basic128" in your policy, but 
it sounds like the sender is using "Basic128Rsa15".

 

Colm.

 

On Wed, Oct 18, 2017 at 3:17 PM, <  
markfu...@yahoo.com.invalid> wrote:

 

> Hi Colm,

> 

> 

> 

> I am still working on it, it looks like a different issue than the xml

> ordering. Maybe you can see the issue from this information?

> 

> 

> 

> Thanks!

> 

> 

> 

> Mark

> 

> 

> 

> From the logs:

> 

> 

> 

> 2017-10-18 10:09:33 - Found encrypted key element

> 

> 2017-10-18 10:09:38 - Sym Enc Algo:   
> http://www.w3.org/2001/04/

> xmlenc#rsa-1_5

> 

> ….

> 

> 2017-10-18 10:09:41 - The Key transport method does not match the 

> requirement

> 

> 

> 

> Stack trace:

> 

> 

> 

> org.apache.cxf.binding.soap.SoapFault: A security error was 

> encountered when verifying the message

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.

> createSoapFault(WSS4JUtils.java:234)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessageInternal(WSS4JInInterceptor.java:340)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:175)

> 

> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.

> handleMessage(WSS4JInInterceptor.java:86)

> 

> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(

> PhaseInterceptorChain.java:308)

> 

> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(

> ChainInitiationObserver.java:121)

> 

> at 

> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(

> AbstractHTTPDestination.java:267)

> 

> at org.apache.cxf.transport.servlet.ServletController.

> invokeDestination(ServletController.java:234)

> 

> at org.apache.cxf.transport.servlet.Ser

Dynamically changing endpoints

2017-10-18 Thread Ken Hancock

I'm implementing a client for a soap endpoint where the messages return
different callouts to be used for individual soap operations, each endpoint
supporting the same service wsdl.  Does anyone have suggestions on the best
way to change the endpoint for different soap operations?

I could create a separate proxy for each operation, but that seems
particularly slow and heavyweight.

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

Yes, the Encrypted Key is using RSA v1.5, whereas probably your security
policy requires RSA OAEP. For example, you might have "Basic128" in your
policy, but it sounds like the sender is using "Basic128Rsa15".

Colm.

On Wed, Oct 18, 2017 at 3:17 PM,  wrote:

> Hi Colm,
>
>
>
> I am still working on it, it looks like a different issue than the xml
> ordering. Maybe you can see the issue from this information?
>
>
>
> Thanks!
>
>
>
> Mark
>
>
>
> From the logs:
>
>
>
> 2017-10-18 10:09:33 - Found encrypted key element
>
> 2017-10-18 10:09:38 - Sym Enc Algo: http://www.w3.org/2001/04/
> xmlenc#rsa-1_5
>
> ….
>
> 2017-10-18 10:09:41 - The Key transport method does not match the
> requirement
>
>
>
> Stack trace:
>
>
>
> org.apache.cxf.binding.soap.SoapFault: A security error was encountered
> when verifying the message
>
> at org.apache.cxf.ws.security.wss4j.WSS4JUtils.
> createSoapFault(WSS4JUtils.java:234)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessageInternal(WSS4JInInterceptor.java:340)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessage(WSS4JInInterceptor.java:175)
>
> at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.
> handleMessage(WSS4JInInterceptor.java:86)
>
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:308)
>
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
>
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(
> AbstractHTTPDestination.java:267)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invokeDestination(ServletController.java:234)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:208)
>
> at org.apache.cxf.transport.servlet.ServletController.
> invoke(ServletController.java:160)
>
> at org.apache.cxf.transport.servlet.CXFNonSpringServlet.
> invoke(CXFNonSpringServlet.java:191)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> handleRequest(AbstractHTTPServlet.java:301)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> doPost(AbstractHTTPServlet.java:220)
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
>
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.
> service(AbstractHTTPServlet.java:276)
>
> at org.apache.catalina.core.ApplicationFilterChain.
> internalDoFilter(ApplicationFilterChain.java:291)
>
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(
> ApplicationFilterChain.java:206)
>
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(
> WsFilter.java:52)
>
>
>
>
>
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Wednesday, October 18, 2017 9:44 AM
> To: markfu...@yahoo.com
> Cc: users@cxf.apache.org
> Subject: Re: Websphere 9 and CXF
>
>
>
> What was the error you saw when you moved the EncryptedKey Element above
> the EncryptedData Element? What is actually stored inside the first
> EncryptedData Element?
>
> Colm.
>
>
>
> On Wed, Oct 18, 2017 at 1:04 PM, Mark Fuini  markfu...@yahoo.com> > wrote:
>
> Thank you so much for getting back to me.  This is an ongoing daily issue
> for us.
>
>
>
> The conclusion you came to was my analysis also.
>
>
>
> But I not sure the actual xml ordering is part of the spec.  So their xml
> may be valid.  But that means web service which use event driven xml
> parsing are at a disadvantage because the security node  would have to be
> completely parsed before assuming the key is not there.
>
>
>
> Regardless IBM is not going to change their security engine just for me.
>
>
>
> Any ideas for work around?
>
>
>
> One idea:
>
> I tried a message change interceptor in cxf on the server side and
> reordered the encrypted key to be first element in the security node.  Is
> this a valid way to resolve it on server side?  It did not work completely.
>
>
>
> The missing keyInfo message went away but then I received a security
> header error.  Can you please try that with the sample xml or I can resend
> it?
>
> Any other suggestions?
>
>
> Thanks again.
>
> On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh
>
> mailto:cohei...@apache.org> > wrote:
>
> The problem here is that the EncryptedKey structure, which contains the
> ReferenceList pointing to the first EncryptedData structure, is below the
> EncryptedData structure. WSS4J parses the security header in order, and so
> when it hits the first EncryptedData structure it does not know how to
> decrypt it. This is a problem with websphere - the ReferenceList or
> EncryptedKey/ReferenceList must be above the EncryptedData element.
>
> Colm.
>
> On Tue, Oct 17, 2017 at 1:08 PM,  markfu...@yahoo.com.invalid> > wrote:
>
> > Hi Colm,
> >
> > Thanks for the help.  Please take a look at this xml generated by
> > websphere 9 (with the exception of the ... where I repla

RE: Websphere 9 and CXF

2017-10-18 Thread markfuini

Hi Colm,

I am still working on it, it looks like a different issue than the xml 
ordering. Maybe you can see the issue from this information?

Thanks!

Mark

>From the logs:

2017-10-18 10:09:33 - Found encrypted key element

2017-10-18 10:09:38 - Sym Enc Algo: http://www.w3.org/2001/04/xmlenc#rsa-1_5

….

2017-10-18 10:09:41 - The Key transport method does not match the requirement

Stack trace:

org.apache.cxf.binding.soap.SoapFault: A security error was encountered when 
verifying the message

at 
org.apache.cxf.ws.security.wss4j.WSS4JUtils.createSoapFault(WSS4JUtils.java:234)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:340)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:175)

at 
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:86)

at 
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)

at 
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)

at 
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)

at 
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)

at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)

at 
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)

at 
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:191)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)

at 
org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276)

at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)

at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

From: Colm O hEigeartaigh [mailto:cohei...@apache.org] 
Sent: Wednesday, October 18, 2017 9:44 AM
To: markfu...@yahoo.com
Cc: users@cxf.apache.org
Subject: Re: Websphere 9 and CXF

What was the error you saw when you moved the EncryptedKey Element above the 
EncryptedData Element? What is actually stored inside the first EncryptedData 
Element?

Colm.

On Wed, Oct 18, 2017 at 1:04 PM, Mark Fuini mailto:markfu...@yahoo.com> > wrote:

Thank you so much for getting back to me.  This is an ongoing daily issue for 
us.

The conclusion you came to was my analysis also. 

But I not sure the actual xml ordering is part of the spec.  So their xml may 
be valid.  But that means web service which use event driven xml parsing are at 
a disadvantage because the security node  would have to be completely parsed 
before assuming the key is not there.

Regardless IBM is not going to change their security engine just for me.

Any ideas for work around?

One idea:

I tried a message change interceptor in cxf on the server side and reordered 
the encrypted key to be first element in the security node.  Is this a valid 
way to resolve it on server side?  It did not work completely.

The missing keyInfo message went away but then I received a security header 
error.  Can you please try that with the sample xml or I can resend it?

Any other suggestions?

Thanks again.

On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh

mailto:cohei...@apache.org> > wrote:

The problem here is that the EncryptedKey structure, which contains the
ReferenceList pointing to the first EncryptedData structure, is below the
EncryptedData structure. WSS4J parses the security header in order, and so
when it hits the first EncryptedData structure it does not know how to
decrypt it. This is a problem with websphere - the ReferenceList or
EncryptedKey/ReferenceList must be above the EncryptedData element.

Colm.

On Tue, Oct 17, 2017 at 1:08 PM, mailto:markfu...@yahoo.com.invalid> > wrote:

> Hi Colm,
>
> Thanks for the help.  Please take a look at this xml generated by
> websphere 9 (with the exception of the ... where I replaced information)
> and let me know if you can think of any workaround.  To me it seems that
> CXF does not parse the reference list for the EncryptedKey.
>
> Here is the error also:
>
> http://schemas.xmlsoap.org/soap/envelope/";>
>
>
>http://ws.apache.org/wss4j
> ">ns1:SecurityError
>A security error was encountered when verifying
> the message Caused by: EncryptedKey/EncryptedData does not contain
> ds:KeyInfo
>
>ht

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

What was the error you saw when you moved the EncryptedKey Element above
the EncryptedData Element? What is actually stored inside the first
EncryptedData Element?

Colm.

On Wed, Oct 18, 2017 at 1:04 PM, Mark Fuini  wrote:

> Thank you so much for getting back to me.  This is an ongoing daily issue
> for us.
>
> The conclusion you came to was my analysis also.
>
> But I not sure the actual xml ordering is part of the spec.  So their xml
> may be valid.  But that means web service which use event driven xml
> parsing are at a disadvantage because the security node  would have to be
> completely parsed before assuming the key is not there.
>
> Regardless IBM is not going to change their security engine just for me.
>
> Any ideas for work around?
>
> One idea:
> I tried a message change interceptor in cxf on the server side and
> reordered the encrypted key to be first element in the security node.  Is
> this a valid way to resolve it on server side?  It did not work completely.
>
> The missing keyInfo message went away but then I received a security
> header error.  Can you please try that with the sample xml or I can resend
> it?
>
> Any other suggestions?
>
> Thanks again.
>
> On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh
>  wrote:
> The problem here is that the EncryptedKey structure, which contains the
> ReferenceList pointing to the first EncryptedData structure, is below the
> EncryptedData structure. WSS4J parses the security header in order, and so
> when it hits the first EncryptedData structure it does not know how to
> decrypt it. This is a problem with websphere - the ReferenceList or
> EncryptedKey/ReferenceList must be above the EncryptedData element.
>
> Colm.
>
> On Tue, Oct 17, 2017 at 1:08 PM,  wrote:
>
> > Hi Colm,
> >
> > Thanks for the help.  Please take a look at this xml generated by
> > websphere 9 (with the exception of the ... where I replaced information)
> > and let me know if you can think of any workaround.  To me it seems that
> > CXF does not parse the reference list for the EncryptedKey.
> >
> > Here is the error also:
> >
> > http://schemas.xmlsoap.org/soap/envelope/";>
> >
> >
> >http://ws.apache.org/wss4j
> > ">ns1:SecurityError
> >A security error was encountered when verifying
> > the message Caused by: EncryptedKey/EncryptedData does not contain
> > ds:KeyInfo
> >
> >http://cxf.apache.org/fault";>Caused
> > by: org.apache.wss4j.common.ext.WSSecurityException:
> > EncryptedKey/EncryptedData does not contain ds:KeyInfo
> > #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> > EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> > engine.WSSecurityEngine!processSecurityHeader!
> WSSecurityEngine.java!340#*#
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!
> handleMessageInternal!
> > WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> > wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*#
> > org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> > WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> > doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> > ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> > 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> > AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> > ServletController!invokeDestination!ServletController.java!234#*#
> > org.apache.cxf.transport.servlet.ServletController!
> > invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> > ServletController!invoke!ServletController.java!160#*#
> > org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> > invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> > AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> > #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> > doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> > HttpServlet!service!HttpServlet.java!648#*#org..
> > apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> > AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> > ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> > 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> > ApplicationFilterChain.java!206#*#org.apache.tomcat.
> > websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> > org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> > ApplicationFilterChain..java!239#*#org.apache.catalina.
> > core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> > 206#*#org.apache.catalina.core.StandardWrapperValve!
> > invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> > StandardContextValve!invoke!StandardContextValve.java!106#
> > *#org.apache.catalina..authenticator.AuthenticatorBase!invoke!
> > AuthenticatorBase.java!502#*#org.apache.catalina.core.
> > StandardHostValve!invoke

Re: AW: fediz_config.xml hosts

2017-10-18 Thread Matthew Broadhead

Hi Jan,

Thank you for your reply.

In simpleWebapp the fediz_config.xml is linked from the context.xml so
does there need to be a separate fediz_config.xml for each webapp?

className="org.apache.cxf.fediz.tomcat8.FederationAuthenticator"
configFile="conf/fediz_config.xml" />

I was hoping to have one IDP defined on the web at
somedomain.tld:9443/idp and then use it for development and production.
i develop on localhost, test.otherdomain.tld and otherdomain.tld.

But in entities-realm-myRealm.xml there is
class="org.apache.cxf.fediz.service.idp.service.jpa.ApplicationEntity">
value="urn:org:apache:cxf:fediz:fedizhelloworld" />
value="http://docs.oasis-open.org/wsfed/federation/200706"; />

value="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";
/>

value="https://localhost:?(\d)*/.*" />
value="https://localhost:?(\d)*/.*" />

Does this mean I have to define each webapp as an ApplicationEntry in
the IDP in order for it to work? And the constraints have to be set to
the domain I am using?

I have lots of small questions would it be possible to talk on IRC?

Regards,
Matthew

On 18/10/2017 12:00, Jan Bernhardt wrote:

Hi Metthew,

Fediz Config is independent of your hostname. You don't need to define your
hostname in your fediz config.

The only exception is when you use a reverse proxy for your application. Fediz
Plugin will always use the same hostname for the wreply URL that was used
within the request. In case of a reverse proxy the fediz plugin would only see
the internal hostname, but an external user could not follow this redirect to
an internal hostname. For this case you can set a wreply URL within the fediz
plugin configuration.

Hope that helps.

Jan

Von: Matthew Broadhead
Gesendet: Mittwoch, 18. Oktober 2017 10:18:06
An: users@cxf.apache.org
Betreff: fediz_config.xml hosts

Hi,
The example fediz_config.xml file has the format

...
which seems to describe a webapp deployed at Host localhost.

How would it be configured if the webapp is deployed at a different host
in Tomcat server.xml? e.g.

I tried searching for the source. I found
https://github.com/apache/cxf-fediz/blob/master/plugins/core/src/main/java/org/apache/cxf/fediz/core/config/FedizContext.java
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]

apache/cxf-fediz
github.com
cxf-fediz - Mirror of Apache CXF

but couldn't find ContextConfig

Thanks
Matthew

Re: Websphere 9 and CXF

2017-10-18 Thread Mark Fuini

Thank you so much for getting back to me.  This is an ongoing daily issue for 
us.
The conclusion you came to was my analysis also. 
But I not sure the actual xml ordering is part of the spec.  So their xml may 
be valid.  But that means web service which use event driven xml parsing are at 
a disadvantage because the security node  would have to be completely parsed 
before assuming the key is not there.
Regardless IBM is not going to change their security engine just for me.
Any ideas for work around? One idea:I tried a message change interceptor in cxf 
on the server side and reordered the encrypted key to be first element in the 
security node.  Is this a valid way to resolve it on server side?  It did not 
work completely.
The missing keyInfo message went away but then I received a security header 
error.  Can you please try that with the sample xml or I can resend it?

Any other suggestions?
Thanks again.
 
 
  On Wed, Oct 18, 2017 at 6:57 AM, Colm O hEigeartaigh 
wrote:   The problem here is that the EncryptedKey structure, which contains the
ReferenceList pointing to the first EncryptedData structure, is below the
EncryptedData structure. WSS4J parses the security header in order, and so
when it hits the first EncryptedData structure it does not know how to
decrypt it. This is a problem with websphere - the ReferenceList or
EncryptedKey/ReferenceList must be above the EncryptedData element.

Colm.

On Tue, Oct 17, 2017 at 1:08 PM,  wrote:

> Hi Colm,
>
> Thanks for the help.  Please take a look at this xml generated by
> websphere 9 (with the exception of the ... where I replaced information)
> and let me know if you can think of any workaround.  To me it seems that
> CXF does not parse the reference list for the EncryptedKey.
>
> Here is the error also:
>
> http://schemas.xmlsoap.org/soap/envelope/";>
>    
>        
>            http://ws.apache.org/wss4j
> ">ns1:SecurityError
>            A security error was encountered when verifying
> the message Caused by: EncryptedKey/EncryptedData does not contain
> ds:KeyInfo
>            
>                http://cxf.apache.org/fault";>Caused
> by: org.apache.wss4j.common.ext.WSSecurityException:
> EncryptedKey/EncryptedData does not contain ds:KeyInfo
> #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> engine.WSSecurityEngine!processSecurityHeader!WSSecurityEngine.java!340#*#
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessageInternal!
> WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*#
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> ServletController!invokeDestination!ServletController.java!234#*#
> org.apache.cxf.transport.servlet.ServletController!
> invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> ServletController!invoke!ServletController.java!160#*#
> org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> HttpServlet!service!HttpServlet.java!648#*#org..
> apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> ApplicationFilterChain.java!206#*#org.apache.tomcat.
> websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> ApplicationFilterChain..java!239#*#org.apache.catalina.
> core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> 206#*#org.apache.catalina.core.StandardWrapperValve!
> invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> StandardContextValve!invoke!StandardContextValve.java!106#
> *#org.apache.catalina..authenticator.AuthenticatorBase!invoke!
> AuthenticatorBase.java!502#*#org.apache.catalina.core.
> StandardHostValve!invoke!StandardHostValve.java!141#*#
> org.apache.catalina.valves.ErrorReportValve!invoke!
> ErrorReportValve.java!79#*#org.apache.catalina.valves.
> AbstractAccessLogValve!invoke!AbstractAccessLogValve.java!
> 616#*#org.apache.catalina.core.StandardEngineValve!
> invoke!StandardEngineValve.java!88#*#org.apache.catalina.
> connector.CoyoteAdapter!service!CoyoteAdapter.java!
> 521#*#org.apache.coyote.http11.Abs

Re: Websphere 9 and CXF

2017-10-18 Thread Colm O hEigeartaigh

The problem here is that the EncryptedKey structure, which contains the
ReferenceList pointing to the first EncryptedData structure, is below the
EncryptedData structure. WSS4J parses the security header in order, and so
when it hits the first EncryptedData structure it does not know how to
decrypt it. This is a problem with websphere - the ReferenceList or
EncryptedKey/ReferenceList must be above the EncryptedData element.

Colm.

On Tue, Oct 17, 2017 at 1:08 PM,  wrote:

> Hi Colm,
>
> Thanks for the help.  Please take a look at this xml generated by
> websphere 9 (with the exception of the ... where I replaced information)
> and let me know if you can think of any workaround.   To me it seems that
> CXF does not parse the reference list for the EncryptedKey.
>
> Here is the error also:
>
> http://schemas.xmlsoap.org/soap/envelope/";>
> 
> 
> http://ws.apache.org/wss4j
> ">ns1:SecurityError
> A security error was encountered when verifying
> the message Caused by: EncryptedKey/EncryptedData does not contain
> ds:KeyInfo
> 
> http://cxf.apache.org/fault";>Caused
> by: org.apache.wss4j.common.ext.WSSecurityException:
> EncryptedKey/EncryptedData does not contain ds:KeyInfo
> #*#org.apache.wss4j.dom.processor.EncryptedDataProcessor!handleToken!
> EncryptedDataProcessor.java!75#*#org.apache.wss4j.dom.
> engine.WSSecurityEngine!processSecurityHeader!WSSecurityEngine.java!340#*#
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessageInternal!
> WSS4JInInterceptor.java!284#*#org.apache.cxf.ws.security.
> wss4j.WSS4JInInterceptor!handleMessage!WSS4JInInterceptor.java!175#*#
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor!handleMessage!
> WSS4JInInterceptor.java!86#*#org.apache.cxf.phase.PhaseInterceptorChain!
> doIntercept!PhaseInterceptorChain.java!308#*#org.apache.cxf.transport.
> ChainInitiationObserver!onMessage!ChainInitiationObserver.java!
> 121#*#org.apache.cxf.transport.http.AbstractHTTPDestination!invoke!
> AbstractHTTPDestination.java!267#*#org.apache.cxf.transport.servlet.
> ServletController!invokeDestination!ServletController.java!234#*#
> org.apache.cxf.transport.servlet.ServletController!
> invoke!ServletController.java!208#*#org.apache.cxf.transport.servlet.
> ServletController!invoke!ServletController.java!160#*#
> org.apache.cxf.transport.servlet.CXFNonSpringServlet!
> invoke!CXFNonSpringServlet.java!191#*#org.apache.cxf.transport.servlet.
> AbstractHTTPServlet!handleRequest!AbstractHTTPServlet.java!301#*
> #org.apache..cxf.transport.servlet.AbstractHTTPServlet!
> doPost!AbstractHTTPServlet.java!220#*#javax.servlet.http.
> HttpServlet!service!HttpServlet.java!648#*#org..
> apache.cxf.transport.servlet.AbstractHTTPServlet!service!
> AbstractHTTPServlet.java!276#*#org.apache.catalina.core.
> ApplicationFilterChain!internalDoFilter!ApplicationFilterChain.java!
> 291#*#org.apache.catalina.core.ApplicationFilterChain!doFilter!
> ApplicationFilterChain.java!206#*#org.apache.tomcat.
> websocket.server.WsFilter!doFilter!WsFilter.java!52#*#
> org.apache.catalina.core.ApplicationFilterChain!internalDoFilter!
> ApplicationFilterChain..java!239#*#org.apache.catalina.
> core.ApplicationFilterChain!doFilter!ApplicationFilterChain.java!
> 206#*#org.apache.catalina.core.StandardWrapperValve!
> invoke!StandardWrapperValve.java!212#*#org.apache.catalina.core.
> StandardContextValve!invoke!StandardContextValve.java!106#
> *#org.apache.catalina..authenticator.AuthenticatorBase!invoke!
> AuthenticatorBase.java!502#*#org.apache.catalina.core.
> StandardHostValve!invoke!StandardHostValve.java!141#*#
> org.apache.catalina.valves.ErrorReportValve!invoke!
> ErrorReportValve.java!79#*#org.apache.catalina.valves.
> AbstractAccessLogValve!invoke!AbstractAccessLogValve.java!
> 616#*#org.apache.catalina.core.StandardEngineValve!
> invoke!StandardEngineValve.java!88#*#org.apache.catalina.
> connector.CoyoteAdapter!service!CoyoteAdapter.java!
> 521#*#org.apache.coyote.http11.AbstractHttp11Processor!process!
> AbstractHttp11Processor.java!1096#*#org.apache.coyote.AbstractProtocol$
> AbstractConnectionHandler!process!AbstractProtocol.java!
> 674#*#org.apache.tomcat.util.net.NioEndpoint$SocketProcessor!doRun!
> NioEndpoint.java!1500#*#org.apache.tomcat.util.net.
> NioEndpoint$SocketProcessor!run!NioEndpoint.java!1456#*#
> java.util.concurrent.ThreadPoolExecutor!runWorker!
> ThreadPoolExecutor.java!1149#*#java.util.concurrent.
> ThreadPoolExecutor$Worker!run!ThreadPoolExecutor.java!624#*#
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable!run!
> TaskThread.java!61#*#java.lang.Thread!run!Thread.java!748#*#
> 
> 
> 
>
> Mark
>
> http://schemas.xmlsoap.org/soap/envelope/
> ">
> 
> http://docs.oasis-
> open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
> soapenv:mustUnderstand="1">
> http://www.w3.org/
> 2001/04/xmlenc#" Id="wssecurity_encryption_id_24" Type="
> http://www.w3.org/200

RE: cxf-java2wadl-plugin java2wadl questions

2017-10-18 Thread Eyal Weingart

Well, actually i was referring to applicative error codes (and their 
descriptions) - that might be useful by users so can they understand the exact 
issue


Thanks, 
Eyal


-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] 
Sent: 18 October, 2017 12:44
To: Eyal Weingart ; users 

Subject: Re: cxf-java2wadl-plugin java2wadl questions

That said, while customizing a response serialization in order to show the 
extra statuses can help users see them, one can document it as well.

For example, I do not see how the information that a given response can return 
405 can be practically used. Well, one can type for example a 405 catch block 
on the client knowing 405 can be returned, but I'm not sure what difference it 
makes, where this 405 info is located in the response statuses or in the docs...

Cheers, Sergey
On 18/10/17 10:37, Sergey Beryozkin wrote:
> I forgot it's really about using a Maven plugin.
> Hmm...I guess we may need to support a custom class...
> 
> Sergey
> On 18/10/17 07:06, Eyal Weingart wrote:
>> Thanks again.
>> Regarding: "Create MyWadlGenerator extending WADLGenerator, override 
>> whatever is needed, and register MyWadlGenerator as a jaxrs:provider"
>> Where exactly do i need to register the MyWadlGenerator as a 
>> jaxrs:provider? I saw it can be done in a spring file that serves 
>> cases for WADL Auto Generation at Runtime.
>> But where/how should i do it in the pom.xml for the 
>> cxf-java2wadl-plugin in order for it to be activated during build 
>> time
>>
>>
>> Thanks,
>> Eyal
>>
>>
>> -Original Message-
>> From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
>> Sent: 17 October, 2017 17:48
>> To: Eyal Weingart ; users 
>> 
>> Subject: Re: cxf-java2wadl-plugin java2wadl questions
>>
>> Hi,
>> On 17/10/17 15:28, Eyal Weingart wrote:
>>> Thanks Sergey for the quick response.
>>>
>>> 1. Regarding the customization option, one example i can think of 
>>> (and it relates to issue#2 below) is that we want to use multiple 
>>> DocTarget.RESPONSE in order to display multiple error codes and 
>>> since the generic code does not support it then this logic could 
>>> have been applied in the customization class.
>>>
>> Well, there are so many possible customization points that one can 
>> think of, some parts like the docs can be easier customized than 
>> others, but FYI, nearly all of if not all of methods in WADLGenerator 
>> are protected.
>> Create MyWadlGenerator extending WADLGenerator, override whatever is 
>> needed, and register MyWadlGenerator as a jaxrs:provider
>>
>>> 3. Sorry, but did not understand the answer regarding generating 1 
>>> WADL per 1 Rest API class.
>>> Each Rest API class is a different service so don't you think it 
>>> should have the option to have its own WADL file?
>>>
>> It depends. They can be part of the composite service, and quite 
>> often, they can share the same (XML) schema types. It's not something 
>> WADLGenerator should be concerned about, trying to push each service 
>> docs into a separate file, and thinking of how to avoid the schema 
>> duplication.
>>
>> If, in your case, each class does indeed represent a standalone 
>> service, then IMHO it would be better to create N jaxrs:endpoints, 
>> one per each class, as opposed to having 1 endpoint with N classes
>>
>> Sergey
>>
>>>
>>> Thanks,
>>> Eyal
>>>
>>> -Original Message-
>>> From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
>>> Sent: 17 October, 2017 00:06
>>> To: users 
>>> Cc: Eyal Weingart 
>>> Subject: Re: cxf-java2wadl-plugin java2wadl questions
>>>
>>> Hi
>>> On 16/10/17 12:35, Eyal Weingart wrote:
 Hi,



 Not sure to whom i need to send my Questions so hopefully one of 
 you can help me.

>>> Forwarding to the CXF users list
>>>
 I want to use the maven plugin cxf-java2wadl-plugin in order to 
 generate WADL from Java rest APIs in build time but i found few 
 issues with that:



 1.  Is there a way to custom the generator class so i can apply 
 some business code during the build? (is it the 
 org.apache.cxf.jaxrs.model.wadl.WadlGenerator that generates it?)
>>>
>>> What do you need to customize in the generated WADL ?
>>>


 2.  When i use multiple DocTarget.RESPONSE in the rest API 
 annotations then it generates only the first one it finds

>>> Right, because WADLGenerator only creates a single wadl:response per 
>>> a given operation

 3.  If i define more than 1 classResourceNames in the 
 configuration in the pom.xml then it generates all services under 1 
 application.wadl file so if i want 1 WADL file per 1 rest API class 
 then i need to define multiple  (1 execution per 1 Rest
 class) - is there a nicer way of doing it?

>>> There's no way to auto-gen 1 wadl per 1 class resource - it would be 
>>> hard to achieve because most likely these class resources will share 
>>> the schema
>>>
>>> Sergey

AW: fediz_config.xml hosts

2017-10-18 Thread Jan Bernhardt


Hi Metthew,


Fediz Config is independent of your hostname. You don't need to define your 
hostname in your fediz config.


The only exception is when you use a reverse proxy for your application. Fediz 
Plugin will always use the same hostname for the wreply URL that was used 
within the request. In case of a reverse proxy the fediz plugin would only see 
the internal hostname, but an external user could not follow this redirect to 
an internal hostname. For this case you can set a wreply URL within the fediz 
plugin configuration.


Hope that helps.


Jan


Von: Matthew Broadhead 
Gesendet: Mittwoch, 18. Oktober 2017 10:18:06
An: users@cxf.apache.org
Betreff: fediz_config.xml hosts

Hi,
The example fediz_config.xml file has the format

 
...
which seems to describe a webapp deployed at Host localhost.

How would it be configured if the webapp is deployed at a different host
in Tomcat server.xml? e.g.


I tried searching for the source.  I found
https://github.com/apache/cxf-fediz/blob/master/plugins/core/src/main/java/org/apache/cxf/fediz/core/config/FedizContext.java
[https://avatars3.githubusercontent.com/u/47359?s=400&v=4]

apache/cxf-fediz
github.com
cxf-fediz - Mirror of Apache CXF



but couldn't find ContextConfig

Thanks
Matthew

RE: Hide the stack trace for org.apache.cxf.interceptor.Fault

2017-10-18 Thread COURTAULT Francois

Hello,

Sorry to have disturb you, my bad !

client = 
ClientBuilder.newBuilder().property("org.apache.cxf.logging.FaultListener", new 
NoOpFaultListener()) as well as
client = 
ClientBuilder.newBuilder().property("org.apache.cxf.logging.FaultListener", new 
MyFaultListener ())

worked.

Best Regards.

-Original Message-
From: Andy McCright [mailto:j.andrew.mccri...@gmail.com]
Sent: mardi 17 octobre 2017 21:44
To: users@cxf.apache.org
Subject: Re: Hide the stack trace for org.apache.cxf.interceptor.Fault

Hi Francois,

The class cast exceptions make me think that you've got multiple versions of 
CXF in play.  I'm a WebSphere guy, so I can't say for sure how TomEE works out 
of the box, but my guess is that they package CXF in their runtime similar to 
how we package it in WAS Liberty.  Assuming so, are you also packaging CXF with 
your application?  If so, then that could explain the class cast exceptions and 
also why you are not having any luck disabling the logging.  You might have 
better luck if you don't package CXF with your app.

In either case, would it be possible for you to post the full stack traces?  
Both the one that appears in the logs that you are trying to get rid of and the 
ClassCastExceptions?

Thanks,

Andy

On Tue, Oct 17, 2017 at 12:29 PM, COURTAULT Francois < 
francois.courta...@gemalto.com> wrote:

> Hello,
>
> First of all, we are using cxf 3.1.10 included in TomEE 7.0.3.
>
> For example:
>
> * we have a REST 2.0  client which send a request to another TomEE
> 7.0.3.
>
> * If this server is not there, we get the following message:
> WebClient has thrown exception, unwinding now
> org.apache.cxf.interceptor.Fault: Could not send Message.
> 
> Caused by: java.net.UnknownHostException: UnknownHostException
> invoking 
>
>
> So, in order to not have this big stack trace in our logs, we
> performed several tests:
>
> * We have written our own class MyFaultListener which implements
> FaultListener
>
> o   Try to register it  client = ClientBuilder.newBuilder().register(new
> MyFaultListener()).build() => it hasn't worked
>
> o   Try client = 
> ClientBuilder.newBuilder()..property("org.apache.cxf.logging.FaultListener",
> new MyFaultListener ()) => failed with ClassCastException
>
> o   Try client = 
> ClientBuilder.newBuilder()..property("org.apache.cxf.logging.FaultListener",
> new NoOpFaultListener()) => failed with
> org.apache.cxf.logging.NoOpFaultListener
> cannot be cast to org.apache.cxf.logging.FaultListener
>
> * We have also tried client = 
> ClientBuilder.newBuilder().property("printStackTrace",
> false) => always the stack trace
>
> So what can we do at configuration level or at code level to avoid
> such big stacktrace in our logs ?
>
> Best Regards.
> 
> This message and any attachments are intended solely for the
> addressees and may contain confidential information. Any unauthorized
> use or disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>

 This message and any attachments are intended solely for the addressees and 
may contain confidential information. Any unauthorized use or disclosure, 
either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the 
message if altered, changed or falsified. If you are not the intended recipient 
of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free 
from viruses, the sender will not be liable for damages caused by a transmitted 
virus.

Re: cxf-java2wadl-plugin java2wadl questions

2017-10-18 Thread Sergey Beryozkin

That said, while customizing a response serialization in order to show 
the extra statuses can help users see them, one can document it as well.


For example, I do not see how the information that a given response can 
return 405 can be practically used. Well, one can type for example a 405 
catch block on the client knowing 405 can be returned, but I'm not sure 
what difference it makes, where this 405 info is located in the response 
statuses or in the docs...


Cheers, Sergey
On 18/10/17 10:37, Sergey Beryozkin wrote:

I forgot it's really about using a Maven plugin.
Hmm...I guess we may need to support a custom class...

Sergey
On 18/10/17 07:06, Eyal Weingart wrote:

Thanks again.
Regarding: "Create MyWadlGenerator extending WADLGenerator, override 
whatever is needed, and register MyWadlGenerator as a jaxrs:provider"
Where exactly do i need to register the MyWadlGenerator as a 
jaxrs:provider? I saw it can be done in a spring file that serves 
cases for WADL Auto Generation at Runtime.
But where/how should i do it in the pom.xml for the 
cxf-java2wadl-plugin in order for it to be activated during build time



Thanks,
Eyal


-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: 17 October, 2017 17:48
To: Eyal Weingart ; users 


Subject: Re: cxf-java2wadl-plugin java2wadl questions

Hi,
On 17/10/17 15:28, Eyal Weingart wrote:

Thanks Sergey for the quick response.

1. Regarding the customization option, one example i can think of 
(and it relates to issue#2 below) is that we want to use multiple 
DocTarget.RESPONSE in order to display multiple error codes and since 
the generic code does not support it then this logic could have been 
applied in the customization class.


Well, there are so many possible customization points that one can 
think of, some parts like the docs can be easier customized than 
others, but FYI, nearly all of if not all of methods in WADLGenerator 
are protected.
Create MyWadlGenerator extending WADLGenerator, override whatever is 
needed, and register MyWadlGenerator as a jaxrs:provider


3. Sorry, but did not understand the answer regarding generating 1 
WADL per 1 Rest API class.
Each Rest API class is a different service so don't you think it 
should have the option to have its own WADL file?


It depends. They can be part of the composite service, and quite 
often, they can share the same (XML) schema types. It's not something 
WADLGenerator should be concerned about, trying to push each service 
docs into a separate file, and thinking of how to avoid the schema 
duplication.


If, in your case, each class does indeed represent a standalone 
service, then IMHO it would be better to create N jaxrs:endpoints, one 
per each class, as opposed to having 1 endpoint with N classes


Sergey



Thanks,
Eyal

-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: 17 October, 2017 00:06
To: users 
Cc: Eyal Weingart 
Subject: Re: cxf-java2wadl-plugin java2wadl questions

Hi
On 16/10/17 12:35, Eyal Weingart wrote:

Hi,



Not sure to whom i need to send my Questions so hopefully one of you 
can help me.



Forwarding to the CXF users list

I want to use the maven plugin cxf-java2wadl-plugin in order to 
generate WADL from Java rest APIs in build time but i found few 
issues with that:




1.  Is there a way to custom the generator class so i can apply 
some business code during the build? (is it the 
org.apache.cxf.jaxrs.model.wadl.WadlGenerator that generates it?)


What do you need to customize in the generated WADL ?




2.  When i use multiple DocTarget.RESPONSE in the rest API 
annotations then it generates only the first one it finds



Right, because WADLGenerator only creates a single wadl:response per a
given operation


3.  If i define more than 1 classResourceNames in the 
configuration in the pom.xml then it generates all services under 1 
application.wadl file so if i want 1 WADL file per 1 rest API class 
then i need to define multiple  (1 execution per 1 Rest 
class) - is there a nicer way of doing it?



There's no way to auto-gen 1 wadl per 1 class resource - it would be
hard to achieve because most likely these class resources will share
the schema

Sergey





Example of how i configured it in the pom.xml:



    org.apache.cxf

    cxf-java2wadl-plugin

   3.1.4

   

   

process-classes1

process-classes

   

java2wadl

   

   



com.exlibris.primo.webservices.rest.EShelfRestApi<
/
classResourceName>



Primo

true

    

   

   

   





Thanks in advance

Eyal




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Re: cxf-java2wadl-plugin java2wadl questions

2017-10-18 Thread Sergey Beryozkin


I forgot it's really about using a Maven plugin.
Hmm...I guess we may need to support a custom class...

Sergey
On 18/10/17 07:06, Eyal Weingart wrote:

Thanks again.
Regarding: "Create MyWadlGenerator extending WADLGenerator, override whatever is 
needed, and register MyWadlGenerator as a jaxrs:provider"
Where exactly do i need to register the MyWadlGenerator as a jaxrs:provider? I 
saw it can be done in a spring file that serves cases for WADL Auto Generation 
at Runtime.
But where/how should i do it in the pom.xml for the cxf-java2wadl-plugin in 
order for it to be activated during build time


Thanks,
Eyal


-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: 17 October, 2017 17:48
To: Eyal Weingart ; users 

Subject: Re: cxf-java2wadl-plugin java2wadl questions

Hi,
On 17/10/17 15:28, Eyal Weingart wrote:

Thanks Sergey for the quick response.

1. Regarding the customization option, one example i can think of (and it 
relates to issue#2 below) is that we want to use multiple DocTarget.RESPONSE in 
order to display multiple error codes and since the generic code does not 
support it then this logic could have been applied in the customization class.


Well, there are so many possible customization points that one can think of, 
some parts like the docs can be easier customized than others, but FYI, nearly 
all of if not all of methods in WADLGenerator are protected.
Create MyWadlGenerator extending WADLGenerator, override whatever is needed, 
and register MyWadlGenerator as a jaxrs:provider


3. Sorry, but did not understand the answer regarding generating 1 WADL per 1 
Rest API class.
Each Rest API class is a different service so don't you think it should 
have the option to have its own WADL file?


It depends. They can be part of the composite service, and quite often, they 
can share the same (XML) schema types. It's not something WADLGenerator should 
be concerned about, trying to push each service docs into a separate file, and 
thinking of how to avoid the schema duplication.

If, in your case, each class does indeed represent a standalone service, then 
IMHO it would be better to create N jaxrs:endpoints, one per each class, as 
opposed to having 1 endpoint with N classes

Sergey



Thanks,
Eyal

-Original Message-
From: Sergey Beryozkin [mailto:sberyoz...@gmail.com]
Sent: 17 October, 2017 00:06
To: users 
Cc: Eyal Weingart 
Subject: Re: cxf-java2wadl-plugin java2wadl questions

Hi
On 16/10/17 12:35, Eyal Weingart wrote:

Hi,



Not sure to whom i need to send my Questions so hopefully one of you can help 
me.


Forwarding to the CXF users list


I want to use the maven plugin cxf-java2wadl-plugin in order to generate WADL 
from Java rest APIs in build time but i found few issues with that:



1.  Is there a way to custom the generator class so i can apply some 
business code during the build? (is it the 
org.apache.cxf.jaxrs.model.wadl.WadlGenerator that generates it?)


What do you need to customize in the generated WADL ?




2.  When i use multiple DocTarget.RESPONSE in the rest API annotations then 
it generates only the first one it finds


Right, because WADLGenerator only creates a single wadl:response per a
given operation


3.  If i define more than 1 classResourceNames in the configuration in the 
pom.xml then it generates all services under 1 application.wadl file so if i want 1 
WADL file per 1 rest API class then i need to define multiple  (1 
execution per 1 Rest class) - is there a nicer way of doing it?


There's no way to auto-gen 1 wadl per 1 class resource - it would be
hard to achieve because most likely these class resources will share
the schema

Sergey





Example of how i configured it in the pom.xml:



org.apache.cxf

cxf-java2wadl-plugin

   3.1.4

   

   

process-classes1

   
process-classes


   

   
java2wadl


   

   

   



   
com.exlibris.primo.webservices.rest.EShelfRestApi<

/
classResourceName>

   



   
Primo


   
true




   

   

   





Thanks in advance

Eyal




--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

fediz_config.xml hosts

2017-10-18 Thread Matthew Broadhead


Hi,
The example fediz_config.xml file has the format

    
...
which seems to describe a webapp deployed at Host localhost.

How would it be configured if the webapp is deployed at a different host 
in Tomcat server.xml? e.g.



I tried searching for the source.  I found 
https://github.com/apache/cxf-fediz/blob/master/plugins/core/src/main/java/org/apache/cxf/fediz/core/config/FedizContext.java 
but couldn't find ContextConfig


Thanks
Matthew

RE: Websphere 9 and CXF

RE: Websphere 9 and CXF

Dynamically changing endpoints

Re: Websphere 9 and CXF

RE: Websphere 9 and CXF

Re: Websphere 9 and CXF

Re: AW: fediz_config.xml hosts

Re: Websphere 9 and CXF

Re: Websphere 9 and CXF

RE: cxf-java2wadl-plugin java2wadl questions

AW: fediz_config.xml hosts

RE: Hide the stack trace for org.apache.cxf.interceptor.Fault

Re: cxf-java2wadl-plugin java2wadl questions

Re: cxf-java2wadl-plugin java2wadl questions

fediz_config.xml hosts

15 matches

Site Navigation

Mail list logo

Footer information