Actually, spec like as DocuentBuilder would be rather a library, shared by all launchers.
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 >> >>
