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/08 14:50:02 UTC
{Disarmed} Re: URLStreamHandler service
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
>>
>>
>>
>
>
>
>
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
{Disarmed} Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by Pierre De Rop <pi...@alcatel-lucent.fr>.
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: URLStreamHandler service
Posted by Karl Pauls <ka...@gmail.com>.
> 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 <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
>>>
>>>
>>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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. ;-)
-> richard
> 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
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by Karl Pauls <ka...@gmail.com>.
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
Re: {Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
{Disarmed} Re: {Disarmed} Re: URLStreamHandler service
Posted by Pierre De Rop <pi...@alcatel-lucent.fr>.
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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: {Disarmed} Re: URLStreamHandler service
Posted by Karl Pauls <ka...@gmail.com>.
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
>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org