karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: [PROPOSAL] Introduce "static" resolver
Date Sat, 09 Mar 2019 22:18:02 GMT
My 0.02€. I had an attempt to use static assemblies and had to step back
from it. There is very little documentation on how to adjust tooling and
example which was pointed earlier does not answer all questions.

Second, also important thing, is having a static feature resolution
doesn't mean that we have completely static configuration. And that's
the case with framework-static AFAIR. Kubernetes can inject new config
maps without restarting process thus leaving possibility to react on
file change and push update Configuration Admin is something which is
still relevant.


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

View raw message