karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Quarkus Integration https://quarkus.io/
Date Fri, 11 Oct 2019 06:51:59 GMT
Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré <jb@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.grzybek@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 <gnodet@apache.org> can tell more about it
> ;)
> >>
> >> regards
> >> Grzegorz Grzybek
> >>
> >> czw., 10 paź 2019 o 23:48 Patrique Legault <patriquelegault@gmail.com>
> >> napisał(a):
> >>
> >>> Yes exactly what I meant.
> >>>
> >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> >>> krzys.sobkowiak@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.goodyear@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
> >>>>>> <rmannibucau@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 <
> >>>>>> patriquelegault@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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>


-- 
------------------------
Guillaume Nodet

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message