I implemented webservice as described in this guide by simply creating "web-services.xml" with the following content (and offcourse i create the 'com.example.WorkFlowEntry' handler class ) :
<web-services>
<handler-chains>
<handler-chain name="enterWorkflowChain">
<handler class-name="com.example.WorkFlowEntry">
<init-params>
<init-param name="workflow-eng-jndi-name"
value="workflow.entry" />
</init-params>
</handler>
</handler-chain>
</handler-chains>
<web-service targetNamespace="http://example.com"
name="myworkflow" uri="myWorkflowService">
<operations xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
<operation name="enterWorkflow"
handler-chain="enterWorkflowChain"
invocation-style="one-way" />
</operations>
</web-service>
My issue is that when i deploy the EAR file in weblogic 11g the '' webservice is deployed successfully and i can access the WSDL of the webservice. When i deploy the same EAR in weblogic 12c it got deployed successfully but the WSDL is not accessible i am getting 404!
Manually assembling weblogic web service is valid if you are using the
Webservice 8.1 environment. The last Weblogic version for which this
approach can be used is Weblogic 12.1.1, from Weblogic 12.1.2 release,
the 8.1 WebLogic Web services run time has been removed.
that means using the 'web-services.xml' to build your webservice is valid till weblogic 12.1.1 version. for the newer version you have to upgrade your webservice implementation as mentioned in this link which mainly go through (Upgrading a 10.x WebLogic Web Service (JAX-WS or JAX-RPC) to 12.1.x). But this solution may affect the current running clients.
In my case i cannot ask the client to change their code. So my workaround for this case is to take the current WSDL and generate the webservice manually by ant as described in this link which is describes using wsdlc Ant task to generate the following artifacts:
JWS service endpoint interface (SEI) that implements the Web service described
by the WSDL file.
JWS implementation file that contains a partial (stubbed-out) implementation of
the generated JWS SEI. This file must be customized by the developer.
JAXB data binding artifacts.
Optional Javadocs for the generated JWS SEI.
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.
I have a web service client generated and built with Apache CXF. Next I have JAX-RS Jersey application in which I want to call methods from that webservice. When I try to deploy this simple project to Glassfish 4.0 server I get this exception:
Exception while deploying the app [pelijee] :
The lifecycle method [finalizeConfig] must not throw a checked exception.
Related annotation information: annotation [#javax.annotation.PostConstruct()] on annotated element [public void org.apache.cxf.transport.http_jetty.JettyHTTPServerEngine.finalizeConfig() throws java.security.GeneralSecurityException,java.io.IOException] of type [METHOD]. Please see server.log for more details.
Command deploy failed.
The only one CXF dependency I have in this project is:
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle-jaxrs</artifactId>
<version>2.7.6</version>
<type>jar</type>
<scope>runtime</scope>
</dependency>
Is there any other CXF library compatible with JSR 250?
Thank you
One of the challenges of Glassfish is that the full server profile comes packaged with Metro for JAX-WS web services and Jersey for JAX-RS rest services. It is recommended to configure the classloader through a sun-web.xml file included in the WEB-INF folder of your WAR. It should include the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC
'-//Sun Microsystems, Inc.//DTD Application Server 9.0 Servlet 2.5//EN'
'http://www.sun.com/software/appserver/dtds/sun-web-app_2_5-0.dtd'>
<sun-web-app>
<class-loader delegate="false"/>
</sun-web-app>
In the past, I have found that occasionally I still have problems with deployment; therefore, I have actually removed the Metro and Jersey features altogether from the Glassfish server profile. Here is some more information about deployment.
http://cxf.apache.org/docs/application-server-specific-configuration-guide.html
One additional thing I noticed is that you posted a log message which included the Jetty transport. This means you are running the Jetty HTTP server and running the Glassfish HTTP server. I would suggest just using Glassfish as the web server and using the CXF servlet transport instead.
My application is a war deployed in weblogic 10. In one of my class, I need to make 2 webservice calls A and W. A is based on AXIS2 using wstx-asl-3.2.4.jar, W is based on weblogic webservice using jars in weblogic. I guess due to the conflict between wstx-asl and weblogic stax implementation, they can not be made at the same time.
Here is the detail of the problem:
1. If I remove wstx-asl-3.2.4.jar from web-inf/lib folder,
B is OK but A is faild due to exception: ClassCastException:weblogic.xml.stax.XMLStreamInputFactory
2. If I keep wstx-asl-3.2.4.jar in web-inf/lib folder,
A is OK but B is faild due to the exception:
[java.lang.ExceptionInInitializerError at com.bea.staxb.runtime.internal.BindingContextImpl.createMarshaller(BindingContextImpl.java:65) at weblogic.wsee.bind.runtime.internal.LiteralSerializerContext.(LiteralSerializerContext.java:54) at weblogic.wsee.bind.runtime.internal.RuntimeBindingsImpl.createSerializerContext(RuntimeBindingsImpl.java:152) at weblogic.wsee.bind.runtime.internal.RuntimeBindingsImpl.createSerializerContext(RuntimeBindingsImpl.java:168) at weblogic.wsee.codec.soap11.SerializationContextUtil.createSerializerContext(SerializationContextUtil.java:26) at weblogic.wsee.codec.soap11.SoapEncoder.encodeParts(SoapEncoder.java:179) at weblogic.wsee.codec.soap11.SoapEncoder.encode(SoapEncoder.java:119) at weblogic.wsee.codec.soap11.SoapCodec.encode(SoapCodec.java:128) at weblogic.wsee.ws.dispatch.client.CodecHandler.encode(CodecHandler.java:52) at weblogic.wsee.ws.dispatch.client.CodecHandler.handleRequest(CodecHandler.java:41) at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:123) at weblogic.wsee.handler.HandlerIterator.handleRequest(HandlerIterator.java:99) at weblogic.wsee.ws.dispatch.client.ClientDispatcher.dispatch(ClientDispatcher.java:101) at weblogic.wsee.ws.WsStub.invoke(WsStub.java:89) at weblogic.wsee.jaxrpc.StubImpl._invoke(StubImpl.java:331) at
.........................
Please advise how to make them successful together. Thanks.
in your deployment weblogic.xml file, use the <prefer-web-inf-classes> tag and set it to true for the axis2 call. And set it to false for the weblogic web service.
http://download.oracle.com/docs/cd/E13222_01/wls/docs90/programming/classloading.html#1082452