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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>> 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
>>>>> <[EMAIL PROTECTED]> 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
>>>>>>> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Karl Pauls
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
