Quoting one statement of yours:
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).
>
I agree. I still believe in "Java applications servers" (whatever the set
of standards - real or de-facto - is used). And I still believe in
long-running apps.
regards
Grzegorz Grzybek
czw., 25 mar 2021 o 10:33 Romain Manni-Bucau <rmannibu...@gmail.com>
napisał(a):
> Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek <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
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
