You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Edell Nolan <ed...@gmail.com> on 2009/05/25 18:41:00 UTC
Query about the CXF Transport for OSGi
Hi,
I have a question on the CXF Transport for OSGi.
Basically if you do the following
Start Servicemix
*at the console run => features/install examples-cxf-osgi
*open a web browser and check that
http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives
you the demo WSDL
set *log/set TRACE
Build the cxf-wsdl-first demo and install it using =>
**osgi/install -s
mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
*
point your web browser to
http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to
verify the cxf-wsdl-first demo is running
this all works fine and you should see the both wsdl files.
Then restart Servicemix.
You can no longer see
http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl
- from debugging this along - it now ends up in the
OSGITransportFactory and will throw an error in the log files
"17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
| mmon.xbean.AbstractXBeanDeployer 103 |
javax.jbi.management.DeploymentException: java.lang.IllegalStateException:
Endpoint address should be a relative URI wrt to the servlet address (use
'/xxx' for example)"
if you look at
https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
In getDestination it throws
if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
throw new IllegalStateException("Endpoint address should be a
relative URI wrt to the servlet address (use '/xxx' for example)");
}
the sequence of starting the two demos is the same on reboot but yet we get
different results.
As when you first attempt to run the cxf-wsdl-first demo the CXF Transport
for OSGi is already running and we can see out PersonService wsdl. But it
looks like the OSGI Transport is not set as the default until after a
refresh/reboot.
Then when you reboot and attempt to launch the PersonService wsdl it ends up
in the OsgiTransportFactory which is not going to work.
Shouldn't other services be able to be deployed independant of the Osgi
Transport Service and use say the SoapTransportFactory.
I did ask Freeman and he mentioned one work around would be to use your own
bus.
thanks, Edell.
Re: Query about the CXF Transport for OSGi
Posted by Edell Nolan <ed...@gmail.com>.
Hi,
I am back to looking at this issue and unfortunatley Eogan suggestion
doesn't work. It appears that I get a new DestinationFactortyManager each
time and then it assigns the values using setMapProvider with the spring
properties set for the bean so by the time it gets to the init method of the
OSGI CXF transport Factory - the transport Id's have already been set and
you can't get access to the original ones.
Edell.
On Wed, May 27, 2009 at 2:13 AM, Freeman Fang <fr...@gmail.com>wrote:
> Eoghan Glynn wrote:
>
>> Hi Folks,
>>
>> I'm not sure we'd have to go so far as to create a separate Bus for
>> the cxf osgi transport.
>>
>> Part of the problem I think is that the super-class,
>> AbstractHTTPTransportFactory, does the overwrite of the
>> DestinationFactory registered with the DestinationFactoryManager in
>> its PostConstruct method.
>>
>> Whereas the sub-class, OsgiServletTransport, does the same thing
>> *again* in its init-method.
>>
>> The result is that by the time the OsgiServletTransport.init() is
>> called, the destination factory has *already* been over-written for
>> the transport IDs.
>>
>> Now if we supress the first step by overriding
>> AbstractHTTPTransportFactory.registerWithBindingManager() as a no-op
>> in OsgiServletTransport, then the OsgiServletTransport.init() can
>> remember the factory previously registered against the transport IDs.
>>
>> Then in OsgiServletTransport.getDestination(), we could delegate to
>> the original transport factory when the EndpointInfo address is
>> absolute.
>>
>>
> So even we run into OsgiServletTransport.getDestination(), if the address
> start with "http", we can still use the normal http transport(not the osgi
> http service), sounds good for me.
> Cheers
> Freeman
>
> Cheers,
>> Eoghan
>>
>> 2009/5/26 Freeman Fang <fr...@gmail.com>:
>>
>>
>>> Hi Edell,
>>>
>>> The cxf bc will try to retrieve the default cxf bus (which already
>>> register
>>> http transportId with osgi http service by cxf osgi transport) if we
>>> didn't
>>> specify bus for cxf bc endpoint, so specify cxf bus for cxf bc endpoint
>>> can
>>> get it around.
>>> I think there should be two ways to fix it
>>> 1) shouldn't set the bus used for cxf osgi transport as default bus, we
>>> can
>>> name this bus with a specific name and any other bundle which want to use
>>> this bus(means use osgi http service as http transport) can retrieve it
>>> with
>>> the specific name
>>> or
>>> 2) endpoint in cxf bc should never use default cxf bus even without
>>> busCfg
>>> attribute
>>> I prefer to the first solution since we kinda hack the cxf bus in cxf
>>> osgi
>>> transport so it shouldn't be the default bus.
>>> Freeman
>>>
>>> Edell Nolan wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I have a question on the CXF Transport for OSGi.
>>>>
>>>> Basically if you do the following
>>>>
>>>> Start Servicemix
>>>>
>>>> *at the console run => features/install examples-cxf-osgi
>>>> *open a web browser and check that
>>>>
>>>> http://localhost:8080/cxf/HelloWorld?wsdl<
>>>> http://localhost:8080/cxf/HelloWorld?wsdl*>gives
>>>> you the demo WSDL
>>>> set *log/set TRACE
>>>> Build the cxf-wsdl-first demo and install it using =>
>>>> **osgi/install -s
>>>>
>>>>
>>>> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
>>>> *
>>>> point your web browser to
>>>>
>>>> http://localhost:8092/PersonService?wsdl<
>>>> http://localhost:8092/PersonService?wsdl*>to
>>>> verify the cxf-wsdl-first demo is running
>>>>
>>>> this all works fine and you should see the both wsdl files.
>>>>
>>>> Then restart Servicemix.
>>>>
>>>> You can no longer see
>>>>
>>>> http://localhost:8092/PersonService?wsdl<
>>>> http://localhost:8092/PersonService?wsdl*>wsdl
>>>> - from debugging this along - it now ends up in the
>>>> OSGITransportFactory and will throw an error in the log files
>>>>
>>>> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
>>>> | mmon.xbean.AbstractXBeanDeployer 103 |
>>>> javax.jbi.management.DeploymentException:
>>>> java.lang.IllegalStateException:
>>>> Endpoint address should be a relative URI wrt to the servlet address
>>>> (use
>>>> '/xxx' for example)"
>>>>
>>>> if you look at
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
>>>>
>>>> In getDestination it throws
>>>> if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
>>>> throw new IllegalStateException("Endpoint address should be a
>>>> relative URI wrt to the servlet address (use '/xxx' for example)");
>>>> }
>>>>
>>>> the sequence of starting the two demos is the same on reboot but yet we
>>>> get
>>>> different results.
>>>>
>>>> As when you first attempt to run the cxf-wsdl-first demo the CXF
>>>> Transport
>>>> for OSGi is already running and we can see out PersonService wsdl. But
>>>> it
>>>> looks like the OSGI Transport is not set as the default until after a
>>>> refresh/reboot.
>>>>
>>>> Then when you reboot and attempt to launch the PersonService wsdl it
>>>> ends
>>>> up
>>>> in the OsgiTransportFactory which is not going to work.
>>>>
>>>> Shouldn't other services be able to be deployed independant of the Osgi
>>>> Transport Service and use say the SoapTransportFactory.
>>>>
>>>> I did ask Freeman and he mentioned one work around would be to use your
>>>> own
>>>> bus.
>>>>
>>>> thanks, Edell.
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Freeman Fang
>>> ------------------------
>>> Open Source SOA: http://fusesource.com
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Freeman Fang
> ------------------------
> Open Source SOA: http://fusesource.com
>
>
Re: Query about the CXF Transport for OSGi
Posted by Freeman Fang <fr...@gmail.com>.
Eoghan Glynn wrote:
> Hi Folks,
>
> I'm not sure we'd have to go so far as to create a separate Bus for
> the cxf osgi transport.
>
> Part of the problem I think is that the super-class,
> AbstractHTTPTransportFactory, does the overwrite of the
> DestinationFactory registered with the DestinationFactoryManager in
> its PostConstruct method.
>
> Whereas the sub-class, OsgiServletTransport, does the same thing
> *again* in its init-method.
>
> The result is that by the time the OsgiServletTransport.init() is
> called, the destination factory has *already* been over-written for
> the transport IDs.
>
> Now if we supress the first step by overriding
> AbstractHTTPTransportFactory.registerWithBindingManager() as a no-op
> in OsgiServletTransport, then the OsgiServletTransport.init() can
> remember the factory previously registered against the transport IDs.
>
> Then in OsgiServletTransport.getDestination(), we could delegate to
> the original transport factory when the EndpointInfo address is
> absolute.
>
So even we run into OsgiServletTransport.getDestination(), if the
address start with "http", we can still use the normal http
transport(not the osgi http service), sounds good for me.
Cheers
Freeman
> Cheers,
> Eoghan
>
> 2009/5/26 Freeman Fang <fr...@gmail.com>:
>
>> Hi Edell,
>>
>> The cxf bc will try to retrieve the default cxf bus (which already register
>> http transportId with osgi http service by cxf osgi transport) if we didn't
>> specify bus for cxf bc endpoint, so specify cxf bus for cxf bc endpoint can
>> get it around.
>> I think there should be two ways to fix it
>> 1) shouldn't set the bus used for cxf osgi transport as default bus, we can
>> name this bus with a specific name and any other bundle which want to use
>> this bus(means use osgi http service as http transport) can retrieve it with
>> the specific name
>> or
>> 2) endpoint in cxf bc should never use default cxf bus even without busCfg
>> attribute
>> I prefer to the first solution since we kinda hack the cxf bus in cxf osgi
>> transport so it shouldn't be the default bus.
>> Freeman
>>
>> Edell Nolan wrote:
>>
>>> Hi,
>>>
>>> I have a question on the CXF Transport for OSGi.
>>>
>>> Basically if you do the following
>>>
>>> Start Servicemix
>>>
>>> *at the console run => features/install examples-cxf-osgi
>>> *open a web browser and check that
>>>
>>> http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives
>>> you the demo WSDL
>>> set *log/set TRACE
>>> Build the cxf-wsdl-first demo and install it using =>
>>> **osgi/install -s
>>>
>>> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
>>> *
>>> point your web browser to
>>>
>>> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to
>>> verify the cxf-wsdl-first demo is running
>>>
>>> this all works fine and you should see the both wsdl files.
>>>
>>> Then restart Servicemix.
>>>
>>> You can no longer see
>>>
>>> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl
>>> - from debugging this along - it now ends up in the
>>> OSGITransportFactory and will throw an error in the log files
>>>
>>> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
>>> | mmon.xbean.AbstractXBeanDeployer 103 |
>>> javax.jbi.management.DeploymentException: java.lang.IllegalStateException:
>>> Endpoint address should be a relative URI wrt to the servlet address (use
>>> '/xxx' for example)"
>>>
>>> if you look at
>>>
>>> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
>>>
>>> In getDestination it throws
>>> if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
>>> throw new IllegalStateException("Endpoint address should be a
>>> relative URI wrt to the servlet address (use '/xxx' for example)");
>>> }
>>>
>>> the sequence of starting the two demos is the same on reboot but yet we
>>> get
>>> different results.
>>>
>>> As when you first attempt to run the cxf-wsdl-first demo the CXF Transport
>>> for OSGi is already running and we can see out PersonService wsdl. But it
>>> looks like the OSGI Transport is not set as the default until after a
>>> refresh/reboot.
>>>
>>> Then when you reboot and attempt to launch the PersonService wsdl it ends
>>> up
>>> in the OsgiTransportFactory which is not going to work.
>>>
>>> Shouldn't other services be able to be deployed independant of the Osgi
>>> Transport Service and use say the SoapTransportFactory.
>>>
>>> I did ask Freeman and he mentioned one work around would be to use your
>>> own
>>> bus.
>>>
>>> thanks, Edell.
>>>
>>>
>>>
>> --
>> Freeman Fang
>> ------------------------
>> Open Source SOA: http://fusesource.com
>>
>>
>>
>
>
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
Re: Query about the CXF Transport for OSGi
Posted by Eoghan Glynn <eo...@gmail.com>.
Hi Folks,
I'm not sure we'd have to go so far as to create a separate Bus for
the cxf osgi transport.
Part of the problem I think is that the super-class,
AbstractHTTPTransportFactory, does the overwrite of the
DestinationFactory registered with the DestinationFactoryManager in
its PostConstruct method.
Whereas the sub-class, OsgiServletTransport, does the same thing
*again* in its init-method.
The result is that by the time the OsgiServletTransport.init() is
called, the destination factory has *already* been over-written for
the transport IDs.
Now if we supress the first step by overriding
AbstractHTTPTransportFactory.registerWithBindingManager() as a no-op
in OsgiServletTransport, then the OsgiServletTransport.init() can
remember the factory previously registered against the transport IDs.
Then in OsgiServletTransport.getDestination(), we could delegate to
the original transport factory when the EndpointInfo address is
absolute.
Cheers,
Eoghan
2009/5/26 Freeman Fang <fr...@gmail.com>:
> Hi Edell,
>
> The cxf bc will try to retrieve the default cxf bus (which already register
> http transportId with osgi http service by cxf osgi transport) if we didn't
> specify bus for cxf bc endpoint, so specify cxf bus for cxf bc endpoint can
> get it around.
> I think there should be two ways to fix it
> 1) shouldn't set the bus used for cxf osgi transport as default bus, we can
> name this bus with a specific name and any other bundle which want to use
> this bus(means use osgi http service as http transport) can retrieve it with
> the specific name
> or
> 2) endpoint in cxf bc should never use default cxf bus even without busCfg
> attribute
> I prefer to the first solution since we kinda hack the cxf bus in cxf osgi
> transport so it shouldn't be the default bus.
> Freeman
>
> Edell Nolan wrote:
>>
>> Hi,
>>
>> I have a question on the CXF Transport for OSGi.
>>
>> Basically if you do the following
>>
>> Start Servicemix
>>
>> *at the console run => features/install examples-cxf-osgi
>> *open a web browser and check that
>>
>> http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives
>> you the demo WSDL
>> set *log/set TRACE
>> Build the cxf-wsdl-first demo and install it using =>
>> **osgi/install -s
>>
>> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
>> *
>> point your web browser to
>>
>> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to
>> verify the cxf-wsdl-first demo is running
>>
>> this all works fine and you should see the both wsdl files.
>>
>> Then restart Servicemix.
>>
>> You can no longer see
>>
>> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl
>> - from debugging this along - it now ends up in the
>> OSGITransportFactory and will throw an error in the log files
>>
>> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
>> | mmon.xbean.AbstractXBeanDeployer 103 |
>> javax.jbi.management.DeploymentException: java.lang.IllegalStateException:
>> Endpoint address should be a relative URI wrt to the servlet address (use
>> '/xxx' for example)"
>>
>> if you look at
>>
>> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
>>
>> In getDestination it throws
>> if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
>> throw new IllegalStateException("Endpoint address should be a
>> relative URI wrt to the servlet address (use '/xxx' for example)");
>> }
>>
>> the sequence of starting the two demos is the same on reboot but yet we
>> get
>> different results.
>>
>> As when you first attempt to run the cxf-wsdl-first demo the CXF Transport
>> for OSGi is already running and we can see out PersonService wsdl. But it
>> looks like the OSGI Transport is not set as the default until after a
>> refresh/reboot.
>>
>> Then when you reboot and attempt to launch the PersonService wsdl it ends
>> up
>> in the OsgiTransportFactory which is not going to work.
>>
>> Shouldn't other services be able to be deployed independant of the Osgi
>> Transport Service and use say the SoapTransportFactory.
>>
>> I did ask Freeman and he mentioned one work around would be to use your
>> own
>> bus.
>>
>> thanks, Edell.
>>
>>
>
>
> --
> Freeman Fang
> ------------------------
> Open Source SOA: http://fusesource.com
>
>
Re: Query about the CXF Transport for OSGi
Posted by Freeman Fang <fr...@gmail.com>.
Hi Edell,
The cxf bc will try to retrieve the default cxf bus (which already
register http transportId with osgi http service by cxf osgi transport)
if we didn't specify bus for cxf bc endpoint, so specify cxf bus for cxf
bc endpoint can get it around.
I think there should be two ways to fix it
1) shouldn't set the bus used for cxf osgi transport as default bus, we
can name this bus with a specific name and any other bundle which want
to use this bus(means use osgi http service as http transport) can
retrieve it with the specific name
or
2) endpoint in cxf bc should never use default cxf bus even without
busCfg attribute
I prefer to the first solution since we kinda hack the cxf bus in cxf
osgi transport so it shouldn't be the default bus.
Freeman
Edell Nolan wrote:
> Hi,
>
> I have a question on the CXF Transport for OSGi.
>
> Basically if you do the following
>
> Start Servicemix
>
> *at the console run => features/install examples-cxf-osgi
> *open a web browser and check that
> http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives
> you the demo WSDL
> set *log/set TRACE
> Build the cxf-wsdl-first demo and install it using =>
> **osgi/install -s
> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
> *
> point your web browser to
> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to
> verify the cxf-wsdl-first demo is running
>
> this all works fine and you should see the both wsdl files.
>
> Then restart Servicemix.
>
> You can no longer see
> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl
> - from debugging this along - it now ends up in the
> OSGITransportFactory and will throw an error in the log files
>
> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
> | mmon.xbean.AbstractXBeanDeployer 103 |
> javax.jbi.management.DeploymentException: java.lang.IllegalStateException:
> Endpoint address should be a relative URI wrt to the servlet address (use
> '/xxx' for example)"
>
> if you look at
> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
>
> In getDestination it throws
> if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
> throw new IllegalStateException("Endpoint address should be a
> relative URI wrt to the servlet address (use '/xxx' for example)");
> }
>
> the sequence of starting the two demos is the same on reboot but yet we get
> different results.
>
> As when you first attempt to run the cxf-wsdl-first demo the CXF Transport
> for OSGi is already running and we can see out PersonService wsdl. But it
> looks like the OSGI Transport is not set as the default until after a
> refresh/reboot.
>
> Then when you reboot and attempt to launch the PersonService wsdl it ends up
> in the OsgiTransportFactory which is not going to work.
>
> Shouldn't other services be able to be deployed independant of the Osgi
> Transport Service and use say the SoapTransportFactory.
>
> I did ask Freeman and he mentioned one work around would be to use your own
> bus.
>
> thanks, Edell.
>
>
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com
Re: Query about the CXF Transport for OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
Not sure how CXF-BC is wired to the OSGi transport, but if this is the
case, maybe we should ensure that when installing cxf-bc feature, the
cxf-osgi transport is installed before that.
On Mon, May 25, 2009 at 18:41, Edell Nolan <ed...@gmail.com> wrote:
> Hi,
>
> I have a question on the CXF Transport for OSGi.
>
> Basically if you do the following
>
> Start Servicemix
>
> *at the console run => features/install examples-cxf-osgi
> *open a web browser and check that
> http://localhost:8080/cxf/HelloWorld?wsdl<http://localhost:8080/cxf/HelloWorld?wsdl*>gives
> you the demo WSDL
> set *log/set TRACE
> Build the cxf-wsdl-first demo and install it using =>
> **osgi/install -s
> mvn:org.apache.servicemix.examples.cxf-wsdl-first/wsdl-first-cxf-sa/4.1.0-SNAPSHOT/zip
> *
> point your web browser to
> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>to
> verify the cxf-wsdl-first demo is running
>
> this all works fine and you should see the both wsdl files.
>
> Then restart Servicemix.
>
> You can no longer see
> http://localhost:8092/PersonService?wsdl<http://localhost:8092/PersonService?wsdl*>wsdl
> - from debugging this along - it now ends up in the
> OSGITransportFactory and will throw an error in the log files
>
> "17:58:41,241 | ERROR | xtenderThread-66 | CxfBcComponent
> | mmon.xbean.AbstractXBeanDeployer 103 |
> javax.jbi.management.DeploymentException: java.lang.IllegalStateException:
> Endpoint address should be a relative URI wrt to the servlet address (use
> '/xxx' for example)"
>
> if you look at
> https://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/cxf/cxf-transport-osgi/src/main/java/org/apache/servicemix/cxf/transport/http_osgi/OsgiTransportFactory.java
>
> In getDestination it throws
> if (URI.create(endpointInfo.getAddress()).isAbsolute()) {
> throw new IllegalStateException("Endpoint address should be a
> relative URI wrt to the servlet address (use '/xxx' for example)");
> }
>
> the sequence of starting the two demos is the same on reboot but yet we get
> different results.
>
> As when you first attempt to run the cxf-wsdl-first demo the CXF Transport
> for OSGi is already running and we can see out PersonService wsdl. But it
> looks like the OSGI Transport is not set as the default until after a
> refresh/reboot.
>
> Then when you reboot and attempt to launch the PersonService wsdl it ends up
> in the OsgiTransportFactory which is not going to work.
>
> Shouldn't other services be able to be deployed independant of the Osgi
> Transport Service and use say the SoapTransportFactory.
>
> I did ask Freeman and he mentioned one work around would be to use your own
> bus.
>
> thanks, Edell.
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com