I have some problems with my server-client communication via web services with Apache CXF framework. I want to log the server errors to an external file instead of terminal. Piece of code for server;
server= new JaxwsNotificationBroker("Hello",..);
server.setAddress("http://localhost:" + brokerPort + "/wsn/NotificationBroker");
And I tried this for logging;
server.getInInterceptors().add(new LoggingInInterceptor());
server.getOutInterceptors().add(new LoggingOutInterceptor());
But it gives the error The method getInInterceptors() is undefined for the type JaxwsNotificationBroker.
Is there any method to log the errors for JaxwsNotificationBroker?
Thank you
You can add loggingInInterceptor & logOutInterceptor inside cxf:bus
<cxf:bus>
<cxf:ininterceptors>
<ref bean="loggingInInterceptor" />
</cxf:ininterceptors>
<cxf:outinterceptors>
<ref bean="logOutInterceptor" />
</cxf:outinterceptors>
</cxf:bus>
add this to your spring config file, if you are using spring:
<cxf:bus>
<cxf:features>
<cxf:logging />
</cxf:features>
</cxf:bus>
don't forget to add cxf namespace as
xmlns:cxf="http://cxf.apache.org/core"
If you use log4j for logging you must put a META-INF/cxf/org.apache.cxf.Logger file onto the classpath with the 'org.apache.cxf.common.logging.Log4jLogger' class name in it as a single line, otherwise cxf will use the JavaTM 2 platform's core logging facilities.
For some reason, gnodet wanted to keep all the WS-N stuff as independent from CXF as possible and only rely on pure JAX-WS stuff. Thus, nice methods for things like the CXF interceptors aren't possible. :-(
Looking at the code, the only option right now would be to write a subclass of JaxwsEndpointManager that would call the super.register method, then cast it to the CXF EndpointImpl, and set the interceptors on there. Not really ideal. :-(
Related
In one of my projects i have to set the ETag header in responses and read the if-none-matched header in the incoming requests. As of now i have implemented this using Apache CXF Filters however as i searched and found, the same functionality can be done by using interceptors as well. what are the significant advantages and/or disadvantages that i will have to experience if i proceed with CXF filters??
as of now i have implemented the filter and it works fine What would be the best practices in using a filter?
Here's a quote from http://cxf.apache.org/docs/jax-rs-filters.html.
Difference between JAXRS filters and CXF interceptors
JAXRS runtime flow is mainly implemented by a pair of 'classical' CXF interceptors. JAXRSInInterceptor is currently at Phase.UNMARSHAL (was at Phase.PRE_STREAM before CXF 2.2.2) phase while JAXRSOutInterceptor is currently at Phase.MARSHAL phase.
JAXRS filters can be thought of as additional handlers. JAXRSInInterceptor deals with a chain of Pre and Post Match ContainerRequestFilters, just before the invocation. JAXRSOutInterceptor deals with a chain of ContainerResponseFilters, just after the invocation but before message body writers get their chance.
Sometimes you may want to use CXF interceptors rather than writing JAXRS filters. For example, suppose you combine JAXWS and JAXRS and you need to log only inbound or outbound messages. You can reuse the existing CXF interceptors :
<beans>
<bean id="logInbound" class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
<bean id="logOutbound" class="org.apache.cxf.interceptor.LoggingOutInterceptor"/>
<jaxrs:server>
<jaxrs:inInterceptors>
<ref bean="logInbound"/>
</jaxrs:inInterceptors>
<jaxrs:outInterceptors>
<ref bean="logOutbound"/>
</jaxrs:outInterceptors>
</jaxrs:server>
<jaxws:endpoint>
<jaxws:inInterceptors>
<ref bean="logInbound"/>
</jaxws:inInterceptors>
<jaxws:outInterceptors>
<ref bean="logOutbound"/>
</jaxws:outInterceptors>
</jaxws:endpoint>
</beans>
Reusing other CXF interceptors/features such as GZIP handlers can be useful too.
At the moment it is not possible to override a response status code from a CXF interceptor running before JAXRSOutInterceptor, like CustomOutInterceptor above, which will be fixed.
Looking at the documentation: http://docs.spring.io/spring-integration/reference/html/ip.html#tcp-adapters I understand that the adapters are for one way only communication. However, only XML configuration examples of these classes are given.
I am trying to configure them as Java beans, but I cannot find any documentation regarding how to do this. Please give me an example how I would configure the following in Java config:
<int-ip:tcp-outbound-channel-adapter
id="outboundClient" channel="rsp_transformed" connection-factory="client" />
<int-ip:tcp-inbound-channel-adapter
id="inboundClient" channel="req" connection-factory="client" client-mode="true" />
See Annotations on Beans.
In 4.3 we have added class information the XML schema for the inbound and outbound endpoints.
In this case, the inbound adapter is simply a TcpReceivingChannelAdapter #Bean, the outbound adapter is a TcpSendingMessageHandler annotated with #ServieActivator - the framework uses the information in the annotation to create a ConsumerEndpointFactoryBean to support the handler.
You should also look at the Java DSL which makes java configuration simpler in many cases.
Setting up an HTTP proxy for Java JVM 6.x isn't working for me; I'm hoping someone can spot what I'm missing.
I have a Java application deployed on JBOSS 5.1.2 that makes several calls to external web services. I'd like to be able to intercept these calls using a proxy: Fiddler version 4.4.8.0.
After doing an SO search I added the following flags to my JBOSS VM parameters at startup:
-DproxySet=true -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8888 -Dhttps.proxyHost=localhost -Dhttps.proxyPort=8888
I'm running JBOSS in IntelliJ 14.
I can see traffic from the browser to the application if I start JBOSS, Fiddler, and open the UI in Chrome. I do not see any calls from JBOSS to external services being intercepted. I thought I would see all the calls from JBOSS to external services in addition to those from the browser to JBOSS.
Update:
I tried adding these to properties-service.xml per this SO answer - no joy.
I'm running Spring 3, using Apache HttpClient as my web service client. I'm going to look into configuring proxy just for it.
Thanks to bmargulies and anyone else who looked at this. I have a solution that I hope will help someone else.
Adding -Dhttp.proxyHost parameters to my JVM startup options did nothing.
Adding those same parameters to JBOSS 5.1.2 configuration in my deployment properties-services.xml did nothing.
I believe that using Spring 3.x is a factor in explaining this behavior. I had to tell the Spring web service clients to use a proxy.
I added some Spring beans to wire in a Fiddler proxy HttpClient and injected that into the web service client, replacing the non-proxied version.
It failed the first time I tried it. It took me a while to figure out that the Apache Commons HttpConfiguration class didn’t follow the Java bean standard, so Spring blew up when it tried to wire it. I had to use the Spring MethodInvokingFactoryBean to get around it.
Here's the pertinent Spring configuration XML:
<!-- New beans for Fiddler proxy -->
<bean id="fiddlerProxyHost" class="org.apache.commons.httpclient.ProxyHost">
<constructor-arg name="hostname" value="localhost"/>
<constructor-arg name="port" value="8888"/>
</bean>
<bean id="fiddlerProxyHostConfiguration" class="org.apache.commons.httpclient.HostConfiguration"/>
<bean id="fiddlerProxyHostSetter" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetObject" ref="fiddlerProxyHostConfiguration"/>
<property name="targetMethod" value="setProxyHost"/>
<property name="arguments" ref="fiddlerProxyHost"/>
</bean>
<bean id="fiddlerProxyClient" class="org.apache.commons.httpclient.HttpClient">
<property name="hostConfiguration" ref="fiddlerProxyHostConfiguration"/>
</bean>
Now I can see the calls from the application to the web service in Fiddler. Joy!
Those parameters, first and foremost, are read by HttpURLConnection. They are specific to HTTP, of course, and so any other means of connecting to the outside world will necessarily ignore them.
There are many good reasons for code to avoid HttpURLConnection and just open a TCP connection through a plain old socket, even if that code plans to talk HTTP. HttpURLConnection has several 'browser emulation features' that get in the way. For example, it's broken for CORS and rejects some legitimate HTTP verbs.
Code that does that and in turn happens to do HTTP might choose to respect those parameters, and it might not. For example, I'm reasonably sure that the Apache Commons HTTP library gives the caller a choice.
If you put JBoss in a debugger and break on the socket connection primitives, I think you'll find out what's happening to you pretty quick in this respect.
I'm wondering about Spring 3.0 whether it provides an automatically generated service definition page after I defined services.
With SOAP we have a WSDL file which contains WHAT, HOW and WHERE we can call a service.
Is that possible with Spring 3.0 or not?
Yes it does. Just add "?WSDL" to the URL of your Spring-generated web service and you'll get the definition. Also you can append "?xsd=1" instead and you'll get the schema you need (this is referenced also from the WSDL).
You can use an MBeanExporter to expose all of your services via JMX, which would be viewable through a JMX dashboard on your container (IE Tomcat, Jboss, etc). This is an easy way to account for 'what is deployed'. Your question is not entirely clear what sort of artifact you're looking for though.
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
<property name="autodetect" value="true"/>
</bean>
Will automatically export all of your defined beans as MBeans. Usually that's not entirely what you want, so alternatively, you'll specify them manually.
<bean id="exporter" class="org.springframework.jmx.export.MBeanExporter">
<property name="beans">
<map>
<entry key="bean:name=testBean1" value-ref="testBean"/>
</map>
</property>
</bean>
I agree with Chochos.
These[?wsdl, ?xsd=N] are universal standard to find the service definition file and any Datacontract defined in the wsdl.
example:
if http://localhost:8080/MyService is your service endpoint then it is service container's responsibility to make the WSDl available at http://localhost:8080/MyService,
by default.
The answer is Yes,
Use tag in your message dispatcher spring context file.
if your message dispatcher bean id is spring-ws then the spring context file for it would be spring-ws-servlet.xml.
In that context file,
import the namespace http://www.springframework.org/schema/web-services/web-services-2.0.xsd
xmlns:sws="http://www.springframework.org/schema/web-services".
then use the tag dynamic-wsdl from this namespace.
Also, you can set attributes for it like portType, binding and id. This will generate the wsdl file for you. You can view it by querying for it in the browser
/.wsdl
I am having a hard time getting cxf to validate an xml request that my service creates for a 3rd party.
My project uses maven. Here is my project structure
Main Module :
+ Sub-Module1 = Application
+ sub-Module2 = Interfaces
In Interfaces, inside src/main/resources I have my wsdl and xsd.
so, src/main/resources
+ mywsdl.wsdl.
+ myschema.xsd
The interface submodule is listed as a dependency in the Application-sub-module.
inside Application sub-module, there is a cxsf file in src/maim/resources.
<jaxws:client name="{myTargerNameSpaceName}port"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:client>
AND:.
<jaxws:endpoint name="{myTargetNameSpaceName}port"
wsdlLocation="/mywsdl.wsdl"
createdFromAPI="true">
<jaxws:properties>
<entry key="schema-validation-enabled" value="true" />
</jaxws:properties>
</jaxws:endpoint>
I tried changing the "name="{myTargetNameSpaceName}port" to "name="{myEndPointName}port"
But to no anvil.
My application works. But it just do not validate the xml I am producing that has to be consumed by a 3rd party application.
I would like to get the validation working, so that any request that I send would be a valid one.
Any suggestions?
Just add #org.apache.cxf.annotations.SchemaValidation annotation on your service implementation class and schema validation will work.
First ensure that the value of the name attribute is {NAMESPACE}PORT_NAME where NAMESPACE is your namespace URI and PORT_NAME is the name of your WSDL port. Without seeing your WSDL, I don't know if you named your WSDL port "port" or if you are just giving a sanitized example.
For example, my WSDL namespace is "http://example.com/services" and the name of my WSDL port element is "myPort", the Spring configuration would look like this
<jaxws:endpoint name="{http://example.com/services}myPort" >
...
See "CreatedFromAPI" attribute description in CXF docs
If that doesn't solve your problem, try looking at the wsdl_first example code, upgrading your CXF version, and/or posting your question with test code demonstrating your issue to the CXF user list.
We had similar issues. CXF 2.3.1 fixed the issue for us on incoming messages but not outgoing messages.
https://issues.apache.org/jira/browse/CXF-3233
We work around it by marshaling the messages and validating them within the server before sending them out through the CXF interceptor chain. We validate using org.springframework.xml.validation.XmlValidator.
I'm hoping a future version of CXF will solve this but this is what we do for now.