>> 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<[email protected]> 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 >>>> [email protected] >>>> >>>> >>> >> >
