cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Konstantinides <Thomas.Konstantini...@isb-ag.de>
Subject AW: AW: CXF HTTP Transport in OSGi: ServiceTracker does not find HttpService
Date Tue, 14 Jul 2015 10:29:54 GMT
I agree, that this might rather be a Felix problem than a CXF problem. I will look into it
and maybe also contact the Felix mailing list on this topic.

Thanks so far,
Thomas


-----Ursprüngliche Nachricht-----
Von: Christian Schneider [mailto:cschneider111@gmail.com] Im Auftrag von Christian Schneider
Gesendet: Dienstag, 14. Juli 2015 11:42
An: users@cxf.apache.org
Betreff: Re: AW: CXF HTTP Transport in OSGi: ServiceTracker does not find HttpService

Now I get it. That explains why the open(true) helped. I think though this should be fixed
in felix.
A HttpService provider should not require the clients to know a proprietary interface.

I think the real problem might be in
org.apache.felix.http.base.internal.service.HttpServiceFactory.HttpServiceFactory
.
There the HttpService is registered using:
         final String[] ifaces = new String[] { HttpService.class.getName(), ExtHttpService.class.getName()
};
         this.httpServiceReg = bundleContext.registerService(ifaces,
this, this.httpServiceProps);
I would not have thought it is a problem if one of the interfaces is not known by a client
but maybe it is.
So I think it might help to do two separate calls to registerService with only one of the
interfaces.
Can you try this?

Christian


On 14.07.2015 11:21, Thomas Konstantinides wrote:
> Hi Christian,
>
> as I see the problem is not the default org.osgi.service.http.HttpService Interface itself
but org.apache.felix.http.api.ExtHttpService which is introduced by Felix and which inherits
from HttpService. So in the end when context.getServiceReferences() is called from the ServiceTracker
to search already registered HttpService implementors it finds the registered instance of
org.apache.felix.http.base.internal.service.HttpServiceImpl. This instance however implements
two interfaces: HttpService and ExtHttpService. This fact makes ServiceRegistrationImpl.isAssignableTo()
return false since the Interface org.apache.felix.http.api.ExtHttpService is not visible for
the CXF HTTP bundle.
>
> Another workaround which makes CXF work in the given scenario is doing the following
change:
> - Add org.apache.felix.http.api to the imported Packages of the 
> cxf-rt-transports-http bundle
>
> This makes the registered Felix HttpServiceImpl visible to CXF HTTP Transport ServiceTracker
and thus the connection between OSGi and the CXF Servlet can be established. The workaround
is based on creating a wiring between the CXF HTTP Transport bundle and the Felix HTTP API.
>
> Maybe this fix - although implementation specific - is the more future proof alternative,
since I think ExtHttpService will disappear over time when in OSGi R6 the default OSGi HttpService
gets more powerful.
>
> Thomas
>
> -----Ursprüngliche Nachricht-----
> Von: Christian Schneider [mailto:cschneider111@gmail.com] Im Auftrag 
> von Christian Schneider
> Gesendet: Dienstag, 14. Juli 2015 07:59
> An: users@cxf.apache.org
> Betreff: Re: CXF HTTP Transport in OSGi: ServiceTracker does not find 
> HttpService
>
> Can you check if there are different sources for the org.osgi.service.http package?
> Whenever you need open(true) the reason is that the client imports a different package
than the service.
> So your goal should be to remove one of that sources so both use the same package.
>
> Honestly I wonder why it works with true as you should not be able to call the service
if it is not compatible.
>
> Christian
>
>
> Am 13.07.2015 um 21:31 schrieb Thomas Konstantinides:
>> Hi Christian,
>>
>> thanks for your fast reply. The example on the Felix webpage is a bit 
>> outdated and the http bridge (version 2.3.2) in its manifest has now
>>
>> Import-Package: javax.servlet;version="[3.0,4)",javax.servlet.descriptor
>>    ;version="[3.0,4)",javax.servlet.http;version="[3.0,4)"
>>
>> So what we have in our framework.properties is
>>
>> org.osgi.framework.system.packages.extra = \
>>     
>> javax.servlet;javax.servlet.http;javax.servlet.descriptor;version=3.0
>>
>> In general the http bridge works fine and for example the Felix webconsole is showing
up without any problems. In the webconsole I can see again that the HttpService is available
and that the CXF HTTP Transport (as well as all other bundles) is started. If a put a breakpoint
into the HTTPTransportActivator.start() method and start a remote debugging session I'm getting
to the breakpoint and all the code within the activator runs. The only issue is that the CXF
ServiceTracker, which is started there, does not see the HttpService. And the only way I could
make it see the HttpService is using the .open(true) version.
>>
>> The fix with .open(true), which makes the CXF Servlet work, does seem a bit dirty
to me, too. However at the moment I see no other way to get this setup working. So if you
have any further ideas it would be great. Maybe someone has a similar setup working?
>>
>> Thomas
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Christian Schneider [mailto:cschneider111@gmail.com] Im Auftrag 
>> von Christian Schneider
>> Gesendet: Montag, 13. Juli 2015 18:05
>> An: users@cxf.apache.org
>> Betreff: Re: CXF HTTP Transport in OSGi: ServiceTracker does not find 
>> HttpService
>>
>> Hi Thomas,
>>
>> I think this fix is not correct. If the http service can only be found with .open(true)
it means that the package the service implements and the package cxf imports are different.
>>
>> I assume you simply forgot one step of the bridge installation guide:
>> http://felix.apache.org/documentation/subprojects/apache-felix-http-s
>> e
>> rvice.html#using-the-servlet-bridge
>>
>> be sure to add |javax.servlet;javax.servlet.http;version=2.6| to OSGi 
>> system packages (|org.osgi.framework.system.packages|);
>>
>> Christian
>>
>> On 13.07.2015 17:07, Thomas Konstantinides wrote:
>>> Hi everyone,
>>>
>>> I am having some problems with CXF HTTP Transport in an OSGi environment using
Apache Felix as OSGi Framwork.
>>>
>>> I'm using the Felix Http Bridge to start Felix within a .war web application
which runs in Tomcat. The problem is, that the ServiceTracker which is set up in org.apache.cxf.transport.http.osgi.HTTPTransportActivator
does not find the HttpService which is provided by the bundle org.apache.felix.http.bridge.
>>>
>>> I tried a small change in the CXF code, changing line 64 in 
>>> HTTPTransportActivator to
>>>
>>> httpServiceTracker.open(true);
>>>
>>> With this change the HttpService is recognized by the ServiceTracker and the
CXF Servlet is setup correctly.
>>>
>>> I did a bit more debugging to get to the root cause of this behavior 
>>> and found, that the problem is caused when the method
>>>
>>> ServiceRegistrationImpl.isAssignableTo()
>>>
>>> is called in the process of opening the ServiceTracker and getting the list of
already available services for the interface HttpService (ServiceTracker. getInitialReferences()
-> context.getServiceReferences). The Implementation of Felix' HttpService (org.apache.felix.http.base.internal.service.HttpServiceImpl)
implements not only HttpService but also ExtHttpService. And when asking ServiceRegistrationImpl.isAssignableTo()
with the parameters requester: "org.apache.cxf.cxf-rt-transports-http [27]" and className:
"org.apache.felix.http.api.ExtHttpService" it returns false.
>>>
>>> Now a simple fix is given by what I already wrote above: Changing
>>> httpServiceTracker.open() to httpServiceTracker.open(true); in 
>>> HTTPTransportActivator
>>>
>>> So I'd like to ask two questions:
>>> 1. Does anyone have a better solution on how to get this scenario working?
>>> 2. If not: Could this fix be inserted into the CXF code to enable us (and others
which might have similar problems) to use the offical .jar and not a self-built one?
>>>
>>> Thanks for your comments,
>>> Thomas
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message