> On 23 mei 2016, at 16:27, Arjun Panday <apan...@apache.org> wrote: > With OSGi, you have to be "all in" ; > ... like OSGi minus Classloading. > But what’s left of OSGi without classloading? Actually a surprising amount of functionality :-) Karl Pauls (who did PojoSR which I think is the parent of OSGi connect at Apache?) showed you can use DS perfectly on this model along with many standard implementations.
The things you lack are bundle uninstall, private code, Bundle classpath, and a
large number of protections. Bundle install, start, stop, and the complete
service layer all work fine.
> 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”
I like that! This truly is the essence! Very well said.
> 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!)
I would add that statics make pretty good enemies as well.
Kind regards,
Peter Kriens
>
>
> Arjun
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
