felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Issues running Felix 1.2.1 and 2.0.1 in the same VM
Date Thu, 26 Nov 2009 15:07:12 GMT
On Thu, Nov 26, 2009 at 2:49 PM, Don Brown <mrdon@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 <karlpauls@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 <karlpauls@gmail.com> wrote:
>>> On Thu, Nov 26, 2009 at 8:14 AM, Chris Kiehl <ckiehl@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
>>> karlpauls@gmail.com
>>>
>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>>
>



-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message