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