You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Scott Christopher <SC...@internode.com.au> on 2010/09/30 13:33:51 UTC
publishedEndpointUrl for cxf:cxfEndpoint
We're using a CXF consuming endpoint, which is listening on a private host behind a firewall / load balancer. As a result, the URL that CXF generates in the WSDL does not reflect the URL that external clients need to use to connect to the service.
I've noticed that it is possible to override the generated URL by setting the publishedEndpointUrl attribute of a <jaxws:endpoint/> bean. Is there a similar option when using a <cxf:cxfEndpoint/> bean instead?
Regards,
Scott Christopher.
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
From the stack trace I can tell is you are using the cxf-http-jetty
transport instead of servlet transport.
Can you double check your beans.xml to make sure you include the
servlet.xml spring configuration like this?
<import resource="classpath:META-INF/cxf/cxf-servlet.xml"/>
On 5/4/11 2:50 AM, gsilverman wrote:
> I don't believe this is correct, simply to change the address in the
> cxfEndpoint. I have a similar firewall problem and need to expose a
> camel-cxf endpoint running behind a firewall. My endpoint is defined as
> follows:
>
>
>
> But a client needs to access this from the outside, as
> https://someURL:4443/ProcessPrescriptionOrder. Putting this URL in the
> address attribute of cxfEndpoint fails to start with the following error
> (I'm running this in jetty:
>
> Failed startup of context
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@15131513{/pharmacyLink,/home/jboss-5.1.0.GA/source/camel-integration/pharmacyLink/src/main/webapp}
> org.apache.camel.RuntimeCamelException: org.apache.cxf.interceptor.Fault:
> Could not start Jetty server on port 4,443: Cannot assign requested address
> at
> org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1139)
> at
> org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:103)
> at
> org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:237)
> at
> org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:97)
> at
> org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
> at
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:911)
> at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:428)
> at
> org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
> at
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
> at
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
> at
> org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
> at
> org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
> at
> org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
> at
> org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
> at
> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at
> org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)
> at
> org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)
> at
> org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
> at
> org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:599)
> at
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> 2011-05-03 11:43:46.623:INFO::Started SelectChannelConnector@0.0.0.0:8085
> [INFO] Started Jetty Server
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/publishedEndpointUrl-for-cxf-cxfEndpoint-tp3046858p4368044.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by gsilverman <gs...@dispensingsolutionsinc.com>.
I don't believe this is correct, simply to change the address in the
cxfEndpoint. I have a similar firewall problem and need to expose a
camel-cxf endpoint running behind a firewall. My endpoint is defined as
follows:
But a client needs to access this from the outside, as
https://someURL:4443/ProcessPrescriptionOrder. Putting this URL in the
address attribute of cxfEndpoint fails to start with the following error
(I'm running this in jetty:
Failed startup of context
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@15131513{/pharmacyLink,/home/jboss-5.1.0.GA/source/camel-integration/pharmacyLink/src/main/webapp}
org.apache.camel.RuntimeCamelException: org.apache.cxf.interceptor.Fault:
Could not start Jetty server on port 4,443: Cannot assign requested address
at
org.apache.camel.util.ObjectHelper.wrapRuntimeCamelException(ObjectHelper.java:1139)
at
org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:103)
at
org.apache.camel.spring.CamelContextFactoryBean.onApplicationEvent(CamelContextFactoryBean.java:237)
at
org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:97)
at
org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:303)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:911)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:428)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:276)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:197)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
at
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:454)
at
org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:396)
at
org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210)
at
org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
2011-05-03 11:43:46.623:INFO::Started SelectChannelConnector@0.0.0.0:8085
[INFO] Started Jetty Server
--
View this message in context: http://camel.465427.n5.nabble.com/publishedEndpointUrl-for-cxf-cxfEndpoint-tp3046858p4368044.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Scott Christopher <SC...@internode.com.au>.
Hi Willem,
I just tested 2.5-SNAPSHOT on the CXF Jetty and OSGi transports with the inclusion of the publishedEndpointUrl property. All worked as expected.
Thanks for your efforts on this!
Regards,
Scott Christopher.
On 10/10/2010, at 2:38 PM, Willem Jiang wrote:
> Hi Scott,
>
> I committed a patch of the CAMEL-3190 few days ago, can you try the
> latest Camel 2.5-SNAPSHOT to verify the fix?
>
> BTW, you can only set the putlishedEndpointUrl option from URI or the
> properties element of the CxfEndpoint like this.
>
> <cxf:cxfEndpoint id="routerEndpoint"
> address="http://localhost:9003/CamelContext/RouterPort"
> serviceClass="org.apache.hello_world_soap_http.Greeter"
> endpointName="s:SoapPort"
> serviceName="s:SOAPService"
> xmlns:s="http://apache.org/hello_world_soap_http">
> <cxf:properties>
> <entry key="publishedEndpointUrl"
> value="http://www.simple.com/services/test" />
> </cxf:properties>
>
> </cxf:cxfEndpoint>
>
>
> On 10/4/10 5:58 PM, Scott Christopher wrote:
>> Thanks Willem.
>>
>> On 02/10/2010, at 10:47 PM, Willem Jiang wrote:
>>
>>> Hi Scott,
>>>
>>> I just checked the schema of cxfEndpoint, it doesn't support the
>>> publishedEndpointUrl.
>>> I filled a JIRA[1] for it.
>>>
>>> [1]https://issues.apache.org/activemq/browse/CAMEL-3190
>>>
>>> On 10/2/10 8:33 PM, Scott Christopher wrote:
>>>> On 02/10/2010, at 9:05 PM, Willem Jiang wrote:
>>>>
>>>>> On 10/2/10 1:33 PM, Scott Christopher wrote:
>>>>>> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>>>>>>
>>>>>>> Not sure why setting the address attribute in the spring.xml file does not
>>>>>>> change the address for you since that is the value that overrides the WSDL
>>>>>>> address... I know that it works!!!
>>>>>>
>>>>>> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
>>>>> The publishedEndpointUrl is just used to reset the Address information
>>>>> from the WSDL, it have nothing to do with the address that the service
>>>>> will be bound to.
>>>>
>>>>
>>>> This is exactly what I'm trying to achieve, and as per my original question, is it possible to use with a cxfEndpoint bean? Adding the publishedEndpointUrl attribute to the cxfEndpoint bean results in "Attribute 'publishedEndpointUrl' is not allowed to appear in element 'cxf:cxfEndpoint'."
>>>>
>>>> It would be great if I could do something like:
>>>>
>>>> <cxf:cxfEndpoint id="endpoint"
>>>> address="http://0.0.0.0:8000/service"
>>>> publishedEndpointUrl="https://www.example.com/service"
>>>> serviceClass="com.example.CxfTest" />
>>>>
>>>> Regards,
>>>> Scott Christopher
>>>
>>>
>>> --
>>> Willem
>>> ----------------------------------
>>> Open Source Integration: http://www.fusesource.com
>>> Blog: http://willemjiang.blogspot.com (English)
>>> http://jnn.javaeye.com (Chinese)
>>> Twitter: http://twitter.com/willemjiang
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Willem Jiang <wi...@gmail.com>.
Hi Scott,
I committed a patch of the CAMEL-3190 few days ago, can you try the
latest Camel 2.5-SNAPSHOT to verify the fix?
BTW, you can only set the putlishedEndpointUrl option from URI or the
properties element of the CxfEndpoint like this.
<cxf:cxfEndpoint id="routerEndpoint"
address="http://localhost:9003/CamelContext/RouterPort"
serviceClass="org.apache.hello_world_soap_http.Greeter"
endpointName="s:SoapPort"
serviceName="s:SOAPService"
xmlns:s="http://apache.org/hello_world_soap_http">
<cxf:properties>
<entry key="publishedEndpointUrl"
value="http://www.simple.com/services/test" />
</cxf:properties>
</cxf:cxfEndpoint>
On 10/4/10 5:58 PM, Scott Christopher wrote:
> Thanks Willem.
>
> On 02/10/2010, at 10:47 PM, Willem Jiang wrote:
>
>> Hi Scott,
>>
>> I just checked the schema of cxfEndpoint, it doesn't support the
>> publishedEndpointUrl.
>> I filled a JIRA[1] for it.
>>
>> [1]https://issues.apache.org/activemq/browse/CAMEL-3190
>>
>> On 10/2/10 8:33 PM, Scott Christopher wrote:
>>> On 02/10/2010, at 9:05 PM, Willem Jiang wrote:
>>>
>>>> On 10/2/10 1:33 PM, Scott Christopher wrote:
>>>>> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>>>>>
>>>>>> Not sure why setting the address attribute in the spring.xml file does not
>>>>>> change the address for you since that is the value that overrides the WSDL
>>>>>> address... I know that it works!!!
>>>>>
>>>>> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
>>>> The publishedEndpointUrl is just used to reset the Address information
>>>> from the WSDL, it have nothing to do with the address that the service
>>>> will be bound to.
>>>
>>>
>>> This is exactly what I'm trying to achieve, and as per my original question, is it possible to use with a cxfEndpoint bean? Adding the publishedEndpointUrl attribute to the cxfEndpoint bean results in "Attribute 'publishedEndpointUrl' is not allowed to appear in element 'cxf:cxfEndpoint'."
>>>
>>> It would be great if I could do something like:
>>>
>>> <cxf:cxfEndpoint id="endpoint"
>>> address="http://0.0.0.0:8000/service"
>>> publishedEndpointUrl="https://www.example.com/service"
>>> serviceClass="com.example.CxfTest" />
>>>
>>> Regards,
>>> Scott Christopher
>>
>>
>> --
>> Willem
>> ----------------------------------
>> Open Source Integration: http://www.fusesource.com
>> Blog: http://willemjiang.blogspot.com (English)
>> http://jnn.javaeye.com (Chinese)
>> Twitter: http://twitter.com/willemjiang
>
> Scott Christopher
> Analyst Programmer, Software Engineering
>
> [ Direct ] +61 8 82282529 schristopher@internode.com.au
> [ Internode ] +61 13 6633 150 Grenfell St, Adelaide, SA 5000
>
>
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Scott Christopher <SC...@internode.com.au>.
Thanks Willem.
On 02/10/2010, at 10:47 PM, Willem Jiang wrote:
> Hi Scott,
>
> I just checked the schema of cxfEndpoint, it doesn't support the
> publishedEndpointUrl.
> I filled a JIRA[1] for it.
>
> [1]https://issues.apache.org/activemq/browse/CAMEL-3190
>
> On 10/2/10 8:33 PM, Scott Christopher wrote:
>> On 02/10/2010, at 9:05 PM, Willem Jiang wrote:
>>
>>> On 10/2/10 1:33 PM, Scott Christopher wrote:
>>>> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>>>>
>>>>> Not sure why setting the address attribute in the spring.xml file does not
>>>>> change the address for you since that is the value that overrides the WSDL
>>>>> address... I know that it works!!!
>>>>
>>>> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
>>> The publishedEndpointUrl is just used to reset the Address information
>>> from the WSDL, it have nothing to do with the address that the service
>>> will be bound to.
>>
>>
>> This is exactly what I'm trying to achieve, and as per my original question, is it possible to use with a cxfEndpoint bean? Adding the publishedEndpointUrl attribute to the cxfEndpoint bean results in "Attribute 'publishedEndpointUrl' is not allowed to appear in element 'cxf:cxfEndpoint'."
>>
>> It would be great if I could do something like:
>>
>> <cxf:cxfEndpoint id="endpoint"
>> address="http://0.0.0.0:8000/service"
>> publishedEndpointUrl="https://www.example.com/service"
>> serviceClass="com.example.CxfTest" />
>>
>> Regards,
>> Scott Christopher
>
>
> --
> Willem
> ----------------------------------
> Open Source Integration: http://www.fusesource.com
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.javaeye.com (Chinese)
> Twitter: http://twitter.com/willemjiang
Scott Christopher
Analyst Programmer, Software Engineering
[ Direct ] +61 8 82282529 schristopher@internode.com.au
[ Internode ] +61 13 6633 150 Grenfell St, Adelaide, SA 5000
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Willem Jiang <wi...@gmail.com>.
Hi Scott,
I just checked the schema of cxfEndpoint, it doesn't support the
publishedEndpointUrl.
I filled a JIRA[1] for it.
[1]https://issues.apache.org/activemq/browse/CAMEL-3190
On 10/2/10 8:33 PM, Scott Christopher wrote:
> On 02/10/2010, at 9:05 PM, Willem Jiang wrote:
>
>> On 10/2/10 1:33 PM, Scott Christopher wrote:
>>> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>>>
>>>> Not sure why setting the address attribute in the spring.xml file does not
>>>> change the address for you since that is the value that overrides the WSDL
>>>> address... I know that it works!!!
>>>
>>> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
>> The publishedEndpointUrl is just used to reset the Address information
>> from the WSDL, it have nothing to do with the address that the service
>> will be bound to.
>
>
> This is exactly what I'm trying to achieve, and as per my original question, is it possible to use with a cxfEndpoint bean? Adding the publishedEndpointUrl attribute to the cxfEndpoint bean results in "Attribute 'publishedEndpointUrl' is not allowed to appear in element 'cxf:cxfEndpoint'."
>
> It would be great if I could do something like:
>
> <cxf:cxfEndpoint id="endpoint"
> address="http://0.0.0.0:8000/service"
> publishedEndpointUrl="https://www.example.com/service"
> serviceClass="com.example.CxfTest" />
>
> Regards,
> Scott Christopher
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Scott Christopher <SC...@internode.com.au>.
On 02/10/2010, at 9:05 PM, Willem Jiang wrote:
> On 10/2/10 1:33 PM, Scott Christopher wrote:
>> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>>
>>> Not sure why setting the address attribute in the spring.xml file does not
>>> change the address for you since that is the value that overrides the WSDL
>>> address... I know that it works!!!
>>
>> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
> The publishedEndpointUrl is just used to reset the Address information
> from the WSDL, it have nothing to do with the address that the service
> will be bound to.
This is exactly what I'm trying to achieve, and as per my original question, is it possible to use with a cxfEndpoint bean? Adding the publishedEndpointUrl attribute to the cxfEndpoint bean results in "Attribute 'publishedEndpointUrl' is not allowed to appear in element 'cxf:cxfEndpoint'."
It would be great if I could do something like:
<cxf:cxfEndpoint id="endpoint"
address="http://0.0.0.0:8000/service"
publishedEndpointUrl="https://www.example.com/service"
serviceClass="com.example.CxfTest" />
Regards,
Scott Christopher
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Willem Jiang <wi...@gmail.com>.
On 10/2/10 1:33 PM, Scott Christopher wrote:
> On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
>
>> Not sure why setting the address attribute in the spring.xml file does not
>> change the address for you since that is the value that overrides the WSDL
>> address... I know that it works!!!
>
> My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
The publishedEndpointUrl is just used to reset the Address information
from the WSDL, it have nothing to do with the address that the service
will be bound to.
>
> The caveat still remains though, as we need the address in the SOAP WSDL to specify the use of HTTPS on port 443, and we need the CXF endpoint to use standard HTTP on an unprivileged port (> 1024) as we can't run this as a root user.
>
> If this can't be achieved through configuration of the cxfEndpoint bean, I guess we'll just have to publish a static WSDL with the correct details.
If you can redirect the ?wsdl request to the CXF endpoint, you still
have a chance to use publishedEndpointUrl to do the job.
>
> Regards,
> Scott Christopher.
Just my two cents.
--
Willem
----------------------------------
Open Source Integration: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: http://twitter.com/willemjiang
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Scott Christopher <SC...@internode.com.au>.
On 02/10/2010, at 1:18 AM, Ashwin Karpe wrote:
> Not sure why setting the address attribute in the spring.xml file does not
> change the address for you since that is the value that overrides the WSDL
> address... I know that it works!!!
My apologies, the cxfEndpoint address does allow you to set any hostname, which updates the generated WSDL accordingly (I was confusing it with the Jetty component, which doesn't allow you to bind to a hostname that doesn't resolve to an IP address on a local interface).
The caveat still remains though, as we need the address in the SOAP WSDL to specify the use of HTTPS on port 443, and we need the CXF endpoint to use standard HTTP on an unprivileged port (> 1024) as we can't run this as a root user.
If this can't be achieved through configuration of the cxfEndpoint bean, I guess we'll just have to publish a static WSDL with the correct details.
Regards,
Scott Christopher.
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Ashwin Karpe <ak...@fusesource.com>.
Hmm...
Not sure why setting the address attribute in the spring.xml file does not
change the address for you since that is the value that overrides the WSDL
address... I know that it works!!!
In any case, looks like you need to have the same service running on
different machine with a different address and configure the loadbalancer to
have a map to these addresses.
The client needs to then call out to the general address known to the load
balancer which farms the request to different services. Not sure I clearly
understand why this in not working. Sounds like a configuration issue on the
loadbalancer.
Cheers,
Ashwin...
-----
---------------------------------------------------------
Ashwin Karpe
Apache Camel Committer & Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
http://opensourceknowledge.blogspot.com
---------------------------------------------------------
--
View this message in context: http://camel.465427.n5.nabble.com/publishedEndpointUrl-for-cxf-cxfEndpoint-tp3046858p3072868.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Scott Christopher <SC...@internode.com.au>.
On 30/09/2010, at 11:47 PM, Ashwin Karpe wrote:
> The answer is yes. Check out the address attribute in the <cxf:endpoint/>
> bean.
I'll assume you're referring to the cxfEndpoint element in the http://camel.apache.org/schema/cxf namespace. In which case, I don't believe that works for us.
To give you an example of our setup:
[client] -> (internet) -> [load balancer] -(1..n)-> [cxf endpoint]
where, for examples sake:
load balancer: services.example.com (12.34.56.78 - just an example IP address)
cxf endpoint: private1.example.com (10.0.0.1)
If we set the address attribute to "http://10.0.0.1/service", the WSDL is populated with <soap:address location="http://10.0.0.1/service"/>, which is inaccessible from the public internet.
If we set the address attribute to "http://services.example.com/services", then Jetty tries to bind to 12.34.56.78, which fails because it doesn't exist on this host. We can get it to do this by setting an entry in /etc/hosts to associate the hostname with the local IP address, though this still doesn't work for us, as our load balancer terminates an SSL connection on the public interface and proxies an unencrypted connection to the CXF endpoint, so the WSDL gets populated with <soap:address location="http://services.example.com/services"/> when we really need it to be <soap:address location="https://services.example.com/services"/>.
Furthermore, we will likely need to make use of the OSGi or Servlet transports for CXF, in which case you don't specify the hostname at all in the address attribute, as it is handled by the OSGi HTTP service or servlet container respectively. Once again, we can probably get the web container to pass on the correct external hostname to CXF to set in the WSDL, though we are still unable to specify the transport is HTTPS rather than HTTP.
Ideally, the listening address should be separately configurable from the published address in the WSDL.
I hope I'm overcomplicating this and missing something obvious here.
Regards,
Scott Christopher
Re: publishedEndpointUrl for cxf:cxfEndpoint
Posted by Ashwin Karpe <ak...@fusesource.com>.
Hi,
The answer is yes. Check out the address attribute in the <cxf:endpoint/>
bean.
Cheers,
Ashwin...
-----
---------------------------------------------------------
Ashwin Karpe
Apache Camel Committer & Sr Principal Consultant
FUSESource (a Progress Software Corporation subsidiary)
http://fusesource.com http://fusesource.com
Blog: http://opensourceknowledge.blogspot.com
http://opensourceknowledge.blogspot.com
---------------------------------------------------------
--
View this message in context: http://camel.465427.n5.nabble.com/publishedEndpointUrl-for-cxf-cxfEndpoint-tp3046858p3047086.html
Sent from the Camel - Users mailing list archive at Nabble.com.