karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Quarkus Integration https://quarkus.io/
Date Fri, 11 Oct 2019 08:20:19 GMT
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é <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
>>
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message