Programmatic CXF Endpoint

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Programmatic CXF Endpoint

jjathman
We are trying to use the CXF component to send web services requests were the endpoint we will send to is not known ahead of time. Since we are not able to configure these endpoints we are trying to create these endpoints dynamically. I suppose my first question is whether or not this is the correct way to solve this problem. Should we create a new CXFEndpoint object each time we are sending to a new remote server?

For example, when we receive an incoming message, we will then need to create 1 to many outgoing messages that we will not know the endpoint of until runtime.

Second question is how to enable SSL support on these programmatically created endpoints. I've tried the normal HTTP Conduit configuration but that doesn't seem to be used when the endpoint is created programmatically. Is that true or do I have something configured incorrectly?

I realize this is pretty complicated, if there's anything I can do to help clarify this, please let me know. Thank you so much!
Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

Willem.Jiang
Administrator
For the first question, you could override the service address by setting header like this

.setHeader(Exchange.DESTINATION_OVERRIDE_URL, constant(getServiceAddress()))


For the second question as CxfEndpoint doesn’t provide the access of Client, you cannot setup conduit there. But I think you can extends the CXFEndpoint to override the createClient() method and setup the conduit there.


--  
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem



On September 12, 2014 at 5:45:53 AM, jjathman ([hidden email]) wrote:

> We are trying to use the CXF component to send web services requests were the
> endpoint we will send to is not known ahead of time. Since we are not able
> to configure these endpoints we are trying to create these endpoints
> dynamically. I suppose my first question is whether or not this is the
> correct way to solve this problem. Should we create a new CXFEndpoint object
> each time we are sending to a new remote server?
>  
> For example, when we receive an incoming message, we will then need to
> create 1 to many outgoing messages that we will not know the endpoint of
> until runtime.
>  
> Second question is how to enable SSL support on these programmatically
> created endpoints. I've tried the normal HTTP Conduit configuration but that
> doesn't seem to be used when the endpoint is created programmatically. Is
> that true or do I have something configured incorrectly?
>  
> I realize this is pretty complicated, if there's anything I can do to help
> clarify this, please let me know. Thank you so much!
>  
>  
>  
> --
> View this message in context: http://camel.465427.n5.nabble.com/Programmatic-CXF-Endpoint-tp5756368.html 
> Sent from the Camel - Users mailing list archive at Nabble.com.
>  

Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

jjathman
Thanks for the help, I will have to check out using the header override. Thank you!

I found that the real problem I was having with the conduits is that it doesn't seem like Camel is respecting the *.http-conduit wildcard pattern for outgoing CXF connections. When I replace that wildcard with the specific names of the conduits then it does work how I would expect. For whatever reason, if the name is a wildcard the conduit isn't used. This seems like a bug to me.
Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

Willem.Jiang
Administrator
The wildcard conduit setting should work.
You can find an example here[1][2].

BTW, I fill a JIRA[3] for setting the conduit in a programmatic way.

[1]https://github.com/apache/camel/blob/master/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfTimeoutTest.java
[2]https://github.com/apache/camel/blob/master/components/camel-cxf/src/test/resources/org/apache/camel/component/cxf/cxfConduitTimeOutContext.xml
[3]https://issues.apache.org/jira/browse/CAMEL-7845

--  
Willem Jiang

Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem



On September 24, 2014 at 3:13:03 AM, jjathman ([hidden email]) wrote:

> Thanks for the help, I will have to check out using the header override.
> Thank you!
>  
> I found that the real problem I was having with the conduits is that it
> doesn't seem like Camel is respecting the *.http-conduit wildcard pattern
> for outgoing CXF connections. When I replace that wildcard with the specific
> names of the conduits then it does work how I would expect. For whatever
> reason, if the name is a wildcard the conduit isn't used. This seems like a
> bug to me.
>  
>  
>  
> --
> View this message in context: http://camel.465427.n5.nabble.com/Programmatic-CXF-Endpoint-tp5756368p5756914.html 
> Sent from the Camel - Users mailing list archive at Nabble.com.
>  

Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

sloanecourt
This post was updated on .
Thanks very much for implementing this change, very simple to use.

The only problem I have at the moment is configuring the SSL support in the Client. Coding is not the main issue, as this is discussed on several threads, what I'm looking for is a way of utilising the mechanism Camel uses internally, when not using CxfEndPointConfigurer to establish the SSL configuration.    

Regards
Anthony Dodd
Fundtech Financial Messaging

Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

Willem.Jiang
Administrator
Yeah, there is a gap between the Camel SSL setting and CXF SSL setting, that is why we introduced the CxfEndpointConfigurer to fill this gap. Current Camel SSL Support is per the camel context , we may need to introduce a option into CXFEndpoint to let it know how to create the SSLContext from Camel SSL setting.

I just fill a JIRA[1] for it.

[1]https://issues.apache.org/jira/browse/CAMEL-9046

--  
Willem Jiang


Blog: http://willemjiang.blogspot.com (English)  
http://jnn.iteye.com (Chinese)
Twitter: willemjiang  
Weibo: 姜宁willem



On August 2, 2015 at 4:46:43 PM, sloanecourt ([hidden email]) wrote:

> Thanks very much for implementing this change, very simple to use.
>  
> The only problem I have at the moment is configuring the SSL support in the
> Client. Coding is not the main issue, as this is discussed on several
> threads, what I'm looking for is a way of utilising the mechanism Camel uses
> internally, when not using CxfEndPointConfigurer to establish the SSL
> configuration.
>  
>  
>  
>  
> --
> View this message in context: http://camel.465427.n5.nabble.com/Programmatic-CXF-Endpoint-tp5756368p5770215.html 
> Sent from the Camel - Users mailing list archive at Nabble.com.
>  

Reply | Threaded
Open this post in threaded view
|

Re: Programmatic CXF Endpoint

sloanecourt
I found that the 3 lines of code following "TLS Parameters" resolved the SSL/TLS issue.

  @Override
  public void configureClient(Client client) {

        // Policy
        HTTPConduit conduit = (HTTPConduit) client.getConduit();
        HTTPClientPolicy policy = conduit.getClient();
        if (policy == null) {
          policy = new HTTPClientPolicy();
          conduit.setClient(policy);
        }

        // Policy
        policy.setConnectionTimeout(10000L);
        policy.setReceiveTimeout(10000L);

        // TLS Parameters
        TLSClientParameters tlsClientParameters = new TLSClientParameters();
        tlsClientParameters.setUseHttpsURLConnectionDefaultSslSocketFactory(true);
        conduit.setTlsClientParameters(tlsClientParameters);

      }
    }

  }

Regards
Anthony Dodd
Fundtech Financial Messaging