On Thu, Nov 26, 2009 at 2:49 PM, Don Brown <mr...@twdata.org> wrote: > Thanks for the help Karl. Unfortunately, we'll be stuck supporting > 1.2.x for a while to come. To make matters worse, we can't guarantee > webapp start loader, as each felix instance is embedded in a webapp, > and the order of webapp initialization is undefined. > > Anything we can do to our 1.2 branch or at least any pointers on what > to look at? If the bundle: protocol works, what exactly won't?
In both cases, i.e., 1.2 is the first or 2.0 is the first, the bundle: protocol should work which is all felix needs for normal operation. 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... 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
