Just to be concrete about Karaf wording: - Library: class loader at Karaf system level - Service: loaded at Karaf system level - Profile: class loader (not attended at karaf system level) - Module: one class loader eventually with profile parent class loader and karaf system classloader
I hope it helps ;) Regards JB > Le 25 mars 2021 à 10:33, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > > Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek <gr.grzy...@gmail.com > <mailto:gr.grzy...@gmail.com>> a > écrit : > >> Thanks Romain for the details! (see inline) >> >> czw., 25 mar 2021 o 08:31 Romain Manni-Bucau <rmannibu...@gmail.com> >> napisał(a): >> >>> Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr.grzy...@gmail.com> a >>> écrit : >>> >>>> Good morning! >>>> >>>> śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rmannibu...@gmail.com> >>>> napisał(a): >>>> >>>>> 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). >>>>> >>>> >>>> Graph → Tree sounds like OSGi → JavaEE... >>>> This can prevent user feature to install a bundle that overrides system >>>> services.... I know that (without "134 Subsystem Service Specification" >>> and >>>> without hooks) effectively OSGi runtime is "flat" - every bundle wire >> is >>>> equal and resolution rules apply. Also every OSGi service is equal and >>>> service rank is taken into account. >>>> >>> >>> Yes and no, a service registration can still use @Priority or a SPI >> method >>> to be sorted, only thing it can prevent is to put conflicting deps in the >>> same bootstrap classloader (that said these days OSGi is rarely used for >>> that and since by design the bootstrap loader will be a single app - ie >>> without any conflict at build time - it is actually sane). >>> >> >> In JavaEE, a WAR can (mostly) configure some providers, so e.g., >> DocumentBuilderFactory may return WAR-specific instance. But it's not >> possible to affect this service loading in other WARs. >> In OSGi, a bundle can register some service that'll become the valid >> service for remaining bundles. >> So I understand that Karaf 5 keeps the OSGi philosophy here, right? >> > > Yes and not, the small language trick is do you speak of bootstrap services > or profile or app in Karaf 5. > Bootstrap services can do whatever they want (ie same as OSGi in terms of > impact even if technicaly it is not linked) but all other layers > (profile+app) must stay static and almost immutable. > > >> >> >>> >>> >>>> >>>> I'm trying to imagine how "it’s powered by OSGi R8 (but you will see >> that >>>> it’s more an internal point)" works - is the "Level1: Karaf itself" a >>>> graph-based layer of bundle classloaders, while applications are given >>>> their own single classloader (kind of like WebSphere is (was?) based on >>>> OSGi and WARs/EARs hand single classloader or like Wildfly/EAP that's >>>> internally a graph of JBoss Modules, while WARs/EARs have single >>>> classloader)? >>>> >>>> java.util.ServiceLoader is dynamic in nature and is a final (IMO) and >>> quite >>>> elegant discovery solution in tree-(ClassLoader)-based monoliths where >>> you >>>> "deploy" applications. And it's reflection based. >>>> >>> >>> Last point does not have to be true, see some graalvm integrations for >>> example, it is reflection less depends how you handle the build phase but >>> being reflection "full" by default enables to keep the tooling (testing) >>> working without breaking your IDE. >>> >> >> Mind that I'm not very experienced with Graal/Quarkus, so my questions may >> be invalid ;) >> > > I was expecting it to come at some point - and btw we can note the fun > thing that the big change is GraalVM but everybody speaks of Quarkus which > is just a rebranding of already existing things, no technology jump by > itself ;). > My vision is that karaf 5 fulfills the microservices pitfalls and drawback > by bringing back a well know and secure deployment alternative to all that. > Indeed graal-ifying your app will make it save some memory, maybe some CPU > cycle in some cases but if you optimize your java code you can get the same > in terms of CPU cycles (and even faster in some cases). > In terms of bootstrap you can same a few ms due to the classloading but not > much more and CDS already solves part of it (at the cost of memory). > So for long running apps graal cost is wayyyyyy more than the runtime gain > and I guess it is where Karaf 5 will sit, long running aggregated and > unified apps (by providing a single admin interface for all kind of apps > and not a different one for spring/spring-boot, microprofile, ee, osgi etc). > > Hope it makes sense and I'm not too far from what JB had in mind but this > is where I see a looot of value for such a design. > > >> >> >>> >>> >>>> How about graal/quarkus? >>>> Let me be clear here - quarkus/graal/native approach is cool and makes >>> Java >>>> great again™, but I know that "enteprise" still likes the idea of >>>> "application servers", so I hope Karaf5 is NOT going to be >>>> "Kubernetes/OpenShift first" - long running processes with reflection >> and >>>> dynamic classloading are still relevant. >>>> >>> >>> Can you precise it there? Quarkus has two modes: JVM (where it is >>> equivalent to most microprofile servers without the standard/spec >> support) >>> and native mode (where arthur does the same closer to graalvm). >>> First mode does not need much but last one does not concern karaf 5 AFAIK >>> since spring-boot has its own graal integration, microprofile servers too >>> (potentially EE ones too even if I didnt see one yet) and OSGi has its >> own >>> through winegroewer so overall Karaf 5 sounds like the aggregator >> platform >>> which would fallback on dropping it to be graal compliant (since you'll >>> drop classloaders which makes all the power of the solution. >>> >> >> I imagine that Quarkus/Graal is designed mostly to develop apps that can >> quickly start/stop and "application servers" is not the most desired goal >> here. >> And I was thinking about the native mode, where everything is mostly set up >> at build time. >> >> >> >>> >>> >>>> >>>> >>>>> 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. >>>>> >>>> >>>> So clear distinguishing between "applications" and "server plugins" >> (with >>>> e.g., replaceable Jackson as JSON provider) - am I interpreting your >>>> statements correctly Romain? >>>> >>> >>> For example yes even if I suspect the services should stick to very >>> technical layers and isolated from the profile+app loaders so means >> jackson >>> from the bootstrap loader shouldnt be usable in an app but you could >>> configure it to leak (in the profile - ie the parent classes to use). >>> Very generally services shouldnt leak but profiles will so a provider >> would >>> sit in a profile loader IMHO. >>> Services would be more about logging integration, http integration etc >> but >>> wouldnt leak as such but as a karaf 5 plugin instrumenting the >> profile/app >>> loader to do the needed replacement, potentially from its own service >>> loader (service dependent outside of karaf 5 structure). >>> Thinking out loud, it is very very close to tomee architecture which has >>> exactly that except the bootstrap loader(s) leaks a lot since it is >> assumed >>> not conflicting much and module services are not mainstream app oriented >>> but EE oriented. But the service and tree of loaders is there so overall >> if >>> Karaf5 would leverage the same architecture but power it by the Karaf >> core >>> feature inherited from OSGi which is to make any app running in the same >>> JVM. >>> A service example could be for example an instrumentation one (since >>> subclassloaders are karaf controlled) and do the javax -> jakarta >> migration >>> on the fly. >>> >> >> Not sure about TomEE (no experience with it), but what I read, seems great >> so far ;) >> >> regards >> Grzegorz Grzybek >> >> >>> >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> >>>>> >>>>> 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
