You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2021/03/24 14:24:30 UTC
[INFO] Apache Karaf 5 will be internally based on OSGi R8
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
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rm...@gmail.com> a écrit :
>
> Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek <gr.grzybek@gmail.com <ma...@gmail.com>> a
> écrit :
>
>> Thanks Romain for the details! (see inline)
>>
>> czw., 25 mar 2021 o 08:31 Romain Manni-Bucau <rm...@gmail.com>
>> napisał(a):
>>
>>> Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr...@gmail.com> a
>>> écrit :
>>>
>>>> Good morning!
>>>>
>>>> śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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 <jb...@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 <
>> rmannibucau@gmail.com
>>>>
>>>> a
>>>>>> écrit :
>>>>>>>
>>>>>>> Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <
>>> jb@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.grzybek@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 <jb@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.grzybek@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 <
>> jb@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
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <rm...@gmail.com>
napisał(a):
> Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek <gr...@gmail.com> a
> écrit :
>
> > Thanks Romain for the details! (see inline)
> >
> > czw., 25 mar 2021 o 08:31 Romain Manni-Bucau <rm...@gmail.com>
> > napisał(a):
> >
> > > Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr...@gmail.com>
> a
> > > écrit :
> > >
> > > > Good morning!
> > > >
> > > > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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 <
> jb@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 <
> > rmannibucau@gmail.com
> > > >
> > > > a
> > > > > > écrit :
> > > > > > >
> > > > > > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <
> > > jb@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.grzybek@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 <
> jb@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.grzybek@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 <
> > jb@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
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 25 mars 2021 à 09:35, Grzegorz Grzybek <gr...@gmail.com> a
écrit :
> Thanks Romain for the details! (see inline)
>
> czw., 25 mar 2021 o 08:31 Romain Manni-Bucau <rm...@gmail.com>
> napisał(a):
>
> > Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr...@gmail.com> a
> > écrit :
> >
> > > Good morning!
> > >
> > > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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 <jb...@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 <
> rmannibucau@gmail.com
> > >
> > > a
> > > > > écrit :
> > > > > >
> > > > > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <
> > jb@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.grzybek@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 <jb@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.grzybek@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 <
> jb@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
> > > > > >>>>
> > > > > >>>>
> > > > > >>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Thanks Romain for the details! (see inline)
czw., 25 mar 2021 o 08:31 Romain Manni-Bucau <rm...@gmail.com>
napisał(a):
> Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr...@gmail.com> a
> écrit :
>
> > Good morning!
> >
> > śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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 <jb...@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 <rmannibucau@gmail.com
> >
> > a
> > > > écrit :
> > > > >
> > > > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <
> jb@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...@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 <jb...@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.grzybek@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 <jb@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
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 25 mars 2021 à 07:13, Grzegorz Grzybek <gr...@gmail.com> a
écrit :
> Good morning!
>
> śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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).
>
> 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.
> 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.
>
>
> > 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.
>
> 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 <jb...@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 <rm...@gmail.com>
> a
> > > écrit :
> > > >
> > > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <jb...@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...@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 <jb...@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...@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 <jb...@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
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Grzegorz Grzybek <gr...@gmail.com>.
Good morning!
śr., 24 mar 2021 o 19:57 Romain Manni-Bucau <rm...@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 <jb...@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 <rm...@gmail.com> a
> > écrit :
> > >
> > > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <jb...@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...@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 <jb...@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...@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 <jb...@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
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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).
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.
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 <jb...@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 <rm...@gmail.com> a
> écrit :
> >
> > Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <jb...@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...@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 <jb...@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...@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 <jb...@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
> >>>>
> >>>>
> >>
> >>
>
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <rm...@gmail.com> a écrit :
>
> Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <jb...@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...@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 <jb...@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...@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 <jb...@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
>>>>
>>>>
>>
>>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 24 mars 2021 à 17:35, Jean-Baptiste Onofre <jb...@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...@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 <jb...@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...@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 <jb...@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
> >>
> >>
>
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <gr...@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 <jb...@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...@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 <jb...@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
>>
>>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <jb...@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...@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 <jb...@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
>
>
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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...@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 <jb...@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
Re: [INFO] Apache Karaf 5 will be internally based on OSGi R8
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <jb...@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