Re: [PROPOSAL] Karaf 5

[Jean-Baptiste Onofre]

Hi,

It sounds good to me.

The K5 repo is currently on my GitHub:

https://github.com/jbonofre/karaf5

I propose:

1. To keep main for karaf-4.4.x for now
2. Fix K4 like assembly on K5 (just have to push some new services)
3. Push Karaf 5 on K5 branch
4. Improve documentation on K5 branch to show what’s a service, and so, allow 
anyone to contribute service/distribution

ETA: end of this week if no objection.

Regards
JB


> Le 7 févr. 2022 à 07:56, Francois Papon  a 
> écrit :
> 
> Hi,
> 
> As we have some users that asking questions about Karaf 5 the next Karaf 
> generation, I think it would be nice to move the current repo to master.
> 
> It could be a good booster if we want to move forward on this for a first RC.
> 
> Thoughts?
> 
> Regards,
> 
> François
> 

Re: [ANN] Apache Karaf runtime 4.3.6 has been released

[Jean-Baptiste Onofre]

Hi Steinar,

Thanks for the update !

I’m about to push the docker images on Docker Hub too.

Regards
JB

> Le 15 janv. 2022 à 15:23, Steinar Bang  a écrit :
> 
>>>>>> Jean-Baptiste Onofre :
> 
>> The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.6 
>> release.
>> This release is an important release on the Karaf 4.3.x series containing:
> 
>> - upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832)
>> - prepare JDK 18 support
>> - fix deployment issue by upgrading to Apache Felix FileInstall 3.7.4
>> - and much more!
> 
> My karaf debian package has been upgraded to 4.3.6:
> https://steinar.bang.priv.no/2018/01/23/installing-apache-karaf-on-debian/comment-page-1/#comment-15843
> 
> In addition to the karaf version upgrade, I have un-embedded the OSGi
> framework and is using the debian packaged OSGi framework, since that is
> currently version 7.0.0 in debian stable.
> 
> (I had to start embedding the OSGi framework when upgrading karaf to
> 4.3.x, since the debian packaged OSGi framework back then, was 6.0.0).
> 

[ANN] Apache Karaf runtime 4.2.15 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.2.15 
release.

This release is an important release on the Karaf 4.2.x series containing:

- upgrade to Pax Logging 1.11.13 upgrading to log4j 2.17.1 (fixing 
CVE-2021-44832)
- upgrade too Apache Felix FileInstall 3.7.4 fixing hot deployment issue

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351124

Download: http://karaf.apache.org/download.html

Enjoy!
The Apache Karaf team

[ANN] Apache Karaf runtime 4.3.6 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.6 release.

This release is an important release on the Karaf 4.3.x series containing:

- upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832)
- prepare JDK 18 support
- fix deployment issue by upgrading to Apache Felix FileInstall 3.7.4
- and much more!

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351123

Download: http://karaf.apache.org/download.html

Enjoy!
The Apache Karaf team

[VOTE] Apache Karaf runtime 4.3.6 release

[Jean-Baptiste Onofre]

Hi everyone,

I submit Apache Karaf runtime 4.3.6 to your vote. 

This release includes:
- upgrade to Pax Logging 2.0.14 with log4j 2.17.1 (fixing CVE-2021-44832)
- prepare support for JDK 18
- fix issue on Apache Felix FileInstall 3.7.4 fixing deployment issue
- and much more!

Please take a look on Release Notes for details !

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351123

Staging Maven Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1170/

Staging Dist Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.3.6/

Git tag:
karaf-4.3.6

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: [ANN] Apache Karaf runtime 4.3.5 has been released

[Jean-Baptiste Onofre]

Hi 

Yes, it’s already planned. The 4.3.6 and 4.2.15 releases will be in vote soon.

Regards
JB

> Le 30 déc. 2021 à 18:17, Robert Dean  a écrit :
> 
> Happy holidays everyone!
> 
> Log4j question: Will there need to be another release for the log4j 2.17.1 
> security fix?
> 
> Thank you,
> Joe Dean
> 
> 
> PTO Alert: None
> 
> On 12/28/21, 10:55 PM, "Jean-Baptiste Onofre"  wrote:
> 
>EXTERNAL EMAIL - Use caution opening attachments and links.
> 
>The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.5 
> release.
> 
>This release is an important release on the Karaf 4.3.x series bringing 
> security fixes (logshell) especially:
> 
>- upgrade to jolokia 1.7.1
>- upgrade to pax-logging 2.0.12
>- upgrade to log4j 2.17.0 fixing CVE-2021-45105 and CVE-2021-44228
>- upgrade to logback 1.2.9 fixing CVE-2021-42550
> 
>The Release Notes are available here: 
> https://urldefense.com/v3/__https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856__;!!AMCWqqRremt4Wx4!FbnwTktvh0yfq-_FDRz1PJ4qUVHCiR1-d_HBoBOppcsDztH1QHnA71yc-pttrw$
> 
>Download: 
> https://urldefense.com/v3/__http://karaf.apache.org/download.html__;!!AMCWqqRremt4Wx4!FbnwTktvh0yfq-_FDRz1PJ4qUVHCiR1-d_HBoBOppcsDztH1QHnA71xZDuHNXg$
>   
> <https://urldefense.com/v3/__http://karaf.apache.org/download.html__;!!AMCWqqRremt4Wx4!FbnwTktvh0yfq-_FDRz1PJ4qUVHCiR1-d_HBoBOppcsDztH1QHnA71xZDuHNXg$
>  >
> 
>Enjoy!
>The Apache Karaf team
> 
> ***
> IMPORTANT MESSAGE FOR RECIPIENTS IN THE U.S.A.:
> This message may constitute an advertisement of a BD group's products or 
> services or a solicitation of interest in them. If this is such a message and 
> you would like to opt out of receiving future advertisements or solicitations 
> from this BD group, please forward this e-mail to optoutbygr...@bd.com. 
> [BD.v1.0]
> ***
> This message (which includes any attachments) is intended only for the 
> designated recipient(s). It may contain confidential or proprietary 
> information and may be subject to the attorney-client privilege or other 
> confidentiality protections. If you are not a designated recipient, you may 
> not review, use, copy or distribute this message. If you received this in 
> error, please notify the sender by reply e-mail and delete this message. 
> Thank you.
> ***
> Corporate Headquarters Mailing Address: BD (Becton, Dickinson and Company) 1 
> Becton Drive Franklin Lakes, NJ 07417 U.S.A.

Re: karaf-maven-plugin generates another org.apache.karaf.features.xml with Java 8/Java 11

[Jean-Baptiste Onofre]

Hi Steven,

Thanks for the update. Now you mention MNG-6506, I think we had this issue 
while ago (at least me on my machine ;)).

Regards
JB

> Le 30 déc. 2021 à 20:18, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> It turns out I was facing this issue :
> https://issues.apache.org/jira/browse/MNG-6506. Upgrading maven solved the
> problem.
> 
> 
> Best regards,
> Steven
> 
> On Thu, Dec 23, 2021 at 10:50 AM Steven Huypens 
> wrote:
> 
>> Hi JB,
>> 
>> Do you have any news on this ? If you could give me any pointers, I'm
>> happy to try and fix it myself, but for now I'm stuck.
>> 
>> Best regards,
>> Steven
>> 
>> On Fri, Dec 3, 2021 at 1:01 PM Jean-Baptiste Onofré 
>> wrote:
>> 
>>> Hi Steven,
>>> 
>>> Not yet, I'm busy with 4.3.4 release preparation. As part of the release
>>> preparation, I will take a look, probably later today or tomorrow.
>>> 
>>> I will keep you posted.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 03/12/2021 12:22, Steven Huypens wrote:
 Hi JB,
 
 Did you find some time to have a look at my example ?
 
 Best regards,
 Steven
 
 On Sun, Nov 28, 2021 at 7:46 PM Steven Huypens <
>>> steven.huyp...@gmail.com>
 wrote:
 
> Hi JB,
> 
> This pom.xml illustrates the problem :
> https://github.com/ponziani/karaf-simple-suite
> 
> Kind regards,
> Steven
> 
> On Sun, Nov 28, 2021 at 5:12 PM JB Onofré  wrote:
> 
>> In that case, it’s weird as Karaf uses jdk11 to build and I don’t see
>> such issue.
>> 
>> Do you have a test repo where I can take a look ?
>> 
>> Thanks
>> Regards
>> JB
>> 
>>> Le 28 nov. 2021 à 16:21, Steven Huypens  a
>> écrit :
>>> 
>>> Hi,
>>> 
>>> I found out package-info.java in the
>>> package org.apache.karaf.features.internal.model.processing contains
>>> 
>>> @XmlSchema(namespace =
>>> "http://karaf.apache.org/xmlns/features-processing/v1.0.0;,
>>>elementFormDefault = XmlNsForm.QUALIFIED,
>>> attributeFormDefault
>>> = XmlNsForm.UNQUALIFIED,
>>>xmlns = {
>>>@XmlNs(prefix = "", namespaceURI =
>> FEATURES_PROCESSING_NS),
>>>@XmlNs(prefix = "f", namespaceURI =
>>> FeaturesNamespaces.URI_CURRENT)
>>>}
>>> )
>>> 
>>> 
>>> These annotations are ignored when using Java 11, I have no idea why,
>> but
>>> looks like a bug to me.
>>> 
>>> Kind regards,
>>> Steven
>>> 
>>> 
 On Sun, Nov 28, 2021 at 12:05 PM Steven Huypens <
>> steven.huyp...@gmail.com>
 wrote:
 
 Hi Bernd,
 
 I must correct myself. Adding the 'ns3'-prefix to all of the
>>> children
>> does
 help. It seems all of the tags without prefix are ignored at
>>> boot-time
 which causes the OOM. So maybe a fix in the karaf-maven-plugin
>>> would be
 best, the prefix should be added to each child...
 
 Kind regards,
 Steven
 
 On Sat, Nov 27, 2021 at 9:56 PM Steven Huypens <
>> steven.huyp...@gmail.com>
 wrote:
 
> Hi Bernd,
> 
> - I do see 'blacklistedRepositories' in
> http://karaf.apache.org/xmlns/features-processing/v1.0.0
> - With the namespace-prefix my app goes OOM immediately, so I
>>> cannot
> compare both running systems.
> - I tried adding the prefix to each child, but that did not help
> 
> Kind regards,
> Steven
> 
> On Sat, Nov 27, 2021 at 9:23 PM Bernd Eckenfels <
>> e...@zusammenkunft.net>
> wrote:
> 
>> In that case maybe the child (deny* list?) is ignored, not sure
>>> how
>> strict the parser is in regards to namespaces. I don’t see a
>> blacklistRepository element in the Schema anyway. It’s maybe best
>>> you
>> inspect the running systems with feature:* commands and look for
>> differences.
>> 
>> 
>> 
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Steven Huypens 
>> Gesendet: Saturday, November 27, 2021 8:58:20 PM
>> An: dev@karaf.apache.org 
>> Betreff: Re: karaf-maven-plugin generates another
>> org.apache.karaf.features.xml with Java 8/Java 11
>> 
>> Hi Bernd,
>> 
>> Thanks for your response. The child elements have no prefix, eg.
>> 
>> 
>> I'm sorry but I do not understand what you mean. You think part
>>> of my
>> org.apache.karaf.features.xml was previously ignored ? I haven't
>> double
>> checked, but that would really surprise me because we have quite
>>> some
>> blacklistedFeatures en blacklistedBundles which would cause
>>> problems
>> if
>> ignored.
>> 
>> Best regards,
>> Steven
>> 

[ANN] Apache Karaf runtime 4.3.5 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.5 release.

This release is an important release on the Karaf 4.3.x series bringing 
security fixes (logshell) especially:

- upgrade to jolokia 1.7.1
- upgrade to pax-logging 2.0.12
- upgrade to log4j 2.17.0 fixing CVE-2021-45105 and CVE-2021-44228
- upgrade to logback 1.2.9 fixing CVE-2021-42550

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856

Download: http://karaf.apache.org/download.html 


Enjoy!
The Apache Karaf team

[ANN] Apache Karaf runtime 4.2.14 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.2.14 
release.

This release is an important release on the Karaf 4.2.x series, bringing 
updates, fixes and new features, especially fixing logshell issue:
- upgrade to Pax Logging 1.11.12
- upgrade to log4j 2.17.0 fixing CVE-2021-45105 and CVE-2021-44228
- upgrade to logback 1.2.9 fixing CVE-2021-42550

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856

Download: http://karaf.apache.org/download.html 


Enjoy!
The Apache Karaf team

Re: [PROPOSAL] Change log4j2 default config to xml (or json)

[Jean-Baptiste Onofre]

Hi

You mean org.ops4j.pax.logging config PID right (so today 
etc/org.ops4j.pax.logging.cfg).

It’s already possible to refresh a log4j XML in org.ops4j.pax.logging. So 
basically, etc/org.ops4j.pax.logging.cfg just contain the location of the 
log4j.xml.

I think it’s good enough.

My point is that, if you proposal is to have etc/org.ops4j.pax.logging.xml 
instead of etc/org.ops4j.pax.logging.cfg, that should be optional, and I think 
it’s not a good idea.
I still prefer to have an indirection where etc/org.ops4j.pax.logging.cfg 
points to log4j XML or JSON file.

Regards
JB

> Le 28 déc. 2021 à 17:32, Matt Pavlovich  a écrit :
> 
> @JB- To be clear, the request is for the log4j2 config file to be in xml or 
> json, not supporting json or xml log formats 
> 
> @Romain- I think heterogenous is a great goal— however, with complex 
> hierarchal configurations, the “simplicity” of properties is lost in the 
> structure. Default Log4j2 as properties is illegible by any UX/DX standard. 
> As with features, having structured format (ie xml) for complex data is more 
> manageable.
> 
> The Developer Experience (DX) gap here is dev-on-laptop writing a simple REST 
> service/camel route, etc and then deploying to karaf has a very different 
> experience with logging. This is especially true for developers without a lot 
> of experience and/or are new to karaf.
> 
> My suggestion is about trying to unify the log4j2 property file so dev laptop 
> to running karaf has the same default and therefore the same DX. 
> 
> -Matt
> 
>> On Dec 28, 2021, at 1:55 AM, Romain Manni-Bucau  
>> wrote:
>> 
>> My 2cts would be that log4j2 or any configuration in karaf should be
>> homogeneous with other config files. Since OSGi is .cfg (enriched
>> properties) by design, I think it is better to stick to this or something
>> very close *by default*.
>> Making the config formats heterogeneous will make your tooling
>> heterogeneous too or more complex at least which is not worth it in almost
>> all cases.
>> 
>> 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 mar. 28 déc. 2021 à 05:41, Jean-Baptiste Onofre  a
>> écrit :
>> 
>>> By the way, just a reminder: a good point about properties format in
>>> pax-logging-log4j2 service is that it doesn’t require extra dependency.
>>> Using xml/json format needs additional dependency/packages/bundles in the
>>> Karaf distribution.
>>> Just a side note.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 27 déc. 2021 à 19:33, Matt Pavlovich  a écrit :
>>>> 
>>>> I’ve created a proposal JIRA KARAF-7307 (
>>> https://issues.apache.org/jira/browse/KARAF-7307 <
>>> https://issues.apache.org/jira/browse/KARAF-7307>) to track any specifics.
>>>> 
>>>> As the subject mentions— I think it would be beneficial to users to
>>> change the default configuration for log4j2 to XML (or maybe JSON).
>>>> 
>>>> Notes:
>>>> 
>>>> 1. Documentation for the properties format is fragmented and incomplete—
>>> especially for advanced features such as routing, etc
>>>> 2. XML format is the more natural format for log4j2
>>>> 3. Allow for developers targeting karaf runtime to use the same
>>> log4j2.xml config file in their dev projects that is used in karaf runtime
>>> (using a org.ops4j.pax.logging.cfg requires developers to add add’l
>>> configuration to their code projects)
>>>> 
>>>> Thoughts?
>>>> 
>>>> Thanks,
>>>> Matt
>>>> 
>>>> 
>>> 
>>> 
> 

Re: [PROPOSAL] Change log4j2 default config to xml (or json)

[Jean-Baptiste Onofre]

By the way, just a reminder: a good point about properties format in 
pax-logging-log4j2 service is that it doesn’t require extra dependency. Using 
xml/json format needs additional dependency/packages/bundles in the Karaf 
distribution.
Just a side note.

Regards
JB

> Le 27 déc. 2021 à 19:33, Matt Pavlovich  a écrit :
> 
> I’ve created a proposal JIRA KARAF-7307 
> (https://issues.apache.org/jira/browse/KARAF-7307 
> ) to track any specifics.
> 
> As the subject mentions— I think it would be beneficial to users to change 
> the default configuration for log4j2 to XML (or maybe JSON). 
> 
> Notes:
> 
> 1. Documentation for the properties format is fragmented and incomplete— 
> especially for advanced features such as routing, etc
> 2. XML format is the more natural format for log4j2
> 3. Allow for developers targeting karaf runtime to use the same log4j2.xml 
> config file in their dev projects that is used in karaf runtime (using a 
> org.ops4j.pax.logging.cfg requires developers to add add’l configuration to 
> their code projects)
> 
> Thoughts?
> 
> Thanks,
> Matt
> 
> 

Merry Christmas and Happy New Year

[Jean-Baptiste Onofre]

On behalf of the Apache Karaf team, I wish you all a Merry Christmas and Happy 
New Year.

2021 has been an active year for Apache Karaf, and we can expect much more for 
2022 with Apache Karaf 5.x coming.

I will prepare a blog post about this year and coming milestones.

Thanks all for your interest on Apache Karaf and your continued open mind.

Kind Regards
JB

[RESULT][VOTE] Apache Karaf runtime 4.2.14 release

[Jean-Baptiste Onofre]

Hi,

This vote passed with the following result:

+1 (binding): François Papon, Achim Nierbeck, Freeman Fang, Jamie Goodyear, JB 
Onofré
+1 (non binding): Matt Pavlovich

I’m promoting the artifacts on Maven Central and dist.apache.org. I will also 
push the docker image.
Finally, I will update Jira and reporter, then I will do the announcement (all 
together with other releases, both on website and mailing lists).

Thanks all for your vote,

Regards
JB

> Le 20 déc. 2021 à 11:48, Jean-Baptiste Onofré  a écrit :
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.14 to your vote.
> 
> This version upgrades to Pax Logging 1.11.12 with:
> - logback 1.2.9 fixing CVE-2021-42550
> - log4j 2.16.0 fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351061
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1168/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.14/
> 
> Git tag:
> karaf-4.2.14
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

[RESULT][VOTE] Apache Karaf runtime 4.3.5 release

[Jean-Baptiste Onofre]

Hi,

This vote passed with the following result:

+1 (binding): Grzegorz Grzybek, François Papon, Achim Nierbeck, Freeman Fang, 
Jamie Goodyear, JB Onofré
+1 (non binding): Romain Manni-Bucau, Steinar Bang, Matt Pavlovich, Lukas Roedl

I’m promoting the artifacts to Maven Central and dist.apache.org, then I will 
update reporter and website. I will do announcement coupled with other 
4.3.3/4.2.13/4.2.14 releases.

Thanks all for your vote!

Regards
JB

> Le 19 déc. 2021 à 22:33, Jean-Baptiste Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.5 to your vote.
> This release includes Pax Logging 2.0.13 update:
> - with logback 1.2.9 upgrade, fixing CVE-2021-42550
> - with log4j 2.17.0 upgrade, fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1167/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.5/
> 
> Git tag:
> karaf-4.3.5
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: Karaf 4.3.4 : spring-legacy feature

[Jean-Baptiste Onofre]

Hi,

First, the spring-security bundles are available on Maven Central: 
https://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.spring-security-core/5.4.6_1/

Second, the resolver uses your bundle headers. So, if you use import package 
statement without boundaries, the resolver could try to use the latest spring 
security version available for the resolver.
Then, you have two options:
1. You use right import package statement, something like 
org.springframework.security*;version=“[5.3,5.4)”.
For instance, if you don’t specify the version (it means version=0.0.0), or 
if you set version=5.3 (meaning [5.3,) so any version newer or equal to 5.3), 
the resolver will try to use 5.4.
2. You can blacklist spring-security 5.4 features to avoid resolver to consider 
it

Regards
JB

> Le 22 déc. 2021 à 16:56, Steven Huypens  a écrit :
> 
> Hi all,
> 
> After upgrading our custom Karaf distribution from 4.3.3 to 4.3.4 our
> application tries to download some spring-security 5.4.x bundles that are
> not used by our application (it uses 5.3.x). The download fails because our
> application has no access to any repository:
> 
> 2021-12-22 12:39:27,040 -
> [o.a.k.f.i.s.BootFeaturesInstaller][activator-1-thread-2] ERROR - Error
> installing boot features
> org.apache.karaf.features.internal.util.MultiException: Error:
>Error downloading
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-security-taglibs/5.4.6_1
>Error downloading
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-security-core/5.4.6_1
>Error downloading
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-security-config/5.4.6_1
>Error downloading
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-security-acl/5.4.6_1
>Error downloading
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.spring-security-web/5.4.6_1
>at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager$MavenDownloader.(MavenDownloadManager.java:91)
>at
> org.apache.karaf.features.internal.download.impl.MavenDownloadManager.createDownloader(MavenDownloadManager.java:72)
>at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:457)
>at
> org.apache.karaf.features.internal.region.Subsystem.downloadBundles(Subsystem.java:452)
>at
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:224)
>at
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:399)
>at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1069)
>at
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
>at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>at java.base/java.lang.Thread.run(Thread.java:829)
> 
> It looks like adding the 5.4.x spring-security features (KARAF-7198) to
> spring-legacy-4.3.4-features.xml makes our application download them,
> although we're explicitly stating we want another version :
> 
>  dependency="false">spring-security
> 
> Because the karaf-maven-plugin does not download the 5.4.x bundles in the
> system-folder when creating the distro, I'm assuming our configuration is
> OK, but it looks the mechanism at runtime works different from the one used
> by the karaf-maven-plugin.
> 
> Any suggestions, other than upgrading to Spring 5.4.x ?
> 
> Kind regards,
> Steven

Re: [VOTE] Apache Karaf runtime 4.2.14 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 20 déc. 2021 à 11:48, Jean-Baptiste Onofré  a écrit :
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.14 to your vote.
> 
> This version upgrades to Pax Logging 1.11.12 with:
> - logback 1.2.9 fixing CVE-2021-42550
> - log4j 2.16.0 fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351061
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1168/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.14/
> 
> Git tag:
> karaf-4.2.14
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: [VOTE] Apache Karaf runtime 4.3.5 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 19 déc. 2021 à 22:33, Jean-Baptiste Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.5 to your vote.
> This release includes Pax Logging 2.0.13 update:
> - with logback 1.2.9 upgrade, fixing CVE-2021-42550
> - with log4j 2.17.0 upgrade, fixing CVE-2021-45105
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350856
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1167/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.5/
> 
> Git tag:
> karaf-4.3.5
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

[RESULT][VOTE] Apache Karaf runtime 4.2.13 release

[Jean-Baptiste Onofre]

Hi,

This vote passed with the following result:

+1 (binding): Jamie Goodyear, Achim Nierbeck, François Papon, JB Onofré
+1 (non binding): Serge Huber, Matt Pavlovich, Romain Manni-Bucau

I’m releasing the artifacts on Maven Central and dist.apache.org, and I’m 
updating reporter and Jira.
I will do website update and announcement coupled with 4.3.4 release.

Thanks all for your vote!

Regards
JB

> Le 16 déc. 2021 à 15:02, Jean-Baptiste Onofré  a écrit :
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.13 to your vote.
> 
> This version includes 8 fixes and improvements. Especially, it includes Pax 
> Logging 1.11.11 update, upgrading to log4j 2.16.0 fixing CVE-2021-44228 and 
> CVE-2021-45046.
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350548
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1166/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.13/
> 
> Git tag:
> karaf-4.2.13
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: Logback CVE-2021-42550

[Jean-Baptiste Onofre]

I’m closing current release votes, and I will update in Karaf to prepare new 
releases.

Regards
JB

> Le 18 déc. 2021 à 20:25, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> Done - I've released Pax Logging 1.11.12 and 2.0.13 with the Logback
> update. Thanks Matt for the initial PR - I've checked that no other changes
> are required.
> 
> regards
> Grzegorz Grzybek
> 
> sob., 18 gru 2021 o 05:42 Jean-Baptiste Onofre  napisał(a):
> 
>> Thanks,
>> 
>> However, the PR is not correct.
>> 
>> We (Greg and I) will create a right PR and move forward on Pax Logging
>> release.
>> 
>> However, just a note for the users: this issue is largely less critical
>> than log4j one.
>> Anyway, I will cut maintenance release quickly.
>> 
>> Regards
>> JB
>> 
>>> Le 17 déc. 2021 à 16:35, Matt Pavlovich  a écrit :
>>> 
>>> PR created for pax-logging against main:
>> https://github.com/ops4j/org.ops4j.pax.logging/pull/425 <
>> https://github.com/ops4j/org.ops4j.pax.logging/pull/425>
>>> 
>>> 
>>>> On Dec 17, 2021, at 9:23 AM, Matt Pavlovich  wrote:
>>>> 
>>>> I summarized notes on the Logback CVE-2021-42550 . While significantly
>> less critical, we probably need to consider another round of releases to
>> address and bring in logback 1.2.9.
>>>> 
>>>> notes here: https://issues.apache.org/jira/browse/KARAF-7299 <
>> https://issues.apache.org/jira/browse/KARAF-7299>
>>>> 
>>>> Thoughts?
>>> 
>> 
>> 

[RESULT][VOTE] Apache Karaf runtime 4.3.4 release (take #3)

[Jean-Baptiste Onofre]

Hi,

This vote passed with the following result:

+1 (binding): François Papon, Achim Nierbeck, Grzegorz Grzybek, Freeman Fang, 
Jamie Goodyear, JB Onofré
+1 (non binding): Lukas Roedl, Romain Manni-Bucau, Matt Pavlovich, Robert 
Varga, Steinar Bang, Oliver Lietz, Serge Huber

I’m promoting the artifacts on Maven Central and dist.apache.org, I’m updating 
Jira and I will prepare announcement (website and mailing lists).

Thanks all for your vote!

Regards
JB

> Le 15 déc. 2021 à 05:43, JB Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.4 to your vote (take #3). 
> 
> This release includes dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing important 
> security issue (CVE-2021-44228) and fixing JNDI issue
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1165/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> 
> Git tag:
> karaf-4.3.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: [VOTE] Apache Karaf runtime 4.2.13 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 16 déc. 2021 à 15:02, Jean-Baptiste Onofré  a écrit :
> 
> Hi all,
> 
> I submit Apache Karaf 4.2.13 to your vote.
> 
> This version includes 8 fixes and improvements. Especially, it includes Pax 
> Logging 1.11.11 update, upgrading to log4j 2.16.0 fixing CVE-2021-44228 and 
> CVE-2021-45046.
> 
> Please take a look on Release Notes for details.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350548
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1166/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.2.13/
> 
> Git tag:
> karaf-4.2.13
> 
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #3)

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 15 déc. 2021 à 05:43, JB Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.4 to your vote (take #3). 
> 
> This release includes dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to Pax Logging 2.0.12, upgrading to log4j2 2.0.15, fixing important 
> security issue (CVE-2021-44228) and fixing JNDI issue
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1165/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> 
> Git tag:
> karaf-4.3.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB
> 

Re: Logback CVE-2021-42550

[Jean-Baptiste Onofre]

Thanks,

However, the PR is not correct.

We (Greg and I) will create a right PR and move forward on Pax Logging release.

However, just a note for the users: this issue is largely less critical than 
log4j one.
Anyway, I will cut maintenance release quickly.

Regards
JB

> Le 17 déc. 2021 à 16:35, Matt Pavlovich  a écrit :
> 
> PR created for pax-logging against main: 
> https://github.com/ops4j/org.ops4j.pax.logging/pull/425 
> 
> 
> 
>> On Dec 17, 2021, at 9:23 AM, Matt Pavlovich  wrote:
>> 
>> I summarized notes on the Logback CVE-2021-42550 . While significantly less 
>> critical, we probably need to consider another round of releases to address 
>> and bring in logback 1.2.9.
>> 
>> notes here: https://issues.apache.org/jira/browse/KARAF-7299 
>> 
>> 
>> Thoughts?
> 

[CANCEL][VOTE] Apache Karaf runtime 4.3.4 release

[Jean-Baptiste Onofre]

Hi guys;

I cancel this vote to:
1. Upgrade to pax-logging 2.0.11 which includes important log4j2 CVE fix
2. Include a quick fix in the features service and autoRefresh flag (populated 
in the cfg file)

I will submit a new take to vote later today.

Sorry about that.

Regards
JB

> Le 7 déc. 2021 à 05:55, Jean-Baptiste Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.4 to your vote.
> 
> This release includes dependency upgrades, fixes, and improvements, 
> especially:
> 
> - align dependencies versions between Karaf and Pax *
> - fix missing system export packages
> - fix on Karaf features json support
> - fix features autoRefresh configuration handling
> - fix on sshd session handling
> - update to sshd 2.8.0
> - lot of pax * updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350547
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1162/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.4/
> 
> Git tag:
> karaf-4.3.4
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: karaf-maven-plugin generates another org.apache.karaf.features.xml with Java 8/Java 11

[Jean-Baptiste Onofre]

Hi Steven,

Let me try to reproduce on a simple test case.

I don’t see yet the relationship between the prefixes generated (which are not 
bad IMHO) and the OOM (I’m suspecting more like a loop in the features XML 
definition).

Just a reminder: in Karaf itself, we don’t use the generate-features MOJO, we 
write the features XML/JSON by hand (largely better to have a complete control).

Regards
JB

> Le 27 nov. 2021 à 22:15, Steven Huypens  a écrit :
> 
> Hi Bernd,
> 
> That's what I did :
> 
> 1) Compile all code with Java 8, create distro with Java 8, run with Java 8
> --> Works
> 2) Compile all code with Java 8, create distro with Java 8, run with Java
> 11 --> Works
> 3) Compile all code with Java 8, create distro with Java 11, run with Java
> 11 --> Doesn't work, app goes OOM
> 4) Compile all code with Java 11, create distro with Java 11, run with Java
> 11 --> Doesn't work, app goes OOM
> 
> The only difference between (2) and (3) is the prefix in
> org.apache.karaf.features.xml, and if I remove that manually, the app works
> as expected. I also think the generated org.apache.karaf.features.xml is
> OK, but I have no clue why the application goes OOM with it.
> 
> Kind regards,
> Steven
> 
> 
> 
> 
> 
> On Sat, Nov 27, 2021 at 10:02 PM Bernd Eckenfels 
> wrote:
> 
>> Yes looked in the wrong Schema. I think, don’t worry about the prefixes,
>> as long as the elements are correctly qualified (the processing elements in
>> your case with ns3:) they are equivalent. Your memory problems have likely
>> another cause. But as stated, it might be a good idea to list the repos and
>> features in both running instances and compare them, just to be sure.
>> 
>> (Besides the maven plugin probably should define a few fixed prefixes to
>> make it better readable)
>> 
>> Not sure why the maven plug-in is so sensitive to the jaxb version (if
>> executed with java11 it needs to provide its own). Can you maybe run both
>> builds with the same JDK?
>> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> Von: Steven Huypens 
>> Gesendet: Saturday, November 27, 2021 9:56:04 PM
>> An: dev@karaf.apache.org 
>> Betreff: Re: karaf-maven-plugin generates another
>> org.apache.karaf.features.xml with Java 8/Java 11
>> 
>> Hi Bernd,
>> 
>> - I do see 'blacklistedRepositories' in
>> http://karaf.apache.org/xmlns/features-processing/v1.0.0
>> - With the namespace-prefix my app goes OOM immediately, so I cannot
>> compare both running systems.
>> - I tried adding the prefix to each child, but that did not help
>> 
>> Kind regards,
>> Steven
>> 
>> On Sat, Nov 27, 2021 at 9:23 PM Bernd Eckenfels 
>> wrote:
>> 
>>> In that case maybe the child (deny* list?) is ignored, not sure how
>> strict
>>> the parser is in regards to namespaces. I don’t see a blacklistRepository
>>> element in the Schema anyway. It’s maybe best you inspect the running
>>> systems with feature:* commands and look for differences.
>>> 
>>> 
>>> 
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> Von: Steven Huypens 
>>> Gesendet: Saturday, November 27, 2021 8:58:20 PM
>>> An: dev@karaf.apache.org 
>>> Betreff: Re: karaf-maven-plugin generates another
>>> org.apache.karaf.features.xml with Java 8/Java 11
>>> 
>>> Hi Bernd,
>>> 
>>> Thanks for your response. The child elements have no prefix, eg.
>>> 
>>> 
>>> I'm sorry but I do not understand what you mean. You think part of my
>>> org.apache.karaf.features.xml was previously ignored ? I haven't double
>>> checked, but that would really surprise me because we have quite some
>>> blacklistedFeatures en blacklistedBundles which would cause problems if
>>> ignored.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Sat, Nov 27, 2021 at 8:22 PM Bernd Eckenfels 
>>> wrote:
>>> 
 Hello Steven
 
 How do the child elements of that element look like? Are they using
 default/f/ns2 prefix and maybe the (semantically equivalent) change
>>> affects
 your memory only because the old form ignored a actual entry for
>>> dependency?
 
 Bernd
 
 --
 http://bernd.eckenfels.net
 
 Von: Romain Manni-Bucau 
 Gesendet: Samstag, November 27, 2021 8:14 PM
 An: dev
 Betreff: Re: karaf-maven-plugin generates another
 org.apache.karaf.features.xml with Java 8/Java 11
 
 Hi Steven,
 
 
 Maybe force jaxb version to an earlier one in karag pluhin dependencies
>>> in
 your pom.
 
 
 Le sam. 27 nov. 2021 à 20:05, Steven Huypens >> 
>>> a
 écrit :
 
> Hi all,
> 
> I tried to create my custom Karaf distribution (using
>>> karaf-maven-plugin
> 4.3.2) with Java 11 for the first time, and I noticed a difference in
>>> the
> resulting org.apache.karaf.features.xml
> 
> The line
> 
> http://karaf.apache.org/xmlns/features-processing/v1.0.0; xmlns:f="
> http://karaf.apache.org/xmlns/features/v1.6.0;>
> 
> 

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi,

I’m happy to say that I just have Pax URL and Pax Logging release to do, and 
open the last PRs and I’m good for 4.3.4 release.

I will move forward on this Karaf release during the weekend.

Regards
JB

> Le 18 nov. 2021 à 13:34, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> I found that jetty 9.4.44 update also breaks CXF.
> 
> So, I decided to rollback to Pax Web 7.2.19 and Pax URL 2.6.7.
> 
> I’m moving forward with other tasks.
> 
> Regards
> JB
> 
>> Le 16 nov. 2021 à 14:59, Jean-Baptiste Onofré  a écrit :
>> 
>> Hi,
>> 
>> Yes, pax-url, and also pax-web ;)
>> 
>> I have both on the way ;)
>> 
>> Regards
>> JB
>> 
>> On 16/11/2021 12:35, Grzegorz Grzybek wrote:
>>> Hi
>>> pon., 15 lis 2021 o 11:05 Jean-Baptiste Onofré  
>>> napisał(a):
>>>> Hi Greg,
>>>> 
>>>> No, it's not related to annotations: it's missing jaspi import in the
>>>> web bundle created on the fly by the war extender.
>>>> 
>>> It looks like pax-url-war problem then...
>>> regards
>>> Grzegorz Grzybek
>>>> 
>>>> I'm testing the fix right now and I will push a new Pax Web release.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>> On 15/11/2021 07:02, Grzegorz Grzybek wrote:
>>>>> Hello
>>>>> 
>>>>> niedz., 14 lis 2021 o 17:18 Jean-Baptiste Onofre 
>>>>> napisał(a):
>>>>> 
>>>>>> Hi guys,
>>>>>> 
>>>>>> FYI, I just found an issue in Pax Web 7.3.21 (related to Jetty update,
>>>> in
>>>>>> the war extender). I’m fixing it now and I will cut a new Pax Web 7.3.x
>>>>>> release to update in Karaf.
>>>>>> 
>>>>> 
>>>>> Is it related to jetty 9.4.44 and annotations? Can I help?
>>>>> 
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>> 
>>>>> 
>>>>>> 
>>>>>> I’m moving forward as quick as possible to submit Karaf 4.3.4 and
>>>>>> 4.4.0.RC1 to vote.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 12 nov. 2021 à 14:38, Jean-Baptiste Onofré  a
>>>> écrit
>>>>>> :
>>>>>>> 
>>>>>>> Hi Robert,
>>>>>>> 
>>>>>>> From an user standpoint, you are right.
>>>>>>> 
>>>>>>> I updated Karaf to use "individual" bundles. I think I sent a message
>>>> on
>>>>>> the mailing list about that.
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>> On 12/11/2021 14:34, Robert Varga wrote:
>>>>>>>> On 12/11/2021 10:23, Paul Stanley wrote:
>>>>>>>>> Thanks JB.
>>>>>>>> Hello Paul,
>>>>>>>>> I would have though that OSGI R8 is backwards compatible with R7, as
>>>> I
>>>>>>>>> didn't see any breaking changes in the spec.
>>>>>>>> True, but the artifact packaging with R8 broken up to support JPMS --
>>>>>> i.e. no osgi.cmpn anymore. That is a breaking change from build system
>>>>>> perspective.
>>>>>>>> Regards,
>>>>>>>> Robert
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
> 

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi guys,

I found that jetty 9.4.44 update also breaks CXF.

So, I decided to rollback to Pax Web 7.2.19 and Pax URL 2.6.7.

I’m moving forward with other tasks.

Regards
JB

> Le 16 nov. 2021 à 14:59, Jean-Baptiste Onofré  a écrit :
> 
> Hi,
> 
> Yes, pax-url, and also pax-web ;)
> 
> I have both on the way ;)
> 
> Regards
> JB
> 
> On 16/11/2021 12:35, Grzegorz Grzybek wrote:
>> Hi
>> pon., 15 lis 2021 o 11:05 Jean-Baptiste Onofré  
>> napisał(a):
>>> Hi Greg,
>>> 
>>> No, it's not related to annotations: it's missing jaspi import in the
>>> web bundle created on the fly by the war extender.
>>> 
>> It looks like pax-url-war problem then...
>> regards
>> Grzegorz Grzybek
>>> 
>>> I'm testing the fix right now and I will push a new Pax Web release.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 15/11/2021 07:02, Grzegorz Grzybek wrote:
>>>> Hello
>>>> 
>>>> niedz., 14 lis 2021 o 17:18 Jean-Baptiste Onofre 
>>>> napisał(a):
>>>> 
>>>>> Hi guys,
>>>>> 
>>>>> FYI, I just found an issue in Pax Web 7.3.21 (related to Jetty update,
>>> in
>>>>> the war extender). I’m fixing it now and I will cut a new Pax Web 7.3.x
>>>>> release to update in Karaf.
>>>>> 
>>>> 
>>>> Is it related to jetty 9.4.44 and annotations? Can I help?
>>>> 
>>>> regards
>>>> Grzegorz Grzybek
>>>> 
>>>> 
>>>>> 
>>>>> I’m moving forward as quick as possible to submit Karaf 4.3.4 and
>>>>> 4.4.0.RC1 to vote.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Le 12 nov. 2021 à 14:38, Jean-Baptiste Onofré  a
>>> écrit
>>>>> :
>>>>>> 
>>>>>> Hi Robert,
>>>>>> 
>>>>>>  From an user standpoint, you are right.
>>>>>> 
>>>>>> I updated Karaf to use "individual" bundles. I think I sent a message
>>> on
>>>>> the mailing list about that.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>> On 12/11/2021 14:34, Robert Varga wrote:
>>>>>>> On 12/11/2021 10:23, Paul Stanley wrote:
>>>>>>>> Thanks JB.
>>>>>>> Hello Paul,
>>>>>>>> I would have though that OSGI R8 is backwards compatible with R7, as
>>> I
>>>>>>>> didn't see any breaking changes in the spec.
>>>>>>> True, but the artifact packaging with R8 broken up to support JPMS --
>>>>> i.e. no osgi.cmpn anymore. That is a breaking change from build system
>>>>> perspective.
>>>>>>> Regards,
>>>>>>> Robert
>>>>> 
>>>>> 
>>>> 
>>> 

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi guys,

FYI, I just found an issue in Pax Web 7.3.21 (related to Jetty update, in the 
war extender). I’m fixing it now and I will cut a new Pax Web 7.3.x release to 
update in Karaf.

I’m moving forward as quick as possible to submit Karaf 4.3.4 and 4.4.0.RC1 to 
vote.

Regards
JB

> Le 12 nov. 2021 à 14:38, Jean-Baptiste Onofré  a écrit :
> 
> Hi Robert,
> 
> From an user standpoint, you are right.
> 
> I updated Karaf to use "individual" bundles. I think I sent a message on the 
> mailing list about that.
> 
> Regards
> JB
> 
> On 12/11/2021 14:34, Robert Varga wrote:
>> On 12/11/2021 10:23, Paul Stanley wrote:
>>> Thanks JB.
>> Hello Paul,
>>> I would have though that OSGI R8 is backwards compatible with R7, as I
>>> didn't see any breaking changes in the spec.
>> True, but the artifact packaging with R8 broken up to support JPMS -- i.e. 
>> no osgi.cmpn anymore. That is a breaking change from build system 
>> perspective.
>> Regards,
>> Robert

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi guys,

As said in my previous email I have a fix that I’m testing now.

I will let you know when done.

Regards
JB

> Le 29 oct. 2021 à 15:28, Grzegorz Grzybek  a écrit :
> 
> Now, when creating Pax Web 8 pax-web-jetty-bundle (all-in-one Jetty), I'm
> getting:
> 
> java.util.ServiceConfigurationError:
> org.eclipse.jetty.security.Authenticator$Factory: Provider
> org.eclipse.jetty.security.jaspi.JaspiAuthenticatorFactory not a subtype
> at java.util.ServiceLoader.fail(ServiceLoader.java:239) ~[?:1.8.0_312]
> at java.util.ServiceLoader.access$300(ServiceLoader.java:185) ~[?:1.8.0_312]
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:376)
> ~[?:1.8.0_312]
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> ~[?:1.8.0_312]
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480) ~[?:1.8.0_312]
> at
> org.eclipse.jetty.security.SecurityHandler.(SecurityHandler.java:88)
> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?]
> ...
> at
> org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:131)
> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.(ServletContextHandler.java:136)
> ~[pax-web-jetty-bundle-8.0.1-SNAPSHOT.jar:?]
> at
> org.ops4j.pax.web.service.jetty.internal.PaxWebServletContextHandler.(PaxWebServletContextHandler.java:97)
> ~[pax-web-jetty-8.0.1-SNAPSHOT.jar:?]
> 
> Checking...
> regards
> Grzegorz Grzybek
> 
> pt., 29 paź 2021 o 13:19 Grzegorz Grzybek  napisał(a):
> 
>> Hi
>> 
>> pax-web-jetty before Pax Web 8 used jetty-all, which has dependency on
>> jetty-jaspic, which has dependency on javax.security.auth.message...
>> 
>> Let me check it.
>> 
>> regards
>> Grzegorz Grzybek
>> 
>> pt., 29 paź 2021 o 13:12 Paul Stanley 
>> napisał(a):
>> 
>>> The Jetty issue: https://github.com/eclipse/jetty.project/issues/6554
>>> resulted in pull request:
>>> 
>>> https://github.com/eclipse/jetty.project/commit/4fd1a4ea4b7a989ea16f40ba7c49dc553ae2ace1
>>> This removed the check for the realm being set, thus always creating a
>>> default identity service, even when one is not defined.
>>> As a result the geronimo JASPI spec  (Java Authentication SPI),  Attempts
>>> to construct a default JASPI factory, resulting in a Class Not Found
>>> Exception.
>>> 
>>> I've had a quick look at the pax-web-jetty project, but i can't see any
>>> geronimo dependencies. As such one of the test modules must have the api
>>> and implementation built in, or it's using a different Jetty Identity
>>> Service?
>>> 
>>> Cheers
>>> Paul
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From:   "Grzegorz Grzybek" 
>>> To: "Karaf Dev" 
>>> Date:   29/10/2021 11:36
>>> Subject:Re: Preparing Karaf runtime 4.3.4
>>> 
>>> 
>>> 
>>> Hello
>>> 
>>> What's the problem with Jetty 9.4.44? I checked with Pax Web 8 without any
>>> changes and I got:
>>> 
>>> [INFO] Results:
>>> [INFO]
>>> [WARNING] Tests run: 201, Failures: 0, Errors: 0, Skipped: 2
>>> ...
>>> [INFO]
>>> [INFO] --- maven-failsafe-plugin:2.22.2:verify (verify) @
>>> pax-web-itest-jetty ---
>>> [INFO]
>>> 
>>> [INFO] BUILD SUCCESS
>>> [INFO]
>>> 
>>> [INFO] Total time:  05:34 min
>>> [INFO] Finished at: 2021-10-29T12:34:12+02:00
>>> [INFO]
>>> 
>>> 
>>> The tests include authentication and TLS tests.
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> pt., 29 paź 2021 o 11:44 Paul Stanley 
>>> napisał(a):
>>> 
>>>> Hi JB,
>>>> 
>>>> Jetty 9.4.44 now attempts to create the default instance of the jaspi,
>>>> even if it is not installed or used.
>>>> I've included the geronimo-jaspi implementation alongside the geronimo
>>>> -jaspic_1.0_spec to address the issue.
>>>> Note that ordering is important as there is static code begin used to
>>>> register the jaspic factories, thus the above packages need to loaded
>>> into
>>>> the runtime prior to the jetty bundles.
>>>> 
>>>> Cheers
>>>> Paul
>

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi guys,

I detected that Jetty 9.4.44 update breaks the authentication layer.
I’m fixing that and I will cut Pax Web 7.3.20 to integrate in Karaf 4.3.4.

I will keep you posted, however, the plan is still to submit Karaf 4.3.4 to 
vote during the week end.

Regards
JB

> Le 12 oct. 2021 à 14:43, JB Onofré  a écrit :
> 
> Hi guys
> 
> I’m working on Felix FileInstall release fixing the first losing issue. I 
> will include couple of other important fixes. 
> 
> I would like to submit Karaf 4.3.4 to vote during the week end or early next 
> week. 
> 
> Thoughts ?
> 
> Regards 
> JB

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Actually, I just have additional binding votes on Felix FileInstall release. I 
will move forward on this front.

Regards
JB

> Le 24 oct. 2021 à 11:02, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> Just to let you know that Felix FileInstall 3.7.2 release is in vote. I hope 
> to have the three binding votes by tomorrow.
> 
> I did several updates/fixes for which I gonna create PRs.
> 
> So, I think I will reasonably have Karaf 4.3.4 release in vote by mid next 
> week.
> 
> Regards
> JB
> 
>> Le 12 oct. 2021 à 14:43, JB Onofré  a écrit :
>> 
>> Hi guys
>> 
>> I’m working on Felix FileInstall release fixing the first losing issue. I 
>> will include couple of other important fixes. 
>> 
>> I would like to submit Karaf 4.3.4 to vote during the week end or early next 
>> week. 
>> 
>> Thoughts ?
>> 
>> Regards 
>> JB
> 

Re: Preparing Karaf runtime 4.3.4

[Jean-Baptiste Onofre]

Hi guys,

Just to let you know that Felix FileInstall 3.7.2 release is in vote. I hope to 
have the three binding votes by tomorrow.

I did several updates/fixes for which I gonna create PRs.

So, I think I will reasonably have Karaf 4.3.4 release in vote by mid next week.

Regards
JB

> Le 12 oct. 2021 à 14:43, JB Onofré  a écrit :
> 
> Hi guys
> 
> I’m working on Felix FileInstall release fixing the first losing issue. I 
> will include couple of other important fixes. 
> 
> I would like to submit Karaf 4.3.4 to vote during the week end or early next 
> week. 
> 
> Thoughts ?
> 
> Regards 
> JB

[INFO] Build failure on Jenkins

[Jean-Baptiste Onofre]

Hi guys,

Just to let you know, I identified a build issue on Jenkins (while testing 
audit core bundle). I will fix that today.

Sorry for the inconvenience.

By the way, I will send another message: I would like to cut Karaf 4.3.4 pretty 
soon to include some missing system packages and couple of fixes. I will keep 
you posted about that.

Regards
JB

[ANN] Apache Karaf Decanter 2.8.0 has been released!

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased to announce Apache Karaf Decanter 2.8.0 
release.

 This release contains bug fixes, dependencies upgrade, and new features, 
especially:

- fix on InfluxDB appender startup
- improvements on the Prometheus appender
- warning message when the socket collector bounded stream is larger
- be able to define topic name in all collectors
- bunch of collector/appender dependency updates

You can take a look on Release Notes for details:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349716

The release and installation instructions are available on Apache Karaf website:
http://karaf.apache.org/download.html

Enjoy!
Apache Karaf team

Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch

[Jean-Baptiste Onofre]

Yeah, we already discussed about this and it makes sense.

So, let me update main and then we can work directly on main for Pax Web 8.0.0 
compliant commands.

Regards
JB

> Le 21 sept. 2021 à 09:05, Grzegorz Grzybek  a écrit :
> 
> Hi
> 
> Visibility has changed slightly, but the main problem is that:
> 
>   - http:* commands relied on stored "initial servlet events" which IMO is
>   bad pattern - first, http:* commands (in Karaf with Pax Web 7) could
>   investigate servlets only. But also it's better to check the current state
>   of Pax Web runtime directly (in kind of HttpServiceRuntime DTO way) instead
>   of relying on past events.
>   - web:* commands relied on weird WarManager interface/service from Pax
>   Web 7, which only exposed bundle IDs of web bundles - it doesn't give any
>   insight into the WAB's content and also we couldn't observe contexts
>   (context paths) created by Whiteboard and HttpService - like "/" context to
>   which CXF registers it's /cxf servlet for example
> 
> The above problems are easily fixable in Pax Web 8, just give me some time
> ;)
> 
> regards
> Grzegorz Grzybek
> 
> wt., 21 wrz 2021 o 08:52 Jean-Baptiste Onofre  napisał(a):
> 
>> Hi
>> 
>> I have couple of issue with SPI visibility as some packages/classes are
>> not « public » anymore (I’m thinking about WebEvent).
>> 
>> It’s especially true in the Karaf http commands, so, this should be
>> updated.
>> 
>> Anyway, I propose to push main with 4.4.0-SNAPSHOT with Pax Web 7.3.x and
>> update to Pax Web 8.0.0 directly on main.
>> 
>> Regards
>> JB
>> 
>>> Le 21 sept. 2021 à 08:50, Grzegorz Grzybek  a
>> écrit :
>>> 
>>> Thanks JBO!
>>> 
>>> I'll have a look at Pax Web 8 integration with Karaf - generally it
>> works,
>>> but I want something "special" here.
>>> Pax Web 8 (historically) re-exports org.osgi.service.http.* packages -
>> I'll
>>> think about moving the HttpService/Whiteboard APIs to external
>>> org.osgi/org.osgi.service.http bundle, but I have no clear opinion yet.
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> wt., 21 wrz 2021 o 08:44 Jean-Baptiste Onofre 
>> napisał(a):
>>> 
>>>> Hi guys,
>>>> 
>>>> I have almost finished the main branch update with:
>>>> 
>>>> - OSGi R8 (Felix Framework 7.0.1)
>>>> - remove of OSGi cmpn and use of single spec bundle now (recommended
>> now)
>>>> - update to Pax Web 8.0.0
>>>> 
>>>> You can take a look on the working branch here:
>>>> 
>>>> https://github.com/jbonofre/karaf/tree/K44
>>>> 
>>>> I’m running several builds now to verify all tests are OK, etc.
>>>> 
>>>> If there’s no objection, I would like to push:
>>>> 
>>>> - create karaf-4.3.x branch with the current main HEAD
>>>> - update main branch with K44 branch
>>>> 
>>>> Thoughts ?
>>>> 
>>>> Thanks
>>>> Regards
>>>> JB
>> 
>> 

Re: Main updated to 4.4.0-SNAPSHOT and karaf-4.3.x branch

[Jean-Baptiste Onofre]

Hi

I have couple of issue with SPI visibility as some packages/classes are not « 
public » anymore (I’m thinking about WebEvent).

It’s especially true in the Karaf http commands, so, this should be updated.

Anyway, I propose to push main with 4.4.0-SNAPSHOT with Pax Web 7.3.x and 
update to Pax Web 8.0.0 directly on main.

Regards
JB

> Le 21 sept. 2021 à 08:50, Grzegorz Grzybek  a écrit :
> 
> Thanks JBO!
> 
> I'll have a look at Pax Web 8 integration with Karaf - generally it works,
> but I want something "special" here.
> Pax Web 8 (historically) re-exports org.osgi.service.http.* packages - I'll
> think about moving the HttpService/Whiteboard APIs to external
> org.osgi/org.osgi.service.http bundle, but I have no clear opinion yet.
> 
> regards
> Grzegorz Grzybek
> 
> wt., 21 wrz 2021 o 08:44 Jean-Baptiste Onofre  napisał(a):
> 
>> Hi guys,
>> 
>> I have almost finished the main branch update with:
>> 
>> - OSGi R8 (Felix Framework 7.0.1)
>> - remove of OSGi cmpn and use of single spec bundle now (recommended now)
>> - update to Pax Web 8.0.0
>> 
>> You can take a look on the working branch here:
>> 
>> https://github.com/jbonofre/karaf/tree/K44
>> 
>> I’m running several builds now to verify all tests are OK, etc.
>> 
>> If there’s no objection, I would like to push:
>> 
>> - create karaf-4.3.x branch with the current main HEAD
>> - update main branch with K44 branch
>> 
>> Thoughts ?
>> 
>> Thanks
>> Regards
>> JB

Re: Pax Web 8 performance (different JDKs)

[Jean-Baptiste Onofre]

Hi Greg 

Thanks for the update and great results !

I’m running a new build/pass and I will test in 4.3.x.

What I have in mind is to prepare 4.4.x with Pax Web 8 and OSGi R8.

So, I would create karaf-4.3.x branch and update main to OSGi R8/Pax Web 8.

Thoughts ?

Regards
JB

> Le 12 sept. 2021 à 19:30, Grzegorz Grzybek  a écrit :
> 
> Good evening!
> 
> I've just pushed last commit before 8.0.0.GA. This commit fixed the 
> compilation and test problems under JDK17.
> 
> Current state is:
>  - all the tasks I've planned for 8.0.0.GA are finished
>  - all the tests (unit, pax-exam-container-native, pax-exam-container-karaf) 
> work on JDK 8, JDK 11 and JDK 17
> 
> I expected that everything would work few percent slower on JDK 11 than on 
> JDK 8 (I observed this performance downgrade on several occasions). What I 
> didn't expect is that generally everything works faster on JDK 17 than on JDK 
> 8!
> 
> Here's the table:
> 
> 
> 
> I hope to write more about "what is Pax Web 8" soon and that the week of Sep 
> 13-17 will be the week of the release.
> 
> kind regards
> Grzegorz Grzybek

[Board Report] September 2021

[Jean-Baptiste Onofre]

Hi guys,

I prepared the board report for this month: 
https://cwiki.apache.org/confluence/display/KARAF/Board+Reports

Here’s the online version:

## Description:
The mission of the Apache Karaf project is to provide an application
ecosystem. Apache Karaf runtime is a modulith runtime allowing to run any kind
of applications. Karaf subprojects bring additional features for this runtime
and running applications.
## Issues:
There are no issues requiring board attention at this time.
## Membership Data:
Apache Karaf was founded 2010-06-16 (11 years ago)
There are currently 31 committers and 17 PMC members in this project.
The Committer-to-PMC ratio is roughly 8:5.
Community changes, past quarter:
- No new PMC members. Last addition was Francois Papon on 2018-11-29.
- No new committers. Last addition was Francois Papon on 2018-05-19.
## Project Activity:
Karaf runtime 4.3.3 has been released, it's a major release on the 4.3 series.
On the other hand, Karaf runtime 4.2.12 is in preparation (vote will start
shortly), as well as Karaf Decanter 2.8.0.
Karaf main will be upgraded to 4.4 series to update to OSGi R8.
We also did good progress on Karaf 5 proposal: it will presented during
ApacheCoon.
## Community Health:
We are looking forward on ApacheCon to have kind of discussion panel about
Karaf 5 (expectations, use cases, etc). We also plan a Karaf meetup before the
end of the year to announce Karaf 5.
We also started to work with other projects (especially Camel and CXF) to have 
a better Karaf support.

Please let me know if it’s OK for you and feel free to add content.

I would like to send the board report asap.

Thanks,
Regards
JB

[RESULT][VOTE] Apache Karaf runtime 4.3.3 release

[Jean-Baptiste Onofre]

Hi all,

This vote passed with the following result:

+1 (binding): Jamie Goodyear, Freeman Fang, François Papon, Grzegorz Grzybek, 
JB Onofré
+1 (non binding): Steinar Bang, Robert Varga, Romain Manni-Bucau, Matt Pavlovich

I’m promoting the artifacts on Maven Central and dist, I will update website 
and Jira and will do the announce. I will also write a quick blog post about 
some highlights in this release.

Thanks all for your vote!

Regards
JB

> Le 2 sept. 2021 à 10:33, Jean-Baptiste Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.3 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - first round of the specs features repository. This repository use will 
> spread (in Karaf and third party projects) and we will improve it, but this 
> first round introduces the skeleton we need.
> - ssh fix new closing socket cleanly
> - memory leak fix on the blueprint state service
> - fix on JMX exception push back to the client
> - bunch of dependency updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1157/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.3/
> 
> Git tag:
> karaf-4.3.3
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: [VOTE] Apache Karaf runtime 4.3.3 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 2 sept. 2021 à 10:33, Jean-Baptiste Onofré  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.3 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - first round of the specs features repository. This repository use will 
> spread (in Karaf and third party projects) and we will improve it, but this 
> first round introduces the skeleton we need.
> - ssh fix new closing socket cleanly
> - memory leak fix on the blueprint state service
> - fix on JMX exception push back to the client
> - bunch of dependency updates
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1157/
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.3/
> 
> Git tag:
> karaf-4.3.3
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: Spring Boot support in Karaf

[Jean-Baptiste Onofre]

Hi Steven,

Yes and no: Spring Boot support is planned but not yet available in Karaf 4.x.

The target is Karaf 5.x (I’m working on it right now): Karaf 5.x is a deep 
refactoring of Karaf runtime.
I will give a talk about Karaf 5.x during ApacheCon.

Regards
JB

> Le 6 sept. 2021 à 11:55, Steven Huypens  a écrit :
> 
> Hi all,
> 
> As I understand from the homepage, the Karaf runtime supports Spring Boot
> applications. However, I'm having a hard time finding any more info on
> this. Can anyone provide some more info or any pointers on this subject ?
> 
> Kind regards,
> Steven

Re: [VOTE] Apache Karaf runtime 4.3.3 release

[Jean-Baptiste Onofre]

Karaf 4.3.3 already ships Jetty 9.4.43:

https://github.com/apache/karaf/blob/karaf-4.3.3/assemblies/features/standard/src/main/feature/feature.xml#L902

And Pax Web does as well (I did the release specifically).

Regards
JB

> Le 2 sept. 2021 à 18:44, Robert Varga  a écrit :
> 
> On 02/09/2021 10:33, Jean-Baptiste Onofré wrote:
>> Hi everyone,
> 
> Hello JB, everyone,
> 
>> I submit Apache Karaf runtime 4.3.3 to your vote.
>> 
>> This release includes bunch of dependency upgrades, fixes, and
>> improvements, especially:
>> 
>> - first round of the specs features repository. This repository use will
>> spread (in Karaf and third party projects) and we will improve it, but
>> this first round introduces the skeleton we need.
>> - ssh fix new closing socket cleanly
>> - memory leak fix on the blueprint state service
>> - fix on JMX exception push back to the client
>> - bunch of dependency updates
>> - and much more !
>> 
>> Please take a look on Release Notes for details !
>> 
>> Release Notes:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12350142
>> 
>> 
>> Staging Maven Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1157/
>> 
>> Staging Dist Repository:
>> https://dist.apache.org/repos/dist/dev/karaf/4.3.3/
>> 
>> Git tag:
>> karaf-4.3.3
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
> 
> A quick ODL smoke test passed, but I really would like a release with
> https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.43.v20210629,
> which is fixing a CVE.
> 
> Regards,
> Robert

Re: Top Contributors

[Jean-Baptiste Onofre]

Hi Bernd,

Thanks, much appreciated ;)

I’m at your service ;)

Regards
JB

> Le 31 août 2021 à 17:51, Bernd Eckenfels  a écrit :
> 
> Congratulations to JB and Andrea for beeing recognized as top committers and 
> senders in the latest annual ASF report
> 
> https://s.apache.org/FY2021AnnualReport
> 
> And of course also a huge thank you to all other contributors from my side. I 
> came across the report and thought it’s a good reason to say thank you.
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

Re: KARAF-4609 Be able to override ConfigAdmin properties with System/JVM properties

[Jean-Baptiste Onofre]

Hi,

Yes it’s normal, the config file can contain whatever you want.

When you use implicit env variable, the config property is override at runtime.

So, if you have etc/my.config.cfg containing:

foo=bar

Without any env variable, foo value will be bar.

If you set export MY_CONFIG_FOO=other, then foo value will be other, but the 
config file itself still contain bar.

Regards
JB

> Le 19 juil. 2021 à 07:24, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> From your answer I understand that Karaf will actually edit my config-file,
> but we don't see this. The application behaviour is as expected, but the
> config-file still contains the default values (as does ConfigAdmin), which
> might be confusing.
> 
> Is that how it is supposed to work, or should I have a closer to look at it?
> 
> Kind regards,
> Steven
> 
> On Fri, Jul 16, 2021 at 4:41 PM Steven Huypens 
> wrote:
> 
>> 
>> Thanks, we got it working now !
>> 
>> Steven
>> 
>> On Fri, Jul 16, 2021 at 1:30 PM Jean-Baptiste Onofré 
>> wrote:
>> 
>>> Hi,
>>> 
>>> yes, it's normal: the env variable support is now "implicit".
>>> 
>>> You can still use ${env:*} syntax (it's the explicit form), or just the
>>> corresponding env variable is enough (implicit).
>>> 
>>> Basically, if you do:
>>> 
>>> export COM_MY_PID_FOO=bar
>>> 
>>> Karaf will set property foo to bar in etc/com.my.pid.cfg configuratuion
>>> file (aka com.my.pid configuration).
>>> 
>>> You can find some details about this here:
>>> 
>>> https://nanthrax.blogspot.com/2020/11/what-new-in-apache-karaf-430_9.html
>>> 
>>> 
>>> http://karaf.apache.org/manual/latest/#_environment_variables_system_properties
>>> 
>>> Regards
>>> JB
>>> 
>>> On 7/16/21 11:46 AM, Steven Huypens wrote:
 Hi all,
 
 After upgrading to Karaf 4.3.2 the config file
 org.apache.karaf.management.cfg seems to have changed unexpectedly. For
 example
 
 *rmiRegistryPort =
>>> ${env:ORG_APACHE_KARAF_MANAGEMENT_RMIREGISTRYPORT:-1099}*
 
 has been changed into
 
 *rmiRegistryPort = 1099*
 
 Is this intentional ? From
>>> https://issues.apache.org/jira/browse/KARAF-4609
 I understand the environment variables should be included in 4.3 as
>>> well ?
 
 Kind regards,
 Steven Huypens
 
>>> 
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>> 
>> 

Karaf at ApacheCon

[Jean-Baptiste Onofre]

Hi guys,

Due to the number of Karaf related talks, and approvals, the Karaf track was 
not "fully" loaded.

So, with the planners, we decided to have the Karaf talks in other track.

You will find the following talk about Karaf:

* In the API & Microservice track:

Wednesday 18:50 UTC
Splitting Monolith Application to Microservices: gains and challenges from the 
practical experience
Andrei Shakirin

* In the Highlights track:

Tuesday 14:10 UTC
Apache Karaf 5, the new runtime (and Decanter for overall observability)
JB Onofré

The later talk will be official announcement/launch of Karaf 5, even if we will 
have some preview release during summer.

I would like also to propose a Karaf Meetup during ApacheCon to give a chance 
to have a discussion panel all together and eventually informal talks.

Regards
JB

Re: Releases schedule

[Jean-Baptiste Onofre]

Hi guys,

New update about the releases ;)

My relocation is almost done (still in the middle of the boxes ;)), so I will 
have time this week to move forward with the fixes and releases preparation.

I will keep you posted soon !

Regards
JB

> Le 20 juin 2021 à 06:11, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> I’m moving forward on the different tasks we have on the fly.
> 
> However, next week I will be semi-off (relocation in progress ;) ).
> 
> I will keep you posted soon !
> 
> Regards
> JB
> 
>> Le 14 juin 2021 à 07:18, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi guys,
>> 
>> I’m a bit late on the releases preparation but moving forward anyway.
>> 
>> I will keep you posted soon.
>> 
>> Regards
>> JB
>> 
>>> Le 25 mai 2021 à 06:33, Jean-Baptiste Onofre  a écrit :
>>> 
>>> Hi guys,
>>> 
>>> Just a quick update about the release schedule:
>>> 
>>> - Karaf runtime 4.2.12 is in preparation. Target date is this week end for 
>>> the vote.
>>> - Karaf Decanter 2.8.0 is in preparation. Target date is this week end for 
>>> the vote as well.
>>> - Karaf Cave 4.2.2 should be in preparation soon but I’ve not yet started.
>>> - Karaf Cellar 4.3.0 refactoring started. Target date for a first RC is 
>>> next month.
>>> 
>>> I’m updating website (schedule table) accordingly.
>>> 
>>> If you have specific Jira or comments to include in these releases, please 
>>> let me know.
>>> 
>>> Thanks,
>>> Regards
>>> JB
>> 
> 

Re: Releases schedule

[Jean-Baptiste Onofre]

Hi guys,

I’m moving forward on the different tasks we have on the fly.

However, next week I will be semi-off (relocation in progress ;) ).

I will keep you posted soon !

Regards
JB

> Le 14 juin 2021 à 07:18, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> I’m a bit late on the releases preparation but moving forward anyway.
> 
> I will keep you posted soon.
> 
> Regards
> JB
> 
>> Le 25 mai 2021 à 06:33, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi guys,
>> 
>> Just a quick update about the release schedule:
>> 
>> - Karaf runtime 4.2.12 is in preparation. Target date is this week end for 
>> the vote.
>> - Karaf Decanter 2.8.0 is in preparation. Target date is this week end for 
>> the vote as well.
>> - Karaf Cave 4.2.2 should be in preparation soon but I’ve not yet started.
>> - Karaf Cellar 4.3.0 refactoring started. Target date for a first RC is next 
>> month.
>> 
>> I’m updating website (schedule table) accordingly.
>> 
>> If you have specific Jira or comments to include in these releases, please 
>> let me know.
>> 
>> Thanks,
>> Regards
>> JB
> 

Re: [PROPOSAL] features.deployer=[true|false] and new tool waiting Karaf 5

[Jean-Baptiste Onofre]

Hi Bernd

Good question: for Karaf 4, the karaf launcher will "extract" and bootstrap 
Karaf as it is today. That’s a first step.

So, it means that we can bootstrap.

Karaf 5 will use a more pure "jar" way ;)

Regards
JB

> Le 14 juin 2021 à 13:51, Bernd Eckenfels  a écrit :
> 
> Hello JB,
> 
> It sounds good. How is the jar been run, will it unpack,dynamically? Is there 
> provisions for config template or a mechanism for a container install?
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> 
> Von: Jean-Baptiste Onofre 
> Gesendet: Monday, June 14, 2021 7:24:10 AM
> An: dev@karaf.apache.org 
> Betreff: [PROPOSAL] features.deployer=[true|false] and new tool waiting Karaf 
> 5
> 
> Hi guys,
> 
> Following the discussion on a previous mailing list thread, I moved forward 
> on the features resolver.
> I will submit a PR containing a new features.deployer=[true|false] property 
> in etc/org.apache.karaf.features.cfg. If true, it’s the current behavior, 
> nothing change (it’s the default). If false, we won’t use a full resolver, 
> but a very simple one, just executing/installing what’s in the features 
> xml/json.
> 
> On the other hand, waiting Karaf 5, I would like to propose a new tool 
> (runnable/cli/maven) to "wrap" karaf distribution and user artifacts in a 
> ready to run jar.
> So, basically, it’s mean that we will be able to do something like:
> 
>$ karaf-packager —version 4.3.2 —features-repos mvn:…,file:… —features 
> foo, bar —name mystuff
> 
> And the result will be mystuff.jar able to do java -jar mystuff.jar
> Of course, we will be able to include Karaf-packager in CI.
> 
> Thoughts ?
> 
> Karaf 5 already works this way and we did good progress on K5, I will share 
> details pretty soon.
> 
> Regards
> JB
> 
> 

[PROPOSAL] features.deployer=[true|false] and new tool waiting Karaf 5

[Jean-Baptiste Onofre]

Hi guys,

Following the discussion on a previous mailing list thread, I moved forward on 
the features resolver.
I will submit a PR containing a new features.deployer=[true|false] property in 
etc/org.apache.karaf.features.cfg. If true, it’s the current behavior, nothing 
change (it’s the default). If false, we won’t use a full resolver, but a very 
simple one, just executing/installing what’s in the features xml/json.

On the other hand, waiting Karaf 5, I would like to propose a new tool 
(runnable/cli/maven) to "wrap" karaf distribution and user artifacts in a ready 
to run jar.
So, basically, it’s mean that we will be able to do something like:

$ karaf-packager —version 4.3.2 —features-repos mvn:…,file:… —features foo, 
bar —name mystuff

And the result will be mystuff.jar able to do java -jar mystuff.jar
Of course, we will be able to include Karaf-packager in CI.

Thoughts ?

Karaf 5 already works this way and we did good progress on K5, I will share 
details pretty soon.

Regards
JB

Re: Releases schedule

[Jean-Baptiste Onofre]

Hi guys,

I’m a bit late on the releases preparation but moving forward anyway.

I will keep you posted soon.

Regards
JB

> Le 25 mai 2021 à 06:33, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> Just a quick update about the release schedule:
> 
> - Karaf runtime 4.2.12 is in preparation. Target date is this week end for 
> the vote.
> - Karaf Decanter 2.8.0 is in preparation. Target date is this week end for 
> the vote as well.
> - Karaf Cave 4.2.2 should be in preparation soon but I’ve not yet started.
> - Karaf Cellar 4.3.0 refactoring started. Target date for a first RC is next 
> month.
> 
> I’m updating website (schedule table) accordingly.
> 
> If you have specific Jira or comments to include in these releases, please 
> let me know.
> 
> Thanks,
> Regards
> JB

Re: Simplification for user specific configuration handling in custom assemblies

[Jean-Baptiste Onofre]

It sounds good ! Thanks for the proposal. Let me know if you need help with 
Jira, I will do the improvement.

Regards
JB

> Le 11 juin 2021 à 12:35, Łukasz Dywicki  a écrit :
> 
> Indeed It is the same mechanism I would love to see employed in
> mentioned places.
> 
> The way how custom.system.properties works is great. Combined with
> property resolver and fallbacks we can save peoples time in
> synchronizing (jre|custom).properties.
> 
> I will try to book some time for this to register JIRA and cook an PR in
> coming weeks (please don't be surprised if it will turn into a month).
> 
> Best,
> Łukasz
> --
> Integrate software (Code-House) & hardware (ConnectorIO)
> http://code-house.org
> http://connectorio.com
> 
> On 11.06.2021 12:25, Jean-Baptiste Onofre wrote:
>> Hi Lukasz
>> 
>> It’s a good idea for system/custom properties. It’s similar/extend of the 
>> custom.system.properties we already have in system.properties right ?
>> 
>> For json/cfg files, it’s not necessary as we can already override with 
>> system properties or env variables (useful with docker) IMHO.
>> 
>> Regards
>> JB
>> 
>>> Le 11 juin 2021 à 10:34, Łukasz Dywicki  a écrit :
>>> 
>>> Hey all,
>>> 
>>> I recently been going over few Karaf assemblies I created in past years
>>> and I realized that in many cases I had to copy entire configuration
>>> shipped by Karaf distribution in order to include a new config in
>>> bootstrap process.
>>> Quite often my requirements were quite small, yet I had to create two
>>> files and take care of updates of distro shipped file in order to keep
>>> assembly well behaving.
>>> 
>>> Looking at base resources:
>>> https://github.com/apache/karaf/tree/karaf-4.3.2/assemblies/features/base/src/main/filtered-resources/resources/etc
>>> 
>>> If distro builder wants to override or extend any of properties defined
>>> in these he needs to copy a whole file. While it is not a problem for
>>> custom properties it is a burden for jre and system properties which
>>> vary between releases.
>>> 
>>> This week I attempted a bit simplified approach which can be summarized as:
>>> 1) Define default ${optionals} dedicated to overrides, ie. ${optionals}
>>> = custom.config.properties
>>> 2) Update each interesting system property to contain an placeholder
>>> with fallback. For example:
>>> org.osgi.framework.system.packages=\
>>> ... \
>>> org.apache.karaf.info;version="4.2.9",\
>>> ${jre-${java.specification.version}}, \
>>> ${custom.org.osgi.framework.system.packages:-}
>>> 
>>> With this approach user who needs to add an extra import or export for
>>> his environment needs to do just one thing. Create a
>>> "custom.config.properties" file with a single line:
>>> custom.org.osgi.framework.system.packages=jdk.internal.math
>>> 
>>> Packager work related to overrides of distro files is completely
>>> removed. More over this also leaves end user free of the need to fight
>>> ordering of dependencies in maven poms to shade Karaf defaults.
>>> 
>>> While above is quite handy there is a security consideration to be made.
>>> First of all, creation of an optional file might simplify process of
>>> affecting existing Karaf installations through easier injection of
>>> additional options. I believe that proper file and folder permissions
>>> should prevent that, however it must be noted that distro will have more
>>> flexible configuration injection with all pros and cons.
>>> 
>>> Best,
>>> Łukasz
>>> --
>>> Integrate software (Code-House) & hardware (ConnectorIO)
>>> http://code-house.org
>>> http://connectorio.com
>> 

Re: Simplification for user specific configuration handling in custom assemblies

[Jean-Baptiste Onofre]

Hi Lukasz

It’s a good idea for system/custom properties. It’s similar/extend of the 
custom.system.properties we already have in system.properties right ?

For json/cfg files, it’s not necessary as we can already override with system 
properties or env variables (useful with docker) IMHO.

Regards
JB

> Le 11 juin 2021 à 10:34, Łukasz Dywicki  a écrit :
> 
> Hey all,
> 
> I recently been going over few Karaf assemblies I created in past years
> and I realized that in many cases I had to copy entire configuration
> shipped by Karaf distribution in order to include a new config in
> bootstrap process.
> Quite often my requirements were quite small, yet I had to create two
> files and take care of updates of distro shipped file in order to keep
> assembly well behaving.
> 
> Looking at base resources:
> https://github.com/apache/karaf/tree/karaf-4.3.2/assemblies/features/base/src/main/filtered-resources/resources/etc
> 
> If distro builder wants to override or extend any of properties defined
> in these he needs to copy a whole file. While it is not a problem for
> custom properties it is a burden for jre and system properties which
> vary between releases.
> 
> This week I attempted a bit simplified approach which can be summarized as:
> 1) Define default ${optionals} dedicated to overrides, ie. ${optionals}
> = custom.config.properties
> 2) Update each interesting system property to contain an placeholder
> with fallback. For example:
> org.osgi.framework.system.packages=\
>  ... \
> org.apache.karaf.info;version="4.2.9",\
> ${jre-${java.specification.version}}, \
> ${custom.org.osgi.framework.system.packages:-}
> 
> With this approach user who needs to add an extra import or export for
> his environment needs to do just one thing. Create a
> "custom.config.properties" file with a single line:
> custom.org.osgi.framework.system.packages=jdk.internal.math
> 
> Packager work related to overrides of distro files is completely
> removed. More over this also leaves end user free of the need to fight
> ordering of dependencies in maven poms to shade Karaf defaults.
> 
> While above is quite handy there is a security consideration to be made.
> First of all, creation of an optional file might simplify process of
> affecting existing Karaf installations through easier injection of
> additional options. I believe that proper file and folder permissions
> should prevent that, however it must be noted that distro will have more
> flexible configuration injection with all pros and cons.
> 
> Best,
> Łukasz
> --
> Integrate software (Code-House) & hardware (ConnectorIO)
> http://code-house.org
> http://connectorio.com

[REPORT] Apache Karaf - June 2021

[Jean-Baptiste Onofre]

## Description:
The mission of the Apache Karaf project is to provide an application
ecosystem. Apache Karaf runtime is a modulith runtime allowing to run any kind
of applications. Karaf subprojects bring additional features for this runtime
and running applications.

## Issues:
There are no issues requiring board attention at this time.

## Membership Data:
Apache Karaf was founded 2010-06-16 (11 years ago)
There are currently 31 committers and 17 PMC members in this project.
The Committer-to-PMC ratio is roughly 8:5.

Community changes, past quarter:
- No new PMC members. Last addition was Francois Papon on 2018-11-29.
- No new committers. Last addition was Francois Papon on 2018-05-19.

## Project Activity:
We are working on Karaf runtime 4.2.12 and 4.3.3 releases, and also Karaf
Decanter 2.8.0 release.

In the mean time, karaf-4.3.x branch will be created for the runtime,
upgrading main branch to R8 spec (Karaf 4.4.0-SNAPSHOT).

Karaf 5 proposal is also moving forward

To summarize, here's the releases during the period:

Karaf runtime 4.2.11 was released on 2021-03-13.

## Community Health:
We see a constant activity in our communities (we can not increasing activity
on both dev and user mailing lists, showing a healthy community).

Re: June '21 board report

[Jean-Baptiste Onofre]

FYI, I submitted the report via whimsy.

Regards
JB

> Le 1 juin 2021 à 15:05, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> I prepared the board report for this month:
> 
> https://cwiki.apache.org/confluence/display/KARAF/Board+Reports 
> <https://cwiki.apache.org/confluence/display/KARAF/Board+Reports>
> 
> Can you please take a look and let me know if you want to add something ?
> 
> Thanks !
> 
> Regards
> JB

June '21 board report

[Jean-Baptiste Onofre]

Hi guys,

I prepared the board report for this month:

https://cwiki.apache.org/confluence/display/KARAF/Board+Reports 


Can you please take a look and let me know if you want to add something ?

Thanks !

Regards
JB

Re: Nice if OSGi and OSGi compendium versions were part of the karaf BoM

[Jean-Baptiste Onofre]

Who cares about JPMS ? ;) It’s deprecated right ? ;)

> Le 31 mai 2021 à 17:22, Robert Varga  a écrit :
> 
> On 31/05/2021 16:50, Jean-Baptiste Onofre wrote:
>> These dependencies are not necessary as they come with cmpn.
> 
> True, but you need the split out artifacts to make JPMS work reasonably:
> 
> https://github.com/opendaylight/yangtools/blob/master/xpath/yang-xpath-impl/src/main/java/module-info.java#L26
> https://github.com/opendaylight/yangtools/blob/master/xpath/yang-xpath-impl/pom.xml#L60-L63
> 
> I do not remember the details anymore, but this setup ended up being the
> most reasonable thing to do.
> 
> I also have no idea how R8 changes the interop picture here -- osgi.core
> has an Automatic-Module-Name manifest entry  (finally!), not sure how
> others will look like.
> 
> Regards,
> Robert
> 
> 
>> 
>> Regards
>> JB
>> 
>>> Le 31 mai 2021 à 15:08, Steinar Bang  a écrit :
>>> 
>>>>>>>> Jean-Baptiste Onofre :
>>> 
>>>> Hi Steinar,
>>>> I just checked and both osgi.core and osgi.cmpn are part of the Karaf BoM 
>>>> (as I thought ;) ):
>>> 
>>>> https://github.com/apache/karaf/blob/main/bom/pom.xml#L39 
>>>> <https://github.com/apache/karaf/blob/main/bom/pom.xml#L39>
>>> 
>>> Hm... that one should be correct.  But the artifactId changed here
>>> between OSGi 6 and 7 and I started using the BoM in karaf 4.2.11 and
>>> just filled up with versions for those dependencies that couldn't find
>>> their so I may have been confused here.
>>> 
>>> But this should work for me, so I'll correct this in my projects.  Thanks!
>>> 
>>>> https://github.com/apache/karaf/blob/main/bom/pom.xml#L525 
>>>> <https://github.com/apache/karaf/blob/main/bom/pom.xml#L525>
>>> 
>>> I'm thinking of stuff that is part of the compendium, e.g. (for OSGi 7)
>>> The log service:
>>>   
>>> org.osgi
>>> org.osgi.service.log
>>> 1.4.0
>>> provided
>>>   
>>> 
>>> the SCR annotations:
>>>   
>>> org.osgi
>>> org.osgi.service.component.annotations
>>> 1.4.0
>>> provided
>>>   
>>> 
>>> the OSGi 7 web whiteboard annotations:
>>>   
>>> org.osgi
>>> org.osgi.service.http.whiteboard
>>> 1.1.0
>>> provided
>>>   
>>> 
>>> (these are the ones I use, but there is probably a lot of others for
>>> stuff I don't know about. Also, I'm not sure of the OSGi 7 web
>>> whiteboard maven dependency?  I found that one by digging around on
>>> maven central and it seems to have the correct contents and a publishing
>>> date matching the rest of the OSGi 7 stuff...?)
>>> 
>> 
> 

Re: Nice if OSGi and OSGi compendium versions were part of the karaf BoM

[Jean-Baptiste Onofre]

I’m not sure about pax-jdbc, as it’s more a third party (I don’t want to 
introduce kind of infinite loop ;) ).

Let me think about that ;)

Regards
JB

> Le 31 mai 2021 à 16:28, Steinar Bang  a écrit :
> 
> But pax-jdbc isn't in https://github.com/apache/karaf/blob/main/bom/pom.xml
> 
> Should it be?
> 

Re: Nice if OSGi and OSGi compendium versions were part of the karaf BoM

[Jean-Baptiste Onofre]

Hi Steinar,

I just checked and both osgi.core and osgi.cmpn are part of the Karaf BoM (as I 
thought ;) ):

https://github.com/apache/karaf/blob/main/bom/pom.xml#L39 


https://github.com/apache/karaf/blob/main/bom/pom.xml#L525 


Maybe you don’t use the correct Maven coordinates in your project.

Regards
JB

> Le 30 mai 2021 à 17:55, Steinar Bang  a écrit :
> 
>> JB Onofré :
> 
>> Good point and I agree. 
>> Does it work for you if I add this to karaf 4.3.3 and 4.2.12 ?
> 
> That would be excellent! Thanks! :-)
> 
>> Thanks for the proposal. 
> 
> My pleasure! :-)
> 

Re: Releases schedule

[Jean-Baptiste Onofre]

Hi Eric,

About Pax Exam, Freeman did the fix already. Let’s move forward on the release 
to include it.

Regards
JB

> Le 27 mai 2021 à 22:27, Eric Lilja  a écrit :
> 
> Looking forward to the releases, JB!
> 
> For 4.2.12, I personally think it's important that the regression that made
> Pax Exam fail if Java version > 8 is fixed first, if it hasn't been
> already. I wouldn't mind to see 4.3.3 out relatively soon with that fix as
> well.
> 
> - Eric L
> 
> On Tue, May 25, 2021 at 8:21 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi Steven,
>> 
>> Yup, +1, it’s already planned ;)
>> 
>> You can expect it for Decanter 2.8.0.
>> 
>> Regards
>> JB
>> 
>>> Le 25 mai 2021 à 08:11, Steven Huypens  a
>> écrit :
>>> 
>>> Hi JB,
>>> 
>>> It would be nice to have
>> https://issues.apache.org/jira/browse/KARAF-7154
>>> included in the new decanter release. Let me know if I can help.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Tue, May 25, 2021 at 6:33 AM Jean-Baptiste Onofre 
>>> wrote:
>>> 
>>>> Hi guys,
>>>> 
>>>> Just a quick update about the release schedule:
>>>> 
>>>> - Karaf runtime 4.2.12 is in preparation. Target date is this week end
>> for
>>>> the vote.
>>>> - Karaf Decanter 2.8.0 is in preparation. Target date is this week end
>> for
>>>> the vote as well.
>>>> - Karaf Cave 4.2.2 should be in preparation soon but I’ve not yet
>> started.
>>>> - Karaf Cellar 4.3.0 refactoring started. Target date for a first RC is
>>>> next month.
>>>> 
>>>> I’m updating website (schedule table) accordingly.
>>>> 
>>>> If you have specific Jira or comments to include in these releases,
>> please
>>>> let me know.
>>>> 
>>>> Thanks,
>>>> Regards
>>>> JB
>> 
>> 

Re: Releases schedule

[Jean-Baptiste Onofre]

Hi Steven,

Yup, +1, it’s already planned ;)

You can expect it for Decanter 2.8.0.

Regards
JB

> Le 25 mai 2021 à 08:11, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> It would be nice to have https://issues.apache.org/jira/browse/KARAF-7154
> included in the new decanter release. Let me know if I can help.
> 
> Best regards,
> Steven
> 
> On Tue, May 25, 2021 at 6:33 AM Jean-Baptiste Onofre 
> wrote:
> 
>> Hi guys,
>> 
>> Just a quick update about the release schedule:
>> 
>> - Karaf runtime 4.2.12 is in preparation. Target date is this week end for
>> the vote.
>> - Karaf Decanter 2.8.0 is in preparation. Target date is this week end for
>> the vote as well.
>> - Karaf Cave 4.2.2 should be in preparation soon but I’ve not yet started.
>> - Karaf Cellar 4.3.0 refactoring started. Target date for a first RC is
>> next month.
>> 
>> I’m updating website (schedule table) accordingly.
>> 
>> If you have specific Jira or comments to include in these releases, please
>> let me know.
>> 
>> Thanks,
>> Regards
>> JB

Re: [PROPOSAL] Create karaf-4.3.x branch and update main to 4.4.0-SNAPSHOT

[Jean-Baptiste Onofre]

Hi,

No other comment about this proposal ? If no, I will proceed.

Thanks,
Regards
JB

> Le 20 mai 2021 à 13:49, Jean-Baptiste Onofre  a écrit :
> 
> Hi guys,
> 
> In order to prepare R8 support, I would like to create karaf-4.3.x branch and 
> update main to version 4.4.0-SNAPSHOT, and update to R8 and corresponding 
> frameworks version (Felix and equinox).
> 
> No objection ?
> 
> Regards
> JB

Re: pax exam tests started failing when I bumped karaf version to 4.3.2

[Jean-Baptiste Onofre]

Hi,

It’s has been discussed on the mailing list already (I don’t remember who 
reported this).

The change we did is that etc/users.properties has the karaf user commented now 
(for security reason).

However, etc/users.properties is still part of the karaf distribution. But, as 
it contains only comments now, I suspect pax-exam-karaf to not include it in 
the core distribution run. Karaf itests use it, so, it should be minor.

A simple workaround is to include your own users.properties in the pax-exam 
option.

I will check and create Jira for 4.3.3.

Regards
JB

> Le 23 mai 2021 à 00:27, Steinar Bang  a écrit :
> 
> When I bumped the karaf version (affects the karaf-maven-plugin, the
> karaf BoM and the pax exam tests in my project builds), then the pax
> exam tests fail with this message:
> 
> [ERROR] 
> initializationError(no.priv.bang.authservice.tests.AuthserviceIntegrationTest)
>   Time elapsed: 0.015 s  <<< ERROR!
> org.ops4j.pax.exam.TestContainerException: java.lang.RuntimeException: Config 
> resource /etc/users.properties not found
>   at 
> no.priv.bang.authservice.tests.AuthserviceIntegrationTest.config(AuthserviceIntegrationTest.java:33)
> 
> Is this expected? Do I need to make a change in my test setup?
> 
> Here's the test that failed when I bumped karaf from 4.3.0 to 4.3.2:
> https://github.com/steinarb/authservice/tree/master/authservice.tests
> 

Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2

[Jean-Baptiste Onofre]

Hi Ben,

I suspect FELIX-6326 to be the cause.

Let me try to reproduce and work on a fix on Felix. I will create a Jira there.

Regards
JB

> Le 22 mai 2021 à 10:51, Benjamin Graf  a écrit :
> 
> [FELIX-6326

Re: [PROPOSAL] Create karaf-4.3.x branch and update main to 4.4.0-SNAPSHOT

[Jean-Baptiste Onofre]

Hi,

I think the work you are doing on Pax Web already cover R8 (no big change 
there).

Pax Logging 2.1.x would be required for the new log version service, but it’s 
minor change (not big effort).

The purpose is to prepare the update step by step, it’s normal that we don’t 
have all ready yet ;)

Regards
JB

> Le 20 mai 2021 à 13:58, Grzegorz Grzybek  a écrit :
> 
> Hi
> 
> Just a side note: I know almost nothing about R8 (core+cmpn), still trying
> to have full R6 (cmpn) Whiteboard implementation in Pax Web ;) Fortunately
> I see no changes in chapters 102 (HttpService), 128 (Web Applications) and
> 140 (Whiteboard).
> 
> However I see that chapter 101 (Log Service) is moved (partially, the
> log.stream is now in chapter 158 of cmpn) to OSGi core and the version is
> bumped from 1.4 to 1.5 - looks like we'll need Pax Logging 2.1.x, but I
> hope I can make it quick as there are only minor changes.
> 
> regards
> Grzegorz Grzybek
> 
> czw., 20 maj 2021 o 13:51 Francois Papon 
> napisał(a):
> 
>> +1
>> 
>> François
>> fpa...@apache.org
>> 
>> Le 20/05/2021 à 13:49, Jean-Baptiste Onofre a écrit :
>>> Hi guys,
>>> 
>>> In order to prepare R8 support, I would like to create karaf-4.3.x
>> branch and update main to version 4.4.0-SNAPSHOT, and update to R8 and
>> corresponding frameworks version (Felix and equinox).
>>> 
>>> No objection ?
>>> 
>>> Regards
>>> JB
>> 

[PROPOSAL] Create karaf-4.3.x branch and update main to 4.4.0-SNAPSHOT

[Jean-Baptiste Onofre]

Hi guys,

In order to prepare R8 support, I would like to create karaf-4.3.x branch and 
update main to version 4.4.0-SNAPSHOT, and update to R8 and corresponding 
frameworks version (Felix and equinox).

No objection ?

Regards
JB

Re: Problem after install pax-trans-tm-narayana with Karaf 4.3.2

[Jean-Baptiste Onofre]

Hi Ben,

Are you using JDK 11 (for both compile and runtime) ?

Regards
JB

> Le 20 mai 2021 à 08:17, Benjamin Graf  a écrit :
> 
> Hi,
> 
> it seems there is a bug with embedded resources. I think it is caused by 
> Felix and not Karaf itself.
> 
> How to reproduce:
> 
> - Clean start of plain Karaf 4.3.2
> 
> - feature:install pax-transx-tm-narayana
> 
> Result:
> 
> 2021-05-20T08:16:02,787 | WARN  | paxtransx-config-1-thread-1 | 
> pax-transx-tm-narayana   | 60 - 
> org.ops4j.pax.transx.pax-transx-tm-narayana - 0.5.0 | Error starting service
> java.lang.reflect.InvocationTargetException: null
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:?]
> at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  ~[?:?]
> at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> at 
> org.jboss.narayana.osgi.jta.internal.Activator.doStart(Activator.java:49) 
> ~[?:?]
> at 
> org.ops4j.pax.transx.tm.impl.AbstractActivator.run(AbstractActivator.java:115)
>  ~[?:?]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>  [?:?]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  [?:?]
> at java.lang.Thread.run(Thread.java:829) [?:?]
> Caused by: java.lang.IllegalStateException: Stream handler unavailable due 
> to: null
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:311)
>  ~[?:?]
> at java.net.URL.openConnection(URL.java:1099) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) 
> ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) 
> ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) 
> ~[?:?]
> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) ~[?:?]
> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475) 
> ~[?:?]
> at jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444) 
> ~[?:?]
> at jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:313) 
> ~[?:?]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:455) ~[?:?]
> at java.net.URLClassLoader$1.run(URLClassLoader.java:452) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:451) ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:589) ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:522) ~[?:?]
> at 
> org.jboss.narayana.osgi.jta.internal.OsgiServer.doStart(OsgiServer.java:73) 
> ~[?:?]
> at 
> org.jboss.narayana.osgi.jta.internal.OsgiServer.start(OsgiServer.java:66) 
> ~[?:?]
> ... 11 more
> Caused by: java.lang.reflect.InvocationTargetException
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:?]
> at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  ~[?:?]
> at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.openConnection(URLHandlersStreamHandlerProxy.java:303)
>  ~[?:?]
> at java.net.URL.openConnection(URL.java:1099) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:815) 
> ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750) 
> ~[?:?]
> at 
> jdk.internal.loader.URLClassPath$JarLoader.(URLClassPath.java:725) 
> ~[?:?]
> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493) ~[?:?]
> at jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at 

Re: JAAS in Karaf4/5

[Jean-Baptiste Onofre]

Hi Bernd,

Thanks for your feedback and proposal.

Generally speaking I agree with the proposal.

Karaf5 service could be a nice location, but keep in mind that Karaf5 service 
are not OSGi service (the osgi application manager is itself a K5 service).

So, I think we can already prepare some stuff for Karaf 4.4/4.5.

Let me think about the roadmap/target.

Thanks again !
Regards
JB

> Le 19 mai 2021 à 11:31, Bernd  a écrit :
> 
> Hello,
> 
> I noticed that Karaf provides quite useful principals for Roles, Groups and
> Client. But if I want to consume or create those principals in my own code,
> I have to depend on the karaf-boot bundle.
> 
> I wonder:
> 
> a) would it make sense for Karaf5 to move the classes to a more focused API
> jar. That would be helpful if I want to build a Microservice Servlet which
> should also run in other containers or if I just dont want to depend on the
> -boot bunfle.
> 
> b) would it make sense to provide utilities (JAASContext.getClientIP() or
> something)
> 
> c) would it make sense to add this to the logger so that it can add this
> (subject/ip) to all log lines generated with active JAAS context.
> 
> d) if I have my own http listener, is there a filter I can use to establish
> the JAAS login and especially also attach the http-client IP principal?
> 
> e) we are using Felix RSA/fastbin, I wonder if somebody has experience with
> adding instance-level authentication to something like this (and to RMI)?
> 
> Gruss
> Bernd

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Same for me ;)

So, let me refactor and remove "my" feature.simple bundle to include in 
features.core.

I will create the PR soon.

Regards
JB

> Le 19 mai 2021 à 09:21, Grzegorz Grzybek  a écrit :
> 
> śr., 19 maj 2021 o 08:59 Jean-Baptiste Onofre  napisał(a):
> 
>> Yes, both are possible.
>> 
>> Maybe keeping all in org.apache.karaf.features.core with a configuration
>> to use a different deploy/approach is better than a complete new features
>> bundle.
>> It’s not a problem to me to refactor what I did.
>> 
>> Thoughts ?
>> 
> 
> Personally I'm 65% for keeping single features.core + configuration option
> and 35% for features.simple ;)
> 
> regards
> Grzegorz Grzybek
> 
> 
>> 
>> Regards
>> JB
>> 
>>> Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit
>> :
>>> 
>>> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre > j...@nanthrax.net>> napisał(a):
>>> 
>>>> Hi,
>>>> 
>>>> Actually, it’s a complete separated bundle.
>>>> 
>>>> So, in the Karaf standard distribution, you will have
>>>> org.apache.karaf.features.core in etc/startup.properties: that’s the
>>>> regular/current one with the resolver.
>>>> 
>>>> Alternatively, you will have another distribution (I have to think about
>>>> the name), where you will have org.apache.karaf.features.simple in
>>>> etc/startup.properties: it doesn’t use the resolver, just loading the
>>>> features model and executing what’s in there.
>>>> 
>>> 
>>> Another, different, "non-canonical" distribution is fine ;)
>>> 
>>> 
>>>> 
>>>> Another possible approach is a configuration in
>>>> etc/org.apache.karaf.features.cfg where we use a different/pluggable
>>>> deployer.
>>>> 
>>> 
>>> This can still be done in standard, "canonical" distro, but as
>>> commented-out configuration option.
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> 
>>> 
>>>> 
>>>> Thoughts ?
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a
>> écrit
>>>> :
>>>>> 
>>>>> Hello
>>>>> 
>>>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
>>>> napisał(a):
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Regarding recent comments from users and lot of refresh
>> issues/questions
>>>>>> we have in the past, I moved forward with a new simple features
>> service
>>>>>> that doesn’t use the resolver. It basically reads the features repo
>>>>>> definition and just install what’s define in there statically.
>>>>>> 
>>>>>> I will prepare a distribution using it by default.
>>>>>> 
>>>>> 
>>>>> Will it be configurable? I know about refresh problems - but the
>> resolver
>>>>> did a good job showing you what's wrong with the set of
>> features/bundles
>>>>> you're installing.
>>>>> Do you plan to switch to resolverless features service in micro release
>>>> of
>>>>> Karaf? Or will it be Karaf 4.4 / 5?
>>>>> 
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>> 
>>>>> 
>>>>>> 
>>>>>> I will share some details soon.
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a
>>>>>> écrit :
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> It doesn’t really break, it just don’t use it.
>>>>>>> 
>>>>>>> It’s up to you to install all feature/bundle requirements.
>>>>>>> 
>>>>>>> Regards
>>>>>>> JB
>>>>>>> 
>>>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb  a
>>>> écrit
>>>>>> :
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>>> - ignore requirement/capability (no resolver)
>>>>>>>> 
>>>>>>>&

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Yes, both are possible.

Maybe keeping all in org.apache.karaf.features.core with a configuration to use 
a different deploy/approach is better than a complete new features bundle.
It’s not a problem to me to refactor what I did.

Thoughts ?

Regards
JB

> Le 19 mai 2021 à 08:01, Grzegorz Grzybek  a écrit :
> 
> śr., 19 maj 2021 o 07:53 Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> napisał(a):
> 
>> Hi,
>> 
>> Actually, it’s a complete separated bundle.
>> 
>> So, in the Karaf standard distribution, you will have
>> org.apache.karaf.features.core in etc/startup.properties: that’s the
>> regular/current one with the resolver.
>> 
>> Alternatively, you will have another distribution (I have to think about
>> the name), where you will have org.apache.karaf.features.simple in
>> etc/startup.properties: it doesn’t use the resolver, just loading the
>> features model and executing what’s in there.
>> 
> 
> Another, different, "non-canonical" distribution is fine ;)
> 
> 
>> 
>> Another possible approach is a configuration in
>> etc/org.apache.karaf.features.cfg where we use a different/pluggable
>> deployer.
>> 
> 
> This can still be done in standard, "canonical" distro, but as
> commented-out configuration option.
> 
> regards
> Grzegorz Grzybek
> 
> 
> 
>> 
>> Thoughts ?
>> 
>> Regards
>> JB
>> 
>>> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a écrit
>> :
>>> 
>>> Hello
>>> 
>>> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre 
>> napisał(a):
>>> 
>>>> Hi,
>>>> 
>>>> Regarding recent comments from users and lot of refresh issues/questions
>>>> we have in the past, I moved forward with a new simple features service
>>>> that doesn’t use the resolver. It basically reads the features repo
>>>> definition and just install what’s define in there statically.
>>>> 
>>>> I will prepare a distribution using it by default.
>>>> 
>>> 
>>> Will it be configurable? I know about refresh problems - but the resolver
>>> did a good job showing you what's wrong with the set of features/bundles
>>> you're installing.
>>> Do you plan to switch to resolverless features service in micro release
>> of
>>> Karaf? Or will it be Karaf 4.4 / 5?
>>> 
>>> regards
>>> Grzegorz Grzybek
>>> 
>>> 
>>>> 
>>>> I will share some details soon.
>>>> 
>>>> Regards
>>>> JB
>>>> 
>>>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a
>>>> écrit :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> It doesn’t really break, it just don’t use it.
>>>>> 
>>>>> It’s up to you to install all feature/bundle requirements.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb  a
>> écrit
>>>> :
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>> - ignore requirement/capability (no resolver)
>>>>>> 
>>>>>> did I get it right that this breaks the dependency=true feature that
>>>>>> installs bundles / features only if a requirement is not fullfilled
>> yet?
>>>>>> 
>>>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>>>> patriquelega...@gmail.com>:
>>>>>> 
>>>>>>> Same here,
>>>>>>> 
>>>>>>> This is behaviour that has been expected for some time now, reversing
>>>> it
>>>>>>> could cause damage to systems that upgrade to the latest Karaf. I
>> would
>>>>>>> make it something that users opt into vs having to opt-out of.
>>>>>>> 
>>>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las >>> .invalid>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> It looks like some kind of backward incompatible change introduced
>>>> within
>>>>>>>> patch version change. I personally would like to keep auto refresh
>>>> "on"
>>>>>>> by
>>>>>>>> default as this is expected/desired behavior for me.
>

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Hi,

Actually, it’s a complete separated bundle.

So, in the Karaf standard distribution, you will have 
org.apache.karaf.features.core in etc/startup.properties: that’s the 
regular/current one with the resolver.

Alternatively, you will have another distribution (I have to think about the 
name), where you will have org.apache.karaf.features.simple in 
etc/startup.properties: it doesn’t use the resolver, just loading the features 
model and executing what’s in there.

Another possible approach is a configuration in 
etc/org.apache.karaf.features.cfg where we use a different/pluggable deployer.

Thoughts ?

Regards
JB

> Le 19 mai 2021 à 07:41, Grzegorz Grzybek  a écrit :
> 
> Hello
> 
> śr., 19 maj 2021 o 07:35 Jean-Baptiste Onofre  napisał(a):
> 
>> Hi,
>> 
>> Regarding recent comments from users and lot of refresh issues/questions
>> we have in the past, I moved forward with a new simple features service
>> that doesn’t use the resolver. It basically reads the features repo
>> definition and just install what’s define in there statically.
>> 
>> I will prepare a distribution using it by default.
>> 
> 
> Will it be configurable? I know about refresh problems - but the resolver
> did a good job showing you what's wrong with the set of features/bundles
> you're installing.
> Do you plan to switch to resolverless features service in micro release of
> Karaf? Or will it be Karaf 4.4 / 5?
> 
> regards
> Grzegorz Grzybek
> 
> 
>> 
>> I will share some details soon.
>> 
>> Regards
>> JB
>> 
>>> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a
>> écrit :
>>> 
>>> Hi,
>>> 
>>> It doesn’t really break, it just don’t use it.
>>> 
>>> It’s up to you to install all feature/bundle requirements.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 11 janv. 2021 à 21:09, Markus Rathgeb  a écrit
>> :
>>>> 
>>>> Hi,
>>>> 
>>>>> - ignore requirement/capability (no resolver)
>>>> 
>>>> did I get it right that this breaks the dependency=true feature that
>>>> installs bundles / features only if a requirement is not fullfilled yet?
>>>> 
>>>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>>>> patriquelega...@gmail.com>:
>>>> 
>>>>> Same here,
>>>>> 
>>>>> This is behaviour that has been expected for some time now, reversing
>> it
>>>>> could cause damage to systems that upgrade to the latest Karaf. I would
>>>>> make it something that users opt into vs having to opt-out of.
>>>>> 
>>>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las > .invalid>
>>>>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> It looks like some kind of backward incompatible change introduced
>> within
>>>>>> patch version change. I personally would like to keep auto refresh
>> "on"
>>>>> by
>>>>>> default as this is expected/desired behavior for me.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre 
>>>>> napisał(a):
>>>>>> 
>>>>>>> Hi everyone,
>>>>>>> 
>>>>>>> We got several user feedback, complaining about unexpected and
>> cascaded
>>>>>>> (unrelated) refresh while installing features.
>>>>>>> 
>>>>>>> As reminder, a refresh can happen when:
>>>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>>>> package
>>>>>>> version. In that case, the features service will refresh A to use the
>>>>>>> newest package version.
>>>>>>> - bundle A has an optional import to package foo and a bundle
>> provides
>>>>>>> this package. In that case, the features service will refresh A to
>>>>>> actually
>>>>>>> use the import as it’s a "resolved" optional.
>>>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>>>> requirement) and B is refreshed. In that case, the features service
>>>>> will
>>>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>>>> instance).
>>>>>>> This can cause "cas

Re: [PROPOSAL] Disable autoRefresh on features service by default and simple optional features service

[Jean-Baptiste Onofre]

Hi,

Regarding recent comments from users and lot of refresh issues/questions we 
have in the past, I moved forward with a new simple features service that 
doesn’t use the resolver. It basically reads the features repo definition and 
just install what’s define in there statically.

I will prepare a distribution using it by default.

I will share some details soon.

Regards
JB

> Le 12 janv. 2021 à 06:07, Jean-Baptiste Onofre  a écrit :
> 
> Hi,
> 
> It doesn’t really break, it just don’t use it.
> 
> It’s up to you to install all feature/bundle requirements.
> 
> Regards
> JB
> 
>> Le 11 janv. 2021 à 21:09, Markus Rathgeb  a écrit :
>> 
>> Hi,
>> 
>>> - ignore requirement/capability (no resolver)
>> 
>> did I get it right that this breaks the dependency=true feature that
>> installs bundles / features only if a requirement is not fullfilled yet?
>> 
>> Am Fr., 8. Jan. 2021 um 15:01 Uhr schrieb Patrique Legault <
>> patriquelega...@gmail.com>:
>> 
>>> Same here,
>>> 
>>> This is behaviour that has been expected for some time now, reversing it
>>> could cause damage to systems that upgrade to the latest Karaf. I would
>>> make it something that users opt into vs having to opt-out of.
>>> 
>>> On Fri, 8 Jan 2021 at 08:42, Daniel Las 
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> It looks like some kind of backward incompatible change introduced within
>>>> patch version change. I personally would like to keep auto refresh "on"
>>> by
>>>> default as this is expected/desired behavior for me.
>>>> 
>>>> Regards
>>>> 
>>>> pt., 8 sty 2021 o 07:31 Jean-Baptiste Onofre 
>>> napisał(a):
>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> We got several user feedback, complaining about unexpected and cascaded
>>>>> (unrelated) refresh while installing features.
>>>>> 
>>>>> As reminder, a refresh can happen when:
>>>>> - bundle A imports package foo:1 and a bundle provides newer foo
>>> package
>>>>> version. In that case, the features service will refresh A to use the
>>>>> newest package version.
>>>>> - bundle A has an optional import to package foo and a bundle provides
>>>>> this package. In that case, the features service will refresh A to
>>>> actually
>>>>> use the import as it’s a "resolved" optional.
>>>>> - bundle A is wired to bundle B (from a package perspective or
>>>>> requirement) and B is refreshed. In that case, the features service
>>> will
>>>>> refresh A as B is itself refreshed (for the previous reasons for
>>>> instance).
>>>>> This can cause "cascading" refresh.
>>>>> 
>>>>> A refresh means that a bundle can be restarted (if the bundle contains
>>> an
>>>>> activator or similar (DS component, blueprint bundle)).
>>>>> 
>>>>> In this PR https://github.com/apache/karaf/pull/1287, I propose to
>>>>> introduce a new property autoRefresh in
>>> etc/org.apache.karaf.features.cfg
>>>>> to disable the auto refresh by the features service (and let the user
>>>>> decides when he wants to trigger refresh with bundle:refresh command
>>> for
>>>>> instance).
>>>>> I propose to keep autoRefresh=true on 4.2.x and turn autoRefresh=false
>>> on
>>>>> 4.3.x.
>>>>> 
>>>>> Thoughts ?
>>>>> 
>>>>> On the other hand (and to prepare the "path" to Karaf5), I have
>>> created a
>>>>> new "simple features service" (PR will be open soon) that:
>>>>> 
>>>>> - just take the features definition in order (ignoring start level)
>>>>> - ignore requirement/capability (no resolver)
>>>>> - no auto refresh
>>>>> 
>>>>> Basically, if you have the following feature definition:
>>>>> 
>>>>> 
>>>>> bar
>>>>> A
>>>>> B
>>>>> 
>>>>> 
>>>>> The features service will fully install/start bar feature first, then
>>>>> bundle A, then bundle B.
>>>>> To use this "simple features services, you just have to replace
>>>>> org.apache.karaf.features.core by org.apache.karaf.features.simple
>>> bundle
>>>>> in etc/startup.properties (or custom distribution).
>>>>> 
>>>>> It’s similar to the Karaf 5 extension behavior (I will share complete
>>>>> details about Karaf 5 and its concepts (module, extension, …) very
>>> soon,
>>>>> but that’s another thread ;)).
>>>>> 
>>>>> The big advantages of this approach is:
>>>>> - predictable/deterministic provisioning (if it works fine, it works
>>>> again)
>>>>> - faster deployment (I estimated the gain to about 70%)
>>>>> 
>>>>> Thoughts ?
>>>>> 
>>>>> If you agree, I will move forward on both tasks.
>>>>> 
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Daniel Łaś
>>>> CTO at Empirica S.A.
>>>> +48 695 616181
>>>> 
>>> 
>>> 
>>> --
>>> *Patrique Legault*
>>> 
> 

[ANN] Apache Karaf runtime 4.3.2 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.2 release.

This release is an important release on the Karaf 4.3.x series, bringing 
updates, fixes and new features, especially:

* OSGi R7 configuration support and fix on configuration json format
* security improvement (default karaf user is now disabled by default, JMX 
server host improvement)
* shell tables have now a clean rendering on Windows and Unix when using 
--no-format option
* maven:* commands don't throw NullPointerException if ~/.m2/settings.xml 
doesn't exist
* JDK16 support thanks (with required eecap)
* improvement on the scheduler to support scheduler properties containing array
* use of ~/.karaf/karaf.history instead of ~/.karaf/karaf41.history
* fix on the logging default pattern layout (to avoid encoded character 
rendering)
* thanks to xbean 4.19, we fixed issue about WAR file support (in Pax Web) 
built with JDK 11+

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
 


Download: http://karaf.apache.org/download.html 


Enjoy!
The Apache Karaf team

[RESULT][VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): François Papon, Freeman Fang, Grzegorz Grzybek, Jamie Goodyear, 
JB Onofré
+1 (non binding): Oliver Lietz, Lukas Roedl, Serge Huber, Matt Pavlovich, 
Steinar Bang

I’m promoting the artifacts on Maven Central, dist, and image on docker hub.

I will then announce the release (with a small blog post).

Thanks all for your vote !

Regards
JB

> Le 9 mai 2021 à 07:18, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.2 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to xbean 4.19 fixing JDK9 style war file
> - improvements on scheduler to support array configuration
> - fix on the JSON configuration to support array
> - improvement on JSON configuration to support R7 factory style
> - fix on the default pax-logging layout pattern
> - fix on the JMX RMI to use the configured host
> - fix race condition on SSHd startup
> - improvement on ShellTable
> - bunch of dependency updates for fixes and CVE
> - and much more !
> 
> *NOTE: for security reason, the default karaf user is commented in 
> etc/users.properties file. Please uncomment and change password if you want 
> to use it (for remote access like ssh, jmx, …).*
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968>
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1156/>
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.2/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.2/>
> 
> Git tag:
> karaf-4.3.2
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: [VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 9 mai 2021 à 07:18, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.2 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - upgrade to xbean 4.19 fixing JDK9 style war file
> - improvements on scheduler to support array configuration
> - fix on the JSON configuration to support array
> - improvement on JSON configuration to support R7 factory style
> - fix on the default pax-logging layout pattern
> - fix on the JMX RMI to use the configured host
> - fix race condition on SSHd startup
> - improvement on ShellTable
> - bunch of dependency updates for fixes and CVE
> - and much more !
> 
> *NOTE: for security reason, the default karaf user is commented in 
> etc/users.properties file. Please uncomment and change password if you want 
> to use it (for remote access like ssh, jmx, …).*
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968>
> 
> Staging Maven Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1156/>
> 
> Staging Dist Repository:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.2/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.2/>
> 
> Git tag:
> karaf-4.3.2
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: Non-Deterministic startup order

[Jean-Baptiste Onofre]

Hi Paul,

You are mixing two things: the generation of the startup.properties at build 
time, and the actual order at runtime.

My point was about the start level at runtime, not build/startup.properties 
generation.

We use start-level in Karaf to define the order, and it’s cleanly sorted. What 
we do is to pass the start level in the features definition:

https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml
 


Then, we define the feature as startupFeature and the startup.properties is 
generated using the start-level defined in the feature definition.

Do you use the same approach or directly startupBundles ?

Regards
JB

> Le 11 mai 2021 à 16:38, Paul Stanley  a écrit :
> 
> Hello.
> 
> I have tested the proposed 4.3.2 release and the startup.properties file is 
> still being generated in a non- deterministic order.  They are grouped in 
> their start level, but within that they are listed in a random order.
> 
> The issue we have been seeing relates to the jetty distribution which listed 
> in the startup.properties file as part of our custom installation, given the 
> unpredictable order has led to the web server restarting a number of times 
> during the boot cycle, this in turn can prevent karaf from starting.
> 
> It appears that the problem is in the builder class in the profile project.  
> This does attempt to sort the bundles, but the startupEffective.getBundles() 
> list is empty and as such the sort operation has no effect.  Would it be 
> possible to updated the resolve() method and the MapUtils class to use 
> LinkedHashMaps when using the Collectors.toMap() stream operations.
> 
> Thanks
> Paul
> 
> 
> From: Romain Manni-Bucau 
> Sent: 05 May 2021 16:10
> To: dev 
> Subject: Re: Non-Deterministic startup order
> 
> Hi Paul,
> 
> Did you use the last 4.3 release? Startup bundles shouldn't be randomized
> anymore. For features it is a bit more complicated since it is a tree so
> guess order can't really be assumed without side effects (whereas it can
> for a flat list of bundles).
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mer. 5 mai 2021 à 17:07, Paul Stanley  a écrit :
> 
>> Hi.
>> 
>> When building and running karaf the boot order for the initial set of
>> startup bundles is being randomised, within their start levels.  As result
>> we are seeing non-deterministic behaviour between development and release
>> builds of custom karaf platforms.
>> 
>> Please can you change the karaf.features.core and the karaf.profile.core
>> to use LinkedHashMaps and Sets, to preserve the order of bundles as
>> discovered in the feature.xml files.
>> 
>> Thanks
>> Paul
>> 
>> 

Re: [VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

Hi,

Can you try to cleanup your ~/.karaf folder (just in case) ?

Regards
JB

> Le 11 mai 2021 à 15:20, Steinar Bang  a écrit :
> 
>>>>>> Jean-Baptiste Onofre :
> 
>> It seems to work for me (about the commands history).
> 
> You started karaf from the command line, did some commands, exited
> karaf, and started karaf from the command line again, and the history
> was preserved?
> 
> Could it be something about the exact tar.gz file I downloaded?
> 
> Should I download again and try again?
> 
> Could it be something to do with the place where I unpacked the file,
> ie. /tmp?
> 
>> Do you see the commands in shell:history ?
> 
> It was empty initially after startup, except for the shell:history
> command itself, then after doing bundle:list and a new shell:history, it
> has three commands (the two shell:history commands and bundle:list).
> 
> Then I exited the shell with Ctrl-d and restarted karaf.  When I ran
> bundle:list again it was the only command in the history.
> 
> Here's the input and output from the test session:
> https://gist.github.com/steinarb/2041929617a96b903cd17f3cfda3a1ba
> 

Re: [VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

Hi,

It seems to work for me (about the commands history).

Do you see the commands in shell:history ?

Regards
JB

> Le 10 mai 2021 à 18:14, Steinar Bang  a écrit :
> 
>>>>>> Jean-Baptiste Onofre :
> 
>> Can you describe your test case ?
> 
> 1. Download the tar.gz of the binary build
> 2. Unpack into /tmp/apache-karaf-4.3.2/
> 3. Do "cd /tmp/apache-karaf-4.3.2/"
> 4. Start karaf with "bin/karaf debug"
> 5. From the karaf console add my own maven repo:
> config:edit org.ops4j.pax.url.mvn
> config:property-append org.ops4j.pax.url.mvn.repositories ", 
> https://maven.bang.priv.no/repository/@id=ukelonn@snapshots;
> config:property-set org.ops4j.pax.url.mvn.globalUpdatePolicy always
> config:update
> 6. Also from the karaf console, add the 4.3.2 staging maven repo (so
>that karaf can provison stuff using maven):
> config:edit org.ops4j.pax.url.mvn
> config:property-append org.ops4j.pax.url.mvn.repositories ", 
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/@id=karaf@staging;
> config:update
> 7. Load myapps
> feature:repo-add mvn:no.priv.bang.myapps/myapps/LATEST/xml/features
> feature:install myapps
> 8. Note: at this point command history work: I can do ctrl-p and see
>the previous commands
> 9. Stop karaf, edit jdbc urls and credentials in some of the
>org.ops4j.datasource-*.cfg files
> 10. Start karaf again and do "Ctrl-p" (because the arrow keys on my
>laptop don't work so well) and there is no command history
> 
> So the failure start at point 10, ie. from the console after stopping
> and starting karaf.
> 
> And this is something I do a lot with tarball karaf releases, and I've
> never seen the command history go away before.
> 
> Note: if you would like the applications to actually run, you would need
> a PostgreSQL server running on the same host as karaf is running, with
> blank databases
> - authservice
> - ukelonn
> - handlereg
> - sonar-collector
> - oldalbum
> all owned by PosgreSQL user "karaf" with password "karaf" (or stop and
> edit the org.ops4j.datasource-*.cfg files to change databases names,
> location or credentiials, like in 9. above)
> 
> (but I don't think working apps is necessary for testing the command
> history issue)
> 

Re: [VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

Hi Steinar,

Sorry, my bad, I didn’t read your message correctly ;)

So, correct me if I’m wrong, but it seems your application runs fine with 
4.3.2, which is good ;)

Now, about the command history, I just did a quick test:

- starting karaf and doing some commands (for instance feature:list and 
feature:info ssh)
- restart karaf to have a new shell session, and I have the commands in the 
history (I can recall with up arrow key, or display with shell:history)
- I also tried with ssh and it works fine

Can you describe your test case ?

Thanks,
Regards
JB

> Le 9 mai 2021 à 15:41, Steinar Bang  a écrit :
> 
> Once I added the staging maven repository to the property
> org.ops4j.pax.url.mvn.repositories in the config, i.e.
> 
> config:edit org.ops4j.pax.url.mvn
> config:property-append org.ops4j.pax.url.mvn.repositories ", 
> https://repository.apache.org/content/repositories/orgapachekaraf-1156/@id=karaf@staging;
> config:update
> 
> then my applications (that currently are running on 4.3.0, but failed on
> 4.3.1) all seemed to run perfectly.
> 
> However, console command history wasn't persisted across karaf
> sessions.
> 
> Not sure if this is a bug or an intended feature?  If it is a feature,
> it is possible to config the persisted history back?
> 

[VOTE] Apache Karaf runtime 4.3.2 release

[Jean-Baptiste Onofre]

Hi everyone,

I submit Apache Karaf runtime 4.3.2 to your vote.

This release includes bunch of dependency upgrades, fixes, and improvements, 
especially:

- upgrade to xbean 4.19 fixing JDK9 style war file
- improvements on scheduler to support array configuration
- fix on the JSON configuration to support array
- improvement on JSON configuration to support R7 factory style
- fix on the default pax-logging layout pattern
- fix on the JMX RMI to use the configured host
- fix race condition on SSHd startup
- improvement on ShellTable
- bunch of dependency updates for fixes and CVE
- and much more !

*NOTE: for security reason, the default karaf user is commented in 
etc/users.properties file. Please uncomment and change password if you want to 
use it (for remote access like ssh, jmx, …).*

Please take a look on Release Notes for details !

Release Notes: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12349968
 


Staging Maven Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1156/ 


Staging Dist Repository:
https://dist.apache.org/repos/dist/dev/karaf/4.3.2/ 


Git tag:
karaf-4.3.2

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Regards
JB

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Hi guys,

Just to let you know that I’m fixing the two last issues for Karaf 4.3.2. The 
vote will be sent soon.

Thanks for your patience.

Regards
JB

> Le 4 mai 2021 à 07:21, Jean-Baptiste Onofre  a écrit :
> 
> Hi Serge,
> 
> It will be on vote today (just doing the triage now).
> 
> Regards
> JB
> 
>> Le 4 mai 2021 à 07:13, Serge Huber  a écrit :
>> 
>> I get that.
>> 
>> Ok so where is this release then ? :)
>> 
>> Just kidding !
>> 
>> Cheers,
>> Serge
>> 
>> Le ven. 30 avr. 2021 à 17:35, Jean-Baptiste Onofre  a
>> écrit :
>> 
>>> Thanks guys for your kind words.
>>> 
>>> I *need* to work on Karaf and Apache projects ;) So, I’m almost back in
>>> the business and targeting weekend ;)
>>> 
>>> Thanks again !
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 30 avr. 2021 à 17:12, Steinar Bang  a écrit :
>>>> 
>>>>>>>>> Serge Huber :
>>>> 
>>>>> Hi JB,
>>>>> Please pace yourself man, we can wait a little !
>>>> 
>>>> Agreed!
>>>> 
>>> 
>>> 
> 

Re: Non-Deterministic startup order

[Jean-Baptiste Onofre]

Hi Paul,

It should be deterministic since Karaf 4.3.1.

And just to let you know that I created 
https://issues.apache.org/jira/browse/KARAF-7130 
 to be able to have a 
pluggable startup order strategy (for instance based on symbolic name).

Regards
JB

> Le 5 mai 2021 à 17:07, Paul Stanley  a écrit :
> 
> Hi.
> 
> When building and running karaf the boot order for the initial set of startup 
> bundles is being randomised, within their start levels.  As result we are 
> seeing non-deterministic behaviour between development and release builds of 
> custom karaf platforms.
> 
> Please can you change the karaf.features.core and the karaf.profile.core to 
> use LinkedHashMaps and Sets, to preserve the order of bundles as discovered 
> in the feature.xml files.
> 
> Thanks
> Paul
> 

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Hi Serge,

It will be on vote today (just doing the triage now).

Regards
JB

> Le 4 mai 2021 à 07:13, Serge Huber  a écrit :
> 
> I get that.
> 
> Ok so where is this release then ? :)
> 
> Just kidding !
> 
> Cheers,
>  Serge
> 
> Le ven. 30 avr. 2021 à 17:35, Jean-Baptiste Onofre  a
> écrit :
> 
>> Thanks guys for your kind words.
>> 
>> I *need* to work on Karaf and Apache projects ;) So, I’m almost back in
>> the business and targeting weekend ;)
>> 
>> Thanks again !
>> 
>> Regards
>> JB
>> 
>>> Le 30 avr. 2021 à 17:12, Steinar Bang  a écrit :
>>> 
>>>>>>>> Serge Huber :
>>> 
>>>> Hi JB,
>>>> Please pace yourself man, we can wait a little !
>>> 
>>> Agreed!
>>> 
>> 
>> 

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Thanks guys for your kind words.

I *need* to work on Karaf and Apache projects ;) So, I’m almost back in the 
business and targeting weekend ;)

Thanks again !

Regards
JB

> Le 30 avr. 2021 à 17:12, Steinar Bang  a écrit :
> 
>> Serge Huber :
> 
>> Hi JB,
>> Please pace yourself man, we can wait a little !
> 
> Agreed!
> 

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Hi guys,

Even if the week is very rough for me, I will move forward with 4.3.2. I hope 
to submit the release to vote during the week end.

Regards
JB

> Le 11 avr. 2021 à 07:48, Jean-Baptiste Onofre  a écrit :
> 
> Hi,
> 
> I will move forward quickly on Karaf 4.3.2 due to the following issue 
> detected:
> 
> - Upgrade xbean to 4.19 for better support on war artifacts
> - Upgrade Pax Web for new Jetty version and xbean
> - Fix/improvement on the JSON configuration
> - Upgrade pax logging and other dependency projects to use 
> maven-bundle-plugin 5.1.2, fixing the headers
> 
> I hope to submit 4.3.2 to vote mid week.
> 
> I will keep you posted.
> 
> Regards
> JB

Re: setenv missing in karaf-service

[Jean-Baptiste Onofre]

Hi Andre,

The reason is because the format is not the same: service wrapper uses tanuki 
wrapper (old version due to license contraint).

The Karaf-service is supposed to only launch wrapper, and wrapper using the 
Karaf-wrapper.conf where you define the config.
As the Karaf-service is executed at system level, it should be pretty simple 
and not load any env variable (it should be done in the wrapper).

So, to simplify:
- setenv is for scripting like karaf, client, etc, but not wrapper
- karaf-wrapper.conf is for wrapper

Regards
JB

> Le 27 avr. 2021 à 09:41, Andre Schlegel-Tylla 
>  a écrit :
> 
> Hello,
> 
> is there a reason why the generated karaf-service file (service-wrapper
> feature) don't load the setenv file?
> 
> We have a prepared setenv file for our needs. But when we want to use the
> wrapper we have to manually fix the karaf-service file.
> 
> Regards
> Andre

ApacheCon CFP will be closed soon

[Jean-Baptiste Onofre]

Hi guys,

The ApacheCon CFP will be closed is a week or so. Please, submit your talk 
asap. The reviewing process will start soon.

Thanks,
Regards
JB

JB off next Tuesday and Wednesday

[Jean-Baptiste Onofre]

Hi guys,

Due to personal issue, I will be off next Tuesday and Wednesday. 

I will move forward on 4.3.2 release tomorrow.

Regards
JB

Re: Error running test org.apache.karaf.itests.BundleTest#listCommand

[Jean-Baptiste Onofre]

Thanks for the update. I will check.

Regards
JB

> Le 23 avr. 2021 à 22:02, Васил Зорев  a écrit :
> 
> Hi, I think i figured it out.
> 
> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer#updateLogProperties
> 
> File customPropertiesFile = new File(karafHome, framework.getKarafEtc() +
> "/org.ops4j.pax.logging.cfg");
> Properties karafPropertyFile = new Properties();
> karafPropertyFile.load(new FileInputStream(customPropertiesFile));
> loggingBackend.updatePaxLoggingConfiguration(karafPropertyFile,
> realLogLevel);
> karafPropertyFile.store(new FileOutputStream(customPropertiesFile),
> "updated by pax-exam");
> 
> 
> Here the file is updated, but the streams are never closed it seems.
> 
> Then later
> in 
> org.ops4j.pax.exam.karaf.container.internal.KarafTestContainer#updateUserSetProperties
> 
> else if (optionToApply instanceof
> KarafDistributionConfigurationFileReplacementOption) {
> 
>karafConfigurationFile
> 
> .replace(((KarafDistributionConfigurationFileReplacementOption)
> optionToApply)
>.getSource());
>store = false;
>break;
>}
> 
> The class tries to replace the config file, which is still open. Ubuntu
> (VM) allows it, but Windows fails (at least in my tests).
> 
> I think pax-exam version is 4.13.4.
> 
> Regards,
> Vassil
> 
> 
> На пн, 19.04.2021 г. в 21:36 ч. Васил Зорев 
> написа:
> 
>> Thanks. Btw yes, i am on main branch (checked it out this weekend)
>> 
>> На пн, 19.04.2021 г. в 21:33 ч. JB Onofré  написа:
>> 
>>> Ok, let me try on Windows VM.
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 19 avr. 2021 à 20:27, Васил Зорев  a
>>> écrit :
>>>> 
>>>> The test passed in ubuntu. In windows I did the two steps you
>>> suggested,
>>>> but still got the same error.
>>>> 
>>>> Regards,
>>>> Vassil
>>>> 
>>>> На пн, 19.04.2021 г. в 8:38 ч. Jean-Baptiste Onofre 
>>>> написа:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Yes mvn clean install should work. And it seems you try with karaf main
>>>>> branch ?
>>>>> 
>>>>> Can you try (even if it should not be required):
>>>>> 
>>>>> 1. First: mvn clean install -DskipTests on root module
>>>>> 2. Then: mvn clean install in the itest/test module
>>>>> 
>>>>> In the meantime, I will try a full build on a Windows VM.
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>>> Le 18 avr. 2021 à 20:37, Васил Зорев  a
>>> écrit
>>>>> :
>>>>>> 
>>>>>> no, same issue. (i guess you meant mvn clean install from the command
>>>>> line,
>>>>>> that's what i tried)
>>>>>> 
>>>>>> Btw one (potentially dumb) question, do i have to build/run anything
>>> else
>>>>>> before running integration tests? So far I just built the root project
>>>>> once
>>>>>> without any tests.
>>>>>> 
>>>>>> Regards,
>>>>>> Have a nice evening
>>>>>> 
>>>>>> На нд, 18.04.2021 г. в 21:01 ч. JB Onofré  написа:
>>>>>> 
>>>>>>> Does it work with maven directly ?
>>>>>>> 
>>>>>>>> Le 18 avr. 2021 à 19:55, Васил Зорев  a
>>>>> écrit
>>>>>>> :
>>>>>>>> 
>>>>>>>> JB,
>>>>>>>> 
>>>>>>>> not sure what kind of test case do you mean? I tried executing
>>>>>>>> org.apache.karaf.itests.BundleTest#listCommand as a single unit
>>> test,
>>>>>>> also
>>>>>>>> as part of the maven build.
>>>>>>>> I'll try to debug a bit more carefully, hopefully something comes
>>> up..
>>>>>>>> 
>>>>>>>> На нд, 18.04.2021 г. в 20:52 ч. Васил Зорев <
>>> vassil.zore...@gmail.com>
>>>>>>>> написа:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I tried initially in IntelliJ IDEA community 2020.3.2.
>>>>>>>>

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Hi,

Regarding some issues reported by users, I will include them in 4.3.2.

Today, I will release Pax projects.

I should be able to submit 4.3.2 to vote Wednesday this week.

Regards
JB

> Le 14 avr. 2021 à 09:51, Jean-Baptiste Onofre  a écrit :
> 
> Just a quick update about this.
> 
> I’m releasing the dependency projects (xbean vote is on the way, pax* 
> preparation is moving forward, …).
> 
> I should be able to submit Karaf 4.3.2 and 4.2.12 to vote during the week end.
> 
> Regards
> JB
> 
>> Le 11 avr. 2021 à 07:48, Jean-Baptiste Onofre  a écrit :
>> 
>> Hi,
>> 
>> I will move forward quickly on Karaf 4.3.2 due to the following issue 
>> detected:
>> 
>> - Upgrade xbean to 4.19 for better support on war artifacts
>> - Upgrade Pax Web for new Jetty version and xbean
>> - Fix/improvement on the JSON configuration
>> - Upgrade pax logging and other dependency projects to use 
>> maven-bundle-plugin 5.1.2, fixing the headers
>> 
>> I hope to submit 4.3.2 to vote mid week.
>> 
>> I will keep you posted.
>> 
>> Regards
>> JB
> 

Re: Error running test org.apache.karaf.itests.BundleTest#listCommand

[Jean-Baptiste Onofre]

Hi,

Yes mvn clean install should work. And it seems you try with karaf main branch ?

Can you try (even if it should not be required):

1. First: mvn clean install -DskipTests on root module
2. Then: mvn clean install in the itest/test module

In the meantime, I will try a full build on a Windows VM.

Regards
JB

> Le 18 avr. 2021 à 20:37, Васил Зорев  a écrit :
> 
> no, same issue. (i guess you meant mvn clean install from the command line,
> that's what i tried)
> 
> Btw one (potentially dumb) question, do i have to build/run anything else
> before running integration tests? So far I just built the root project once
> without any tests.
> 
> Regards,
> Have a nice evening
> 
> На нд, 18.04.2021 г. в 21:01 ч. JB Onofré  написа:
> 
>> Does it work with maven directly ?
>> 
>>> Le 18 avr. 2021 à 19:55, Васил Зорев  a écrit
>> :
>>> 
>>> JB,
>>> 
>>> not sure what kind of test case do you mean? I tried executing
>>> org.apache.karaf.itests.BundleTest#listCommand as a single unit test,
>> also
>>> as part of the maven build.
>>> I'll try to debug a bit more carefully, hopefully something comes up..
>>> 
>>> На нд, 18.04.2021 г. в 20:52 ч. Васил Зорев 
>>> написа:
>>> 
>>>> Hi,
>>>> 
>>>> I tried initially in IntelliJ IDEA community 2020.3.2.
>>>> 
>>>> Just tried in Eclipse Oxygen.3a (4.7.3a) and it failed with the same
>>>> error. I'm currently setting up an ubuntu dev environment (also for
>> other
>>>> purposes) so when this is running i can try to run the test there as
>> well.
>>>> Will let you know.
>>>> 
>>>> Regards,
>>>> Vassil
>>>> 
>>>> На нд, 18.04.2021 г. в 19:10 ч. Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>>>> написа:
>>>> 
>>>>> Hi
>>>>> 
>>>>> Do you use eclipse or some IDE visiting target/ during the test? Can
>> make
>>>>> it happen.
>>>>> 
>>>>> 
>>>>> Le dim. 18 avr. 2021 à 17:48, Jean-Baptiste Onofre  a
>>>>> écrit :
>>>>> 
>>>>>> Hi Vassil,
>>>>>> 
>>>>>> Don’t you have two tests running ?
>>>>>> 
>>>>>> I never had this issue (but I’m not using Windows), and Jenkins works
>>>>> fine.
>>>>>> 
>>>>>> Do you have a simple test case to reproduce ?
>>>>>> 
>>>>>> Regards
>>>>>> JB
>>>>>> 
>>>>>>> Le 18 avr. 2021 à 12:58, Васил Зорев  a
>>>>> écrit
>>>>>> :
>>>>>>> 
>>>>>>> Reposted from the user mailing list:
>>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> I tried to run some of the unit tests in the itests project to check
>>>>> an
>>>>>> issue, but most of them failed. The most common error is that pax exam
>>>>>> couldn't start the container as it failed to replace the
>>>>>> etc\org.ops4j.pax.logging.cfg file.
>>>>>>> 
>>>>>>> Caused by: java.nio.file.FileSystemException:
>>>>>> 
>>>>> 
>> C:\Users\vasil\IdeaProjects\karaf\itests\test\target\exam\95aa38e2-a6a1-405e-8072-afe35347a34e\etc\org.ops4j.pax.logging.cfg:
>>>>>> The process cannot access the file because it is being used by another
>>>>>> process.
>>>>>>> at
>>>>>> 
>>>>> 
>> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
>>>>>>> ... (full log attached)
>>>>>>> 
>>>>>>> I have checked out karaf sources version 4.2.12-SNAPSHOT from some
>>>>> time
>>>>>> ago (probably a few months).
>>>>>>> 
>>>>>>> Please find attached the intellij test log.
>>>>>>> It failed the same way when I executed the test as part of the maven
>>>>>> build.
>>>>>>> 
>>>>>>> I added a breakpoint at the place where the FileSystemException is
>>>>>> thrown and examined the open file handles of this file in Sysinternals
>>>>>> Process Explorer. Seems there are two open file handles for it, both
>> by
>>>>> the
>>>>>> same java process that is executing the test (screenshots attached).
>>>>>>> 
>>>>>>> Please let me know if this is a known issue on my end if i can
>> already
>>>>>> resolve it, is it version dependent or something else? Also I can
>>>>> provide
>>>>>> further details if needed.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Vassil
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: Error running test org.apache.karaf.itests.BundleTest#listCommand

[Jean-Baptiste Onofre]

Hi Vassil,

Don’t you have two tests running ? 

I never had this issue (but I’m not using Windows), and Jenkins works fine.

Do you have a simple test case to reproduce ?

Regards
JB

> Le 18 avr. 2021 à 12:58, Васил Зорев  a écrit :
> 
> Reposted from the user mailing list:
> 
> Hello,
> 
> I tried to run some of the unit tests in the itests project to check an 
> issue, but most of them failed. The most common error is that pax exam 
> couldn't start the container as it failed to replace the 
> etc\org.ops4j.pax.logging.cfg file.
> 
> Caused by: java.nio.file.FileSystemException: 
> C:\Users\vasil\IdeaProjects\karaf\itests\test\target\exam\95aa38e2-a6a1-405e-8072-afe35347a34e\etc\org.ops4j.pax.logging.cfg:
>  The process cannot access the file because it is being used by another 
> process.
> at 
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
> ... (full log attached)
> 
> I have checked out karaf sources version 4.2.12-SNAPSHOT from some time ago 
> (probably a few months).
> 
> Please find attached the intellij test log.
> It failed the same way when I executed the test as part of the maven build.
> 
> I added a breakpoint at the place where the FileSystemException is thrown and 
> examined the open file handles of this file in Sysinternals Process Explorer. 
> Seems there are two open file handles for it, both by the same java process 
> that is executing the test (screenshots attached).
> 
> Please let me know if this is a known issue on my end if i can already 
> resolve it, is it version dependent or something else? Also I can provide 
> further details if needed.
> 
> Regards,
> Vassil
> 

Re: Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Just a quick update about this.

I’m releasing the dependency projects (xbean vote is on the way, pax* 
preparation is moving forward, …).

I should be able to submit Karaf 4.3.2 and 4.2.12 to vote during the week end.

Regards
JB

> Le 11 avr. 2021 à 07:48, Jean-Baptiste Onofre  a écrit :
> 
> Hi,
> 
> I will move forward quickly on Karaf 4.3.2 due to the following issue 
> detected:
> 
> - Upgrade xbean to 4.19 for better support on war artifacts
> - Upgrade Pax Web for new Jetty version and xbean
> - Fix/improvement on the JSON configuration
> - Upgrade pax logging and other dependency projects to use 
> maven-bundle-plugin 5.1.2, fixing the headers
> 
> I hope to submit 4.3.2 to vote mid week.
> 
> I will keep you posted.
> 
> Regards
> JB

Apache Karaf 4.3.2 very soon

[Jean-Baptiste Onofre]

Hi,

I will move forward quickly on Karaf 4.3.2 due to the following issue detected:

- Upgrade xbean to 4.19 for better support on war artifacts
- Upgrade Pax Web for new Jetty version and xbean
- Fix/improvement on the JSON configuration
- Upgrade pax logging and other dependency projects to use maven-bundle-plugin 
5.1.2, fixing the headers

I hope to submit 4.3.2 to vote mid week.

I will keep you posted.

Regards
JB

Re: Karaf 4.3.1 issue when KARAF_BASE is set

[Jean-Baptiste Onofre]

Hi Jakub,

Yes, we will fix that on wrapper as well.

Thanks,
Regards
JB

> Le 8 avr. 2021 à 09:35, Jakub Herkel  a écrit :
> 
> Today I found out that there is also similar problem with
> chronos-wraper. Could you also please check this?
> 
> Jakub
> 
> On Thu, Apr 8, 2021 at 7:12 AM Jean-Baptiste Onofre  wrote:
>> 
>> Hi Jakub,
>> 
>> Good catch. FYI, this "issue" is there for a while on main branch.
>> 
>> Freeman already did a fix, it will be included in Karaf 4.3.2.
>> 
>> Thanks !
>> Regards
>> JB
>> 
>>> Le 7 avr. 2021 à 20:07, Jakub Herkel  a écrit :
>>> 
>>> Hi,
>>> 
>>> During migration from servicemix 7.0.1 to karaf 4.3.1 I can see these
>>> lines before karaf start:
>>> karaf: Ignoring predefined value for KARAF_HOME
>>> WARNING: package org.apache.karaf.specs.locator not in java.base
>>> Error starting karaf activator
>>> org.apache.karaf.specs.activator.Activator:
>>> org/apache/karaf/specs/locator/OsgiLocator
>>> 
>>> After some testing I found out that problem appears when KARAF_BASE is
>>> set and it is not the same directory as KARAF_HOME. I think that
>>> problem is in karaf.sh where I can see :
>>> cd "${KARAF_BASE}"
>>> ant later there is a line:
>>> --patch-module 
>>> java.base=lib/endorsed/org.apache.karaf.specs.locator-4.3.1.jar
>>> 
>>> So org.apache.karaf.specs.locator-4.3.1.jar has to be located under
>>> KARAF_BASE/lib.  Due to this reason wouldn't it be better when the
>>> line is prefixed with KARAF_HOME?
>>> i.e. --patch-module
>>> java.base=$KARAF_HOME/lib/endorsed/org.apache.karaf.specs.locator-4.3.1.jar
>>> 
>>> with best regards
>>> 
>>> jakub
>> 

Re: Karaf 4.3.1 issue when KARAF_BASE is set

[Jean-Baptiste Onofre]

Hi Jakub,

Good catch. FYI, this "issue" is there for a while on main branch.

Freeman already did a fix, it will be included in Karaf 4.3.2.

Thanks !
Regards
JB

> Le 7 avr. 2021 à 20:07, Jakub Herkel  a écrit :
> 
> Hi,
> 
> During migration from servicemix 7.0.1 to karaf 4.3.1 I can see these
> lines before karaf start:
> karaf: Ignoring predefined value for KARAF_HOME
> WARNING: package org.apache.karaf.specs.locator not in java.base
> Error starting karaf activator
> org.apache.karaf.specs.activator.Activator:
> org/apache/karaf/specs/locator/OsgiLocator
> 
> After some testing I found out that problem appears when KARAF_BASE is
> set and it is not the same directory as KARAF_HOME. I think that
> problem is in karaf.sh where I can see :
> cd "${KARAF_BASE}"
> ant later there is a line:
> --patch-module java.base=lib/endorsed/org.apache.karaf.specs.locator-4.3.1.jar
> 
> So org.apache.karaf.specs.locator-4.3.1.jar has to be located under
> KARAF_BASE/lib.  Due to this reason wouldn't it be better when the
> line is prefixed with KARAF_HOME?
> i.e. --patch-module
> java.base=$KARAF_HOME/lib/endorsed/org.apache.karaf.specs.locator-4.3.1.jar
> 
> with best regards
> 
> jakub

Re: Problems making debian package of karaf 4.3.1

[Jean-Baptiste Onofre]

I created https://issues.apache.org/jira/browse/KARAF-7094 
 related to that.

Regards
JB

> Le 5 avr. 2021 à 23:55, Steinar Bang  a écrit :
> 
>> JB Onofré :
> 
>> Yea it makes sense to use an empty file for 4.3. Actually, I think it makes 
>> sense to do it by default on 4.3. I will create the jira related to that. 
> 
> +1
> 

Re: Problems making debian package of karaf 4.3.1

[Jean-Baptiste Onofre]

Hi Steinar,

It’s weird: it looks like the boot feature are not startup.

Do you have the features core bundle in etc/startup.properties ?
Did you update etc/org.apache.karaf.features.cfg ?

What JDK did you try ?

Regards
JB

> Le 3 avr. 2021 à 23:53, Steinar Bang  a écrit :
> 
> I'm trying to make a debian package of karaf 4.3.1[1].
> 
> The resulting deb package so far:
> 1. Builds without any error messages
> 2. Installs without any error messages
> 3. Leaves a running process
> 4. Leaves very few messages in the logs[6]
> 5. Does not start an SSH server (I think...? at least nothing responds
>on port 8101)
> 
> According to the git history it's been two years since I last had any
> issues upgrading (this was when moving from 4.1.x to 4.2.x).
> 
> Since this, all I've had to do is bump the version number and rebuild
> the package.
> 
> All hints and ideas to what I could look at when debugging
> this issue, are, as always, highly appreciated!
> 
> What I've done so far[2] is:
> 1. Bump the karaf version number
> 2. Embed OSGi 7 instead of getting it from a debian dependency, since
>debian stable still has OSGi 6[3] (using a debian package can be
>reintroduced when "bullsey" is released[4].  There is an OSGi 7
>package in buster-backports[5], but that will have to be installed
>explicitly, it won't automatically be installed as a dependency
> 
> Thanks!
> 
> - Steinar
> 
> 
> References:
> [1] 
> [2] 
> [3] 
> [4] 
> [5] 
> [6] 
> 

[ANN] Apache Karaf 4.3.1 has been released

[Jean-Baptiste Onofre]

The Apache Karaf team is pleased so announce Apache Karaf runtime 4.3.1 release.

This release is a major release on the Karaf 4.3.x series, bringing updates, 
fixes and new features, especially:

- java.* now exported by system packages (as expected since R7)
- fixed on configuration with json format
- jetty alias feature for backward compatibility
- resolver parallelism default value fixed (to run on Kubernetes by default)
- fix on SSH, log commands
- improvement on the JMX layer (especially JMXMP)
- env/prop interpolation support on the SSH client
- add property to disable auto refresh in features service
- and much more !

The Release Notes are available here: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
 


Download: http://karaf.apache.org/download.html 


Enjoy!
The Apache Karaf team

[RESULT][VOTE] Apache Karaf runtime 4.3.1 release

[Jean-Baptiste Onofre]

Hi everyone,

This vote passed with the following result:

+1 (binding): François Papon, JB Onofré, Jamie Goodyear, Freeman Fang, Grzegorz 
Grzybek
+1 (non binding): Romain Manni-Bucau, Serge Huber, Matt Pavlovich

I’m promoting the artifacts on Maven Central and dist, update Jira, and I will 
do the announcement.

Thanks all for your vote !

Regards
JB

> Le 29 mars 2021 à 15:14, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.1 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - java.* now exported by system packages (as expected since R7)
> - fixed on configuration with json format
> - jetty alias feature for backward compatibility
> - resolver parallelism default value fixed (to run on Kubernetes by default)
> - fix on SSH, log commands
> - improvement on the JMX layer (especially JMXMP)
> - env/prop interpolation support on the SSH client
> - add property to disable auto refresh in features service
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1155/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1155/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.1/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.1/>
> 
> Git tag:
> karaf-4.3.1
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB

Re: [VOTE] Apache Karaf runtime 4.3.1 release

[Jean-Baptiste Onofre]

+1 (binding)

Regards
JB

> Le 29 mars 2021 à 15:14, Jean-Baptiste Onofre  a écrit :
> 
> Hi everyone,
> 
> I submit Apache Karaf runtime 4.3.1 to your vote.
> 
> This release includes bunch of dependency upgrades, fixes, and improvements, 
> especially:
> 
> - java.* now exported by system packages (as expected since R7)
> - fixed on configuration with json format
> - jetty alias feature for backward compatibility
> - resolver parallelism default value fixed (to run on Kubernetes by default)
> - fix on SSH, log commands
> - improvement on the JMX layer (especially JMXMP)
> - env/prop interpolation support on the SSH client
> - add property to disable auto refresh in features service
> - and much more !
> 
> Please take a look on Release Notes for details !
> 
> Release Notes: 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818
>  
> <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12348818>
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1155/ 
> <https://repository.apache.org/content/repositories/orgapachekaraf-1155/>
> 
> Staging Dist:
> https://dist.apache.org/repos/dist/dev/karaf/4.3.1/ 
> <https://dist.apache.org/repos/dist/dev/karaf/4.3.1/>
> 
> Git tag:
> karaf-4.3.1
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Regards
> JB