You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jérôme Revillard <jr...@gnubila.fr> on 2015/08/13 21:42:28 UTC
CXF + Karaf 4: how to access the CXFNonSpringServlet
Dear all,
Since a couple of days, I'm trying to secure or web services which are
running inside a Karaf 4 container with keycloak
(http://keycloak.jboss.org).
I followed a bit the demo here:
https://github.com/keycloak/keycloak/tree/master/examples/fuse and more
particularly the "*Builtin web applications*" part which is here to
secure the all /cxf context.
I had to update different things to be able to work with Karaf 4 but, I
cannot make it working because I cannot get access to the cxf servlet.
If you look at the blueprint.xml
<https://github.com/keycloak/keycloak/blob/master/examples/fuse/cxf-jaxrs/src/main/resources/OSGI-INF/blueprint/blueprint.xml>
file, you can see:
<bean id="defaultCxfReregistration" class="org.keycloak.adapters.osgi.ServletReregistrationService" depends-on="cxfKeycloakPaxWebIntegration"
init-method="start" destroy-method="stop">
<property name="bundleContext" ref="blueprintBundleContext" />
<property name="servletReference">
<reference interface="javax.servlet.Servlet" filter="(alias=/cxf)" timeout="5000" />
</property>
</bean>
Unfortunately, this bean is never instanciated because there is no
"javax.servlet.Servlet" registered as service as it "should" be as
written in ServletReregistrationService.java
<https://github.com/keycloak/keycloak/blob/5301b556f09a8e06b8d2fd8c957c5b2a6251e3ab/integration/osgi-adapter/src/main/java/org/keycloak/adapters/osgi/ServletReregistrationService.java>:
"Service, which allows to remove previously registered servlets in
karaf/fuse environment. It assumes that particular servlet was
previously registered as service in OSGI container under {@link
javax.servlet.Servlet} interface."
I can get access to the ServletExporter but, the servlet object is
private there, without anyway to retrieve it.
Could somebody help me to solve this issue please ? Would there have
another approach ?
Thanks in advance!
Jerome
--
=====================================================
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Jérôme Revillard <jr...@gnubila.fr>.
Dear all,
I just have some random issues with this solution because, sometime, the
first bus-extensions.txt file which is taken into account is not mine
but the default one. Is there a way to overwrite the default one with
CXF 3.1.X ? I found this https://issues.apache.org/jira/browse/CXF-3601
but the solution does not work anymore with CXF 3.X
Best,
Jerome
Le 14/08/2015 17:41, Sergey Beryozkin a écrit :
> 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
>>>>>>>> =====================================================
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
--
=====================================================
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>>>> =====================================================
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Jérôme Revillard <jr...@gnubila.fr>.
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
>>>>>> =====================================================
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
--
=====================================================
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>>>> =====================================================
>>>>>
>>>>
>>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Jérôme Revillard <jr...@gnubila.fr>.
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
>>>> =====================================================
>>>>
>>>
>>
>
--
=====================================================
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
>>> =====================================================
>>>
>>
>
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Jérôme Revillard <jr...@gnubila.fr>.
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
>> =====================================================
>>
>
--
=====================================================
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
> =====================================================
>
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Jérôme Revillard <jr...@gnubila.fr>.
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
=====================================================
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by jrevillard <jr...@gnubila.fr>.
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.
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by jrevillard <jr...@gnubila.fr>.
I just see that in my previous message I made a mistake when I copied the
logs, here are the good ones:
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Karaf-4-how-to-access-the-CXFNonSpringServlet-tp5760086p5760091.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by jrevillard <jr...@gnubila.fr>.
Hi Christian,
Good idea indeed. I tested it: I setup the property to true, and basically
copy pasted your classes which register the CXF servlet in my own code in
order to register the servlet after after my keycloack jetty-web.xml
inclusion (would be good to make theses classes public in order to avoid
this copy ).
This mostly works but, when I open my browser on https://localhost:8443/cxf
I get "No services have been found." instead of the service list as usual.
In the logs, I see that the servce registration seems ok:
Any idea ?
Best,
Jerome
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Karaf-4-how-to-access-the-CXFNonSpringServlet-tp5760086p5760090.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: CXF + Karaf 4: how to access the CXFNonSpringServlet
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Jerome,
maybe you can instead just avoid that the CXF servlet is installed in
the first place:
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/osgi/HTTPTransportActivator.java
See the property org.apache.cxf.osgi.http.transport.disable
Christian
Am 13.08.2015 um 21:42 schrieb Jérôme Revillard:
> Dear all,
>
> Since a couple of days, I'm trying to secure or web services which are
> running inside a Karaf 4 container with keycloak
> (http://keycloak.jboss.org).
>
> I followed a bit the demo here:
> https://github.com/keycloak/keycloak/tree/master/examples/fuse and
> more particularly the "*Builtin web applications*" part which is here
> to secure the all /cxf context.
>
> I had to update different things to be able to work with Karaf 4 but,
> I cannot make it working because I cannot get access to the cxf
> servlet. If you look at the blueprint.xml
> <https://github.com/keycloak/keycloak/blob/master/examples/fuse/cxf-jaxrs/src/main/resources/OSGI-INF/blueprint/blueprint.xml>
> file, you can see:
>
> <bean id="defaultCxfReregistration" class="org.keycloak.adapters.osgi.ServletReregistrationService" depends-on="cxfKeycloakPaxWebIntegration"
> init-method="start" destroy-method="stop">
> <property name="bundleContext" ref="blueprintBundleContext" />
> <property name="servletReference">
> <reference interface="javax.servlet.Servlet" filter="(alias=/cxf)" timeout="5000" />
> </property>
> </bean>
> Unfortunately, this bean is never instanciated because there is no
> "javax.servlet.Servlet" registered as service as it "should" be as
> written in ServletReregistrationService.java
> <https://github.com/keycloak/keycloak/blob/5301b556f09a8e06b8d2fd8c957c5b2a6251e3ab/integration/osgi-adapter/src/main/java/org/keycloak/adapters/osgi/ServletReregistrationService.java>:
> "Service, which allows to remove previously registered servlets in
> karaf/fuse environment. It assumes that particular servlet was
> previously registered as service in OSGI container under {@link
> javax.servlet.Servlet} interface."
>
> I can get access to the ServletExporter but, the servlet object is
> private there, without anyway to retrieve it.
>
> Could somebody help me to solve this issue please ? Would there have
> another approach ?
>
> Thanks in advance!
> Jerome
> --
> =====================================================
> 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
> =====================================================