Param Headers with mustUnderstand=true
Hi all
I've got an issue with a mustUnderstand SOAP Header that is used as service
parameter (it's a method parameter of the implementor).
As the MustUnderstandInterceptor is placed in the PRE_PROTOCOL phase, the
binding operation is not known at this time (except if there is a
SOAPAction header somewhere), so
the HeaderUtil.getHeaderQNameInOperationParam(soapMessage) don't return the
QName of the param header.
That leads the MustUnderstandInterceptor to think that the header is not
understood by the current interceptor chain. And thus, it register a
SOAPFault in the Message, fault that will be thrown as an Exception in
the MustUnderstandEndingInterceptor.
I've got that issue as part of the Java EE TCK on OW2 JOnAS, running CXF
2.5.2 (but it's also broken with 2.3.9).
I've attached to this message a modification of a soap header test case
that show the problem.
After some analyzing, it appears the MU interceptor runs too early in the
chain : before one of the AbstractInDatabindingInterceptor sub-classes (I
presume that on of theses implementations is setting up the
BindingOperationInfo into the message).
I've done a (naive) workaround simply by chaging the phase of the MU
interceptor: from PRE_PROTOCOL to UNMARSHAL.
That fixes the test, but I don't know if this is the right approach, or if
that breaks the streaming, or anything else ... :)
Any advice ?
Should I create a bug with the testcase and my proposed patch ?
Thanks
--Guillaume
PS: Theses git patches are build against the 2.5.x-fixes branch of the
github CXF mirror
From 83b2d6cbebc2a4446c9638ddca4f1ac0163b7767 Mon Sep 17 00:00:00 2001
From: Guillaume Sauthier guillaume.sauth...@ow2.org
Date: Fri, 24 Feb 2012 10:51:46 +0100
Subject: [PATCH 1/2] Adapted the soap_header testcase to show the error
---
.../systest/soapheader/HeaderClientServerTest.java |1 +
.../test/resources/wsdl_systest/pizza_service.wsdl |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/systests/uncategorized/src/test/java/org/apache/cxf/systest/soapheader/HeaderClientServerTest.java b/systests/uncategorized/src/test/java/org/apache/cxf/systest/soapheader/HeaderClientServerTest.java
index 2aa2bed..2d68c95 100644
--- a/systests/uncategorized/src/test/java/org/apache/cxf/systest/soapheader/HeaderClientServerTest.java
+++ b/systests/uncategorized/src/test/java/org/apache/cxf/systest/soapheader/HeaderClientServerTest.java
@@ -63,6 +63,7 @@ public class HeaderClientServerTest extends AbstractBusClientServerTestBase {
CallerIDHeaderType header = new CallerIDHeaderType();
header.setName(mao);
header.setPhoneNumber(108);
+header.setMustUnderstand(true);
OrderPizzaResponseType res = port.orderPizza(req, header);
diff --git a/systests/uncategorized/src/test/resources/wsdl_systest/pizza_service.wsdl b/systests/uncategorized/src/test/resources/wsdl_systest/pizza_service.wsdl
index b1465b8..cbaa9f2 100644
--- a/systests/uncategorized/src/test/resources/wsdl_systest/pizza_service.wsdl
+++ b/systests/uncategorized/src/test/resources/wsdl_systest/pizza_service.wsdl
@@ -22,6 +22,7 @@ under the License.
targetNamespace=http://cxf.apache.org/pizza;
xmlns:tns=http://cxf.apache.org/pizza;
xmlns:types=http://cxf.apache.org/pizza/types;
+ xmlns:env=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
@@ -32,6 +33,8 @@ under the License.
elementFormDefault=qualified
version=1.0
+xsd:import namespace=http://schemas.xmlsoap.org/soap/envelope/;
+schemaLocation=http://schemas.xmlsoap.org/soap/envelope/; /
xsd:element name=CallerIDHeader type=tns:CallerIDHeaderType /
xsd:complexType name=CallerIDHeaderType
@@ -39,6 +42,7 @@ under the License.
xsd:element name=Name type=xsd:string /
xsd:element name=PhoneNumber type=xsd:string /
/xsd:sequence
+ xsd:attribute ref=env:mustUnderstand /
/xsd:complexType
xsd:element name=OrderRequest type=tns:OrderPizzaType /
--
1.7.9.1
From 7af8c7e0efc6953958e091e5ce556fca55d90342 Mon Sep 17 00:00:00 2001
From: Guillaume Sauthier guillaume.sauth...@ow2.org
Date: Fri, 24 Feb 2012 10:52:14 +0100
Subject: [PATCH 2/2] Proposed fix (move the MU interceptor later in the
chain)
---
.../interceptor/MustUnderstandInterceptor.java |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/MustUnderstandInterceptor.java b/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/MustUnderstandInterceptor.java
index c981ded..0b04d8c 100644
--- a/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/MustUnderstandInterceptor.java
+++ b/rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Hi Christian
I'm happy to see that you're interested to discuss this contribution.
I don't know if/when you may take some time to compare the 2
implementations, but if we can help in any way, let us know.
For example, we could, from our POV, list the differences between the 2
transports, at least a first draft that you could review/enhance in order to
make up your mind.
Regards
--Guillaume
2011/7/8 Christian Schneider ch...@die-schneider.net
Yes request / response correlation is definately a place where we currently
loose message when the client goes down.
I think this is o big issue though as you typically only use request
response when you wait for the response. So normally you will even want the
responses to be lost when the client goes down. In the one way case we
should not loose messages as we can also use transactions.
Still your JMS transport my be interesting. When doing the refactoring to
spring jms templates and message listener I also thought about making the
transport more asynchronous but never really did it.
So I would like to compare your implementation with the current one in cxf.
I would not like to have both though. If your transport is more suitable we
should throw the other away. In any case we should only have one JMS
transport.
Christian
Am 08.07.2011 14:39, schrieb Florent BENOIT:
Hi,
One example about the reliable stuff is that we should include
recovery.
For example the correlation map used to match JMS replies is stored in
memory [1]
341 Exchange exchange = correlationMap.remove(**correlationId);
342 if (exchange == null) {
343 LOG.log(Level.WARNING, Could not correlate message with
correlationId + correlationId);
344 return;
345 }
So, if the JVM of the client is restarted, we will loose any replies as we
won't know how to match the reply.
Also, there is no JTA used with the current JMS transport. It means that
we can loose data or to get some messages twice or so one.
So even by using ActiveMQ with the messages being stored on the disk, this
won't work after a restart.
[1] :
http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
view=markuphttp://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup
Regards,
Florent
On 07/08/2011 02:25 PM, Benson Margulies wrote:
I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?
On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOITflorent.ben...@ow2.org
wrote:
Hi CXF guys,
I would like to introduce a new CXF transport that we've developed and
that
could be contributed back to the CXF community. It is called Reliable
JMS
transport
When this transport has been designed, the goal was to have a reliable
transport that we could called Enterprise Transport as we wanted to
use
transactions and JMS by using containers like Java EE EJB or Spring MDP
(we
support both). We don't want to loose any requests or answers and we
want to
avoid waiting threads. This transport has not been designed from scratch
as
it is using the JMS layer and share some classes with the current CXF
JMS
transport but there are some differences between them. But we couldn't
change the current transport as the design is not the same.
First, let me give you details about this transport and why it's
different
from the current JMS CXF transport.
The current CXF JMS transport is not reliable. For example, if you
restart a
client or a server you may loose some requests/answers. This is because
the
mechanism that is used is keeping data in memory. So after a JVM crash,
all
the data are lost.
Also, for this new transport, we wanted to guarantee the delivery so it
is
using transactions. (A transaction manager is then required).
As said before, we wanted to avoid the use of threads waiting for an
answer.
If there are 100 requests, we don't want 100 threads waiting their
answer.
This is because we can use either EJB MDB or Spring MDP to handle the
answer. In this way, resources are allocated only if an answer is
handled
and not during all the waiting time. So the number of threads is
dramatically reduced. Also by relying on EJB MDB or Spring MDP we're
based
on existing patterns.
Here is a link to the documentation of this transport and pictures that
are
illustrating this solution :
http://wiki.jonas.ow2.org/**xwiki/bin/view/Main/**
ReliableJMS_Transport_CXFhttp://wiki.jonas.ow2.org/xwiki/bin/view/Main/ReliableJMS_Transport_CXF
This illustrates how the
And the errors handling that is working with all kind of JVM crash :
http://wiki.jonas.ow2.org/**xwiki/bin/download/Main/**
ReliableJMS_Transport_CXF/cxf-**reliablejms-execution-flow-**
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
I'm sorry guys, I just noticed that we did give you an URL where you can
take/look the code :)
Here is the websvn URL:
http://websvn.ow2.org/listing.php?repname=jonaspath=%2Fsub-projects%2Fcxf-reliable-jms-transport%2F
And here the SVN URL:
svn://svn.forge.objectweb.org/svnroot/jonas/sub-projects/
cxf-reliable-jms-transport/trunk
As it was introduced in OW2 JOnAS and that our preferred license in LGPL,
all the current sources are in LGPL, but if the CXF community is interested
in this contribution, I foresee no issues of changing the license to ASL2.
Thanks for your comments
--G
2011/7/8 Guillaume Sauthier (Objectweb) guillaume.sauth...@objectweb.org
Hi
I've helped to do this new transport, so let me add my 2 cents ;)
If the message exchange pattern is one way, there is no problem as no one
expects an answer.
But that new transport support the request-response pattern.
That means that we have to manage reliabiilty of the call end to end, from
the client that initiates the call, to the code that process the answer,
through the endpoint.
If you look at the global picture:
http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-english.png
you'll notice that the client is split in 2 parts: the initiator (initiates
the call) and the handler (process the result).
We don't use the JAXWS AsyncHandler API because it is tightly coupled to
the execution context of the client initiator: maybe the handler has some
ref to live objects that we cannot persist and/or recreate if the initiator
JVM crashes.
In order to bypass this issue, we had to tweak the jaxws development model
a little bit:
* on initiator side, we use the normal (synchronous) generated API, but the
stub always returns null (as the call was synchronous, the answer is not
there yet)
* the initiator provides an AsynchHandler through the Spring application
context, this handler will be notified when a response will be posted on the
response queue. As this object is created from Spring beans, it is decoupled
from the initiator execution context and can be safely used.
* The request flow is quite normal: we define a jaxws:client on the
client side, a jaxws:endpoint on the server side
* But the response flow is different than what we could expect: the client
also defines a jaxws:endpoint that will be invoked when JMS messages will
be posted on the response queue.
As everything is transactional, we have dead message queues, so that we
never lost any messages.
Hope that helps to understand this potential contribution.
Thanks
--Guillaume
2011/7/8 Christian Schneider ch...@die-schneider.net
Yes request / response correlation is definately a place where we
currently loose message when the client goes down.
I think this is o big issue though as you typically only use request
response when you wait for the response. So normally you will even want the
responses to be lost when the client goes down. In the one way case we
should not loose messages as we can also use transactions.
Still your JMS transport my be interesting. When doing the refactoring to
spring jms templates and message listener I also thought about making the
transport more asynchronous but never really did it.
So I would like to compare your implementation with the current one in
cxf.
I would not like to have both though. If your transport is more suitable
we should throw the other away. In any case we should only have one JMS
transport.
Christian
Am 08.07.2011 14:39, schrieb Florent BENOIT:
Hi,
One example about the reliable stuff is that we should include
recovery.
For example the correlation map used to match JMS replies is stored in
memory [1]
341 Exchange exchange = correlationMap.remove(**correlationId);
342 if (exchange == null) {
343 LOG.log(Level.WARNING, Could not correlate message with
correlationId + correlationId);
344 return;
345 }
So, if the JVM of the client is restarted, we will loose any replies as
we won't know how to match the reply.
Also, there is no JTA used with the current JMS transport. It means that
we can loose data or to get some messages twice or so one.
So even by using ActiveMQ with the messages being stored on the disk,
this won't work after a restart.
[1] :
http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
view=markuphttp://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup
Regards,
Florent
On 07/08/2011 02:25 PM, Benson Margulies wrote:
I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?
On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOITflorent.ben...@ow2.org
wrote:
Hi CXF guys,
I would like to introduce a new CXF transport that we've developed
Re: [DISCUSSION] Introducing a new Reliable JMS CXF Transport
Hi
I've helped to do this new transport, so let me add my 2 cents ;)
If the message exchange pattern is one way, there is no problem as no one
expects an answer.
But that new transport support the request-response pattern.
That means that we have to manage reliabiilty of the call end to end, from
the client that initiates the call, to the code that process the answer,
through the endpoint.
If you look at the global picture:
http://wiki.jonas.ow2.org/xwiki/bin/download/Main/ReliableJMS_Transport_CXF/cxf-reliablejms-execution-flow-simple-english.png
you'll notice that the client is split in 2 parts: the initiator (initiates
the call) and the handler (process the result).
We don't use the JAXWS AsyncHandler API because it is tightly coupled to the
execution context of the client initiator: maybe the handler has some ref to
live objects that we cannot persist and/or recreate if the initiator JVM
crashes.
In order to bypass this issue, we had to tweak the jaxws development model a
little bit:
* on initiator side, we use the normal (synchronous) generated API, but the
stub always returns null (as the call was synchronous, the answer is not
there yet)
* the initiator provides an AsynchHandler through the Spring application
context, this handler will be notified when a response will be posted on the
response queue. As this object is created from Spring beans, it is decoupled
from the initiator execution context and can be safely used.
* The request flow is quite normal: we define a jaxws:client on the client
side, a jaxws:endpoint on the server side
* But the response flow is different than what we could expect: the client
also defines a jaxws:endpoint that will be invoked when JMS messages will
be posted on the response queue.
As everything is transactional, we have dead message queues, so that we
never lost any messages.
Hope that helps to understand this potential contribution.
Thanks
--Guillaume
2011/7/8 Christian Schneider ch...@die-schneider.net
Yes request / response correlation is definately a place where we currently
loose message when the client goes down.
I think this is o big issue though as you typically only use request
response when you wait for the response. So normally you will even want the
responses to be lost when the client goes down. In the one way case we
should not loose messages as we can also use transactions.
Still your JMS transport my be interesting. When doing the refactoring to
spring jms templates and message listener I also thought about making the
transport more asynchronous but never really did it.
So I would like to compare your implementation with the current one in cxf.
I would not like to have both though. If your transport is more suitable we
should throw the other away. In any case we should only have one JMS
transport.
Christian
Am 08.07.2011 14:39, schrieb Florent BENOIT:
Hi,
One example about the reliable stuff is that we should include
recovery.
For example the correlation map used to match JMS replies is stored in
memory [1]
341 Exchange exchange = correlationMap.remove(**correlationId);
342 if (exchange == null) {
343 LOG.log(Level.WARNING, Could not correlate message with
correlationId + correlationId);
344 return;
345 }
So, if the JVM of the client is restarted, we will loose any replies as we
won't know how to match the reply.
Also, there is no JTA used with the current JMS transport. It means that
we can loose data or to get some messages twice or so one.
So even by using ActiveMQ with the messages being stored on the disk, this
won't work after a restart.
[1] :
http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/jms/**
src/main/java/org/apache/cxf/**transport/jms/JMSConduit.java?**
view=markuphttp://svn.apache.org/viewvc/cxf/trunk/rt/transports/jms/src/main/java/org/apache/cxf/transport/jms/JMSConduit.java?view=markup
Regards,
Florent
On 07/08/2011 02:25 PM, Benson Margulies wrote:
I'm confused. If you use AMQ configured for reliable storage on disk,
how do you lose things with the existing CXF transport?
On Fri, Jul 8, 2011 at 8:23 AM, Florent BENOITflorent.ben...@ow2.org
wrote:
Hi CXF guys,
I would like to introduce a new CXF transport that we've developed and
that
could be contributed back to the CXF community. It is called Reliable
JMS
transport
When this transport has been designed, the goal was to have a reliable
transport that we could called Enterprise Transport as we wanted to
use
transactions and JMS by using containers like Java EE EJB or Spring MDP
(we
support both). We don't want to loose any requests or answers and we
want to
avoid waiting threads. This transport has not been designed from scratch
as
it is using the JMS layer and share some classes with the current CXF
JMS
transport but there are some differences between them. But we couldn't
change the current transport as the design is not the same.
First, let me give
Re: Fwd: GSoC: Integrate CXF JAX-RS with EJB
Hi I don't know if this help but we have the same kind of glue in OW2 JOnAS where we integrate JAXWS/CXF with our EJB3 container (EasyBeans). Here is the package content: http://websvn.ow2.org/listing.php?repname=jonaspath=%2Fjonas%2Ftrunk%2Fjonas%2Fmodules%2Fservices%2Fwebservices%2Fcxf%2Fsrc%2Fmain%2Fjava%2Forg%2Fow2%2Fjonas%2Fws%2Fcxf%2Feasybeans%2F And more particularily the InvokerFactory http://websvn.ow2.org/filedetails.php?repname=jonaspath=%2Fjonas%2Ftrunk%2Fjonas%2Fmodules%2Fservices%2Fwebservices%2Fcxf%2Fsrc%2Fmain%2Fjava%2Forg%2Fow2%2Fjonas%2Fws%2Fcxf%2Feasybeans%2FEasyBeansInvokerFactory.java Having a Factory concept was absolutely required because of the pool used in EJBs (get and release instances). and the Invoker if a really simple extension of the JAXWS default Invoker. Nothing very complicated. Cheers --G Le 08/04/2011 14:34, Sergey Beryozkin a écrit : Forwarding to the dev list... Do we actually have an EJB JAX-WS invoker on the trunk ? Ryan can definitely play with the JBossWS distribution, in order to get the idea of how the CXF EJBInvoker can be done, but I guess he does not even need to it, it is probably can be regarded as a general FAQ ? thanks, Sergey Please checkout the CXF 2.4.0-SNAPSHOT trunk, do 'mvn install -Pfastinstall' 'mvn -Psetup.eclipse' then import the projects from the trunk. cxf-rt-frontend-jaxrs is the module containing the JAX-RS impl. Go to systests/jaxrs and debug one of the system tests, ex, JAXRSClientServerBookTest (), update launchServer(BookServer.class) to launchServer(BookServer.class, true) and run one of the tests in the debug mode. Set breakpoints in JAXRSInInterceptor and JAXRSInvoker and see how things work. So one of the tasks is to get a better understanding of how CXF JAX-RS is implemented. Check CXF JAX-RS docs. Next: download an EJB3 app server, JBoss 6.0 Community Edition or GlassFish. With JBoss you can actually try their CXF EJBInvoker and see how EJBs are exposed as SOAP WebServices and invoked upon; the task is understand how a custom CXF EJB invoker can be created, creating a CXF JAX-RS invoker is the next stage, most likely it will be identical to the JAX-WS one. Next: try this CXF JAX-RS invoker in practice by doing a simple demo/etc
Re: CXF and HTTP proxy properties
(re-sending to the list this time) Thanks for the tips Dan. I've attached patches to the original issue: https://issues.apache.org/jira/browse/CXF-2839 It's for the 2.2.x branch (Sorry that was my primary target). As per the last comment, I was wondering what was the best option to contribute things to CXF when using git ? There is a git mirror of CXF in github, so we could fork that repository and you could see the progress directly (no more patches exchanges)... Do you have any prior experience ? Thanks --G Le 18/10/2010 18:47, Daniel Kulp a écrit : On Monday 18 October 2010 7:57:50 am Guillaume Sauthier wrote: OK, I need a little help on this. I'm trying to imlpement the new HTTPClientPolicy NonProxyHosts attributes. Ideally, I would like to directly have in the bean a Pattern so that it's only initiallized once at parsing time. How to deal with that in JAXB ? It's simple to add a String attribute in the schema resulting in a new property in the generated bean, but how can I convert it into a regular Pattern ? Some ideas ? You'll probably need a jaxb binding file for the http-conf.xsd. Not a huge deal. It would need to do two thing: 1) For this element, it would need to set the java class to Pattern (or whatever) 2) Provide parse and print methods. (which would have to be added to a utility class in HTTP component someplace. Here is an example for a Calendar thing: jxb:bindings schemaLocation=hello_schema2.xsd node=/xs:schema jxb:globalBindings xmlns:jxb=http://java.sun.com/xml/ns/jaxb; xmlns:xs=http://www.w3.org/2001/XMLSchema; jxb:javaType name=java.util.Calendar xmlType=xs:dateTime parseMethod=javax.xml.bind.DatatypeConverter.parseDateTime printMethod=javax.xml.bind.DatatypeConverter.printDateTime/ /jxb:globalBindings /jxb:bindings However, that sets it on a global level which isn't what you'd want. You would need to xpath it into the right element and set it that way.
Re: CXF and HTTP proxy properties
OK Let's go for it :) --G Le 15/10/2010 17:33, Daniel Kulp a écrit : On Friday 15 October 2010 3:53:54 am Guillaume Sauthier wrote: So, I come here to discuss this point. Could it be possible (currently I'm not sure, but maybe as an evolution) to provide the proxy configuration as some kind of global variable for all the services (maybe as a per-bus configuration), but with support for nonProxyHost (or the like) ? WDYT ? I think this could be done via an interceptor as well. An interceptor run very early in the chain could grab the conduit and reconfigure the proxy stuff fairly easily based on the URL it's going to hit. The other way to handle this, which is how JBoss does this I believe, is to set their own Configurer on the bus that wrappers the original one and has configureBean methods that, if the bean is an HTTPConduit, completely configures the conduit based on information from the app servers configs. Really, that is the ideal way for app servers and containers and such to configure the various parts of CXF as CXF uses that mechanism to configure itself. OK I get your point. But how this solution (not interceptor based) can handle the issue of the client changing the endpoint address after it has retrieved the port proxy ? After reading the code, it seems that the real URL is finally known during HTTPConduit.prepare(Message) (more precisely in HTTPConduit.setupUrl() ), so using an Interceptor will probably not help :'( Then the URL is passed to an HttpConnectionFactory along with a Proxy instance (created from the proxy information in the Conduit's config) After some more thinking I think my solution will be something like: * Configure the HTTPConduit using the Configurer extension to propagate the System HTTP proxy properties Yep, although ideally, HTTPConduit would call client.isSetProxyServer() and if false, use the system properties. Then nothing to configure. A patch for that would be more than welcome. :-) * Provides a new HttpUrlConnectionFactory that will act as a proxy and nullify the Proxy reference (given as param) if the URL endpoint is one of the hosts filtered by http.nonProxyHosts before delegating to the real HttpUrlConnectionFactory I really wouldn't go there. If you look at what I'm doing on the branch for async work, the HttpUrlConnectionFactory isn't used for that since the http- client stuff doesn't use the HttpURLConnection object. Actually, an interceptor CAN configure an HTTPClientPolicy. I can do something like: HTTPClientPolicy pol = new HTTPClientPolicy(); pol.setABunchOf Things(); message.put(HTTPClientPolicy.class, pol) and the HTTPConduit will intersect that with the one it has to create an effective HTTPClientPolicy that is used. Thus, you can set a proxy from an interceptor that way and not really modify the CXF code at all. HOWEVER, my suggestion would be to: 1) Add a nonProxyHosts element to the HTTPClientPolicy so it can be configured. 2) Update the getProxy(..) call in HTTPConduit to take the URL as a param and have it call the isSet things and such to do the logic. Use the sysprops if unset. Then attach the above to a JIRA as a patch and we'll get it committed real soon. :-) Dan // Theses 2 first points could be contributed back directly to CXF * Indeed, for JOnAS I'll have to intercept the HTTPConduit creation with my own HTTPConduit subclass that will return my own HttpUrlConnectionFactory. // This last part could be introduced directly into CXF HTTPConduit if you're ok with this (directly using the FilteringNonProxyHostsHttpUrlConnectionFactory - quite long name BTW :) ) WDYT ? --G
Re: CXF and HTTP proxy properties
Le 13/10/2010 23:21, Daniel Kulp a écrit : On Wednesday 13 October 2010 9:34:27 am Guillaume Sauthier wrote: Hi team I've found plenty of examples over the internet explaining how to setup an HTTP proxy (using Spring or the API). This is always done on a per-service basis. I was wondering why the http.proxy* System properties were not used for supporting this ? This is: https://issues.apache.org/jira/browse/CXF-2839 Oops missed that issue ... So, I come here to discuss this point. Could it be possible (currently I'm not sure, but maybe as an evolution) to provide the proxy configuration as some kind of global variable for all the services (maybe as a per-bus configuration), but with support for nonProxyHost (or the like) ? WDYT ? I think this could be done via an interceptor as well. An interceptor run very early in the chain could grab the conduit and reconfigure the proxy stuff fairly easily based on the URL it's going to hit. The other way to handle this, which is how JBoss does this I believe, is to set their own Configurer on the bus that wrappers the original one and has configureBean methods that, if the bean is an HTTPConduit, completely configures the conduit based on information from the app servers configs. Really, that is the ideal way for app servers and containers and such to configure the various parts of CXF as CXF uses that mechanism to configure itself. OK I get your point. But how this solution (not interceptor based) can handle the issue of the client changing the endpoint address after it has retrieved the port proxy ? After reading the code, it seems that the real URL is finally known during HTTPConduit.prepare(Message) (more precisely in HTTPConduit.setupUrl() ), so using an Interceptor will probably not help :'( Then the URL is passed to an HttpConnectionFactory along with a Proxy instance (created from the proxy information in the Conduit's config) After some more thinking I think my solution will be something like: * Configure the HTTPConduit using the Configurer extension to propagate the System HTTP proxy properties * Provides a new HttpUrlConnectionFactory that will act as a proxy and nullify the Proxy reference (given as param) if the URL endpoint is one of the hosts filtered by http.nonProxyHosts before delegating to the real HttpUrlConnectionFactory // Theses 2 first points could be contributed back directly to CXF * Indeed, for JOnAS I'll have to intercept the HTTPConduit creation with my own HTTPConduit subclass that will return my own HttpUrlConnectionFactory. // This last part could be introduced directly into CXF HTTPConduit if you're ok with this (directly using the FilteringNonProxyHostsHttpUrlConnectionFactory - quite long name BTW :) ) WDYT ? --G
CXF and HTTP proxy properties
Hi team I've found plenty of examples over the internet explaining how to setup an HTTP proxy (using Spring or the API). This is always done on a per-service basis. I was wondering why the http.proxy* System properties were not used for supporting this ? In my use case (the JOnAS application server), I have fileds annotated with @WebServiceRef (plus some standard XML descriptors). The job of the AS is to prepare the instances (port or services) that will be injected into theses fields. I was thinking that I could configure the CXF Client object in this phase. I was hoping that I could take the proxy System properties, extract required values from them and apply them on an HTTPClientPolicy for the HTTPConduit (no Spring Configuration here, remember the Java EE saint graal of portability between different providers), but I found that I may be blindly configuring a port to use the system proxy without knowing if the real endpoint address required a proxy or not. For example, imagine an environment were system proxy is required and configured to access external world, but the user wants to use a WS on localhost: if I configure it to use the proxy, it will fail during the call. I thought to use the nonProxyHost system property to conditionally apply the proxy config but my use case required me to apply the config at the very last moment (when we know the exact endpoint URL), requiring me to wrap and proxy a lot of CXF classes. Definitely not an ideal solution :) Or maybe I could implement this directly inside CXF... So, I come here to discuss this point. Could it be possible (currently I'm not sure, but maybe as an evolution) to provide the proxy configuration as some kind of global variable for all the services (maybe as a per-bus configuration), but with support for nonProxyHost (or the like) ? WDYT ? Thanks --Guillaume
Re: [VOTE] Release CXF 2.0.7
+1 2.0.7 fix the bug CXF-1642 :) --G Daniel Kulp wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a vote to release CXF 2.0.7 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.0.7 release. Over 48 JIRA issues are resolved for 2.0.7 which is a large number of fixes for the 2.0.x branch. The staging area is at: http://people.apache.org/~dkulp/stage_cxf/2.0.7 The distributions are in the dist directory. The maven directory contains the stuff that will by pushed to the central repository. This release is tagged at: http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.7 Here is my +1. The vote will be open here for at least 72 hours. - --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (Darwin) iD8DBQFIV83Qq8juObtVB0YRAk9IAJ94zSGaE98mw4z2UOdcCeX8HzAntACfb4Zv Px3oDUHzRTC53LDAs2yxIz8= =fif0 -END PGP SIGNATURE-
