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