karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Mon, 04 Mar 2019 18:18:48 GMT
Hello

pon., 4 mar 2019 o 17:58 Serge Huber <shuber@apache.org> napisał(a):

> I also like the proposed solution using build-time generation.
>
> Just a question about the single classloader though: isn't that going to
> cause problems if projects want to use different versions of a library? I
> agree that they shouldn't but it's also something that makes Karaf more
> powerful than Spring in general.
>

Felix-Connect (formerly known as PojoSR) is a single classloader base and
osgi registry. It can run some scenarios, for example there's
camel-test-blueprint framework, but some bundles simply don't work there -
for example Aries JPA (at least it didn't work last time we've checked).

So I agree. Build time resolution (and long etc/startup.properties - all
features as <startupFeatures>), static configadmin, reference: URIs, so
they're read directly from system/ (not populating data/cache/).
But single classloader is a bit against OSGi ;)

regards
Grzegorz Grzybek


>
> Regards,
>   Serge...
>
> On Mon, Mar 4, 2019 at 4:28 PM Christian Schneider <
> chris@die-schneider.net>
> wrote:
>
> > +1
> >
> > Am Mo., 4. März 2019 um 15:29 Uhr schrieb Guillaume Nodet <
> > gnodet@apache.org
> > >:
> >
> > > Right, and also, the demo is using profiles, and I think we should
> have a
> > > demo using plain features instead.  That does not really change
> anything,
> > > as the assembly is all done by the plugin, but this lead to a simpler
> > demo.
> > >
> > > Le lun. 4 mars 2019 à 15:18, Jean-Baptiste Onofré <jb@nanthrax.net>
a
> > > écrit :
> > >
> > > > That's a very good argument and actually I think you are right,
> that's
> > > > even better.
> > > >
> > > > Maybe the "missing" part if the tooling and the documentation around
> > > this.
> > > >
> > > > Let me prepare a PR for that !
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On 04/03/2019 15:15, Guillaume Nodet wrote:
> > > > > I would argue that we should not use any resolver at all for such
> > > > > containers, and that's already doable with the karaf plugin.
> > > > > We have a demo of that in the
> > > > >   examples/karaf-profile-example/karaf-profile-example-static
> > > > > The resolution is done at build time and the list of bundles is
> > written
> > > > in
> > > > > the
> > > > >   etc/startup.properties
> > > > > file, by virtue of having the features configured at startup phase
> > > rather
> > > > > than boot phase.
> > > > > In this demo, we even avoid the fact that felix usually copy the
> > > bundles
> > > > in
> > > > > its internal storage by using startup bundles referenced as:
> > > > >
> > > >
> > >
> >
> reference\:file\:org/ops4j/pax/logging/pax-logging-api/1.10.1/pax-logging-api-1.10.1.jar
> > > > > = 8
> > > > > This leads to no resolution at all at runtime (the example assembly
> > > does
> > > > > not even contain the karaf features service), a much faster startup
> > > time,
> > > > > less disk space used.
> > > > >
> > > > > Unless I'm mistaken, I don't really see the need to build another
> > > > different
> > > > > thing, but maybe I missed something.
> > > > >
> > > > > Guillaume
> > > > >
> > > > > Le lun. 4 mars 2019 à 15:00, Jean-Baptiste Onofré <jb@nanthrax.net
> >
> > a
> > > > > écrit :
> > > > >
> > > > >> Hi guys,
> > > > >>
> > > > >> During the introduction thread about "kloud initiative", we
> quickly
> > > > >> discussed about the resolver.
> > > > >>
> > > > >> Today, we can see concerns about the current features resolver,
> > > > especially:
> > > > >> - the resolution at runtime can be different than the one done
> > during
> > > > >> verify
> > > > >> - the resolution at runtime can be impacted by the version range
> > > > >> - the resolution can cause bunch of refresh, impacting startup
and
> > > > >> resolution time
> > > > >>
> > > > >> If the current resolver is great for a "container/dynamic"
> approach
> > > > >> where karaf is running and we deploy things in it, it's not good
> > for a
> > > > >> "static" bootstrapping as expected for a runtime running on cloud
> or
> > > > >> docker.
> > > > >>
> > > > >> I would like to propose to introduce a feature resolver named
> > "karaf".
> > > > >> The idea is to use a resolver that reads the features repositories
> > as
> > > > >> they are and install bundles/configuration/etc without checking
> all
> > > > >> capabilities and requirements. It sounds a bit like a mix of
the
> > > simple
> > > > >> resolver we use in the Karaf maven plugin in the verify goal,
and
> > what
> > > > >> we had in the past (in Karaf 2.x for instance). It doesn't perform
> > any
> > > > >> refresh, it's up to the developer (and of course the tooling)
to
> > > provide
> > > > >> a complete features definition.
> > > > >>
> > > > >> The resolver could be configured in
> > etc/org.apache.karaf.features.cfg
> > > > >> and we can have a "static" distribution with this resolver by
> > default.
> > > > >>
> > > > >> I would propose to rename "standard" distribution as "container",
> > and
> > > we
> > > > >> will provide the "static" distribution.
> > > > >>
> > > > >> Thoughts ?
> > > > >>
> > > > >> Another idea around this is Karaf Winegrower. Winegrower is kind
> of
> > > > >> Karaf Boot, using a single/unique classloader instead of one
> > > classloader
> > > > >> per bundle. It's pretty convenient for cloud as well.
> > > > >> Maybe we can have winegrower as Karaf subproject.
> > > > >> Currently Winegrower is here:
> > https://github.com/jbonofre/winegrower
> > > > >>
> > > > >> Thoughts ?
> > > > >>
> > > > >> Regards
> > > > >> JB
> > > > >> --
> > > > >> 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
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
> >
>

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