felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nima Kaviani <nima.kavi...@gmail.com>
Subject Re: Enforcing Class Unloading
Date Wed, 01 Dec 2010 08:04:37 GMT
Thanks a lot Chris and Richard for the hints.

I tried refreshing packages for the bundles that I initially assumed were
affected. An immediate outcome was running into the "unresolved constraint
violation" exception due to inconsistent class spaces. Digging into the
previous posts and looking into the wirings between packages, I was able to
iteratively figure out which bundles need to be refreshed an in what order
in order to properly propagate the changes into the using bundles.

I have a question now. Is there a way to figure out these wirings
programmatically. Looking into Spring's extender library, it seems like they
offer a ServiceDependencySorter interface that figures out the dependency
wirings between services. My question is, can it be figured out for implicit
code-related dependencies that Richard has pointed out too? I am sure Felix
is already doing it internally, but is anything exposed for external use as
well?

cheers,
-Nima

On Tue, Nov 30, 2010 at 7:09 AM, Richard S. Hall <heavy@ungoverned.org>wrote:

> On 11/30/10 5:03, Christopher Brind wrote:
>
>> After installing your replacement bundle make sure you refresh the
>> packages.
>>
>
> This assumes that there is a code-related dependency among the bundles and
> there might not be. However, if there is, then this would be the correct
> thing to do.
>
> If there isn't, then there isn't much that OSGi can do. The OSGi model
> assumes that bundles obey the lifecycle of a service, so when it goes away
> you should stop using it and the objects it generated.
>
> This does create extra work for the clients of services, which is one of
> the reasons why OSGi moved away from active client models like the HTTP
> Service, to the whiteboard pattern.
>
> -> richard
>
>
>  Cheers,
>> Chris
>>
>>
>> On 30 November 2010 09:53, Nima Kaviani<nima.kaviani@gmail.com>  wrote:
>>
>>  Hello all,
>>>
>>> I have a ClassLoading issue with my bundles and I hope you can help me
>>> solve
>>> it.
>>>
>>> The problem is that I have two versions of a bundle ( let's name them A
>>> and
>>> A' ) exposing some services to other bundles in the application. Both
>>> versions have quite identical classes except for bundle A having some
>>> extra
>>> profiling code in all of its classes compared bundle A. Each bundle A or
>>> A'
>>> shares instances from its classes with other bundles either through
>>> service
>>> hooks or through explicit export- and import-package constructs.
>>>
>>> The problem I am facing is that when I swap A with A', the objects shared
>>> as
>>> OSGi services get swapped as expected, however the classes shared through
>>> explicit import and export constructs don't get swapped. Explicitly said,
>>> some of the classes from A remain loaded and accessible to classes in
>>> other
>>> bundles through the defining class loader that for the first time loads
>>> those classes. However, classes providing a service are swapped as a
>>> matter
>>> of replacing A with A'.
>>>
>>> I believe this is mainly because the defining loader that initially loads
>>> classes from A remains reachable by some other bundles in the
>>> application.
>>> However, it seems very difficult for me to detect which bundles are
>>> holding
>>> references and to which classes from the initially loaded classes in A. I
>>> wonder if there is any way to explicitly enforce the initially loaded
>>> classes to get garbage collected so that every single time I swap A and
>>> A',
>>> I get proper wiring for classes in each bundle as expected.
>>>
>>> I would very much appreciate any help or hint,
>>> -Nima
>>>
>>> --
>>> http://nima.magic.ubc.ca
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
http://nima.magic.ubc.ca

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message