My point was not to compare Karaf and Quarkus, it was more to mention the static distribution ;)
I think Winegrower on Quarkus is easy and direct, it could be a Karaf mode (merging into Karaf). It provides the OSGi programming model with one flat classloader. Regards JB On 11/10/2019 08:51, Guillaume Nodet wrote: > Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré <j...@nanthrax.net> a > écrit : > >> Just a side note, not necessary about "happens during runtime" ;) >> >> Look on the Karaf static distribution: >> >> >> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist >> >> you will see that the resolution is "prepared" at build time, the >> runtime resolution is super fast. >> >> Karaf is not necessary "I start empty and I add stuff in it", it can be >> "I prepare all at build for a super fast start". >> > > That's right, but Quarkus goes a lot further than what Karaf does (which is > to basically to pre-install the bundles). > Such Karaf distributions could eventually benefit from Quarkus too, but > going native Karaf still uses OSGi and dynamic classloading, whereas > compiling to native imposes the whole world to be know at build time and > thus prohibits the use of dynamic classloading. > So I think there would be a path for Karaf to leverage Quarkus but that > would be very limited in JVM mode, unless Karaf is only used to create a > Quarkus powered distribution where the OSGi classloading would go away. In > a karaf "static" distribution, we could actually think about it, i.e. use > something like Felix Connect instead of a real Felix / Equinox framework, > which removes all classloaders afaik. The only limitation would be to > choose a way to handle multiple bundle versions, either by rejecting those > use cases, or try to shadow them into a different package. > > >> >> Regards >> JB >> >> On 11/10/2019 08:17, Patrique Legault wrote: >>> Thank you for your response. >>> >>> That is very interesting to know. I did not know that Quarkus can do all >> of >>> that rendering in build time. It makes sense that this is the opposite of >>> OSGi as everythin happens during runtime. >>> >>> Thank you. >>> >>> On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, < >> gr.grzy...@gmail.com> >>> wrote: >>> >>>> Hello >>>> >>>> I'm not expert on Quarkus (and GraalVM)... Quoting one of the >> descriptions: >>>> >>>> *The approach that Quarkus takes is to tailor a runtime that only >> contains >>>>> what your application needs and to boil down most of the dynamics of an >>>>> enterprise runtime.* >>>>> >>>> >>>> The idea is to get rid of all the parts of the Java runtime aspects that >>>> ... do nothing except preparing your application to run. These are: >>>> – initialization of jaxb context >>>> – configuring Hibernate model >>>> – wiring your CDI beans >>>> – wiring your Spring beans >>>> – generally transforming some metadata (annotations, XMLs, >> configurations, >>>> ...) into a live object model that no longer changes (usually hashmaps) >>>> >>>> When the model is read, application does it's job. And we all confirm, >> that >>>> if the only goal of Java application is to read file and store it into >>>> database, starting Hibernate sessionfactory → session and creating Camel >>>> context to do that is ~95% of entire work. Rest is "read file, store in >>>> DB". >>>> >>>> Quarkus' goal is to move this 95% work to build time. Yes - build time. >>>> Effectively the goal is to have Java application, that (when starting) >>>> *already has this model read* - and (in extreme) just mapped in your >>>> process' virtual memory as set of pages that JVM can already use. >>>> And it's not only making native JVM images. >>>> >>>> This is *directly* opposite to what Karaf (and OSGi in general) is for. >>>> >>>> But maybe +Guillaume Nodet <gno...@apache.org> can tell more about it >> ;) >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> czw., 10 paź 2019 o 23:48 Patrique Legault <patriquelega...@gmail.com> >>>> napisał(a): >>>> >>>>> Yes exactly what I meant. >>>>> >>>>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, < >>>>> krzys.sobkow...@gmail.com> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> Do you mean a Karaf feature prviding the Quarkus libraries (like the >>>>>> Spring or Hibernate feaures)? >>>>>> >>>>>> Best regards >>>>>> Krzysztof >>>>>> >>>>>> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote: >>>>>>> Hello Romain, >>>>>>> >>>>>>> Let me just start by saying I probably should have done more research >>>>> on >>>>>>> Quarkus before sending off this email. >>>>>>> >>>>>>> In my mind when I think of Karaf, I think of a service that allows >>>>>>> developers to simply install a feature into the service and gives >>>> them >>>>>>> access to a framework that they can then develop against. For >>>> instance, >>>>>>> installing a version of hibernate, spring, etc...into the Karaf >>>>> service. >>>>>>> >>>>>>> When I saw the Quarkus framework, I thought of a potential >>>> opportunity >>>>>> for >>>>>>> Karaf to provide another framework for developers to use. That being >>>>> said >>>>>>> if this is something that Karaf already exposes through various other >>>>>>> libraries then there is nothing to do. >>>>>>> >>>>>>> Next time though I will definitely do some more research prior to a >>>>>>> proposition. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> On Thu, Sep 26, 2019 at 10:10 AM Jamie G. <jamie.goody...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>>> I'm not sure the the ask entails here. >>>>>>>> >>>>>>>> Why does it need to be integrated into Karaf? Can Quarkus just >>>>> publish >>>>>>>> a feature which Karaf users could install in the usual manner? >>>>>>>> >>>>>>>> On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau >>>>>>>> <rmannibu...@gmail.com> wrote: >>>>>>>>> Hi Patrique, >>>>>>>>> >>>>>>>>> I have to admit I'm not following, Quarkus is mainly a >>>> microprofile >>>>>> based >>>>>>>>> server integrated with GraalVM in the IBM/Redhat ecosystem to >>>> build >>>>>>>>> natively a HTTP app (for k8s). >>>>>>>>> It also supports a JVM mode but then it is like any CDI/JAXRS >>>>> server. >>>>>>>>> In this last mode Karaf is already very competitive so I guess it >>>>> is >>>>>> not >>>>>>>>> the target and in the first mode the current challenge of Graal >>>> for >>>>>> Karaf >>>>>>>>> (OSGi actually) is that it does not support classloading (and >>>>>> conflicting >>>>>>>>> API in the same application). >>>>>>>>> >>>>>>>>> Concretely my point is that Karaf already supports Tomcat and >>>> Jetty >>>>>> (and >>>>>>>>> undertow i think) through pax-web and jersey/cxf so it already >>>> has >>>>> a >>>>>>>> "lean >>>>>>>>> and efficient Java server". Add all the recent work about >>>>>>>> containerization >>>>>>>>> (static resolver, docker mojo etc) and you can couple it with >>>>>> "container >>>>>>>>> first framework". >>>>>>>>> >>>>>>>>> Finally, still relying on the JVM enable to Karaf to be more >>>>>> reliable at >>>>>>>>> runtime that Quarkus in native mode which still has a poor GC >>>>>>>>> implementation (it will be enhanced but they are not yet there). >>>>>>>>> >>>>>>>>> All that to say I'm not sure the outcome you expect of such a >>>> task, >>>>>> can >>>>>>>> you >>>>>>>>> refine it a bit maybe? >>>>>>>>> >>>>>>>>> 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 jeu. 26 sept. 2019 à 15:54, Patrique Legault < >>>>>>>> patriquelega...@gmail.com> >>>>>>>>> a écrit : >>>>>>>>> >>>>>>>>>> There is a new framework released by Red Hat called Quarkus, >>>> see >>>>>>>>>> https://quarkus.io/, it is designed/built for >>>> containerization . >>>>>>>>>> >>>>>>>>>> If integrated within Karaf, we could create a feature that >>>> would >>>>>>>> install >>>>>>>>>> the Quarkus framework within Karaf. This would allow for a lean >>>>> and >>>>>>>>>> efficient Java server with a container first framework embedded >>>>>> within >>>>>>>> it. >>>>>>>>>> Allowing for quick and easy RESTful services development with a >>>>> low >>>>>>>> memory >>>>>>>>>> footprint and quick container runtime. >>>>>>>>>> >>>>>>>>>> Let me know what you think, and if this is worth logging a >>>> ticket >>>>>> for. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Patrique Legault* >>>>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Krzysztof Sobkowiak >>>>>> >>>>>> JEE & OSS Architect, Integration Architect >>>>>> Apache Software Foundation Member (http://apache.org/) >>>>>> Apache ServiceMix Committer & PMC Member ( >>>> http://servicemix.apache.org/) >>>>>> Apache OpenWhisk PMC Member (https://openwhisk.apache.org/) >>>>>> Apache Incubator PMC Member (https://incubator.apache.org/) >>>>>> Senior Solution Architect @ Capgemini SSC ( >>>>>> http://www.capgeminisoftware.pl/) >>>>>> >>>>>> >>>>> >>>> >>> >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
