On Thu, Nov 26, 2009 at 11:55 PM, Don Brown <mr...@twdata.org> wrote: > On Fri, Nov 27, 2009 at 2:07 AM, Karl Pauls <karlpa...@gmail.com> wrote: >> What won't work is URLStreamHandlerServices registered inside the >> framework of the version not being the first. Is that actually >> something you need? I can look into it if you do (I think I can see a >> potential workaround) but It isn't worth it if you don't have bundles >> that expose URLStreamHandlerServices in the first place... > > Well, I know we don't use that explicitly and if Spring DM doesn't > either, we are probably in good shape. Thanks for the help,
Spring DM only needs the bundle: protocol so you should be good. Otherwise let me know. regards, Karl > Don > >> >> regards, >> >> Karl >> >>> Don >>> >>> On Thu, Nov 26, 2009 at 10:14 PM, Karl Pauls <karlpa...@gmail.com> wrote: >>>> Hm, on second thought we still have an issue when several versions of >>>> felix are running inside the same jvm. I believe that with felix 2.0.2 >>>> or 1.2 we should do the right thing for the bundle: protocol (which is >>>> what you need iirc) but we probably wont be able to find >>>> URLStreamHandlerServices from the framework that was registered last. >>>> I'm working on a patch which should fix this issue at least if the >>>> next version of felix is started first. >>>> >>>> Again, we just didn't think about this case until recently but its on >>>> the radar now and I will make sure that we stay backwards compatible >>>> starting with felix 2.0.2 from now on for sure. >>>> >>>> regards, >>>> >>>> Karl >>>> >>>> On Thu, Nov 26, 2009 at 9:20 AM, Karl Pauls <karlpa...@gmail.com> wrote: >>>>> On Thu, Nov 26, 2009 at 8:14 AM, Chris Kiehl <cki...@atlassian.com> wrote: >>>>>> Hi everyone! >>>>>> >>>>>> We ran into an issue with running two webapps with different versions of >>>>>> Felix (1.2.1 and 2.0.1) in the same VM. The symptom we see is that it >>>>>> can't find the the framework context as described in an existing issue >>>>>> (<http://issues.apache.org/jira/browse/FELIX-1834>). The problem was >>>>>> that the class name of the class loader that is used to detect the >>>>>> context changed between 1.2.1 and 2.0. The committed fix only helps if >>>>>> the application which uses Felix 2.0 starts up first, because then the >>>>>> 2.0 version of URLHandlers is used. If the application with Felix 1.2 >>>>>> starts up first you run into the same problem as before. So I patched >>>>>> Felix 1.2 as well to check against the class name of the Felix 2.0 class >>>>>> loader, which makes the applications apparently run fine, no matter in >>>>>> which order they start. >>>>>> >>>>>> Even though it seems to work fine, I'm a bit worried that the Felix 2.0 >>>>>> application is using the Felix 1.2 URLHandlers class and dependencies. >>>>>> Do you guys see any issues with that? >>>>>> >>>>>> I don't know much about Felix, but wouldn't it be better to have a very >>>>>> small dispatching URLStreamHandlerFactory which chooses the actual >>>>>> URLStreamHandlerFactory to use based on the class loader (like it does >>>>>> for the context now). That would minimize the overlap of code between >>>>>> versions of Felix. >>>>> >>>>> Well, this should be fixed in felix 2.0.2. At least you can now run >>>>> felix 2.0.2 and assuming it starts first, older versions of felix are >>>>> not an issue. Furthermore, you can disable urlhandlers per framework >>>>> so even if its the other way around, you can disable the urlhandlers >>>>> for felix 1.2 and enable it for felix 2.0.2. >>>>> >>>>> Granted, it isn't optimal that we had this bug getting in but at least >>>>> it should be fixed now. >>>>> >>>>> regards, >>>>> >>>>> Karl >>>>> >>>>>> Cheers, >>>>>> Chris >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Karl Pauls >>>>> karlpa...@gmail.com >>>>> >>>> >>>> >>>> >>>> -- >>>> Karl Pauls >>>> karlpa...@gmail.com >>>> >>> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> > -- Karl Pauls karlpa...@gmail.com
