Hi Richard, Looking at: http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/Bundle.html#adapt(java.lang.Class)
...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. Thanks, Christopher On 24 July 2012 16:04, Richard S. Hall <[email protected]> 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<[email protected]> > For additional commands, e-mail: [email protected] > >
