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, 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 >
