{Disarmed} Re: {Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service

[Pierre De Rop <pi...@alcatel-lucent.fr>]

I'm sorry Karl, I just missed the jira issue. I will add my comments in it.

thanks
/pierre

Karl Pauls wrote:
> We created issue FELIX-756 a while ago to track this. Please go and
> add your comment there.
>
> I just assigned the issue to me and can try to look into it.
>
> regards,
>
> Karl
>
> On Tue, Oct 21, 2008 at 10:48 AM, Pierre De Rop
> <pi...@alcatel-lucent.fr> wrote:
>   
>> Hi Karl,
>>
>> I come back to you on this problem.
>> I understand it's possible to provide an http/https URLStream handler, by
>> exposing some classes along with the classpath (like you suggested).
>> But the point is: we have implemented the http/https URL Stream handler
>> service in a bundle (our http container) and
>> we don't really want to "unbundle-ize" it in order to expose some of its
>> classes from the classpath ...
>> It's a big deal ... I would have to unbundle-ize many other dependent
>> bundles ...
>>
>> On the other hand, I noticed that there is a property in Felix called
>> felix.strict.osgi: What is exactly the impact of setting this to false?
>> Would it be acceptable for you, when this property is set to false, to
>> enable the http/https protocols for URLStreamHandler service ?
>> *
>> *Best Regards;
>> /pierre
>>
>> Karl Pauls wrote:
>>     
>>> Well, maybe. The issue is that it is not impossible that the jvm
>>> already used a handler and then we are stuck (assuming the hack with
>>> flushing the cache doesn't work). I agree that this is a corner case
>>> but still. We should probably create a jira issue to track this and
>>> come-up with a suggestion for the override property.
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> On Wed, Oct 8, 2008 at 8:58 PM, Richard S. Hall <he...@ungoverned.org>
>>> wrote:
>>>
>>>       
>>>> Apparently, this part of the spec has been weakened for the next release
>>>> since neither Equinox nor KF actually enforced it.
>>>>
>>>> Perhaps we should add an option for allowing overriding too.
>>>>
>>>> -> richard
>>>>
>>>>
>>>> Pierre De Rop wrote:
>>>>
>>>>         
>>>>> Karl,
>>>>> Yes, It should work fine. I'll try as you suggest.
>>>>>
>>>>> Thanks a lot !
>>>>> /pierre
>>>>>
>>>>> Karl Pauls wrote:
>>>>>
>>>>>           
>>>>>> Ok. Well, from my interpretation of the spec, this isn't possible
>>>>>> using an URLStreamHandler because of the build-in handlers being
>>>>>> preferred (and for good reasons).
>>>>>>
>>>>>> However, it does sound to me like you have control over the jvm so
>>>>>> what you can do is put your handler on the classpath (assuming it is
>>>>>> in a package called http and is called Handler) and start with
>>>>>> -Djava.protocol.handler.pkgs=your.pkg.prefix e.g., assuming I have a
>>>>>> http handler called org.foo.http.Handler it would have to look like
>>>>>> this:
>>>>>>
>>>>>> java -Djava.protocol.handler.pkgs=org.foo -jar bin/felix.jar
>>>>>>
>>>>>> and the org.pauls.http.Handler.class need to be available on the
>>>>>> classpath.
>>>>>>
>>>>>> Hope this helps?
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Karl
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 8, 2008 at 2:50 PM, Pierre De Rop
>>>>>> <pi...@alcatel-lucent.fr> wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Hi Karl,
>>>>>>>
>>>>>>> We are running our A5350 cluster application server on top of OSGi.
>>>>>>> Our
>>>>>>> server is made up of the following processes:
>>>>>>>
>>>>>>>  * Protocol load balancers (http/sip/diameter etc ...)
>>>>>>>  * Felix Jvm frameworks.
>>>>>>>
>>>>>>> The load balancers dispatch all messages among Jmvs frameworks.
>>>>>>> In each framework we start the following bundles:
>>>>>>>
>>>>>>>  * A container for each protocol (http container/sip container, etc
>>>>>>> ...)
>>>>>>>  * applications (WARs, Diameter applications, Sip applications, etc
>>>>>>> ...)
>>>>>>>
>>>>>>> Now, in the case of the http container, we wan't to take the control,
>>>>>>> when
>>>>>>> WARs
>>>>>>> are using the java.net.HttpURLConnection: We just want to forward the
>>>>>>> http
>>>>>>> request to our load balancer (using our own socket multiplexer),
>>>>>>> instead
>>>>>>> of
>>>>>>> letting the jdk http client open itself a socket to the web servers
>>>>>>> directly.
>>>>>>>
>>>>>>> With KnopflerFish, I used the OSGi URLStreamHandler service in order
>>>>>>> to
>>>>>>> do
>>>>>>> that trick.
>>>>>>>
>>>>>>> Thanks
>>>>>>> /pierre
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Karl Pauls wrote:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> You are trying to override a build-in handler. The http schema is
>>>>>>>> handled by the jvm and must not be overridden (see 11.3.2 of the
>>>>>>>> spec).
>>>>>>>>
>>>>>>>> Could you explain your use-case a bit more (why do you want to use
>>>>>>>> your own http implementation?) - maybe we can find a workaround ....
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Karl
>>>>>>>>
>>>>>>>> On Wed, Oct 8, 2008 at 1:57 PM, Pierre De Rop
>>>>>>>> <pi...@alcatel-lucent.fr> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> Hello everyone,
>>>>>>>>>
>>>>>>>>> I have a bundle which provides a
>>>>>>>>> org.osgi.service.url.URLStreamHandlerService with protocol "http"
>>>>>>>>> and
>>>>>>>>> "https".
>>>>>>>>> but, when I use java.net.HttpURLConnection, my handlers are not
>>>>>>>>> invoked.
>>>>>>>>>
>>>>>>>>> I use SCR in order to provide my stream handlers. Here is he
>>>>>>>>> SCR.xml:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------------------------------------------------
>>>>>>>>> <component name="HttpUrlStreamHandler" immediate="true">
>>>>>>>>>  <implementation
>>>>>>>>> class="com.nextenso.http.agent.impl.HttpUrlStreamHandlerService"/>
>>>>>>>>>  <service>
>>>>>>>>>  <provide interface="org.osgi.service.url.URLStreamHandlerService"/>
>>>>>>>>>  </service>
>>>>>>>>>  <property name="url.handler.protocol">
>>>>>>>>>  http
>>>>>>>>>  https
>>>>>>>>>  </property>
>>>>>>>>> </component>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> In the Felix configuration properties, I have set the property
>>>>>>>>> "felix.service.urlhandlers=true"
>>>>>>>>> But it sounds like my http/https handlers are not invoked by the
>>>>>>>>> framework
>>>>>>>>> when I
>>>>>>>>> do the following:
>>>>>>>>>
>>>>>>>>>  HttpURLConnection uc = (HttpURLConnection) new
>>>>>>>>> URL("http://www.verisign.com/").openConnection();
>>>>>>>>>
>>>>>>>>> -> could anyone help about this problem ?
>>>>>>>>>
>>>>>>>>> (fwi, the same code works with KnopflerFish).
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> /pierre
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>>>                 
>>>>>>>               
>>>>>>
>>>>>>             
>>>>>           
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>>     
>
>
>
>