Hi Jérôme
If that works for you then it is fine, it is all good as long as the
user is happy :-) No need to spend extra time on trying the alternatives,
Cheers, Sergey
On 14/08/15 16:27, Jérôme Revillard wrote:
Found!
I did not test your solution yet Sergey but I found that the
HTTPTransportFactory was instantiated by the CXFExtensionBundleListener
classe.
I then decided to put the META-INF/cxf/bus-extensions.txt file inside my
bundle and it works!
Any possible side effect here ? Do you see it more like a workaround or
as a real solution ?
Best,
Jerome
Le 14/08/2015 17:19, Sergey Beryozkin a écrit :
I can see a default constructor is called by Jetty or Netty
destinations, may be you need to remove http-jetty bundle...
Cheers, Sergey
On 14/08/15 15:18, Jérôme Revillard wrote:
Ok, just a quick follow up on my tests.
My problem comes from the fact the something else is instantiating a new
HTTPTransportFactory but calling the default constructor which therefore
create a new DestinationRegistryImpl. This later is then filled with the
endpoints instead of the one that I instantiated. I still don't know who
instantiat it and why.
Best,
Jerome
Le 14/08/2015 14:31, Sergey Beryozkin a écrit :
Hi, no, no idea why your approach does not work.
I'd choose at any time the CXFBlueprintServlet path, but it is only my
opinion
Cheers, Sergey
On 14/08/15 13:24, Jérôme Revillard wrote:
Thanks Sergey,
I would really like to be be able to fix my issue because it seems
to be
the "cleanest" way of doing what I want to achieve even if it's a bit
more complex.
Would you have an idea ?
Best,
Jerome
Le 14/08/2015 13:49, Sergey Beryozkin a écrit :
Hi
I did try disabling the default servlet in one of the demos. But I
used CXFBlueprintServlet instead and registered the bundle as a war
bundle, without having to create the analog of the default CXF
Transport - appears to be a complex path.
For example:
https://fisheye6.atlassian.com/browse/cxf/systests/jaxrs/src/test/resources/jaxrs_soap_blueprint/WEB-INF/web.xml?r=d2fc5e244b042a47c84c57426f74cb589501489e
that is a link to a non-osgi test, but the same worked for me in
Karaf, I only used an aries blueprint-web-osgi bundle to support it
Cheers, Sergey
On 14/08/15 12:40, Jérôme Revillard wrote:
Hi Sergey,
No, /test-uri does not respond (404 from jetty).
Concerning the default HTTP transport, the fact is that I creates
the
/cxf context myself now (I basically copy/pasted the classes from
here
<https://github.com/apache/cxf/tree/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi>
to it). So /cxf respond but, it says "No services have been found."
instead of displaying the actually exposed ones that I can find
inside
the Karaf shell
karaf@root()> cxf:list-endpoints
Name State Address BusID
[TestURI ] [Started ]
[/test-uri ]
[fr.maatg.pandora.gateway.pandora-gateway-sal-saga-cxf1486728741]
[SagaServiceJobPort ] [Started ]
[/job ]
[fr.maatg.pandora.gateway.pandora-gateway-sal-saga-cxf1486728741]
[SagaServiceDataManagementPort] [Started ]
[/data ]
[fr.maatg.pandora.gateway.pandora-gateway-sal-saga-cxf1486728741]
In fact, if I try to contact my test web service:
https://localhost:8443/cxf/test-uri/test, it says also "No
service was
found." instead of displaying the service output.
Best,
Jerome
Le 14/08/2015 13:16, Sergey Beryozkin a écrit :
Hi
The default HTTP transport creates a /cxf context, without it it
is up
to the custom application how to control the context name, does
/test-uri respond, etc ?
Sergey
On 14/08/15 10:31, jrevillard wrote:
Last but not least, my enpoints are registered:Best,Jerome
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-Karaf-4-how-to-access-the-CXFNonSpringServlet-tp5760086p5760092.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
=====================================================
Dr Jérôme Revillard
CTO MAAT/GNUBILA France
www.gnubila.fr
174 Impasse des Prés d'en Bas
74370 Argonay (France)
Mob. 0033 676 108 185
Tel. 0033 450 685 601
=====================================================
