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.
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.
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.
> 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?
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
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
