Re: ClassLoader
Hi Richard, In OpenLiberty, we have our own subclass of the ExtensionManagerBus - and we pass in the classloader to it's constructor. See [1]. >From the looks of it, you could create your own ExtensionManagerBus instance in your CxfNonSpringServlet's subclass by overriding the loadBus(ServletConfig) method. That method should create a new instance of the ExtensionManagerBus (with your classloader). Another alternative might be to set the thread's context classloader to your classloader. The default classloader for the ExtensionManagerBus is the current thread's context classloader. Hope this helps, Andy [1] https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.jaxrs.2.0.common/src/com/ibm/ws/jaxrs20/bus/LibertyApplicationBus.java On Thu, Oct 19, 2017 at 7:04 AM, Richard Stollar wrote: > Hello, > > Out system uses a custom class-loader but, because of the stack-trace > (below) we receive in some circumstances, I suspect that CXF does not use > our ClassLoader which should be the default by the time we initialize CXF. > We have a *CxfWebServiceServlet* which extends the *CXFNonSpringServlet* > for deploying JaxWS websevices and looking at the source it uses the BUS to > get a ClassLoader derived from the BusExtensions. > > How can I ensure that our ClassLoader is always used? Can I push our > ClassLoader into the BUS before we start initializing the servlet? Do I > need to configure/create a BusExtension for this and if so, how? Do you > have any examples or can you point me at some useful documentation? > > > Here is the exception: > >[13:51:13.810+0300] SYSERR javax.xml.ws.WebServiceException: >java.lang.reflect.UndeclaredThrowableException >[13:51:13.811+0300] SYSERR at >org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:375) >[13:51:13.811+0300] SYSERR at >org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) >[13:51:13.811+0300] SYSERR at >org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpo > int(ProviderImpl.java:136) >[13:51:13.811+0300] SYSERR at >javax.xml.ws.Endpoint.publish(Endpoint.java:240) >[13:51:13.812+0300] SYSERR at >com.foo.server.jetty.servlet.CxfWebServiceServlet.publishCX > F(CxfWebServiceServlet.java:77) >... REMOVED LINES GENERATING THE WEB SERVICE CODE AND COMPILE ETC ... >[13:51:13.813+0300] SYSERR at >com.foo.server.jetty.JettyContextListener.contextInitialize > d(JettyContextListener.java:89) >[13:51:13.814+0300] SYSERR at >org.eclipse.jetty.server.handler.ContextHandler.callContext > Initialized(ContextHandler.java:800) >[13:51:13.814+0300] SYSERR at >org.eclipse.jetty.servlet.ServletContextHandler.callContext > Initialized(ServletContextHandler.java:444) >[13:51:13.814+0300] SYSERR at >org.eclipse.jetty.server.handler.ContextHandler.startContex > t(ContextHandler.java:791) >[13:51:13.814+0300] SYSERR at >org.eclipse.jetty.servlet.ServletContextHandler.startContex > t(ServletContextHandler.java:294) >[13:51:13.815+0300] SYSERR at >org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppCo > ntext.java:1349) >[13:51:13.815+0300] SYSERR at >org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppC > ontext.java:1342) >[13:51:13.815+0300] SYSERR at >org.eclipse.jetty.server.handler.ContextHandler.doStart( > ContextHandler.java:741) >[13:51:13.815+0300] SYSERR at >org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >[13:51:13.815+0300] SYSERR at >com.basis.server.jetty.BBjWebAppContext.doStart(BBjWebAppCo > ntext.java:229) >[13:51:13.815+0300] SYSERR at >org.eclipse.jetty.util.component.AbstractLifeCycle.start( > AbstractLifeCycle.java:68) >[13:51:13.816+0300] SYSERR at >org.eclipse.jetty.util.component.ContainerLifeCycle.start( > ContainerLifeCycle.java:132) >[13:51:13.816+0300] SYSERR at >org.eclipse.jetty.util.component.ContainerLifeCycle.doStart > (ContainerLifeCycle.java:114) >[13:51:13.816+0300] SYSERR at >org.eclipse.jetty.server.handler.AbstractHandler.doStart( > AbstractHandler.java:61) >[13:51:13.816+0300] SYSERR at >org.eclipse.jetty.server.handler.ContextHandlerCollection.d > oStart(ContextHandlerCollection.java:163) >[13:51:13.816+0300] SYSERR at >org.eclipse.jetty.util.component.AbstractLifeCycle.start( > AbstractLifeCycle.java:68) >[13:51:13.817+0300] SYSERR at >org.eclipse.jetty.util.component.ContainerLifeCycle.start( > ContainerLifeCycle.java:132) >[13:51:13.817+0300] SYSERR at >org.eclipse.jetty.util.component.ContainerLifeCycle.doStart > (ContainerLifeCycle.java:114) >[13:51:13.817+0300] SYSERR at >org.eclipse.jetty.server.handler.AbstractHandler.doStart( > AbstractHandler.java:61) >[13:51:13.817+0300] SYSERR at >org.eclipse.jetty.serve
Re: Absolute path of ws-security.signature.crypto doesn't work on REST SAML Support
i know this was long time ago but I just wanted to check if you were able to solve this issue. You mention ResourceResolver. What would that solution look like? Can you please explain? -- Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: Cannot load the resource for signing of a soap message
Colm, that's great! Can you please let me know when this would be available for use? Will it be made available via maven? Is it a wss4j 1.6.19 fix? Unfortunately, I cannot upgrade to the latest versions of cxf because we support sdk code given to us which was written a long time ago. Much appreciate the quick response. IS there some work-around for this specific issue or not really? Thanks, PR -- Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
CXF Client - HTTP Connection pooling
Hello, I am using CXF client to make REST calls. org.apache.cxf *cxf-rt-rs-client* *3.1.5* I would like to know if CXF client does connection pooling by default. If not, are there any parameters to set to configure connection pooling. Also, I did set http.maxConnection and http.keepAlive parameters in JVM, but it did not work. Any information/code snippets on how connection pooling works with CXF client would be helpful. Thanks, Ravishankar Thanks Simon -- Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
CXF Client - HTTP Connection pooling
Hello, I am using CXF client to make REST calls. org.apache.cxf *cxf-rt-rs-client* *3.1.5* I would like to know if CXF client does connection pooling by default. If not, are there any parameters to set to configure connection pooling. Also, I did set http.maxConnection and http.keepAlive parameters in JVM, but it did not work. Any information/code snippets on how connection pooling works with CXF client would be helpful. Thanks, Ravishankar -- Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: Cannot load the resource for signing of a soap message
I've found the issue and merged a fix for WSS-540: https://issues.apache.org/jira/browse/WSS-540 In terms of upgrading, the latest CXF releases are 3.1.13 and 3.2.0. Please note that the bundle is removed from 3.0.x, instead just refer to the individual modules that you need. Colm. On Thu, Oct 19, 2017 at 3:54 PM, pra...@tracelink.com wrote: > Colm, > > thanks for responding. > > It's hard for me to create a test-case because there is so many things > involved. I did my best below: > > Client creates a file called client.properties under */tmp* which looks > like > this: > sign.propFile=client/100/sign.properties > enc.propFile=client/100/encrypt.properties > resp.propFile=client/100/decrypt.properties > > My java application is able to find this file without any issues even > though > /tmp is *not * in the classpath. > > however when WSS4JOutInterceptor runs when I prepare the soap message, it > goes into the WSHandler.loadSignatureCrypto -> WSHandler.loadCrypto method > -> WSHandler.loadCryptoFromPropertiesFile -> CryptoFactory.getInstance -> > org.apache.ws.security.Loader.getResource which always tries to use the > classloader to load the resource. > > No matter what path I try for the sign.propFile , I get the same error. > > *What versions of cxf + wss4j are supported currently?* Let me know please > so that I can see if I can upgrade. Currently I have the following: > > > org.apache.cxf > cxf-bundle > 2.7.15 > > Which pulls in wss4j 1.6.19 as a transitive dependency. > > > > -- > Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: Cannot load the resource for signing of a soap message
Is there a way of using this technique described in to load 2 different
keystores rather than just 1? Construct Properties object in-memory, and
have CXF use that instead.
package soap.common.interceptors;
import client.clientmgr.ClientInfo;
import org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor;
import org.apache.ws.security.WSSecurityException;
import org.apache.ws.security.components.crypto.Crypto;
import org.apache.ws.security.components.crypto.CryptoFactory;
import org.apache.ws.security.handler.RequestData;
import java.util.Map;
import java.util.Properties;
public class CryptoPropsOutInterceptor extends WSS4JOutInterceptor {
private ClientInfo clientInfo;
public CryptoPropsOutInterceptor(Map props, ClientInfo
clientInfo) {
super(props);
this.clientInfo = clientInfo;
}
@Override
protected Crypto loadCryptoFromPropertiesFile(String propFilename,
RequestData reqData)
throws WSSecurityException {
Properties cxfProps = new Properties();
cxfProps.setProperty("org.apache.ws.security.crypto.provider",
"org.apache.ws.security.components.crypto.Merlin");
cxfProps.setProperty("org.apache.ws.security.crypto.merlin.keystore.type",
"jks");
cxfProps.setProperty("org.apache.ws.security.crypto.merlin.keystore.alias",
this.clientInfo.getSignAlias());
cxfProps.setProperty("org.apache.ws.security.crypto.merlin.keystore.password",
this.clientInfo.getSignPassword());
cxfProps.setProperty("org.apache.ws.security.crypto.merlin.keystore.file",
"client/1080.1/client.jks"); //here this would load only one but i would
like to load 2 if it's possible
// one for signing the other for encrypting.
return CryptoFactory.getInstance(cxfProps);
}
}
--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: fediz in production
i am using 1.4.2. my stsKeystore.properties is as follows, but i have had to modify values for security org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin org.apache.ws.security.crypto.merlin.keystore.type=jks org.apache.ws.security.crypto.merlin.keystore.password=mypassword (jks password NOT certificate password) org.apache.ws.security.crypto.merlin.keystore.alias=realmmyrealm (same as the alias of the cert in the jks) org.apache.ws.security.crypto.merlin.keystore.file=stsrealm_myrealm.jks (name of the jks located in the same directory as this file) Matthew On 19/10/2017 16:48, Colm O hEigeartaigh wrote: What Fediz version are you using? Are you specifying a "org.apache.ws.security.crypto.merlin.keystore.alias" in your keystore properties and does it match " realmmyrealm"? Colm. On Thu, Oct 19, 2017 at 12:52 PM, Matthew Broadhead < matthew.broadh...@nbmlaw.co.uk> wrote: Thanks Colm, yes that was caused by a typo in stsKeystore.properties. but now I get this: org.apache.wss4j.common.ext.WSSecurityException: The private key for the supplied alias does not exist in the keystore Original Exception was org.apache.wss4j.common.ext.WSSecurityException: The private key for the supplied alias does not exist in the keystore Original Exception was java.security.UnrecoverableKeyException: Cannot recover key at org.apache.wss4j.common.saml.SamlAssertionWrapper.signAssert ion(SamlAssertionWrapper.java:542) at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. signToken(AbstractSAMLTokenProvider.java:121) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa mlToken(SAMLTokenProvider.java:319) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo ken(SAMLTokenProvider.java:117) at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle (TokenIssueOperation.java:171) but if i do keytool -list -v -keystore stsrealm_myrealm.jks i get Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: realmmyrealm Creation date: 17-Oct-2017 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: On 19/10/2017 13:27, Colm O hEigeartaigh wrote: The error is that the STS can't load the signature properties file. For example, in the default STS the RealmProperties references the signaturePropertiesFile for the realm here: https://github.com/apache/cxf-fediz/blob/aee07e167458e468f12 3954f177c79f17df2c083/services/sts/src/main/webapp/ WEB-INF/data/realms.xml#L62 which in turn is here: https://github.com/apache/cxf-fediz/blob/master/services/sts /src/main/resources/stsKeystoreA.properties On Thu, Oct 19, 2017 at 10:31 AM, Matthew Broadhead < matthew.broadh...@nbmlaw.co.uk> wrote: Hi, I am following this article by Jan https://janbernhardt.blogspot. com.es/2016/02/apache-fediz-installation-in-productive.html and I think I am close to getting it working but I have hit this error that I cannot work out. Can anyone help? org.apache.cxf.sts.token.provider.SAMLTokenProvider - org.apache.cxf.ws.security.sts.provider.STSException: Configuration error: cannot load signature properties at org.apache.cxf.sts.token.realm.RealmProperties.getSignatureC rypto(RealmProperties.java:156) at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. signToken(AbstractSAMLTokenProvider.java:59) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa mlToken(SAMLTokenProvider.java:319) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo ken(SAMLTokenProvider.java:117) at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle (TokenIssueOperation.java:171)
Re: Cannot load the resource for signing of a soap message
Colm, thanks for responding. It's hard for me to create a test-case because there is so many things involved. I did my best below: Client creates a file called client.properties under */tmp* which looks like this: sign.propFile=client/100/sign.properties enc.propFile=client/100/encrypt.properties resp.propFile=client/100/decrypt.properties My java application is able to find this file without any issues even though /tmp is *not * in the classpath. however when WSS4JOutInterceptor runs when I prepare the soap message, it goes into the WSHandler.loadSignatureCrypto -> WSHandler.loadCrypto method -> WSHandler.loadCryptoFromPropertiesFile -> CryptoFactory.getInstance -> org.apache.ws.security.Loader.getResource which always tries to use the classloader to load the resource. No matter what path I try for the sign.propFile , I get the same error. *What versions of cxf + wss4j are supported currently?* Let me know please so that I can see if I can upgrade. Currently I have the following: org.apache.cxf cxf-bundle 2.7.15 Which pulls in wss4j 1.6.19 as a transitive dependency. -- Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
Re: fediz in production
What Fediz version are you using? Are you specifying a "org.apache.ws.security.crypto.merlin.keystore.alias" in your keystore properties and does it match " realmmyrealm"? Colm. On Thu, Oct 19, 2017 at 12:52 PM, Matthew Broadhead < matthew.broadh...@nbmlaw.co.uk> wrote: > Thanks Colm, yes that was caused by a typo in stsKeystore.properties. > > but now I get this: > org.apache.wss4j.common.ext.WSSecurityException: The private key for the > supplied alias does not exist in the keystore > Original Exception was org.apache.wss4j.common.ext.WSSecurityException: > The private key for the supplied alias does not exist in the keystore > Original Exception was java.security.UnrecoverableKeyException: Cannot > recover key > at org.apache.wss4j.common.saml.SamlAssertionWrapper.signAssert > ion(SamlAssertionWrapper.java:542) > at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. > signToken(AbstractSAMLTokenProvider.java:121) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa > mlToken(SAMLTokenProvider.java:319) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo > ken(SAMLTokenProvider.java:117) > at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle > (TokenIssueOperation.java:171) > > but if i do keytool -list -v -keystore stsrealm_myrealm.jks i get > Keystore type: JKS > Keystore provider: SUN > > Your keystore contains 1 entry > > Alias name: realmmyrealm > Creation date: 17-Oct-2017 > Entry type: PrivateKeyEntry > Certificate chain length: 1 > Certificate[1]: > > > On 19/10/2017 13:27, Colm O hEigeartaigh wrote: > >> The error is that the STS can't load the signature properties file. For >> example, in the default STS the RealmProperties references the >> signaturePropertiesFile for the realm here: >> >> https://github.com/apache/cxf-fediz/blob/aee07e167458e468f12 >> 3954f177c79f17df2c083/services/sts/src/main/webapp/ >> WEB-INF/data/realms.xml#L62 >> >> which in turn is here: >> >> https://github.com/apache/cxf-fediz/blob/master/services/sts >> /src/main/resources/stsKeystoreA.properties >> >> On Thu, Oct 19, 2017 at 10:31 AM, Matthew Broadhead < >> matthew.broadh...@nbmlaw.co.uk> wrote: >> >> Hi, >>> >>> I am following this article by Jan https://janbernhardt.blogspot. >>> com.es/2016/02/apache-fediz-installation-in-productive.html and I think >>> I >>> am close to getting it working but I have hit this error that I cannot >>> work >>> out. Can anyone help? >>> >>> org.apache.cxf.sts.token.provider.SAMLTokenProvider - >>> org.apache.cxf.ws.security.sts.provider.STSException: Configuration >>> error: cannot load signature properties >>> at org.apache.cxf.sts.token.realm.RealmProperties.getSignatureC >>> rypto(RealmProperties.java:156) >>> at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. >>> signToken(AbstractSAMLTokenProvider.java:59) >>> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa >>> mlToken(SAMLTokenProvider.java:319) >>> at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo >>> ken(SAMLTokenProvider.java:117) >>> at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle >>> (TokenIssueOperation.java:171) >>> >>> >>> >> > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
Re: Cannot load the resource for signing of a soap message
Could you submit a test-case that reproduces the problem? Note that CXF
2.7.x + WSS4J 1.6.x are no longer supported.
Colm.
On Thu, Oct 19, 2017 at 12:45 PM, pra...@tracelink.com wrote:
> Environment:
> cxf-bundle: 2.7.18
> wss4j: 1.6.19
>
> I am trying to act as a soap client and send a soap message which is both
> signed and encrypted. For signing and encrypting, different keystores are
> used. My own private key for signing and a server's public certificate for
> encrypting the soap body.
>
> The signaturePropFile points to a location which is at the following level
> relative to my application's jar :
>
> | - soap-client-application.jar
> | - client (directory containing different clients and their keys)
> | | - clientName
> | | | - client.jks
>
> The issue I'm facing is the following:
> DEBUG [2017-10-19 11:29:54,644] org.apache.ws.security.util.Loader:
> Trying to find [file:///Users/blah/git/ms-service-tl-de-eucompliance/
> target/client/1080.1/sign.properties] using sun.misc.Launcher$
> AppClassLoader@18b4aac2 class loader.
> DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader:
> Trying to find [file:///Users/blah/git/ms-service-tl-de-eucompliance/
> target/client/1080.1/sign.properties] using sun.misc.Launcher$
> AppClassLoader@18b4aac2 class loader.
> DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader:
> Trying to find [file:///Users/blah/git/ms-service-tl-de-eucompliance/
> target/client/1080.1/sign.properties] using ClassLoader.getSystemResource(
> ).
> WARN [2017-10-19 11:29:54,649] org.apache.cxf.phase.PhaseInterceptorChain:
> Interceptor for {http://EMVS.EU/20161/}Product#{http://EMVS.EU/20161/
> }ProcessProductMasterData has thrown exception, unwinding now
> ! org.apache.ws.security.WSSecurityException: General security error
> (Cannot load the resource file:///Users/blah/git/ms-
> service-tl-de-eucompliance/target/client/1080.1/sign.properties)
> ! at org.apache.ws.security.components.crypto.CryptoFactory.getProperties(
> CryptoFactory.java:261)
> ! at org.apache.ws.security.components.crypto.CryptoFactory.getInstance(
> CryptoFactory.java:186)
> ! at org.apache.cxf.ws.security.wss4j.AbstractWSS4JInterceptor.
> loadCryptoFromPropertiesFile(AbstractWSS4JInterceptor.java:224)
> ! at org.apache.ws.security.handler.WSHandler.loadCrypto(
> WSHandler.java:910)
> ! at org.apache.ws.security.handler.WSHandler.
> loadSignatureCrypto(WSHandler.java:823)
> ! at org.apache.ws.security.handler.WSHandler.
> doSenderAction(WSHandler.java:143)
> ! at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(
> WSS4JOutInterceptor.java:52)
> ! at org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$
> WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:265)
>
> As you can see above, the application is unable to load the sign.props
> file even though the path is valid. I tried several different paths like
> the following but I get the same error:
> - (Cannot load the resource file:///Users/blah/git/ms-
> service-tl-de-eucompliance/target/client/1080.1/sign.properties)
> - (Cannot load the resource file:Users/blah/git/ms-
> service-tl-de-eucompliance/target/client/1080.1/sign.properties)
> - (Cannot load the resource /Users/blah/git/ms-service-tl-
> de-eucompliance/target/client/1080.1/sign.properties)
>
> I have also followed this thread: https://stackoverflow.com/
> questions/30685860/how-to-load-the-cxf-wss4j-crypto-
> property-file-from-external-location-other-than . This thread has 2
> comments:
>
> 1.
> one is to load the properties by extending the WSS4JOutInterceptor class.
> This works but I need to be able to use different keystores: one for
> signing and another different one for encrypting. The crypto property does
> not allow me to do that.
>
> 2.
> the other is to do what I have been describing above which is to create
> the files in a certain place on the filesystem and then load them up. I get
> the error above when I do this. This is supposedly fixed in
> https://issues.apache.org/jira/browse/WSS-540 .
>
> I'm not sure what I'm doing wrongly. Any help is greatly appreciated. I
> have been trying to solve this for a couple of days now.
>
> Thanks!
> -PR
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: cxf-java2wadl-plugin java2wadl questions
Np, by the way, the custom provider will need to have a constructor accepting 'Bus' which it can provide to the super... Sergey On 19/10/17 14:06, Eyal Weingart wrote: Thanks a lot! I will check this on Sunday (leaving for the weekend) and will let you know Working currently with version 3.1.4 and not 3.1.14 so will need to fix some dependencies so my build will not fail... Thanks, Eyal -Original Message- From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] Sent: 19 October, 2017 15:20 To: Eyal Weingart ; users Subject: Re: cxf-java2wadl-plugin java2wadl questions Hi Eyal On 19/10/17 09:47, Eyal Weingart wrote: Hi Sergey 1. Do you see a future option to custom the WADL generator class during the maven build? If so, what is a reasonable timeline for this? (Just to know how to plan ahead) I've added a 'customWadlGenerator' parameter, give 3.1.14-SNAPSHOT or 3.2.1-SNAPSHOT a try 2. Regarding the "classResourceNames" and multiple WADL files question, i think i was misunderstood, it is not that each rest class holds 1 service, i meant that each rest class holds 1 business with few operations. For example, 1 class holds books operations, another class holds teachers operations and another class will hold course operations - so our expectation is that we should have 3 separate WADLs generated - what do you think? That is fine, it is just that it can't be really solved at the WADLGenerator level - in your case the separation may be clean, in other cases - may be not. And from the practical point of view it will push the already very complex WADLGenerator code to the limit if we started trying updating it to push the info to many files Thanks, Sergey Thanks, Eyal -Original Message- From: Eyal Weingart Sent: 18 October, 2017 13:47 To: Sergey Beryozkin ; users Subject: RE: cxf-java2wadl-plugin java2wadl questions 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 op
Cannot load the resource for signing of a soap message
Environment:
cxf-bundle: 2.7.18
wss4j: 1.6.19
I am trying to act as a soap client and send a soap message which is both
signed and encrypted. For signing and encrypting, different keystores are used.
My own private key for signing and a server's public certificate for encrypting
the soap body.
The signaturePropFile points to a location which is at the following level
relative to my application's jar :
| - soap-client-application.jar
| - client (directory containing different clients and their keys)
| | - clientName
| | | - client.jks
The issue I'm facing is the following:
DEBUG [2017-10-19 11:29:54,644] org.apache.ws.security.util.Loader: Trying to
find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader: Trying to
find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader: Trying to
find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using ClassLoader.getSystemResource().
WARN [2017-10-19 11:29:54,649] org.apache.cxf.phase.PhaseInterceptorChain:
Interceptor for
{http://EMVS.EU/20161/}Product#{http://EMVS.EU/20161/}ProcessProductMasterData
has thrown exception, unwinding now
! org.apache.ws.security.WSSecurityException: General security error (Cannot
load the resource
file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
! at
org.apache.ws.security.components.crypto.CryptoFactory.getProperties(CryptoFactory.java:261)
! at
org.apache.ws.security.components.crypto.CryptoFactory.getInstance(CryptoFactory.java:186)
! at
org.apache.cxf.ws.security.wss4j.AbstractWSS4JInterceptor.loadCryptoFromPropertiesFile(AbstractWSS4JInterceptor.java:224)
! at org.apache.ws.security.handler.WSHandler.loadCrypto(WSHandler.java:910)
! at
org.apache.ws.security.handler.WSHandler.loadSignatureCrypto(WSHandler.java:823)
! at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:143)
! at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOutInterceptor.java:52)
! at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:265)
As you can see above, the application is unable to load the sign.props file
even though the path is valid. I tried several different paths like the
following but I get the same error:
- (Cannot load the resource
file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
- (Cannot load the resource
file:Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
- (Cannot load the resource
/Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
I have also followed this thread:
https://stackoverflow.com/questions/30685860/how-to-load-the-cxf-wss4j-crypto-property-file-from-external-location-other-than
. This thread has 2 comments:
1.
one is to load the properties by extending the WSS4JOutInterceptor class. This
works but I need to be able to use different keystores: one for signing and
another different one for encrypting. The crypto property does not allow me to
do that.
2.
the other is to do what I have been describing above which is to create the
files in a certain place on the filesystem and then load them up. I get the
error above when I do this. This is supposedly fixed in
https://issues.apache.org/jira/browse/WSS-540 .
I'm not sure what I'm doing wrongly. Any help is greatly appreciated. I have
been trying to solve this for a couple of days now.
Thanks!
-PR
Resource loading fails for signPropFile
Environment:
cxf-bundle: 2.7.18
org.apache.ws.security.wss4j: 1.6.19
I am trying to act as a soap client and send a soap message which is both
signed and encrypted. For signing and encrypting, different keystores are
used. My own private key for signing and a server's public certificate for
encrypting the soap body.
The signaturePropFile points to a location which is at the following level
relative to my application's jar :
| soap-client-application.jar
| client (directory containing different clients and their keys)
| | clientName
| | | client.jks
| server.jks
The issue I'm facing is the following:
DEBUG [2017-10-19 11:29:54,644] org.apache.ws.security.util.Loader: Trying
to find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader: Trying
to find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using sun.misc.Launcher$AppClassLoader@18b4aac2 class loader.
DEBUG [2017-10-19 11:29:54,645] org.apache.ws.security.util.Loader: Trying
to find
[file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties]
using ClassLoader.getSystemResource().
WARN [2017-10-19 11:29:54,649] org.apache.cxf.phase.PhaseInterceptorChain:
Interceptor for
{http://EMVS.EU/20161/}Product#{http://EMVS.EU/20161/}ProcessProductMasterData
has thrown exception, unwinding now
! org.apache.ws.security.WSSecurityException: General security error (Cannot
load the resource
file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
! at
org.apache.ws.security.components.crypto.CryptoFactory.getProperties(CryptoFactory.java:261)
! at
org.apache.ws.security.components.crypto.CryptoFactory.getInstance(CryptoFactory.java:186)
! at
org.apache.cxf.ws.security.wss4j.AbstractWSS4JInterceptor.loadCryptoFromPropertiesFile(AbstractWSS4JInterceptor.java:224)
! at org.apache.ws.security.handler.WSHandler.loadCrypto(WSHandler.java:910)
! at
org.apache.ws.security.handler.WSHandler.loadSignatureCrypto(WSHandler.java:823)
! at
org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:143)
! at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor.access$200(WSS4JOutInterceptor.java:52)
! at
org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor$WSS4JOutInterceptorInternal.handleMessage(WSS4JOutInterceptor.java:265)
As you can see above, the application is unable to load the sign.props file
even though the path is valid. I tried several different paths like the
following but I get the same error:
- (Cannot load the resource
file:///Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
- (Cannot load the resource
file:Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
- (Cannot load the resource
/Users/blah/git/ms-service-tl-de-eucompliance/target/client/1080.1/sign.properties)
I have also followed this thread:
https://stackoverflow.com/questions/30685860/how-to-load-the-cxf-wss4j-crypto-property-file-from-external-location-other-than
. This thread has 2 comments:
1.
one is to load the properties by extending the WSS4JOutInterceptor class.
This works but I need to be able to use different keystores: one for signing
and another different one for encrypting. The crypto property does not allow
me to do that.
2.
the other is to do what I have been describing above which is to create the
files in a certain place on the filesystem and then load them up. I get the
error above when I do this. This is supposedly fixed in
https://issues.apache.org/jira/browse/WSS-540 .
I'm not sure what I'm doing wrongly. Any help is greatly appreciated. I have
been trying to solve this for a couple of days now.
Thanks!
-PR
--
Sent from: http://cxf.547215.n5.nabble.com/cxf-user-f547216.html
RE: cxf-java2wadl-plugin java2wadl questions
Thanks a lot! I will check this on Sunday (leaving for the weekend) and will let you know Working currently with version 3.1.4 and not 3.1.14 so will need to fix some dependencies so my build will not fail... Thanks, Eyal -Original Message- From: Sergey Beryozkin [mailto:sberyoz...@gmail.com] Sent: 19 October, 2017 15:20 To: Eyal Weingart ; users Subject: Re: cxf-java2wadl-plugin java2wadl questions Hi Eyal On 19/10/17 09:47, Eyal Weingart wrote: > Hi Sergey > > 1. Do you see a future option to custom the WADL generator class > during the maven build? If so, what is a reasonable timeline for this? > (Just to know how to plan ahead) > I've added a 'customWadlGenerator' parameter, give 3.1.14-SNAPSHOT or 3.2.1-SNAPSHOT a try > 2. Regarding the "classResourceNames" and multiple WADL files question, i > think i was misunderstood, it is not that each rest class holds 1 service, i > meant that each rest class holds > 1 business with few operations. > For example, 1 class holds books operations, another class holds > teachers operations and another class will hold course operations - so our > expectation is that we should have > 3 separate WADLs generated - what do you think? > That is fine, it is just that it can't be really solved at the WADLGenerator level - in your case the separation may be clean, in other cases - may be not. And from the practical point of view it will push the already very complex WADLGenerator code to the limit if we started trying updating it to push the info to many files Thanks, Sergey > > Thanks, > Eyal > > > -Original Message- > From: Eyal Weingart > Sent: 18 October, 2017 13:47 > To: Sergey Beryozkin ; users > > Subject: RE: cxf-java2wadl-plugin java2wadl questions > > 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 duplicati
Re: cxf-java2wadl-plugin java2wadl questions
Hi Eyal On 19/10/17 09:47, Eyal Weingart wrote: Hi Sergey 1. Do you see a future option to custom the WADL generator class during the maven build? If so, what is a reasonable timeline for this? (Just to know how to plan ahead) I've added a 'customWadlGenerator' parameter, give 3.1.14-SNAPSHOT or 3.2.1-SNAPSHOT a try 2. Regarding the "classResourceNames" and multiple WADL files question, i think i was misunderstood, it is not that each rest class holds 1 service, i meant that each rest class holds 1 business with few operations. For example, 1 class holds books operations, another class holds teachers operations and another class will hold course operations - so our expectation is that we should have 3 separate WADLs generated - what do you think? That is fine, it is just that it can't be really solved at the WADLGenerator level - in your case the separation may be clean, in other cases - may be not. And from the practical point of view it will push the already very complex WADLGenerator code to the limit if we started trying updating it to push the info to many files Thanks, Sergey Thanks, Eyal -Original Message- From: Eyal Weingart Sent: 18 October, 2017 13:47 To: Sergey Beryozkin ; users Subject: RE: cxf-java2wadl-plugin java2wadl questions 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.
ClassLoader
Hello, Out system uses a custom class-loader but, because of the stack-trace (below) we receive in some circumstances, I suspect that CXF does not use our ClassLoader which should be the default by the time we initialize CXF. We have a *CxfWebServiceServlet* which extends the *CXFNonSpringServlet* for deploying JaxWS websevices and looking at the source it uses the BUS to get a ClassLoader derived from the BusExtensions. How can I ensure that our ClassLoader is always used? Can I push our ClassLoader into the BUS before we start initializing the servlet? Do I need to configure/create a BusExtension for this and if so, how? Do you have any examples or can you point me at some useful documentation? Here is the exception: [13:51:13.810+0300] SYSERR javax.xml.ws.WebServiceException: java.lang.reflect.UndeclaredThrowableException [13:51:13.811+0300] SYSERR at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:375) [13:51:13.811+0300] SYSERR at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:255) [13:51:13.811+0300] SYSERR at org.apache.cxf.jaxws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:136) [13:51:13.811+0300] SYSERR at javax.xml.ws.Endpoint.publish(Endpoint.java:240) [13:51:13.812+0300] SYSERR at com.foo.server.jetty.servlet.CxfWebServiceServlet.publishCXF(CxfWebServiceServlet.java:77) ... REMOVED LINES GENERATING THE WEB SERVICE CODE AND COMPILE ETC ... [13:51:13.813+0300] SYSERR at com.foo.server.jetty.JettyContextListener.contextInitialized(JettyContextListener.java:89) [13:51:13.814+0300] SYSERR at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800) [13:51:13.814+0300] SYSERR at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444) [13:51:13.814+0300] SYSERR at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791) [13:51:13.814+0300] SYSERR at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294) [13:51:13.815+0300] SYSERR at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) [13:51:13.815+0300] SYSERR at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) [13:51:13.815+0300] SYSERR at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741) [13:51:13.815+0300] SYSERR at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) [13:51:13.815+0300] SYSERR at com.basis.server.jetty.BBjWebAppContext.doStart(BBjWebAppContext.java:229) [13:51:13.815+0300] SYSERR at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [13:51:13.816+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) [13:51:13.816+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) [13:51:13.816+0300] SYSERR at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) [13:51:13.816+0300] SYSERR at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:163) [13:51:13.816+0300] SYSERR at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [13:51:13.817+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) [13:51:13.817+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) [13:51:13.817+0300] SYSERR at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) [13:51:13.817+0300] SYSERR at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:163) [13:51:13.817+0300] SYSERR at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:140) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [13:51:13.818+0300] SYSERR at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) [13:51:13.819+0300]
Re: fediz in production
Thanks Colm, yes that was caused by a typo in stsKeystore.properties. but now I get this: org.apache.wss4j.common.ext.WSSecurityException: The private key for the supplied alias does not exist in the keystore Original Exception was org.apache.wss4j.common.ext.WSSecurityException: The private key for the supplied alias does not exist in the keystore Original Exception was java.security.UnrecoverableKeyException: Cannot recover key at org.apache.wss4j.common.saml.SamlAssertionWrapper.signAssertion(SamlAssertionWrapper.java:542) at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider.signToken(AbstractSAMLTokenProvider.java:121) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:319) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:117) at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle(TokenIssueOperation.java:171) but if i do keytool -list -v -keystore stsrealm_myrealm.jks i get Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry Alias name: realmmyrealm Creation date: 17-Oct-2017 Entry type: PrivateKeyEntry Certificate chain length: 1 Certificate[1]: On 19/10/2017 13:27, Colm O hEigeartaigh wrote: The error is that the STS can't load the signature properties file. For example, in the default STS the RealmProperties references the signaturePropertiesFile for the realm here: https://github.com/apache/cxf-fediz/blob/aee07e167458e468f123954f177c79f17df2c083/services/sts/src/main/webapp/WEB-INF/data/realms.xml#L62 which in turn is here: https://github.com/apache/cxf-fediz/blob/master/services/sts/src/main/resources/stsKeystoreA.properties On Thu, Oct 19, 2017 at 10:31 AM, Matthew Broadhead < matthew.broadh...@nbmlaw.co.uk> wrote: Hi, I am following this article by Jan https://janbernhardt.blogspot. com.es/2016/02/apache-fediz-installation-in-productive.html and I think I am close to getting it working but I have hit this error that I cannot work out. Can anyone help? org.apache.cxf.sts.token.provider.SAMLTokenProvider - org.apache.cxf.ws.security.sts.provider.STSException: Configuration error: cannot load signature properties at org.apache.cxf.sts.token.realm.RealmProperties.getSignatureC rypto(RealmProperties.java:156) at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. signToken(AbstractSAMLTokenProvider.java:59) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa mlToken(SAMLTokenProvider.java:319) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo ken(SAMLTokenProvider.java:117) at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle (TokenIssueOperation.java:171)
Re: providing basic auth via wadl2java?
OK, I've renamed it to "authentication", but please do test it before it gets released Sergey On 15/09/17 16:03, Shan Syed wrote: Truthfully I think "authentication" is a more appropriate word, but it's not a big deal ;) On Thu, Sep 14, 2017 at 5:16 PM, Sergey Beryozkin wrote: Thanks, should we rename 'authorization' to 'authentication' ? First I named it 'nameAndPassword', then thought, well, too specific, renamed it to 'authorization' (prob because of Http Authorization header). May be we will leave it as is... Sergey On 14/09/17 18:52, Shan Syed wrote: yes, it's communicating fine and processing the remote WADL :) thanks! On Thu, Sep 14, 2017 at 12:07 PM, Sergey Beryozkin wrote: Can you please try 3.1.14-SNAPSHOT now ? Sergey On 13/09/17 18:34, Shan Syed wrote: ok, thanks, looking forward to it! On Wednesday, September 13, 2017, Sergey Beryozkin < sberyoz...@gmail.com> wrote: For some reasons I thought it was about retrieving the internal references only, so more work is needed then in 3.1.14-SNAPSHOT On 13/09/17 16:19, Shan Syed wrote: So I just got the 3.1.14-SNAPSHOT working (sorry, was a silly issue), and still getting 401 from it. On Wed, Sep 13, 2017 at 11:12 AM, Shan Syed wrote: So outside of my snapshot issues, I updated my local jaxrs-toolspec.xml, locally here: .m2\repository\org\apache\cxf\cxf-tools-wadlto-jaxrs\3.1.13 I updated the option section for authorization, so all the items match Specifies a colon separated user name and password for retrieving the remote WADL content from the servers requiring Basic authentication authorization authorization In my POM: https://whatever/api/somemodel?_wadl true com.whatever -authorization apiuser:apiuser I'm still getting a 401 java.io.IOException: Server returned HTTP response code: 401 for URL: https://... snip -> [Help 1] On Wed, Sep 13, 2017 at 10:25 AM, Shan Syed wrote: Unfortunately, I can't seem to build off of the snapshots; I have this in my POM: apache-snapshot-repo http://repository.apache.org/snapshots true ..SNIP.. org.apache.cxf cxf-wadl2java-plugin 3.1.14-SNAPSHOT ..SNIP.. Getting this error: "[ERROR] Plugin org.apache.cxf:cxf-wadl2java-plugin:3.1.14-SNAPSHOT or one of its dependencies could not be resolved: Could not find artifact org.apache.cxf:cxf-wadl2java-plugin:jar :3.1.14-SNAPSHOT -> [Help 1]" Any ideas? I looked around in the repo, nothing seems off at a first glance, I can't see why it's not being found. On Tue, Sep 12, 2017 at 6:09 AM, Sergey Beryozkin < sberyoz...@gmail.com wrote: I've deployed a cxf-tools-wadlto-jaxrs/3.1.14-SNAPSHOT with the fix, can you try it ? If it works then may be you can just update the jaxrs-toolspec.xml in the 3.1.13 version in the .m2 repository and use till 3.1.14 is out Sergey On 11/09/17 22:17, Sergey Beryozkin wrote: Yes, I did it few days before the release, https://github.com/apache/cxf/blob/cxf-3.2.0/tools/wadlto/ja xrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/jaxrs-to olspec.xml#L262 I changed the 'id', but did not changed the switch...That's why it's always useful to test the snapshot... The fix will be avail in 3.1.14/3.2.1 Sergey On 11/09/17 22:12, Shan Syed wrote: Also, I just managed to grab the 3.2.0 release (congrats!) I noticed that wadl2java has this option now: -namePassword though in your commits, it looks like this was later renamed to "authorization" I tried both via the bat file, and "authorization" is an unknown option there are no complaints when I supply the namePassword though, like this: \apache-cxf-3.2.0\bin>wadl2java -namePassword apiuser:apiuser https://whatever:8000/api/rest/somemodel?_wadl I still get: Server returned HTTP response code: 401 Looks like the auth pair didn't seem to affect the connection? On Mon, Sep 11, 2017 at 3:39 PM, Shan Syed wrote: Hi, I I tried this on 3.0.15 just now, and it doesn't seem like the "authorization" is available as an option for me. In my POM: https://whatever8000/api/rest/somemodel?_wadl true apiuser:apiuser com.whatever "Cannot find 'authorization' in class org.apache.cxf.maven_plugin.wa dlto.WadlOption" Does the option go somewhere else? Thanks! On Fri, Sep 8, 2017 at 12:23 PM, Shan Syed wrote: Great, I will try it when it's available! On Wed, Sep 6, 2017 at 11:39 AM, Sergey Beryozkin < sberyoz...@gmail.com> wrote: Np. hope that code I added will work from the 1st attempt :-), I did not want to introduce a strong dep on the CXF JAX-RS client code, so resorted to writing some HttpUrlConnection code which is tricky to do right... Cheers, Sergey On 06/09/17 16:32, Shan Syed wrote: amazing, thank you On Friday, September 1, 2017, Sergey Beryozkin < sberyoz...@gmail.com> wrote: I've create
Re: fediz in production
The error is that the STS can't load the signature properties file. For example, in the default STS the RealmProperties references the signaturePropertiesFile for the realm here: https://github.com/apache/cxf-fediz/blob/aee07e167458e468f123954f177c79f17df2c083/services/sts/src/main/webapp/WEB-INF/data/realms.xml#L62 which in turn is here: https://github.com/apache/cxf-fediz/blob/master/services/sts/src/main/resources/stsKeystoreA.properties On Thu, Oct 19, 2017 at 10:31 AM, Matthew Broadhead < matthew.broadh...@nbmlaw.co.uk> wrote: > Hi, > > I am following this article by Jan https://janbernhardt.blogspot. > com.es/2016/02/apache-fediz-installation-in-productive.html and I think I > am close to getting it working but I have hit this error that I cannot work > out. Can anyone help? > > org.apache.cxf.sts.token.provider.SAMLTokenProvider - > org.apache.cxf.ws.security.sts.provider.STSException: Configuration > error: cannot load signature properties > at org.apache.cxf.sts.token.realm.RealmProperties.getSignatureC > rypto(RealmProperties.java:156) > at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider. > signToken(AbstractSAMLTokenProvider.java:59) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSa > mlToken(SAMLTokenProvider.java:319) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createTo > ken(SAMLTokenProvider.java:117) > at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle > (TokenIssueOperation.java:171) > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
fediz in production
Hi, I am following this article by Jan https://janbernhardt.blogspot.com.es/2016/02/apache-fediz-installation-in-productive.html and I think I am close to getting it working but I have hit this error that I cannot work out. Can anyone help? org.apache.cxf.sts.token.provider.SAMLTokenProvider - org.apache.cxf.ws.security.sts.provider.STSException: Configuration error: cannot load signature properties at org.apache.cxf.sts.token.realm.RealmProperties.getSignatureCrypto(RealmProperties.java:156) at org.apache.cxf.sts.token.provider.AbstractSAMLTokenProvider.signToken(AbstractSAMLTokenProvider.java:59) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:319) at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:117) at org.apache.cxf.sts.operation.TokenIssueOperation.issueSingle(TokenIssueOperation.java:171)
RE: cxf-java2wadl-plugin java2wadl questions
Hi Sergey 1. Do you see a future option to custom the WADL generator class during the maven build? If so, what is a reasonable timeline for this? (Just to know how to plan ahead) 2. Regarding the "classResourceNames" and multiple WADL files question, i think i was misunderstood, it is not that each rest class holds 1 service, i meant that each rest class holds 1 business with few operations. For example, 1 class holds books operations, another class holds teachers operations and another class will hold course operations - so our expectation is that we should have 3 separate WADLs generated - what do you think? Thanks, Eyal -Original Message- From: Eyal Weingart Sent: 18 October, 2017 13:47 To: Sergey Beryozkin ; users Subject: RE: cxf-java2wadl-plugin java2wadl questions 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
