> 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.
>>
>
> Yes, we (i.e., you) should. ;-)

:-)

https://issues.apache.org/jira/browse/FELIX-756

regards,

Karl

> -> richard
>
>> 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]
>>>
>>>
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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]

Reply via email to