I recently updated my environment from WSO2 IS 5.0.0 to WSO2 IS 5.2.0. My environment consists of 2 machines that are creating a cluster (using the WKA membership scheme and Load Balancer(AWS ELB) with sticky session enabled). I am using MySQL(not the default H2 database). The machines on which the IS is deployed are Windows Server 2012 R2 (EC2 AWS machines).
In the IS 5.0.0 version we had custom grant OAuth grant type. It was implemented following the article below:
https://docs.wso2.com/display/IS500/Writing+a+Custom+OAuth+2.0+Grant+Type
After the upgrade process, the .jar file was added in the [IS_HOME]\repository\components\lib and the system was started successfully without errors in the console.log. But then when we started calling the token endpoint, the systems tarted to error out:
https://slack-files.com/T0DDMMC9Y-F2QRF2JLA-bcd85857dc
https://slack-files.com/T0DDMMC9Y-F2QRFES10-ab528f64e5
Then we rebuilt the custom OAuth grant type. We updated the org.wso2.carbon.identity.oauth_4.2.3.jar to version 4.2.7. We followed these article:
https://docs.wso2.com/display/IS520/Extension+Points+for+OAuth#ExtensionPointsforOAuth-CustomOAuthgranthandler
https://docs.wso2.com/display/IS520/Writing+a+Custom+OAuth+2.0+Grant+Type
But still when we enable the custom grant type and the start calling the token endpoint, the mentioned above errors are logged in the console.log and are returned as response by the tomcat server.
After we implemented some adjustments in order to resolve some of the issues, we have progress, but this still we do not have a complete solution:
https://slack-files.com/T0DDMMC9Y-F2S5LKT6V-560a2854ea
Could this be related to some issues while migrating from 5.0.0 to 5.2.0, or this is some sort of configuration issue with Tomcat server?
Or this is related to the grant type itself? We followed all the instructions as we did with IS 5.0.0 but we are not able to make it run on IS 5.2.0.
Thanks in advance.
The root cause for this is,
Caused by: java.lang.ClassNotFoundException: org.apache.amber.oauth2.common.validators.AbstractValidator
Amber library is no longer used by WSO2 IS. Therefore amber library is not available in the IS 5.2.0 runtime causing the class not found error.
Instead, we are using Apache Oltu instead in 5.2.0
You can simply fix this by copying the amber amber_0.22.1358727.wso2v4.jar found in IS_HOME/repository/components/plugins of IS 5.0.0 to IS_HOME/repository/components/dropins.
Update :
Another reason why this extension was not working was the use of a class that was not exported by the OAuth osgi bundle at runtime.
I've tried to deploy my war file in Wildfly 8.2. My application uses org.apache.cxf for web service. But Wildfly (Jboss) comes by default with its own cxf jars which can be provide full Java EE support. I could eliminate jboss cxf and utilise my own cxf jars for web services by
jboss-deployment-structure.xml
<jboss-deployment-structure>
<deployment>
<exclude-subsystems>
<subsystem name="webservices" />
</exclude-subsystems>
</deployment>
</jboss-deployment-structure>
But it'll disable ws support by jboss which means I can't even find ws endpoints in Jboss admin console. But my client needs to utilise jboss's build in ws features so that he can disable or enable any ws calls at any time. Does anyone know on how to configure my application to utilise jboss's cxf jars so that I can tune my ws in Jboss admin console at any time. The following link explains exactly the same which I've mentioned so far. I'm successfull with the first option, but I need it to work with second option.
http://cxf.apache.org/docs/application-server-specific-configuration-guide.html
Note: See the first topic ( JBoss Application Server )
I can't seem to figure out how I can configure my application to utilise jboss's cxf jars..!
If I remove all the org.apache.cxf dependencies from my build.gradle file, it give ClassNotFoundException error which infact tells me that it can find the cxf-transport jar.
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.ClassNotFoundException: org.apache.cxf.transport.servlet.CXFServlet
If I include org.apache.cxf dependenices in build.gradle file, it shows that it's conflicting with the cxf jar which is also present in Jboss. The whole problem is I need to utilise the cxf which is present in jboss for full Java EE support by eliminating the user defined cxf jars.
This is probably overlap with some other dependency what implies different version.
I had the same situation and had to test and remove all un-nesesery ones from org.apache.cxf, especially deprecated ones like:
cxf-rt-rs-extension-providers,
cxf-distribution-manifest,
cxf-bundle-jaxrs and
cxf-rt-frontend-jaxrs.
It is important for keeping compatibility to use ${cxf.version} for all
org.apache.cxf, especialy for later versions and check the dependency hierarchy if other dependencies are bringing in older cxf libraries.
I'm having a problem registering a REST web service in the ColdFusion Administrator. I'm using ColdFusion 10 on a Windows server, and the error I get after trying to register a REST web service is:
Error registering REST service. Please ensure that you have entered a proper mapping and path.
Application CA could not be initialized.
Reason: class "com.sun.xml.bind.Util"'s signer information does not match signer information of other classes in the same package
class "com.sun.xml.bind.Util"'s signer information does not match signer information of other classes in the same package
I've tried registering a service on both a remote CF instance as well as my local instance. Locally I've tried just a real basic service - basically one CFC in an application all by itself, but still get the error. I am putting in both the Root path and the Service Mapping, as I do not have an Application.cfc in the application.
Any ideas?
This problem was caused by some custom JARs I was referencing in the ColdFusion Class Path in the Java and JVM settings in the CF Admin utility. I removed the references to the JARs and restarted the CF instance. Then I was able to successfully add the REST WS. I then re-added the JARs in the class path and restarted the instance. The proper solution is probably to recompile those JARs with the same certificate, but if you don't have access to the source code, this may be the only workaround.
I am wrote and deployed a CXF web service into a Tomcat server using the instructions here. The web service deploys fine as I can see the WSDL file in a web browser.
My standalone Java client program doesn't work though. Here is the code:
System.out.println("Creating client");
Properties properties = System.getProperties();
properties.put("org.apache.cxf.stax.allowInsecureParser", "1");
System.setProperties(properties);
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(ExampleWebService.class);
factory.setAddress("http://X.X.X.X:9090/WebServices/ExampleWebService");
ExampleWebService exampleWebService = (ExampleWebService)factory.create();
System.out.println("Done creating client");
exampleWebService.method1("test");
System.out.println("After calling method1");
I copied all the jar files (including the woodstox-core-asl-4.2.0.jar file) from the CXF 2.7.7 distribution into the client program's classpath, and when I run the client I get the following exception:
Creating client
Nov 20, 2013 8:05:26 PM org.apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://webservices.server/}ExampleWebServiceService from class server.webservices.ExampleWebService
Done creating client
javax.xml.ws.soap.SOAPFaultException: Cannot create a secure XMLInputFactory
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
at $Proxy38.printString(Unknown Source)
at ExampleNmsWebServiceClient.printString(ExampleNmsWebServiceClient.java:29)
at ExampleNmsWebServiceClient.main(ExampleNmsWebServiceClient.java:40)
Caused by: org.apache.cxf.binding.soap.SoapFault: Cannot create a secure XMLInputFactory
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.java:84)
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:51)
at org.apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.java:40)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:113)
at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:69)
at org.apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.java:34)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:835)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1606)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1502)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1309)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:627)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
... 3 more
I found a page saying the "Cannot create a secure XMLInputFactory" can be fixed by setting the org.apache.cxf.stax.allowInsecureParser property to "1", which is why I tried to set it in the System properties, but that didn't work. I also tried to add -Dorg.apache.cxf.stax.allowInsecureParser=1 to the java command that runs the client, but that didn't work either. (Nor did setting it to "true" instead of 1.) Any ideas on how to solve this error?
Had this problem when upgrading from CXF 2.3.x to 2.7.x
Added stax2-api and woodstox-core-asl jars from the 2.7.x CXF distribution and the webservice works again.
Since version 2.7.4, CXF added a feature in order to ensure that the XMLInputFactory is secured and loaded from woodstox (>= 4.2.x packages, see StaxUtil implementation) in order to deal with a Denial of Service vulnerability
But the fact is that in a J2EE environment, by default, webservices-rt.jar has the priority over war libs (and then over the woodstock jar). That is why the non-secure implementation is loaded, triggering the exception.
Turning off the org.apache.cxf.stax.allowInsecureParser property, is not an option as it brings back the DOS vulnerability.
In order to make the class loader to prefer woodstox (ear/war lib) over webservices-rt.jar (j2ee lib), the solution depends on your application server and is described in CXF application server specific configuration guide
I had similar problem
After adding this -Dorg.apache.cxf.stax.allowInsecureParser=1 to the JAVA_OPTIONS in setDomainEnv.sh, It is working fine now.
I had this problem on weblogic and fixed the problem by adding this to my weblogic-application.xml
<prefer-application-packages>
<package-name>com.ctc.wstx.*</package-name>
</prefer-application-packages>
Check for any other versions of woodstox that may be found on the classpath or in the jre's lib/endorsed or similar. It sounds like an older 4.1 version may be picked up.
I had the same problem whenI upgraded CXF to 2.7.x. I resolved this by adding following dependencies in POM
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>stax2-api</artifactId>
<version>4.0.0</version>
</dependency>
<dependency>
<groupId>org.codehaus.woodstox</groupId>
<artifactId>woodstox-core-asl</artifactId>
<version>4.4.1</version>
</dependency>
There was not an answer here that describes the root cause of this error message for my issue. We had transitive dependencies on both a new version
woodstox-core-asl-4.2.0.jar
and and old
wstx-asl-3.2.1.jar
Excluding the old version from our build did the trick.
If you dig into the bowels of the old version, you'll find that it fails with an exception that ends up getting wrapped in another exception with this generic message that is not very informative.
I hit this issue and it was because, when i upgraded from an older version of cxf, i did not change stax-api-*.jar to stax2-api-*.jar in my client classpath.
If you upgrade to 3.0.0 or later, you shouldn't add woodstock dependencies
Interestingly I had this issue in docker container and not while running it on tomcat server.
The problem that I faced was that the project had another lower version of wstx-asl-3.2.7 and the class loader probably could have loaded this versions first.
I got rid of it and the necessary woodstox was considered and the problem was solved.
The problem was some missing CXF jar files in the web service deployment on the server. This was tough to debug because there were no errors on the server.
In my case there were two jars (Cxf 3.0.1, Jboss 7.1.1)
javax.xml.stream:stax-api:jar:1.0-2:compile
org.codehaus.woodstox:stax2-api:jar:3.1.4:compile
I removed the 1st one and it started working
from my end, I had to do both remove the stax-api-1.0-2.jar (leaving stax2-api-3.1.4.jar & woodstock 4.4 jar) and specify in the weblogic-application.xml at the end of it:
.
.
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.codehaus.stax2.*</package-name>
</prefer-application-packages>
I had this problem on weblogic, Application get Deployed Successfully but when i fired the soap-request then i got this fault : Cannot create a secure XMLInputFactory.
fixed the problem by adding this package to weblogic-application.xml
com.ctc.wstx.*
I looked through my dependencies to find version conflicts with woodstox or stax-api.
Turns out that axis2-transport-http introduced these conflicts.
If you happen to have this dependency as well, add the following exclusion to your pom dependency that introduced it
<exclusions>
<exclusion>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-transport-http</artifactId>
</exclusion>
</exclusions>
I can solve this problem by adding weblogic.xml in the WEB-INF folder of my app with the following code:
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>com.ctc.*</package-name>
</prefer-application-packages>
1: -Dorg.apache.cxf.stax.allowInsecureParser=1 to the JAVA_OPTIONS
or
2: rename woodstox-core-asl-4.4.1.jar -> awoodstox-core-asl-4.4.1.jar
I'm refering to the following article
http://wso2.com/library/articles/2010/10/using-xacml-fine-grained-authorization-wso2-platform/
I would like to use the sample echoService from the WSO2 AS over a secured proxy in WSO2 ESB in combination with the Identity Server for fine-grained authorization. All the settings mentioned on this page seem to work, however I am stuck concerning the client part. I use NetBeans and the given client code, but the .jars in the classpath there have older versions then the ones in the current version of WSO2 IS, so I started to exchange them manually. Now I get some exceptions like
Exception in thread "main" java.lang.NoSuchMethodError: org.apache.xml.security.transforms.Transform.init()V
and I am stuck again. I just want to test the echoService in this constellation and send some string over the ESB via IS and receive the response(if I have the appropriate role) from the AS, is there not another client or how could I test it else?
Thank you!
I can suggest you 3 options:
Use SoapUI to test the service which is the easiest way to test a web service.
Generate the stub for the service and have stub as the dependency in your client. You can use the WSDL2Java tool that ship with AS. Loging to AS --> Tools in left pane --> WSDL2Java --> Provide the wsdl URL and generate the stub jar.
Generate correct dependency libs. Go to [IS-Home]/bin folder, and issue that command "ant" to run the build.xml, this will copy all required libs to [IS-HOME]/repository/lib/ folder. Have them in your class path.