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 < [email protected]>: > Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré <[email protected]> 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, < > > [email protected]> > > > 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 <[email protected]> can tell more about it > > ;) > > >> > > >> regards > > >> Grzegorz Grzybek > > >> > > >> czw., 10 paź 2019 o 23:48 Patrique Legault <[email protected] > > > > >> napisał(a): > > >> > > >>> Yes exactly what I meant. > > >>> > > >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, < > > >>> [email protected]> 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. < > [email protected]> > > >>>> 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 > > >>>>>> <[email protected]> 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 < > > >>>>>> [email protected]> > > >>>>>>> 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é > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > -- > ------------------------ > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
