I will add that it is rather difficult to retrofit an existing framework or library for OSGi when it has extensive use of ThreadContext class loaders and other hacks. It's important to catch any design problems before a x.0 release so that backwards compatibility can be maintained.
On 23 May 2016 at 09:27, Arjun Panday <[email protected]> wrote: > With OSGi, you have to be "all in" ; >> >> >> ... like OSGi minus Classloading. >> >> > But what's left of OSGi without classloading? > > I'd like to argue that OSGi is not so much a framework as it is a > philosophy; much like immutability I would say, and therefore, yes, you > have to be all in. (It's also possible to mix mutable and immutable code, > but it becomes a mess). > > OSGi the philosophy of modularity; and it enforces modularity with only > one simple rule: > > "thou shall not instanciate a class that does not belong to your module" > > In order to enforce this, it creates a graph of classloaders with explicit > exports and imports and that's what OSGi is about really. > Everything else; the service layer and dynamic dependency injection, > modular packaging, modular configuration, flexible plugins, hot deploy, > multiple versions.. everything is a direct consequence of the first rule. > > That's why you should be all in, and why OSGi class loaders are your > friends, not your enemy. (ThreadContext classloaders are your enemies!) > > > Arjun > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
