+1 for me! Karaf static distributions is something that could add many usefull use cases to Karaf users and help us to promote Karaf not as a pure OSGi runtime.
regards, François fpa...@apache.org Le 11/10/2019 à 10:29, Jean-Baptiste Onofré a écrit : > Hi Guillaume, > > (cross messages), it's what we did in Winegrower: > > https://github.com/jbonofre/winegrower > > We have a single classloader but OSGi "flavor": service registry, etc. > > You can see on the examples that we are able to use scr, to run the > shell, to run decanter, etc in winegrower. > > I'm ready to donate that with some polishing if users and you think it's > valuable. > > Regards > JB > > On 11/10/2019 10:25, Guillaume Nodet wrote: >> The other limitation in native-mode to be aware of is the reflection : it's >> all doable but needs >> some opt-in so that the reflection informations can be included in the >> native binary and made available at runtime. >> >> Fwiw, the output of Quarkus is a single runnable jar, so everything is >> flattened. For embedded dependencies, this may require additional work, >> but nothing impossible. Problems may come when using the OSGi registry and >> for class visibility. The fact that the OSGi framework would work in a >> single classloader may cause some problems with bundles wrt service and >> classes visibility, because there would be no hidden classes anymore, >> everything would be visible to all bundles. The other problem would >> definitely be for native mode (reflection and a few other limitations). >> But a Quarkus JVM mode could definitely be interesting to have for Karaf >> static distributions. >> >> Even with a few limitations, like forcing the user to align dependencies to >> avoid multiple versions of the same class which would remove the need for a >> complex shading mechanism, it could be worth investigating the benefit when >> booting those karaf static distributions. I think it could be a big win >> for Karaf users. >> >> Le ven. 11 oct. 2019 à 09:07, Christian Schneider <ch...@die-schneider.net> >> a écrit : >> >>> There is also another issue about embedding dependencies. >>> >>> In OSGi it is quite popular to embed dependencies into the bundle with the >>> original package names. >>> When used in a flat classloader this makes these embedded packages collide >>> between bundles. This can be solved though by embedding with a different >>> unique >>> classname. I think the shade plugin can do this but I have never tried. >>> >>> Christian >>> >>> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet < >>> gno...@apache.org>: >>> >>>> 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 >>>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> >>> >>> -- >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Computer Scientist >>> http://www.adobe.com >>> >>
