You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Royce Ausburn <ro...@inomial.com> on 2009/11/10 04:13:43 UTC
URLStreamHandlers and the java.protocol.handler.pkgs system property
G'day all,
I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
Cheers!
--Royce
Re: URLStreamHandlers and the java.protocol.handler.pkgs system
property
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/12/09 22:28, Royce Ausburn wrote:
>>> I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
>>>
>>>
>> I am not sure I understand. The "-D" option is used to define a system property...thus this is already looked up via a system property in the Felix framework. I think this is how Java defines it to work, since "java.protocol.handler.pkgs" is defined by the JRE, not us.
>>
>> So, you should be able to set this property in your startup code. It is initialized in a static block, however, so you should set the system property before trying to do anything with any framework classes, since the property is only read once.
>>
>>
> I believe the static block will run before any code of mine will ever run, though, because the framework is loaded up by the application container.
>
Ok, I understand the issue now...you are not always in control of the
startup.
Yes, you should do what Karl says if you can. All you need to do is
create a bundle that registers an URLStreamHandlerService and then the
framework's URL Handlers service will use it automatically.
Not sure if any one as a demo for this, but grab the core OSGi spec and
read about URL Handlers Service and then go to our tutorial on how to
create a bundle that registers a service and adapt it to register an
URLStreamHandlerService.
-> richard
> --Royce
>
>
>
>
>> -> richard
>>
>>
>>> I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
>>>
>>> I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
>>>
>>> Thoughts?
>>>
>>> --Royce
>>>
>>> On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>>>
>>>
>>>
>>>> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>>>>
>>>> --Royce
>>>>
>>>> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>>>>
>>>>
>>>>
>>>>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>>>>> Let us know if you run into any difficulties with that as it would be
>>>>> a bug if that doesn't work :-)
>>>>>
>>>>> regards,
>>>>>
>>>>> Karl
>>>>>
>>>>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn<ro...@inomial.com> wrote:
>>>>>
>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>>>>
>>>>>> Sorry - must have got a wire crossed.
>>>>>>
>>>>>> --Royce
>>>>>>
>>>>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> G'day all,
>>>>>>>
>>>>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>>>>
>>>>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>>>>
>>>>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>>>>
>>>>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>>>>
>>>>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>> --Royce
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Karl Pauls
>>>>> karlpauls@gmail.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system property
Posted by Royce Ausburn <ro...@inomial.com>.
>> I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
>>
>
> I am not sure I understand. The "-D" option is used to define a system property...thus this is already looked up via a system property in the Felix framework. I think this is how Java defines it to work, since "java.protocol.handler.pkgs" is defined by the JRE, not us.
>
> So, you should be able to set this property in your startup code. It is initialized in a static block, however, so you should set the system property before trying to do anything with any framework classes, since the property is only read once.
>
I believe the static block will run before any code of mine will ever run, though, because the framework is loaded up by the application container.
--Royce
> -> richard
>
>> I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
>>
>> I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
>>
>> Thoughts?
>>
>> --Royce
>>
>> On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>>
>>
>>> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>>>
>>> --Royce
>>>
>>> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>>>
>>>
>>>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>>>> Let us know if you run into any difficulties with that as it would be
>>>> a bug if that doesn't work :-)
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn<ro...@inomial.com> wrote:
>>>>
>>>>> Hi again,
>>>>>
>>>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>>>
>>>>> Sorry - must have got a wire crossed.
>>>>>
>>>>> --Royce
>>>>>
>>>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>>>
>>>>>
>>>>>> G'day all,
>>>>>>
>>>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>>>
>>>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>>>
>>>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>>>
>>>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>>>
>>>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> --Royce
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>>
>>>
>>
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system
property
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 11/12/09 7:46, Royce Ausburn wrote:
> Hi again,
>
> I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
>
I am not sure I understand. The "-D" option is used to define a system
property...thus this is already looked up via a system property in the
Felix framework. I think this is how Java defines it to work, since
"java.protocol.handler.pkgs" is defined by the JRE, not us.
So, you should be able to set this property in your startup code. It is
initialized in a static block, however, so you should set the system
property before trying to do anything with any framework classes, since
the property is only read once.
-> richard
> I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
>
> I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
>
> Thoughts?
>
> --Royce
>
> On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>
>
>> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>>
>> --Royce
>>
>> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>>
>>
>>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>>> Let us know if you run into any difficulties with that as it would be
>>> a bug if that doesn't work :-)
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn<ro...@inomial.com> wrote:
>>>
>>>> Hi again,
>>>>
>>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>>
>>>> Sorry - must have got a wire crossed.
>>>>
>>>> --Royce
>>>>
>>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>>
>>>>
>>>>> G'day all,
>>>>>
>>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>>
>>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>>
>>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>>
>>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>>
>>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>>
>>>>> Cheers!
>>>>>
>>>>> --Royce
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>>
>>
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system property
Posted by Royce Ausburn <ro...@inomial.com>.
Hey Karl,
> Well, handlers are cached by the jvm so there shouldn't be any
> unstable handlers for a given protocol except that they are unstable
> by definition as you can just write a bundle that exposes a
> URLHandlers service. In this case, the framework will just delegate to
> that one as long as its there. Is that really not an option for you?
Do you mean writing a bundle? I'm open to that. At this point I don't know enough about bundles nor osgi in general to be able to make a call. I'm really just trying to get everything working for the moment, noting down things that I feel are hacks so I can fix them up on a 2nd pass.
As for the JVM option - it's working for the moment, and I realise that I can set up domain templates that remember this configuration for me so it's not like I'll be kicking myself in 6 months time.
I'd really prefer that my application was fully contained within its WAR... As far as I can tell, unless I want to make my WAR a bundle that registers a URLHandlers service there's no way I'll be able to do this while I need URL handlers?
>
> I'm not necessarily against the idea of allowing the property to
> change during runtime but it needs careful testing as the URLHandlers
> are a minefield in regard to deadlocks, classloading cycles, and
> performance. Feel free to add a jira issue for this feature and I will
> try to look into it but it might take a while...
Actually, if it's not simple it's probably not worth the effort as this doesn't entirely solve my problem. I'd still need to deploy extra jars in $DOMAINDIR/lib/ext, I believe.... I might as well write a bundle ;)
OTOH, seeing as the JVM consults the option at runtime, perhaps consistency is a compelling enough reason for you? I'd be happy to open a jira issue.
Thanks for your responses, Karl =)
--Royce
>
> On Thu, Nov 12, 2009 at 1:46 PM, Royce Ausburn <ro...@inomial.com> wrote:
>> Hi again,
>>
>> I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
>>
>> I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
>>
>> I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
>>
>> Thoughts?
>>
>> --Royce
>>
>> On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>>
>>>
>>> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>>>
>>> --Royce
>>>
>>> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>>>
>>>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>>>> Let us know if you run into any difficulties with that as it would be
>>>> a bug if that doesn't work :-)
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn <ro...@inomial.com> wrote:
>>>>> Hi again,
>>>>>
>>>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>>>
>>>>> Sorry - must have got a wire crossed.
>>>>>
>>>>> --Royce
>>>>>
>>>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>>>
>>>>>> G'day all,
>>>>>>
>>>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>>>
>>>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>>>
>>>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>>>
>>>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>>>
>>>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>>>
>>>>>> Cheers!
>>>>>>
>>>>>> --Royce
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpauls@gmail.com
>>>>
>>>
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system
property
Posted by Karl Pauls <ka...@gmail.com>.
Well, handlers are cached by the jvm so there shouldn't be any
unstable handlers for a given protocol except that they are unstable
by definition as you can just write a bundle that exposes a
URLHandlers service. In this case, the framework will just delegate to
that one as long as its there. Is that really not an option for you?
I'm not necessarily against the idea of allowing the property to
change during runtime but it needs careful testing as the URLHandlers
are a minefield in regard to deadlocks, classloading cycles, and
performance. Feel free to add a jira issue for this feature and I will
try to look into it but it might take a while...
regards,
Karl
On Thu, Nov 12, 2009 at 1:46 PM, Royce Ausburn <ro...@inomial.com> wrote:
> Hi again,
>
> I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
>
> I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
>
> I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
>
> Thoughts?
>
> --Royce
>
> On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>
>>
>> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>>
>> --Royce
>>
>> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>>
>>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>>> Let us know if you run into any difficulties with that as it would be
>>> a bug if that doesn't work :-)
>>>
>>> regards,
>>>
>>> Karl
>>>
>>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn <ro...@inomial.com> wrote:
>>>> Hi again,
>>>>
>>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>>
>>>> Sorry - must have got a wire crossed.
>>>>
>>>> --Royce
>>>>
>>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>>
>>>>> G'day all,
>>>>>
>>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>>
>>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>>
>>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>>
>>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>>
>>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>>
>>>>> Cheers!
>>>>>
>>>>> --Royce
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Karl Pauls
>>> karlpauls@gmail.com
>>>
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: URLStreamHandlers and the java.protocol.handler.pkgs system property
Posted by Royce Ausburn <ro...@inomial.com>.
Hi again,
I've got my handler working properly now, but I'm unhappy that I need to add the -Djava.protocol.handler.pkgs=my.pkg.prefix property to my application container's startup configuration. Ideally I could update the system property in some startup code and have one less thing to make sure is configured. This works when I run my application in a "standalone" mode where my application starts up Jetty and manually registers its servlets, and it seems to work without the jvm-option in glassfish 2.1.1 (pre felix, I believe).
I appreciate that this change may cause the handler for a particular protocol to be unstable depending upon when the system property is set, and that's a compelling reason to not do this, but I felt it'd be worth discussing. I'm certainly no expert in your domain, so please feel free to get the hell off your mailing list ;)
I guess I'm reeling from how much configuration I'm finding I need to do as I move to Java EE... perhaps I just need to harden up ;)
Thoughts?
--Royce
On 11/11/2009, at 2:09 AM, Royce Ausburn wrote:
>
> Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
>
> --Royce
>
> On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
>
>> Yes, we do fallback to the java.protocol.handler.pkgs system property.
>> Let us know if you run into any difficulties with that as it would be
>> a bug if that doesn't work :-)
>>
>> regards,
>>
>> Karl
>>
>> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn <ro...@inomial.com> wrote:
>>> Hi again,
>>>
>>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>>
>>> Sorry - must have got a wire crossed.
>>>
>>> --Royce
>>>
>>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>>
>>>> G'day all,
>>>>
>>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>>
>>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>>
>>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>>
>>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>>
>>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>>
>>>> Cheers!
>>>>
>>>> --Royce
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system property
Posted by Royce Ausburn <ro...@inomial.com>.
Just wanted to confirm I'm a fool and it's all working beautifully. Sorry for the false alarm =)
--Royce
On 10/11/2009, at 8:43 PM, Karl Pauls wrote:
> Yes, we do fallback to the java.protocol.handler.pkgs system property.
> Let us know if you run into any difficulties with that as it would be
> a bug if that doesn't work :-)
>
> regards,
>
> Karl
>
> On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn <ro...@inomial.com> wrote:
>> Hi again,
>>
>> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>>
>> Sorry - must have got a wire crossed.
>>
>> --Royce
>>
>> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>>
>>> G'day all,
>>>
>>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>>
>>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>>
>>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>>
>>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>>
>>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>>
>>> Cheers!
>>>
>>> --Royce
>>>
>>
>>
>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
>
Re: URLStreamHandlers and the java.protocol.handler.pkgs system
property
Posted by Karl Pauls <ka...@gmail.com>.
Yes, we do fallback to the java.protocol.handler.pkgs system property.
Let us know if you run into any difficulties with that as it would be
a bug if that doesn't work :-)
regards,
Karl
On Tue, Nov 10, 2009 at 8:16 AM, Royce Ausburn <ro...@inomial.com> wrote:
> Hi again,
>
> I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
>
> Sorry - must have got a wire crossed.
>
> --Royce
>
> On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
>
>> G'day all,
>>
>> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>>
>> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>>
>> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>>
>> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>>
>> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>>
>> Cheers!
>>
>> --Royce
>>
>
>
--
Karl Pauls
karlpauls@gmail.com
Re: URLStreamHandlers and the java.protocol.handler.pkgs system property
Posted by Royce Ausburn <ro...@inomial.com>.
Hi again,
I've been doing a little more reading of the code and I think I was mistaken. Looks like the lookup is done properly in URLHandlers.getBuiltInStreamHandler().
Sorry - must have got a wire crossed.
--Royce
On 10/11/2009, at 2:13 PM, Royce Ausburn wrote:
> G'day all,
>
> I'm porting a legacy application to Java EE and having trouble running my app under glassfish v3 prelude.
>
> The problem is URL stream handlers. My application used to register a URLStreamHandlerFactory against java.net.URL, but that doesn't work anymore as felix registers a factory before my app starts. So I decided to use the java.protocol.handler.pkgs system property only to find that it's not effective. After checking out Felix from svn I found the URLHandlers class honours handlers for some default protocols (file, ftp, http, https, jar), but it seems that any other protocols are discarded.
>
> I'm not familiar with osgi... Is it intended behaviour to ignore the rest? If so, I'm interested to know why.
>
> I suppose I have the option to write a bundle and register that, but I'm not keen on it... The application's handlers use classes from the application and working out how this would work in a bundle isn't something I'd like to spend my time on as I have deadlines to meet =(
>
> Is there any way I can get around this? Would it be possible to have the URLHandler class fall back to the system properties if no bundle has been registered?
>
> Cheers!
>
> --Royce
>