+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
>>>
>>

Reply via email to