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?
>
>
> >
> > 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 ;)
>
>
> > 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
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
