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 <[email protected]>:
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
