As Romain just reminded me, you can take a look on the "website":
https://jbonofre.github.io/winegrower/ 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 >> > > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
