On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet <gno...@apache.org> wrote:
> An extension sounds doable. > However, I found something weird: > > https://github.com/apache/felix/blob/trunk/framework/ > src/main/java/org/apache/felix/framework/ExtensionManager.java#L505-L507 > > Is that expected that the framework is using the classloader loading the > framework instead of the classloader from the extension bundle ? Yeah, that is a little confusing but the point is that the extension bundle will have the same class loader. It's content has been added to the class loader of felix at this point (hopefully) and the wiring we use for the extension bundle will just return the class loader of felix (or at least the ExtensionManager). Granted, it looks a little confusing so you could argue it should still get the class loader via the normal api (never mind it being the same result). I don't think that should cause any issues. regards, Karl > > 2016-10-03 18:14 GMT+02:00 Richard S. Hall <he...@ungoverned.org>: > > > On 10/3/16 12:02 , Guillaume Nodet wrote: > > > >> I have a use case where the wiring is a bit complicated. > >> Karaf uses the felix resolver to compute the full wiring and then > applies > >> it. > >> At this point, all the bundles are resolved and started correctly. > >> If Karaf is restarted, the framework restarts and resolves the bundles > on > >> its own, using a bad solution (because the resolver is not greedy) which > >> leaves some bundles in a non resolvable state (i.e. without refreshing > >> some > >> bundles). > >> At this point, I've tried to have Karaf stores the computed wiring so > that > >> it can be re-applied when restarting. Unfortunately, in my very case, > the > >> wiring is done in such a way that nearly all bundles needs to be > >> refreshed, > >> even the one containing the bundle hook, so that's bound to deadlocks > and > >> various problems. > >> > >> I'm left with two solutions : > >> * implement a framework extension to minimize the chances to have to > >> refresh the bundle containing the resolver hook > >> * implement a persistent resolution in felix > >> > >> I don't mind either way, but I wonder if instead of implementing it in > >> Karaf, it could be done in the framework in a slightly more robust way > >> (i.e. not contained in a bundle which itself is bound to refreshes, > >> etc...) > >> and may be reused by others. > >> > >> Thoughts ? > >> > > > > I don't have a strong opinion, but we had always tried to avoid caching > > too much run-time state in the framework cache because this increases the > > opportunity for the framework cache to become corrupt and then > subsequently > > fail to restart. In a perfect world, it seems like it would be nice if > this > > could be a resolver hook implemented externally (and generically) to > > provide a management agent service where an agent could attempt to save > > resolution state and the resolver hook would be responsible for trying to > > recreate the saved state upon subsequent startups. Then the framework's > > cache stays out of the whole scenario. Perhaps that is wishful thinking. > > > > I believe Equinox' resolves are persisted across executions, so it is not > > unheard of and does have benefits if implemented well of reducing startup > > time on subsequent executions by avoid re-resolving complex systems. > > > > -> richard > > > > > >> Guillaume > >> > >> > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > -- Karl Pauls karlpa...@gmail.com
