You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Pierre De Rop <pi...@alcatel-lucent.fr> on 2008/10/21 10:48:11 UTC
{Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
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
>>
>>
>>
>
>
>
>
Re: {Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by Karl Pauls <ka...@gmail.com>.
Hi Pierre,
I did implement the feature. You can now start the current trunk with
-Dfelix.service.urlhandlers.override=true in order to allow
URLStreamHandler and ContentHandler services to override the built-in
handlers. Please test and close the JIRA issue if it works for you.
regards,
Karl
On Tue, Oct 21, 2008 at 10:32 AM, Karl Pauls <ka...@gmail.com> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
{Disarmed} Re: {Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler
service
Posted by 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: {Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by Karl Pauls <ka...@gmail.com>.
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
>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org