2016-10-03 22:12 GMT+02:00 Karl Pauls <[email protected]>: > On Mon, Oct 3, 2016 at 9:49 PM, Guillaume Nodet <[email protected]> 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. >
Ok, thx. Actually, I had a typo in my activator name, so I blamed the somewhat crypted code for the ClassNotFoundException ;-) > > regards, > > Karl > > > > > > 2016-10-03 18:14 GMT+02:00 Richard S. Hall <[email protected]>: > > > > > 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: [email protected] > > Web: http://fusesource.com > > Blog: http://gnodet.blogspot.com/ > > > > > > -- > Karl Pauls > [email protected] > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
