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 >>>> karlpa...@gmail.com >>>> >>> >> >> > > > > -- > Karl Pauls > karlpa...@gmail.com >
