in terms of arch yes, the key feature is to have a tree classloader and not
a graph (drops all the build complexity of OSGi and enable scanning
pluggability, yeah).
In terms of service since the launcher is a monolith it has the key
advantage to be able to scan all then dispatch so I guess we can just have
a ServiceLoader kind of SPI for "module service" impls and order them as
needed. a ModuleService { setModuleServiceRegistry(Registry); } would then
do the trick probably, no need of fancy IoC for such low level framework
IMHO.Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 24 mars 2021 à 19:13, Jean-Baptiste Onofre <j...@nanthrax.net> a écrit : > Hi Romain, > > About OSGi, the way I did it (up to now), it’s as you describe: > > - Karaf "launcher" > — Libraries service > — Profiles service > — SpringBootModuleService > — OsgiModuleService > — MicroprofileModuleService (not yet started) > > The framework is only started when the first OSGi module is deployed. > > If the user deploys only SpringBoot apps in Karaf, he won’t have any OSGi > framework. > > Is it what you expected ? > > On Karaf "launcher", we have services available (for now just using > karaf.getService("id")). > > I would love your feedback here. Thoughts ? > > Regards > JB > > > Le 24 mars 2021 à 19:03, Romain Manni-Bucau <rmannibu...@gmail.com> a > écrit : > > > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <j...@nanthrax.net> a > > écrit : > > > >> Actually, spec like as DocuentBuilder would be rather a library, shared > by > >> all launchers. > >> > > > > Ok but what about jackson? the same? > > > > Joke apart what if spring-boot-app1 uses one impl and spring-boot-app2 > uses > > another one? > > > > Think at the end there is the JVM, the framework stack which is isolated > > from the app and the apps or it does not move the ball very far from what > > we have today. > > > > Until there is it is EE server - in terms of architecture not scope/impl. > > But the gold of this solution is the ability to configure the leakage > > between layers/profiles to let an app override and potentially > > aggregate/share parts. Obvious example is the http service which can leak > > in spring boot app to override the servlet layer enabling to admistrate > it > > globally. Another more advanced solution is to deploy app1 and app2 > called > > each other through a kafka topic and replace kafka stack by a local event > > (event admin or not is an impl detail), imagine the perf boost and admin > > simplicity it will bring - all that meaning saving a lot of green piece > of > > paper for managers ;). > > > > My only "?" as of today is: why OSGi, this technology is not really > needed > > for such a project (for ex this module provides it wihout OSGi > > > https://github.com/Talend/component-runtime/tree/master/container/container-core > ) > > and can bring several drawbacks like the slowness to upgrade libs due to > > meta, the blockers to add libs due to the lack of OSGi support, the > > enforcement of architecture teams to adopt OSGi to use that solution etc. > > Why not making OSGi a launcher as spring boot or microprofile, sounds to > be > > at the same level to me. > > > > > >> > >> I would rather say that Karaf 5 is a runtime in the way of launcher. If > we > >> consider an application server as launcher + some key turn features, > then > >> Karaf5 could be considered as an new light app server. > >> > >> You are right: for now, each spring boot app is in its own class loader, > >> embedding its own spring version. > >> However, a spring boot module (karaf 5 terminology uses module more than > >> app) can use a profile. A profile basically brings a class loader where > you > >> can override spring boot module dependencies. > >> > >> Great questions: Karaf 5 MVP is a first attempt, it will be refine for > >> sure. I just want to have a first running version to share with you all > and > >> chat about. > >> > >> Regards > >> JB > >> > >>> Le 24 mars 2021 à 16:55, Grzegorz Grzybek <gr.grzy...@gmail.com> a > >> écrit : > >>> > >>> Thanks for the insight ;) > >>> > >>> So first question that comes to my mind is - what will > >>> `javax.xml.parsers.DocumentBuilderFactory#newInstance()` return? I > guess > >> it > >>> depends on the layer. > >>> If this will be (via java.util.ServiceLoader#load()) be configured at > low > >>> layer, we can have the "application server aspect"... > >>> > >>> Is "application server" view of Karaf 5 emphasized (existing at all?) > >>> somehow? > >>> Is Karaf 5 going to be a "deployment platform to run different kinds of > >>> applications"? > >>> For "Spring Boot applications classloaders" - will many "Spring Boot > >>> Applications" be separated? If yes, then will each Spring Boot > >> Application > >>> "bring its own Spring"? Or will the Spring libraries be part of given > >> Karaf > >>> 5 release? > >>> > >>> sorry for chaotic questions ;) But these are quite natural, assuming > >>> "single JVM process" by default (is it?) > >>> > >>> regards > >>> Grzegorz Grzybek > >>> > >>> śr., 24 mar 2021 o 16:46 Jean-Baptiste Onofre <j...@nanthrax.net> > >> napisał(a): > >>> > >>>> Hi, > >>>> > >>>> Actually, you will have three class loader levels: > >>>> > >>>> - Level1: Karaf itself/Karaf services/libraries class loaders > >>>> - Level2: profiles class loader > >>>> - Level3: OSGi module running in the internal framework (inheriting > >> first > >>>> level) > >>>> - Level3: Spring Boot applications classloaders > >>>> - Level3: other kind of applications (micro profile, …) > >>>> > >>>> So, basically, framework will be used for OSGi modules mostly. > >>>> > >>>> Today, launchers are "isolated", but I will implement bridges. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 24 mars 2021 à 15:37, Grzegorz Grzybek <gr.grzy...@gmail.com> a > >>>> écrit : > >>>>> > >>>>> Hello > >>>>> > >>>>> OSGi Core R8 still assumes req/cap model[1] and resolution: > >>>>> > >>>>> The Framework must resolve bundles. > >>>>>> > >>>>> > >>>>> If OSGi (and thus resolution) is _internal_, what kind of "classpath" > >>>>> ("module path"?) will users see? Looking forward for 10000-feet > >> overview > >>>> of > >>>>> Karaf 5 ;) > >>>>> > >>>>> Is Connect specification[2] the inherent part of Karaf5? Is > "classpath" > >>>>> generally flat, hierarchical or irrelevant (?) by default? > >>>>> > >>>>> Anyway - the future looks bright ;) > >>>>> > >>>>> regards > >>>>> Grzegorz Grzybek > >>>>> === > >>>>> [1]: > >>>>> > >>>> > >> > https://docs.osgi.org/specification/osgi.core/8.0.0/framework.module.html#framework.module-resolving > >>>>> [2]: > >>>>> > >>>> > >> > https://docs.osgi.org/specification/osgi.core/8.0.0/framework.connect.html > >>>>> > >>>>> śr., 24 mar 2021 o 15:24 Jean-Baptiste Onofre <j...@nanthrax.net> > >>>> napisał(a): > >>>>> > >>>>>> Hi guys, > >>>>>> > >>>>>> As you probably know, we are working on first Karaf 5 MVP, which is > a > >>>>>> complete Karaf refactoring. > >>>>>> > >>>>>> We will share some details soon, but I can already inform you that > >>>>>> internally, it’s powered by OSGi R8 (but you will see that it’s more > >> an > >>>>>> internal point). > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>> > >>>> > >> > >> > >
