How about using address="/UserAgentsDataLoad/1.0/TaskSchedulerClient" ?
This will make cxf use the servlet transport. It allows all your
services to run on the same port and use the OSGi http service.
Christian
Am 22.11.2013 10:13, schrieb Jim Talbut:
Hi,
I've got a number of web services running using Camel configured like:
<camel-cxf:cxfEndpoint id="serviceSchedulerClient"
address="http://0.0.0.0:8026/UserAgentsDataLoad/1.0/TaskSchedulerClient"
wsdlURL="resources/1.0.0/TaskSchedulerClient.wsdl"
xmlns:cli="http://groupgti.com/esb/jobengines/client/service/GroupGtiSupportSystem/ClientSchedulerTarget"
serviceName="cli:ClientSchedulerTargetService"
endpointName="cli:ClientSchedulerPortTypeBindingPort"
serviceClass="com.groupgti.esb.jobengines.client.service.groupgtisupportsystem.clientschedulertarget.ClientSchedulerTargetPortType"
/>
These services are all on the same port, but different URLs.
There are other services on other ports.
The services are configured using fileinstall by simply dropping
spring configuration files in a "deploy" directory (separate from the
etc directory).
I'm finding that fileinstall (or something on the same timeframe as
fileinstall) is causing all of these spring bundles to restart, and
they are failing to come back up.
I think what is happening is that fileinstall is taking them down and
bringing them back up at the same time, so some are going down whilst
others are coming up and the ports are in use so it fails.
I don't know why fileinstall is restarting these bundles, it shouldn't
need to, nothing has changed.
As a fix I'm looking at moving to use the OSGi HTTP transport rather
than the direct Jetty one (thinking that this will mean the ports are
always open, but it also fixes another problem I have with configuring
the jetty engines).
I know I can have the OSGi container listen on different ports, but is
it possible to keep them separate?
So port 8026, managed by PAX, only responds to this set of endpoints
and not any other endpoints that may also be running (on other ports
also managed by OSGi) in the same container.
Thanks
Jim
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com