felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher BROWN <br...@reflexe.fr>
Subject Re: OSGi 4.3 and Felix 4.0: is PackageAdmin.refreshPackages() obsolete?
Date Tue, 24 Jul 2012 14:16:37 GMT
Hi Richard,

Looking at:

...I don't see any specific mention of the special case for the system
bundle.  Of course, I don't doubt it :-)  but is this detailed somewhere?
 For example, I'd like to know if there are any differences in behavior, if
I can just replace the current call to PackageAdmin (as in, call "adapt()"
at the same point in the code execution path as I currently call
"refreshPackages()"), and so on...

Specifically, I recall from the book "OSGi in Action" - which you may know
:) - p112, section 3.5.3, that the "refreshPackages()" approach is a bit of
a hack.  I'd be more generally interested to find out about how OSGi v4.3
improves this, especially any new related capabilities.


On 24 July 2012 16:04, Richard S. Hall <heavy@ungoverned.org> wrote:

> On 7/24/12 09:27 , Christopher BROWN wrote:
>> Hi,
>> The project I'm working on is (still) based on Felix 3.2.2, because we
>> don't know yet how much work is involved moving *effectively* to Felix 4.x
>> (to make use of generics, upgrading to more recent compendium packages
>> such
>> as EventAdmin, recompiling Felix from source using Java 6 to avoid issues
>> with the "-jsr14" source option...).
>> However, as we're embedding Felix from a host application, I can't seem to
>> find specific information in the OSGi 4.3 specs about the relationship
>> between PackageAdmin and the new "wiring" stuff, which IIRC makes
>> PackageAdmin more or less obsolete (the host application in our case has
>> similar functionality to FileInstall and calls PackageAdmin.refresh()
>> after
>> updating bundles).
>> Is PackageAdmin.refreshPackages() still officially the "proper" solution,
>> or is it obsolete?  If so, where should I look to find out how to migrate
>> to any newer, better "official" solution?
> It is deprecated. The new approach is to use Bundle.adapt(FrameworkWiring.
> **class) on the system bundle.
> -> richard
>> Thanks,
>> Christopher
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@felix.**apache.org<users-unsubscribe@felix.apache.org>
> For additional commands, e-mail: users-help@felix.apache.org

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