Re: BUG: Overriding ports via environment variable don't work on first start

[Jean-Baptiste Onofre]

Thanks,

I’m working on Decanter and ActiveMQ this week end, I will take a look next 
week.

Regards
JB

> Le 28 janv. 2022 à 11:28, Andre Schlegel-Tylla  a 
> écrit :
> 
> Done
> 
> https://issues.apache.org/jira/browse/KARAF-7362
> 
> Am Fr., 28. Jan. 2022 um 11:07 Uhr schrieb Jean-Baptiste Onofré 
> :
> Yes, please if you can (else I will do it).
> 
> Thanks !
> Regards
> JB
> 
> On 28/01/2022 11:05, Andre Schlegel-Tylla wrote:
> > Thank you.
> > 
> > Should I file a Jira ticket?
> > 
> > Regards
> > Andre
> > 
> > Am Fr., 28. Jan. 2022 um 10:34 Uhr schrieb Jean-Baptiste Onofré 
> > mailto:j...@nanthrax.net>>:
> > 
> > Hi Andre,
> > 
> > thanks for the update.
> > 
> > Yeah, it seems to be a race condition where the config interceptor
> > (overriding values with system properties and env variables) is started
> > after some other services.
> > 
> > Let me investigate a bit (probably finalizing interceptor start before
> > features service).
> > 
> > Regards
> > JB
> > 
> > On 28/01/2022 10:01, Andre Schlegel-Tylla wrote:
> >  > Hi JB,
> >  >
> >  > yes I have used Karaf 4.3.6 vanilla. I have repeated my tests by
> >  > deleting the data folder.
> >  >
> >  > I have repeated it again and got different results (now with
> > deleting
> >  > the whole karaf and unpack the vanilla tar.gz again).
> >  >
> >  > I had used this:
> >  >
> >  > export ORG_APACHE_KARAF_SHELL_SSHPORT=18101
> >  > tar -xzf apache-karaf-4.3.6.tar.gz
> >  > apache-karaf-4.3.6/bin/karaf
> >  >
> >  >
> >  > * First time all went as expected; ports have been changed
> >  > * Second time I got this:
> >  >
> >  >karaf-env-test tar -xzf apache-karaf-4.3.6.tar.gz
> >  >karaf-env-test apache-karaf-4.3.6/bin/karaf
> >  >  __ __  
> >  > / //_/ __ _/ __/
> >  >/ ,<  / __ `/ ___/ __ `/ /_
> >  >   / /| |/ /_/ / /  / /_/ / __/
> >  >  /_/ |_|\__,_/_/   \__,_/_/
> >  >
> >  >Apache Karaf (4.3.6)
> >  >
> >  > Hit '' for a list of available commands
> >  > and '[cmd] --help' for help on a specific command.
> >  > Hit '' or type 'system:shutdown' or 'logout' to shutdown
> > Karaf.
> >  >
> >  > karaf@root()> Exception in thread "JMX Connector Thread
> >  >
> > [service:jmx:rmi://127.0.0.1:4/jndi/rmi://127.0.0.1:1099/karaf-root
> > 
> >  >  > >]"
> >  > java.lang.RuntimeException: Could not start JMX connector server
> >  > at
> >  >
> > 
> > org.apache.karaf.management.ConnectorServerFactory.lambda$init$0(ConnectorServerFactory.java:438)
> >  > at java.base/java.lang.Thread.run(Thread.java:829)
> >  > Caused by: java.io.IOException: Cannot bind to URL
> >  > [rmi://127.0.0.1:1099/karaf-root
> >   > >]:
> >  > javax.naming.CommunicationException [Root exception is
> >  > java.rmi.NoSuchObjectException: no such object in table]
> >  > at
> >  >
> > 
> > java.management.rmi/javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:854)
> >  > at
> >  >
> > 
> > java.management.rmi/javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:501)
> >  > at
> >  >
> > 
> > org.apache.karaf.management.ConnectorServerFactory.lambda$init$0(ConnectorServerFactory.java:421)
> >  > ... 1 more
> >  > Caused by: javax.naming.CommunicationException [Root exception is
> >  > java.rmi.NoSuchObjectException: no such object in table]
> >  > at
> >  >
> > 
> > jdk.naming.rmi/com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:162)
> >  > at
> >  >
> > 
> > java.naming/com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:230)
> >  > at
> > java.naming/javax.naming.InitialContext.bind(InitialContext.java:417)
> >  > at
> >  >
> > 
> > java.management.rmi/javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:713)
> >  > at
> >  >
> > 
> > java.management.rmi/javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:496)
> >  > ... 2 more
> >  > Caused by: java.rmi.NoSuchObjectException: no such object in table
> >  > at
> >  >
> > 
> > java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:303)
> >  > at
> >  >
> > 
> > java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:279)
> >  > at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:380)
> > 

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

[Jean-Baptiste Onofre]

Hi Paul,

Thanks for your message ;)

Glad you are happy with 4.3.6 release ;)

Regards
JB

> Le 15 janv. 2022 à 09:43, Paul Fraser  a écrit :
> 
> Hi JB,
> 
> Great result
> 
> Cleanall works as planned.
> 
> Deployer runs any kars or jars in deploy directory at startup.
> 
> All my code runs without problem.
> 
> Thanks for the great effort in getting 4.3.6 out.
> 
> Paul Fraser
> 
> On 15/1/22 4:26 pm, Jean-Baptiste Onofre wrote:
>> 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

[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

Re: SSH issue when trying to upgrade from 4.2.11 to 4.2.14

[Jean-Baptiste Onofre]

Possible. I already changed the stream handling.

Can you create a Jira dedicated to that ? I will take a look.

Thanks,
Regards
JB

> Le 14 janv. 2022 à 16:16, Martin Lichtin  a écrit :
> 
> Hmm, still seeing this issue with 4.2.15
> 
> It could be the change done for KARAF-7190 was not correct?
> The 2.5.1 ssh upgrade can't be the issue as ssh-2.5.1 is already used in 
> 4.2.11 and in that Karaf version the issue does not show up.
> 
> - Martin
> 
> On 10/01/2022 17:05, Jean-Baptiste Onofre wrote:
>> Hi,
>> 
>> I think it’s what I fixed for 4.2.15 (closing the ssh session).
>> 
>> Let me double check the commit id.
>> 
>> Regards
>> JB
>> 
>>> Le 10 janv. 2022 à 15:49, Martin Lichtin  a écrit :
>>> 
>>> I've an issue upgrading from 4.2.11 to 4.2.14.
>>> 
>>> Programmatically connecting via SSH into Karaf, this works fine with 
>>> 4.2.11. Using an SSH session one can remotely execute several commands. 
>>> However, with 4.2.14, after executing one command, that SSH Session to 
>>> Karaf starts to hang.
>>> 
>>> See attached some test code that can be used to reproduce the issue.
>>> 
>>> - Martin
>>> 
>>> 
>>> 
>> 

Re: loading differences cfg and json.

[Jean-Baptiste Onofre]

Hi Serge,

I’m releasing 4.3.6 and 4.2.15 right now, so, you will have 4.2.15 on Maven 
Central later this week (assuming the vote will pass).

Regards
JB

> Le 10 janv. 2022 à 16:09, Serge Démoulin  a écrit 
> :
> 
> Hi Jean-Baptiste
> 
> The currently version 4.2.15-SNAPHOT (github) fix our deploy problem.
> We need a release soon (4.2.15) because without this release we can not 
> upgrade karaf to version 4.2.13, 4.2.14
> So we are not able to deliver our software with a safe log4j version 
> Our software is only correctly running with karaf 4.2.12
> Best regards
> Serge Démoulin
> 
> On Thu, Jan 6, 2022 at 2:04 PM Jean-Baptiste Onofré  wrote:
> Hi Joerg,
> 
> It's a known issue in Felix FileInstall that I already fixed, you can 
> take a look on:
> 
> https://issues.apache.org/jira/browse/FELIX-6461
> https://github.com/apache/felix-dev/pull/127
> 
> It will be included in Karaf 4.3.6 (currently in preparation).
> 
> Regards
> JB
> 
> On 06/01/2022 11:38, Jörg Jansen wrote:
> > Dear all,
> > 
> > during migrating from karaf-4.3.2 to karaf-4.3.5 I recognized an strange 
> > behavior.
> > For my bundles I've configured a configuration file via blueprint.
> > Those files are provided in json format.
> > 
> > When starting the karaf with an existing configuration, this file is 
> > ignored until it get touched.
> > In version 4.3.2 and earlier, it was loaded automatically on startup.
> > 
> > When providing the configuration as a cfg file, everything works fine and 
> > as expected.
> > 
> > Can you provide my any hint, where to take a look at?
> > 
> > Kind regards,
> > Joerg
> > 
> 
> 
> -- 
> Serge Démoulin
> Senior Software Engineer
> 
> Averbis GmbH
> Salzstraße 15
> 79098 Freiburg
> Germany
> 
> Fon: +49 761 708 394 18
> Email: serge.demou...@averbis.com
> Web: https://averbis.com
> 
> Headquarters: Freiburg im Breisgau
> Register Court: Amtsgericht Freiburg im Breisgau, HRB 701080
> Managing Directors: Dr. med. Philipp Daumke, Dr. Kornél Markó
> 

Re: SSH issue when trying to upgrade from 4.2.11 to 4.2.14

[Jean-Baptiste Onofre]

Hi,

I think it’s what I fixed for 4.2.15 (closing the ssh session).

Let me double check the commit id.

Regards
JB

> Le 10 janv. 2022 à 15:49, Martin Lichtin  a écrit :
> 
> I've an issue upgrading from 4.2.11 to 4.2.14.
> 
> Programmatically connecting via SSH into Karaf, this works fine with 4.2.11. 
> Using an SSH session one can remotely execute several commands. However, with 
> 4.2.14, after executing one command, that SSH Session to Karaf starts to hang.
> 
> See attached some test code that can be used to reproduce the issue.
> 
> - Martin
> 
> 
> 

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.

[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

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

Re: Updated mitigation for Log4JShell in Karaf 4.2.x and 4.3.x since setting log4j2.formatMsgNoLookups is a insufficient mitigation measure

[Jean-Baptiste Onofre]

It would mitigate only the JNDI part, not the other CVE (about the lookup).

Anyway, it’s a good workaround.

I don’t understand why you don’t want to upgrade to a new version. It’s exactly 
the purpose of the new releases to address CVE.
Else, why we would do new releases if you are stuck with old versions. Log4j 
did couple of new releases to address the CVE issue, so it’s worth to update.

Regards
JB

> Le 23 déc. 2021 à 18:37, Paul Spencer  a écrit :
> 
> JB,
> Aymen Furter suggested the following:
> 
> $ cd karaf-directory
> $ zip -q -d $(find . | grep pax-logging-log4j2 | grep jar) 
> org/apache/logging/log4j/core/lookup/JndiLookup.class
> $ zip -q -d $(grep -rlnw . -e "pax-logging-log4j2" | grep "data/cache/bundle" 
> | grep jar) org/apache/logging/log4j/core/lookup/JndiLookup.class
> 
> 
> This looks like a reasonable short term workaround that is relatively easy to 
> implement. Relative to the Karaf and its services, do you see any potential 
> problems with the workaround?
> 
> 
> Paul Spencer
> 
>> On Dec 23, 2021, at 12:17 PM, JB Onofré  wrote:
>> 
>> Then create your own custom distro upgrading pax logging. 
>> 
>>> Le 23 déc. 2021 à 17:23, Paul Spencer  a écrit :
>>> 
>>> JB,
>>> As stated earlier, upgrading Karaf is not an option in the short term.
>>> 
>>> Paul Spencer
>>> 
>>> 
 On Dec 23, 2021, at 11:21 AM, JB Onofré  wrote:
 
 Upgrade to Karaf 4.2.13. 
 
>> Le 23 déc. 2021 à 17:02, Paul Spencer  a 
>> écrit :
> 
> In light of the updated mitigation for the Log4JShell published by 
> Log4J[1], specifically "zip -q -d log4j-core-*.jar 
> org/apache/logging/log4j/core/lookup/JndiLookup.class", the insufficient 
> mitigation measure of setting system property log4j2.formatMsgNoLookups, 
> and the presents of JndiLookup.class in the pax-logging-log4j2 jar. What 
> is the suggested mitigation for Karaf 4.2.x and Karaf 4.3.x when 
> upgrading Karaf is not an option in the short term?
> 
> ***
> * Example from Karaf 4.2.9
> 
> [user@localhost karaf]$ zip -sf 
> ./system/org/ops4j/pax/logging/pax-logging-log4j2/1.11.6/pax-logging-log4j2-1.11.6.jar
>  | grep JndiLookup
> org/apache/logging/log4j/core/lookup/JndiLookup.class
> [user@localhost karaf]$ 
> 
> Paul Spencer
> 
> [1] https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228
> 
> 
 
>>> 
>> 
> 

Re: Change to bin/karaf clean

[Jean-Baptiste Onofre]

OK, fair enough.

I created https://issues.apache.org/jira/browse/KARAF-7304 about that.

Regards
JB

> Le 23 déc. 2021 à 06:25, Paul Fraser  a écrit :
> 
> Hi JB,
> 
> On 23/12/21 4:00 pm, Jean-Baptiste Onofre wrote:
>> Hi Paul
>> 
>> Clean all are argument to karaf script doesn’t exist, only clean exists. So 
>> basically, doing ./bin/karaf clean or ./binn/karaf clean all is the same 
>> (all is just ignored):
> I looked in the script and could not see anything, perhaps because it was not 
> there 
>> https://github.com/apache/karaf/blob/main/main/src/main/java/org/apache/karaf/main/Main.java
>> 
>> karaf.clean.all exists in etc/system.properties.
>> 
>> Do you want me to add clean.all argument to bin/karaf (allowing you to do 
>> ./bin/karaf clean.all for instance) ?
>> 
> Just cleanall without the dot if possible. e.g. bin/karaf cleanall
> 
> Thanks,
> 
> Paul
> 
> 
> 
> 

Re: Change to bin/karaf clean

[Jean-Baptiste Onofre]

Hi Paul

Clean all are argument to karaf script doesn’t exist, only clean exists. So 
basically, doing ./bin/karaf clean or ./binn/karaf clean all is the same (all 
is just ignored):

https://github.com/apache/karaf/blob/main/main/src/main/java/org/apache/karaf/main/Main.java

karaf.clean.all exists in etc/system.properties.

Do you want me to add clean.all argument to bin/karaf (allowing you to do 
./bin/karaf clean.all for instance) ?

Regards
JB

> Le 22 déc. 2021 à 22:29, Paul Fraser  a écrit :
> 
> Hi,
> 
> Since the change to "bin/karaf clean" where the log is not cleaned, a 
> statement was made earlier in this group along the lines that "bin/karaf 
> clean all" was the way to produce the previous clean functionality.
> 
> This does not work and I have been unable to find the correct method.
> 
> Anyone able to provide the correct technique?
> 
> Paul Fraser
> 

Re: apache-karaf with logback

[Jean-Baptiste Onofre]

Hi,

The Karaf log command (log:set, log:get, log:list, etc) assumes that you use 
log4j style configuration. It doesn’t support other configuration format.
However, you can still use log4j style configuration even if you use logback 
service.

If you want that log:* commands support logback style, then, ok to create a 
Jira (but IMHO it’s very low priority).

NB: logback has been also impacted by CVE ;) So worth to keep log4j2 with Karaf 
4.3.4 at least ;)

Regards
JB

> Le 22 déc. 2021 à 15:43, Jörg Jansen  a 
> écrit :
> 
> Hi all, 
> 
> caused by the known log4j2 vulnerability, I tried to switch from log4j to 
> logback. 
> I've updated the startup.properties and pax-logging configuration file and at 
> the first view it seems to work fine. 
> 
> Unfortunately, when running any log command within the shell (e.g. 
> log:display) I receive an IllegalStateException with message "Unrecognized 
> configuration".
> 
> Looking into the code, I could see, that the getDelegate onlyprovides log4j 
> implementations. 
> 
> Is that a bug, which I should register in JIRA?
> Does karaf support logback (as pax-logging do).
> 
> Used karaf version is 4.3.2.
> 
> Thanks for any comment,
> Joerg
> 

Re: Karaf 4.2.12 and Java 8: Failure to Resolve javax.activation Framework

[Jean-Baptiste Onofre]

Hi Ralf,

Are you using JDK8 or JDK11 ?

Jakarta Activation 1.2.2 bundle seems to require Java >= 9.

You have two options:
- wrap the bundle to remove ee requirement header (I did that in ActiveMQ 
bundles for instance)
- upgrade to Java 11 ;)

Regards
JB

> Le 21 déc. 2021 à 15:56, Ralf Steppacher  a écrit :
> 
> Hello all,
> 
> I am trying to migrate an application from Karaf 4.0 to Karaf 4.2.12, Camel 
> 2.25, and Spring 5.3. Things work alright as long as I use Java 11 as the 
> runtime, but the application fails to resolve its activation framework 
> dependency as soon as I use Java 8 as the runtime because the activation 
> bundle pulled in appears to require a Java 9 runtime:
> 
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve reportCreator/3.40.0.SNAPSHOT: missing requirement 
> [reportCreator/3.40.0.SNAPSHOT] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=javax.activation)(version>=1.2.0)(!(version>=2.0.0)))"
>  [caused by: Unable to resolve com.sun.activation.jakarta.activation/1.2.2: 
> missing requirement [com.sun.activation.jakarta.activation/1.2.2] osgi.ee; 
> filter:="(&(osgi.ee=JavaSE)(version=9.0))"]
> at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> ... 14 more
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve com.sun.activation.jakarta.activation/1.2.2: missing requirement 
> [com.sun.activation.jakarta.activation/1.2.2] osgi.ee; 
> filter:="(&(osgi.ee=JavaSE)(version=9.0))"
> at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1343)
> ... 15 more
> 
> As with Java 8 the javax namespace implementation is still included in the 
> JDK runtime I tried to add the javax.activation package(s) to the boot 
> delegation path and/or the extra system packages, but the result is always 
> the same.
> 
> What am I missing here? Thanks in advance!
> 
> 
> Ralf
> 
> 

Re: Karaf 4.2.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Jean-Baptiste Onofre]

I already replied to Oleg:

log4j2.formatMsgNoLookups=true

In system.properties

Regards
JB

> Le 12 déc. 2021 à 19:05, Paul Spencer  a écrit :
> 
> For users of Karaf 4.2.x, what is the recommended mitigation for "Apache 
> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
> 
> Paul Spencer
> 

Re: Karaf 4.3.x "Apache Log4j Remote Code Execution Vulnerability" mitigation?

[Jean-Baptiste Onofre]

log4j2.formatMsgNoLookups=true in etc/system.properties should do the trick.

Regards
JB

> Le 12 déc. 2021 à 18:10, Oleg Cohen  a écrit :
> 
> Hi JB,
> 
> Thank you for the info.
> 
> Do you have an example of how this can be dome in system.properties?
> 
> Best,
> Oleg
> 
>> On Dec 12, 2021, at 10:08 AM, JB Onofré  wrote:
>> 
>> You can use system.properties to set the msg format on existing version. 
>> 
>> Else Karaf 4.3.4 will include fix by default. 
>> 
>>> Le 12 déc. 2021 à 17:54, Paul Spencer  a écrit :
>>> 
>>> For users of Karaf 4.3.x, what is the recommended mitigation for "Apache 
>>> Log4j Remote Code Execution Vulnerability", CVE-2021-44228?
>>> 
>>> Paul Spencer
>>> 
>> 
> 

Re: Different result between Linux and Windows

[Jean-Baptiste Onofre]

You can set this up in pom.xml (in the maven-bundle-plugin configuration) of 
your bundle.

Regards
JB

> Le 1 nov. 2021 à 13:02, Paul Fraser  a écrit :
> 
> Hi JB,
> 
> On 25/10/21 4:03 pm, JB Onofré wrote:
>> Use <_noee>true on maven-bundle-plugin wrapping to avoid the 
>> requirement.
> Not sure how or where to use this.
> 
> Are you able to point me to an example?
> 
> Paul Fraser
> 
>>  
>> 
>> It’s because the JRE wrapping tag name could be different. 
>> 
>> Regards 
>> JB
>> 
>>> Le 25 oct. 2021 à 06:57, Paul Fraser  a écrit :
>>> 
>>> 
>>> Hi,
>>> 
>>> I am using a Vaadin addon ckeditor-vaadin_2.2.0, karaf 4.3.3, intellij 
>>> latest.
>>> 
>>> The addon specifies java 11 in the pom
>>> 
>>> 
>>> maven-compiler-plugin
>>> 3.8.1
>>> 
>>> 11
>>> 
>>> 
>>>  
>>> 
>>> It has to be wrapped by karaf. 
>>> 
>>> system runs OK in linux mint but fails in Windows as follows-
>>> 
>>> [caused by: Unable to resolve  
>>> 
>>> wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor-vaadin_2.2.0_ckeditor-
>>> vaadin-2.2.0.jar/0.0.0:  
>>> missing requirement 
>>> [wrap_file__C__Users_paulf_qneCustomKaraf_karaf_data_kar_qaddonbaseweb-0.0.1_com_wontlost_ckeditor-
>>> vaadin_2.2.0_ckeditor-vaadin-2.2.0.jar/0.0.0]  
>>> osgi.ee; filter:="(&(osgi.ee=JavaSE)(version=11))"]]] 
>>> 
>>> How can this be handled in karaf?
>>> 
>>> Paul Fraser
>>> 

Re: Charset issue

[Jean-Baptiste Onofre]

Don’t you have the full JVM command args ? Else use jconsole to get it for 
instance.

Regards
JB

> Le 28 oct. 2021 à 11:17, Andrei Petru Mura  a écrit :
> 
> Hi Jean,
> 
> Using shell:info displays no info related to locales.
> 
> Andrei
> 
> On Thu, Oct 28, 2021 at 11:54 AM JB Onofré  wrote:
> Hi
> 
> It’s JVM default so using LC_ALL and other env variable. You can check the 
> passed locales using shell:info 
> 
> Regards 
> JB
> 
> > Le 28 oct. 2021 à 08:41, Andrei Petru Mura  a écrit :
> > 
> > 
> > I have AlmaLinux (CentOS follower) with jre 1.8.0. And Apache Karaf 4.0.4. 
> > installed in this environment. Two almost identical servers.
> > 
> > If I run this Java code from terminal:
> > System.out.println(Charset.defaultCharset());
> > 
> > I get 
> > US-ASCII.
> > 
> > If I run the same command from a karaf bundle, I get this on one server: 
> > 
> > UTF-8
> > 
> > and on the second server, I get:
> > 
> > US-ASCII
> > 
> > My question would be: where does Apache Karaf load the default encoding 
> > from? Or how does it set this?
> > 
> > N.B. Locale for both servers are identical: en_US.
> > 
> 

Re: ClassNotFoundException for BouncyCastleProvider

[Jean-Baptiste Onofre]

Hi Barry,

Why you don’t install bc as bundle ?

Any requirement to be in lib ?

Regards
JB

> Le 18 oct. 2021 à 16:58, Barry Rawlinson  a écrit 
> :
> 
> Hello,
> 
> Karaf: 4.3.3
> Java: openjdk version "11.0.12" 2021-07-20
> 
> I'm trying to use the BouncyCastleProvider for jasypt PBE (without installing 
> the provider in the JRE).
> 
> Any idea where I am going wrong with this?
> 
> I have followed the instructions here: 
> https://karaf.apache.org/manual/latest/#_security_providers
> 
> Downloaded the bouncy castle jar to:
> 
> ${KARAF_HOME}/lib/ext/bcprov-jdk15on-1.69.jar
> 
> Added this to the end of config.properties:
> 
> org.apache.karaf.security.providers=org.bouncycastle.jce.provider.BouncyCastleProvider
> 
> Edited config.properties (I've also tried org.bouncycastle.*, \):
> 
> org.osgi.framework.bootdelegation = \
> com.sun.*, \
> org.bouncycastle*, \
> 
> But whenever I start karaf with the blueprint below deployed I always get:
> 
> BlueprintContainerImpl   | 57 - org.apache.aries.blueprint.core - 
> 1.10.3 | Unable to start container for blueprint bundle 
> bouncycastle-bp.xml/0.0.0
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error 
> setting property: PropertyDescriptor  setter: [class 
> org.jasypt.encryption.pbe.config.EnvironmentPBEConfig.setProviderClassName(class
>  java.lang.String)]
> 
> Caused by: org.jasypt.exceptions.EncryptionInitializationException: 
> java.lang.ClassNotFoundException: 
> org.bouncycastle.jce.provider.BouncyCastleProvider
> 
> Caused by: java.lang.ClassNotFoundException: 
> org.bouncycastle.jce.provider.BouncyCastleProvider
> 
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
>xsi:schemaLocation="
>  http://www.osgi.org/xmlns/blueprint/v1.0.0 
> https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
>  http://camel.apache.org/schema/blueprint 
> http://camel.apache.org/schema/blueprint/camel-blueprint.xsd
>  http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 
> http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd;>
> 
>  class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
>  value="org.bouncycastle.jce.provider.BouncyCastleProvider"/>
> 
> 
> 
>  xmlns="http://camel.apache.org/schema/blueprint;>
> 
> 
> 
> 
> 
> --
> TIA.  
> Barry.

Re: Feature install of pax-jdbc-oracle fails

[Jean-Baptiste Onofre]

HI Oliver,

I will check for next PAX JDBC (maybe SMX bundle) release.

I will keep you posted.

Regards
JB

> Le 15 oct. 2021 à 08:38, Oliver Fürniß  a écrit :
> 
> Hi JB,
> 
> > Let me provide a wrapping to you as workaround.
> Would be great if you would provide a workaround. :-)
> 
> Oliver
> 
> Am Do., 7. Okt. 2021 um 11:01 Uhr schrieb Jean-Baptiste Onofré 
> :
> Hi Oliver,
> 
> I think that the Oracle driver headers are not fully correct.
> 
> Let me provide a wrapping to you as workaround.
> 
> Regards
> JB
> 
> On 07/10/2021 10:52, Oliver Fürniß wrote:
> > 
> > Hi John,
> > 
> > Thanks for your response. I tried your suggestion, but it does not work 
> > due to a wiring error when I try to install the bundle:
> > 
> > bundle:install -s mvn:org.ops4j.pax.jdbc/pax-jdbc-oracle/1.5.0
> > Bundle ID: 266
> > Error executing command: Error installing bundles:
> > Unable to start bundle mvn:org.ops4j.pax.jdbc/pax-jdbc-oracle/1.5.0: 
> > org.osgi.framework.BundleException: Unable to resolve 
> > org.ops4j.pax.jdbc.oracle [266](R 266.0): missing requirement 
> > [org.ops4j.pax.jdbc.oracle [266](R 266.0)] osgi.wiring.package; 
> > (osgi.wiring.package=oracle.jdbc.datasource.impl) Unresolved 
> > requirements: [[org.ops4j.pax.jdbc.oracle [266](R 266.0)] 
> > osgi.wiring.package; (osgi.wiring.package=oracle.jdbc.datasource.impl)]
> > 
> > In the pax-jdbc-oracle-1.5.0.jar/META-INF/MANIFEST.MF is an 
> > Import-Package statement for the "oracle.jdbc.datasource.impl" package, 
> > but this package does not exist in older Oracle JDBC drivers. Just in 
> > the latest. :-(
> > 
> > Oliver
> > 
> > Am Mi., 6. Okt. 2021 um 17:24 Uhr schrieb John Taylor 
> > mailto:jtt77...@gmail.com>>:
> > 
> > Hi Oliver,
> > I had the same problem with mssql-jdbc.
> > But it's not exactly the same because the pax-jdbc-mssql feature
> > only depends on pax-jdbc-spec and only includes the driver
> > mvn:com.microsoft. . .And that means there's no wrapper around
> > the driver needed for osgi and nothing is needed specially to
> > configure it from pax.
> > 
> > But the pax-jdb-oracle feature includes the driver from oracle
> > (wrapped as wrap:mvn: because it's not an osgi bundle) and a wrapper
> > from pax mvn:org.ops4j.pax.jdbc/pax-jdbc-oracle/1.5.0
> > 
> > So you could try not installing the bundle and just install the
> > pax-jdbc-spec and the mvn:org.ops4j.pax.jdbc bundle along with the
> > driver jar you put in deploy.
> > 
> > -John
> > 
> > On Wed, Oct 6, 2021 at 11:13 AM Oliver Fürniß
> > mailto:oliver.fuern...@virtimo.de>> wrote:
> > 
> > Hello,
> > 
> > I'm trying to upgrade from Karaf 4.2.8 to 4.3.3.
> > 
> > With 4.2.8 I was able to place the required Oracle driver to the
> > deploy-folder and do a "feature:install pax-jdbc-oracle". With
> > 4.3.3 it seems to be a little bit different. When I place the
> > ojdbc6.jar or ojdbc7.jar or ojdbc8.jar in the deploy folder I
> > will get the error below (at the end) after "feature:install
> > pax-jdbc-oracle".
> > 
> > It works when I do not place a specific Oracle driver to the
> > deploy folder and just do "feature:install pax-jdbc-oracle". In
> > this case it installs the latest Oracle driver by using maven.
> > 
> > This is different to 4.2.8 and not the expected behaviour. IMO
> > the latest Oracle driver cannot be used for all Oracle versions.
> > Even Oracle provides specific downloads of their JDBC driver for
> > different DB versions:
> > 
> > https://www.oracle.com/de/database/technologies/appdev/jdbc-downloads.html
> > 
> > 
> > 
> > In the ops4j features.xml file details is written, that "This
> > feature requires actual Oracle JDBC driver installed",
> > which conflicts with the auto bundle dependency installation of
> > the latest Oracle driver. This line does not exist in 4.2.8.
> > 
> > 
> > 
> >  This feature requires actual Oracle JDBC driver 
> > installed
> >  pax-jdbc-spec
> > 
> >   > dependency="true">wrap:mvn:com.oracle.database.jdbc/ojdbc8/${version.com.oracle.database.jdbc}
> >  
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-oracle/${project.version}
> > 
> > 
> > Is there a reason why the latest and not with all Oracle
> > versions compatible driver gets installed? Am I able to install
> > somehow a different version of the Oracle driver?
> > 
> > All the best,
> >   Oliver
> > 
> > 
> > karaf@root()> feature:install pax-jdbc-oracle
> > org.apache.karaf.features.internal.util.MultiException: Error
> > restarting bundles:
> > Activator start error in bundle org.ops4j.pax.jdbc.oracle [223].
> > at
> > 
> > 

Re: Problems with javax.annotation package

[Jean-Baptiste Onofre]

Hi Richard

Sorry I misread the trace especially this part:

export: osgi.wiring.package=org.atmosphere.cpr; uses:=javax.annotation
  com.vaadin.external.atmosphere.runtime 
[com.vaadin.external.atmosphere.runtime [141](R 141.0)]
import: (osgi.wiring.package=javax.annotation)

AFAIR we already discuss about google findbugs bundle that cause an issue (it 
should not export Java.annotation package as it’s not a spec).

Maybe I can wrap this bundle in SMX to avoid issue in the future. Thoughts ?

Regards
JB

> Le 28 sept. 2021 à 20:19, Richard Hierlmeier  a 
> écrit :
> 
> Hi J.B,
> 
> The javax.annotation package is exported by 
> 
> mvn:com.google.code.findbugs/jsr305/3.0.2 (dependency of jsoup)
> and by
> mvn:jakarta.annotation/jakarta.annotation-api/1.3.5 (from cxf-specs feature)
> 
> None of them comes from Vaadin. vaadin-server has a dependency to jsoup that 
> was upgraded with Vaadin 8.14.0 to version 1.14.2.
> The jsr305 bundle imports to javax.annotation;version=[3.0.2,4)
> My vaadin8osgi Bundle imports javax.annotation;version=[1.3.5,2)
> 
> It seems that the jsr305 bundle ist the problem:
> https://stackoverflow.com/questions/64568455/why-does-findbugs-jsr305-break-osgi-package-export-of-javax-annotations-in-redha
> 
> Richard
> 
> 
> 
> 
> Am Di., 28. Sept. 2021 um 17:35 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi Richard,
> 
> It seems that vaadin.annotations bundle is just wrong as it exports 
> javax.annotation whereas it should not.
> 
> You have basically three options:
> 1. Fix vaadin.annotations ;)
> 2. Wrap vaadin.annotations to remove the “bad” export
> 3. Don’t use six annotation-api-1.3 and use vaadin.annotations instead but it 
> means changing the core features
> 
> Regards
> JB
> 
> > Le 28 sept. 2021 à 17:27, Richard Hierlmeier  a 
> > écrit :
> > 
> > 
> > After upgrading  the Vaadin OSGI demo to VAADIN 8.14.0 it tried
> > to integrate a jax-rs resource into this application.
> > 
> > I used the rest whiteboard examples from the Karaf 4.3.3 distribution. It 
> > worked in a first step fine.
> > 
> > Finally I tried to implement a JAX-RS authentication filter for this 
> > application.
> > 
> > I implemented this class: 
> > https://github.com/rhierlmeier/vaadin8_karaf_demo/blob/jaxrs-integration/src/main/java/de/rhierlmeier/vaadin8osgi/rest/AuthenticationFilter.java
> > 
> > I needs the javax.annotation.Priority annotation.
> > 
> > When I start now the bundle, I get following error:
> > 
> > Error executing command: Error executing command on bundles:
> > Error starting bundle 148: Uses constraint violation. Unable to 
> > resolve resource de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi 
> > [148](R 148.2)] because it is exposed to package 'javax.annotation' from 
> > resources org.apache.servicemix.specs.annotation-api-1.3 
> > [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)] and 
> > org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two 
> > dependency chains.
> > 
> > Chain 1:
> >   de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi [148](R 148.2)]
> > import: 
> > (&(osgi.wiring.package=javax.annotation)(version>=1.3.0)(!(version>=2.0.0)))
> >  |
> > export: osgi.wiring.package: javax.annotation
> >   org.apache.servicemix.specs.annotation-api-1.3 
> > [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)]
> > 
> > Chain 2:
> >   de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi [148](R 148.2)]
> > import: 
> > (&(osgi.wiring.package=com.vaadin.annotations)(version>=8.14.0)(!(version>=9.0.0)))
> >  |
> > export: osgi.wiring.package=com.vaadin.annotations; 
> > uses:=org.atmosphere.cpr
> >   com.vaadin.server [com.vaadin.server [145](R 145.0)]
> > import: 
> > (&(osgi.wiring.package=org.atmosphere.cpr)(version>=2.4.30.vaadin4))
> >  |
> > export: osgi.wiring.package=org.atmosphere.cpr; uses:=javax.annotation
> >   com.vaadin.external.atmosphere.runtime 
> > [com.vaadin.external.atmosphere.runtime [141](R 141.0)]
> > import: (osgi.wiring.package=javax.annotation)
> >  |
> > export: osgi.wiring.package: javax.annotation
> >   org.apache.felix.framework [org.apache.felix.framework [0](R 0)] 
> > Unresolved requirements: [[de.rhierlmeier.vaadin8osgi [148](R 148.2)] 
> > osgi.wiring.package; 
> > (&(osgi.wiring.package=com.vaadin.annotations)(version>=8.14.0)(!(version>=9.0.0)))]
> > 
> > How can I solve this problem?
> > 
> > This problem can be reproduced by building and installing this branch:
> > 
> > https://github.com/rhierlmeier/vaadin8_karaf_demo/tree/jaxrs-integration
> > 
> > Regards 
> > 
> >   Richard
> 

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofre]

  >  > org.opennms.features.telemetry.listeners-NXOS-Listener
> >  >  >  >  >  >>...
> >  >  >  >  >  >>
> >  >  >  >  >  >> Here's a reference to the
> > feature file in
> >  > question:
> >  >  >  >  >  >>
> >  >  >  >
> >  >
> > https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>>
> >  >  >  >  >
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>>>
> >  >  >  >  >  >>
> >  >  >  >  >
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-whi

Re: Problems with javax.annotation package

[Jean-Baptiste Onofre]

Hi Richard,

It seems that vaadin.annotations bundle is just wrong as it exports 
javax.annotation whereas it should not.

You have basically three options:
1. Fix vaadin.annotations ;)
2. Wrap vaadin.annotations to remove the “bad” export
3. Don’t use six annotation-api-1.3 and use vaadin.annotations instead but it 
means changing the core features

Regards
JB

> Le 28 sept. 2021 à 17:27, Richard Hierlmeier  a 
> écrit :
> 
> 
> After upgrading  the Vaadin OSGI demo to VAADIN 8.14.0 it tried
> to integrate a jax-rs resource into this application.
> 
> I used the rest whiteboard examples from the Karaf 4.3.3 distribution. It 
> worked in a first step fine.
> 
> Finally I tried to implement a JAX-RS authentication filter for this 
> application.
> 
> I implemented this class: 
> https://github.com/rhierlmeier/vaadin8_karaf_demo/blob/jaxrs-integration/src/main/java/de/rhierlmeier/vaadin8osgi/rest/AuthenticationFilter.java
> 
> I needs the javax.annotation.Priority annotation.
> 
> When I start now the bundle, I get following error:
> 
> Error executing command: Error executing command on bundles:
> Error starting bundle 148: Uses constraint violation. Unable to 
> resolve resource de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi 
> [148](R 148.2)] because it is exposed to package 'javax.annotation' from 
> resources org.apache.servicemix.specs.annotation-api-1.3 
> [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)] and 
> org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two 
> dependency chains.
> 
> Chain 1:
>   de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi [148](R 148.2)]
> import: 
> (&(osgi.wiring.package=javax.annotation)(version>=1.3.0)(!(version>=2.0.0)))
>  |
> export: osgi.wiring.package: javax.annotation
>   org.apache.servicemix.specs.annotation-api-1.3 
> [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)]
> 
> Chain 2:
>   de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi [148](R 148.2)]
> import: 
> (&(osgi.wiring.package=com.vaadin.annotations)(version>=8.14.0)(!(version>=9.0.0)))
>  |
> export: osgi.wiring.package=com.vaadin.annotations; 
> uses:=org.atmosphere.cpr
>   com.vaadin.server [com.vaadin.server [145](R 145.0)]
> import: 
> (&(osgi.wiring.package=org.atmosphere.cpr)(version>=2.4.30.vaadin4))
>  |
> export: osgi.wiring.package=org.atmosphere.cpr; uses:=javax.annotation
>   com.vaadin.external.atmosphere.runtime 
> [com.vaadin.external.atmosphere.runtime [141](R 141.0)]
> import: (osgi.wiring.package=javax.annotation)
>  |
> export: osgi.wiring.package: javax.annotation
>   org.apache.felix.framework [org.apache.felix.framework [0](R 0)] Unresolved 
> requirements: [[de.rhierlmeier.vaadin8osgi [148](R 148.2)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=com.vaadin.annotations)(version>=8.14.0)(!(version>=9.0.0)))]
> 
> How can I solve this problem?
> 
> This problem can be reproduced by building and installing this branch:
> 
> https://github.com/rhierlmeier/vaadin8_karaf_demo/tree/jaxrs-integration
> 
> Regards 
> 
>   Richard

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofre]

ngle-port-flows
> >  >  >  >  >  >>
> >  >  > org.opennms.features.telemetry.listeners-JTI-Listener
> >  >  >  >  >  >>
> >  >  > org.opennms.features.telemetry.listeners-NXOS-Listener
> >  >  >  >  >  >>...
> >  >  >  >  >  >>
> >  >  >  >  >  >> Here's a reference to the
> > feature file in
> >  > question:
> >  >  >  >  >  >>
> >  >  >  >
> >  >
> > https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>>
> >  >  >  >  >
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>>>>>
> >  >  >  >  >  >>
> >  >  >  >  >
> >  >  >  >
> >  >  >
> >  > 
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b>
> >  >   
> >   <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b 
> > <https://gist.github.com/j-white/1574f34cb94dc2d9166ae9805bd4ba3b&g

Re: Karaf 5

[Jean-Baptiste Onofre]

Hi

No sure, it’s only class loader issue. I remember this issue in pure spring 
boot with JDK11.

Let me check.

Regards
JB

> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
> 
> Hi JB,
> 
> Fully understand that it is still work in progress.
> 
> Regarding the .NoClassDefFoundError: org/ietf/jgss/GSSException
> --add-modules java.security.jgss does not solve it?
> Is it a class loader problem?
> 
> Best,
> 
> -- Jaap
> 
> 
> |-Oorspronkelijk bericht-
> |Van: Jean-Baptiste Onofre 
> |Verzonden: zondag 26 september 2021 14:20
> |Aan: user@karaf.apache.org
> |Onderwerp: Re: Karaf 5
> |
> |Hi Jaap,
> |
> |First, maybe I was not clean in my presentation: Karaf 5 is still under
> |development and so, everything is not yet ready.
> |As said, I will “move” the code to Apache Karaf repo as soon as I consider I
> |have something clean and running.
> |
> |Anyway, about your email, I will check. Today my focus is on the
> |OsgiApplicationManager to be Karaf 4 compliant.
> |I also have to improve the Karaf Config service.
> |
> |By the way, you don’t need your own Main, just use the repackage with
> |regular provided Main (you can take a look on the K4 assembly repackage as
> |an example). I will create a gradle/maven plugin with repackage.
> |
> |Regarding your issue, as you are running with JDK11, I guess you have to add 
> --
> |add-modules java.security.jgss to avoid the NoClassDefFoundException.
> |
> |Thanks anyway for your feedback, much appreciated.
> |
> |Regards
> |JB
> |
> |> Le 26 sept. 2021 à 12:00, jgfrm  a écrit :
> |>
> |> Hi Jean-Baptiste,
> |>
> |> I managed to start (well not completely) my spring application.
> |> However, while starting up, I get an exception:
> |>
> |> 11:43:03.148 [main] ERROR o.s.boot.SpringApplication:837 - Application
> |> run failed
> |> org.springframework.context.ApplicationContextException: Unable to
> |> start web server; nested exception is java.lang.NoClassDefFoundError:
> |> org/ietf/jgss/GSSException
> |>
> |> Any ideas?
> |>
> |> Also, I had to make modifications in
> |SpringBootApplicationManagerService/start:
> |>
> |> try {
> |>Thread.currentThread().setContextClassLoader(classLoader);
> |>// disable tomcat stream handler
> |>/* There is no TomcatURLStreamHandlerFactory in my spring jar
> |>final Method tomcat =
> |classLoader.loadClass("org.apache.catalina.webresources.TomcatURLStream
> |HandlerFactory").getMethod("disable");
> |>if (!tomcat.isBridge()) {
> |>tomcat.setAccessible(true);
> |>}
> |>tomcat.invoke(null, null);
> |> */
> |>// invoke spring boot main
> |>final Method main =
> |classLoader.loadClass("org.springframework.boot.loader.JarLauncher").getM
> |ethod("main", String[].class);
> |>main.setAccessible(true);
> |>log.info("Call JarLauncher");
> |>if (properties.get("args") != null) {
> |>log.info("Call JarLauncher with args");
> |>main.invoke(null, new Object[]{ properties.get("args") });
> |>} else {
> |>log.info("Call JarLauncher without args");
> |>main.invoke(null, new Object[]{new String[0]}); // the 
> original invoke
> |did not work for me
> |>}
> |>} finally {
> |>Thread.currentThread().setContextClassLoader(original);
> |>}
> |>
> |> Further details:
> |> - openjdk version "11.0.12" 2021-07-20
> |> - invocation:
> |> java -cp
> |> ../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1
> |> .0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/tar
> |> get/spring-boot-application-manager-5.0-SNAPSHOT.jar
> |> -Dkaraf.config=src/main/resources/karaf.json Main
> |>
> |> Main.java:
> |> ###
> |> public class Main {
> |>public static void main(String[] args){
> |>System.out.println("Starting Karaf");
> |>Karaf karaf = Karaf.builder().build();
> |>karaf.start();
> |>}
> |> }
> |> ###
> |>
> |> Best,
> |>
> |> -- Jaap
> |>
> |> |-Oorspronkelijk bericht-
> |> |Van: Jean-Baptiste Onofré 
> |> |Verzonden: vrijdag 24 september 2021 10:34
> |> |Aan: user@karaf.apache.org
> |> |Onderwerp: Re: Karaf 5
>

Re: How to detect Feature or Kar install is complete

[Jean-Baptiste Onofre]

Hi,

You can use the verify goal on the feature, you will be able to see the 
requirements of a feature (including required services).

Is it what you mean ?

Regards
JB

> Le 26 sept. 2021 à 09:29, Paul Fraser  a écrit :
> 
> Hi,
> 
> What methods are available to detect Feature or Kar install is complete if a 
> system needs to wait for completion of a previous feature or kar?
> 
> OpenHAB inspects the list returned from FeatureService or KarService to find 
> if the required addon is in the list.
> 
> Any other method suggestions?
> 
> Paul Fraser
> 
> 

Re: Karaf 5

[Jean-Baptiste Onofre]

Hi Jaap,

First, maybe I was not clean in my presentation: Karaf 5 is still under 
development and so, everything is not yet ready.
As said, I will “move” the code to Apache Karaf repo as soon as I consider I 
have something clean and running.

Anyway, about your email, I will check. Today my focus is on the 
OsgiApplicationManager to be Karaf 4 compliant.
I also have to improve the Karaf Config service.

By the way, you don’t need your own Main, just use the repackage with regular 
provided Main (you can take a look on the K4 assembly repackage as an example). 
I will create a gradle/maven plugin with repackage.

Regarding your issue, as you are running with JDK11, I guess you have to add 
--add-modules java.security.jgss to avoid the NoClassDefFoundException.

Thanks anyway for your feedback, much appreciated.

Regards
JB

> Le 26 sept. 2021 à 12:00, jgfrm  a écrit :
> 
> Hi Jean-Baptiste,
> 
> I managed to start (well not completely) my spring application.
> However, while starting up, I get an exception:
> 
> 11:43:03.148 [main] ERROR o.s.boot.SpringApplication:837 - Application run 
> failed
> org.springframework.context.ApplicationContextException: Unable to start web 
> server; nested exception is java.lang.NoClassDefFoundError: 
> org/ietf/jgss/GSSException
> 
> Any ideas?
> 
> Also, I had to make modifications in 
> SpringBootApplicationManagerService/start:
> 
> try {
>Thread.currentThread().setContextClassLoader(classLoader);
>// disable tomcat stream handler
>/* There is no TomcatURLStreamHandlerFactory in my spring jar
>final Method tomcat = 
> classLoader.loadClass("org.apache.catalina.webresources.TomcatURLStreamHandlerFactory").getMethod("disable");
>if (!tomcat.isBridge()) {
>tomcat.setAccessible(true);
>}
>tomcat.invoke(null, null);
> */
>// invoke spring boot main
>final Method main = 
> classLoader.loadClass("org.springframework.boot.loader.JarLauncher").getMethod("main",
>  String[].class);
>main.setAccessible(true);
>log.info("Call JarLauncher");
>if (properties.get("args") != null) {
>log.info("Call JarLauncher with args");
>main.invoke(null, new Object[]{ properties.get("args") });
>} else {
>log.info("Call JarLauncher without args");
>main.invoke(null, new Object[]{new String[0]}); // the 
> original invoke did not work for me
>}
>} finally {
>Thread.currentThread().setContextClassLoader(original);
>}
> 
> Further details:
> - openjdk version "11.0.12" 2021-07-20
> - invocation:
> java -cp 
> ../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1.0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/target/spring-boot-application-manager-5.0-SNAPSHOT.jar
>  -Dkaraf.config=src/main/resources/karaf.json Main
> 
> Main.java:
> ###
> public class Main {
>public static void main(String[] args){
>System.out.println("Starting Karaf");
>Karaf karaf = Karaf.builder().build();
>karaf.start();
>}
> }
> ###
> 
> Best,
> 
> -- Jaap
> 
> |-Oorspronkelijk bericht-
> |Van: Jean-Baptiste Onofré 
> |Verzonden: vrijdag 24 september 2021 10:34
> |Aan: user@karaf.apache.org
> |Onderwerp: Re: Karaf 5
> |
> |Hi Jaap,
> |
> |The presentation is available here:
> |
> |https://docs.google.com/presentation/d/1nDqd4oVbrggTDlwrzWc8zEdahKhcS
> |VZJjlPk5FPxfBE/edit?usp=sharing
> |
> |Karaf 5 WIP is available here:
> |
> |https://github.com/jbonofre/karaf5
> |
> |I'm available on Slack or by email if you wanna chat about Karaf5.
> |
> |Regards
> |JB
> |
> |On 24/09/2021 10:06, jgfrm wrote:
> |> Hi,
> |>
> |> I have two questions about Karaf 5:
> |> - is the presentation by Onofre at ApacheConf online somewhere?
> |> - is it possible to explore Karaf 5 (or: what is there right now)? I
> |> am in particular interested in the Spring Boot functionality, as I
> |> have a Spring Boot application that I want to port to Karaf to support
> |> dynamic loading of components. I have found the github repo of Onofre,
> |> but it is unclear to me how e.g. to start Karaf.
> |>
> |> Best,
> |>
> |> -- Jaap
> |>
> 

Re: Karaf feature update without internet connection

[Jean-Baptiste Onofre]

Hi,

I guess you should add wagon as dependency of the karaf-maven-plugin execution.

Regards
JB

> Le 22 sept. 2021 à 09:45, Andre Schlegel-Tylla  a 
> écrit :
> 
> Hi JB,
> 
> I tried this:
> 
> 
> 4.0.0
> test
> de.virtimo.bpc
> 1.0.0-SNAPSHOT
> 
> 
> 
> org.apache.karaf.tooling
> features-maven-plugin
> 2.4.4
> 
> 
> 
> add-features-to-repo
> generate-resources
> 
> add-features-to-repo
> 
> 
> 
> 
> mvn:org.apache.cxf.karaf/apache-cxf/3.3.11/xml/feature
> 
> 
> cxf
> 
> target/features-repo
> 
> 
> 
> 
> 
> 
> 
> But when I get this error:
> 
> [ERROR] Failed to execute goal 
> org.apache.karaf.tooling:features-maven-plugin:2.4.4:add-features-to-repo 
> (add-features-to-repo) on project test: Can't resolve bundle 
> org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11: Could not transfer 
> artifact org.apache.cxf.karaf:apache-cxf:xml:feature:3.3.11 from/to central 
> (https://repo.maven.apache.org/maven2): Cannot access 
> https://repo.maven.apache.org/maven2 with type default using the available 
> connector factories: BasicRepositoryConnectorFactory
> [ERROR]   org.apache.cxf.karaf:apache-cxf:xml:3.3.11
> [ERROR] 
> [ERROR] from the specified remote repositories:
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=true),
> [ERROR]   virtimo-central (https://virtimo.jfrog.io/artifactory/libs-release, 
> releases=true, snapshots=false),
> [ERROR]   virtimo-snapshots 
> (https://virtimo.jfrog.io/artifactory/libs-snapshot, releases=true, 
> snapshots=true): Cannot access https://repo.maven.apache.org/maven2 using the 
> registered transporter factories: WagonTransporterFactory: Unsupported 
> transport protocol https: com.google.inject.ProvisionException: Unable to 
> provision, see the following errors:
> [ERROR] 
> [ERROR] 1) Error in custom provider, java.lang.TypeNotPresentException: Type 
> org.apache.maven.wagon.providers.http.HttpWagon$__sisu33 not present
> [ERROR]   at 
> ClassRealm[plugin>org.apache.karaf.tooling:features-maven-plugin:2.4.4, 
> parent: jdk.internal.loader.ClassLoaders$AppClassLoader@4b85612c] (via 
> modules: org.eclipse.sisu.wire.WireModule -> 
> org.eclipse.sisu.plexus.PlexusBindingModule)
> [ERROR]   while locating org.apache.maven.wagon.Wagon annotated with 
> @com.google.inject.name.Named(value="https")
> [ERROR] 
> [ERROR] 1 error
> [ERROR]   role: org.apache.maven.wagon.Wagon
> [ERROR]   roleHint: https: org/apache/maven/wagon/providers/http/HttpWagon
> [ERROR] -> [Help 1]
> 
> The maven repo config is fine. He loaded the plugin from maven (the 
> 2.4.5-SNAPSHOT which is mentioned in the documentation is not available).
> 
> Regards
> Andre
> 
> Am Di., 21. Sept. 2021 um 08:36 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi Andre,
> 
> You can populate the system maven repository using add-features-to-repo goal 
> of the Karaf-maven-plugin.
> 
> Regards
> JB
> 
> > Le 21 sept. 2021 à 08:25, Andre Schlegel-Tylla 
> >  a écrit :
> > 
> > Hello,
> > 
> > we want to update CXF on some customer systems. This is no problem with an 
> > internet connection. We also now how to install a single jar file into the 
> > local maven repository. But in this case CXF is based on many features.
> > 
> > How can we update all the used CXF features? A Karaf update is currently no 
> > option.
> > 
> > Kind regards
> > Andre
> 

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofre]

Yes, I tried both, no clean, clean as argument, clean in config.properties.

All works fine.

Can you share some details about your test case and environment (especially if 
you are on Windows or Unix) ?

Regards
JB

> Le 21 sept. 2021 à 15:00, Matthias Leinweber  a 
> écrit :
> 
> For me it's a custom dist. Did you do a clean start?
> 
> Am Di., 21. Sept. 2021 um 14:28 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi,
> 
> I did several test and it works fine for me.
> 
> Here’s the very simplest test:
> 
> - Starting from Karaf 4.3.3 vanilla
> - I put commons-lang-2.6.jar in the deploy folder (while Karaf is stopped)
> - then, I’m starting Karaf with bin/karaf
> - When I checked the bundle:list:
> 
> 54 │ Active   │  10 │ 2.6.7  │ OPS4J Pax Url - wrap:
> 55 │ Active   │  80 │ 2.6│ Commons Lang
> 
> So, you can see commons-lang installed and active, meaning the deployers 
> deployed it from the deploy folder.
> 
> It works for me.
> 
> Can you elaborate a bit your test case ?
> Is it a custom distribution ?
> 
> Regards
> JB
> 
> > Le 20 sept. 2021 à 08:29, Paul Fraser  a écrit :
> > 
> > Hi JB,
> > 
> > Any result on this check?
> > 
> > Paul Fraser
> > 
> > On 17/9/21 9:55 pm, JB Onofré wrote:
> >> I checked etc I will check deploy now.
> >> 
> >> Regards
> >> JB
> >> 
> >>> Le 17 sept. 2021 à 12:29, Paul Fraser  a écrit :
> >>> 
> >>> Hi JB,
> >>> 
> >>> In my case the problem occurs using the deploy folder.
> >>> 
> >>> Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder 
> >>> files.
> >>> 
> >>> Paul
> >>> 
> >>>> On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote:
> >>>> Hi,
> >>>> 
> >>>> did you updated the etc location in etc/config.properties (in the 
> >>>> felix.fileinstall.dir property) ?
> >>>> 
> >>>> I just tried and it works fine for me. Here's my test case:
> >>>> 
> >>>> 1. I created etc/my.config.cfg containing foo=bar
> >>>> 2. I'm starting karaf
> >>>> 3. I can see the config loaded:
> >>>> 
> >>>> karaf@root()> config:list "(service.pid=my.config)"
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> Pid:my.config
> >>>> BundleLocation: ?
> >>>> Properties:
> >>>>felix.fileinstall.filename = 
> >>>> file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg
> >>>>foo = bar
> >>>>service.pid = my.config
> >>>> 
> >>>> Can you share your test case ?
> >>>> 
> >>>> Regards
> >>>> JB
> >>>> 
> >>>> 
> >>>> 
> >>>>> On 16/09/2021 14:31, Matthias Leinweber wrote:
> >>>>> Hello,
> >>>>> 
> >>>>> I am having a strange issue after I updated my assembly to 4.3.3. I am 
> >>>>> using a custom file installer location which I deploy with a feature.
> >>>>> 
> >>>>> The strange thing is that the folder is not processed automatically at 
> >>>>> startup, but if I touch a single file in the folder all others files 
> >>>>> get processed as well.
> >>>>> 
> >>>>> Any ideas?
> >>>>> 
> >>>>> br,
> >>>>> Matthias
> 
> 
> 
> 

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofre]

Hi,

I did several test and it works fine for me.

Here’s the very simplest test:

- Starting from Karaf 4.3.3 vanilla
- I put commons-lang-2.6.jar in the deploy folder (while Karaf is stopped)
- then, I’m starting Karaf with bin/karaf
- When I checked the bundle:list:

54 │ Active   │  10 │ 2.6.7  │ OPS4J Pax Url - wrap:
55 │ Active   │  80 │ 2.6│ Commons Lang

So, you can see commons-lang installed and active, meaning the deployers 
deployed it from the deploy folder.

It works for me.

Can you elaborate a bit your test case ?
Is it a custom distribution ?

Regards
JB

> Le 20 sept. 2021 à 08:29, Paul Fraser  a écrit :
> 
> Hi JB,
> 
> Any result on this check?
> 
> Paul Fraser
> 
> On 17/9/21 9:55 pm, JB Onofré wrote:
>> I checked etc I will check deploy now.
>> 
>> Regards
>> JB
>> 
>>> Le 17 sept. 2021 à 12:29, Paul Fraser  a écrit :
>>> 
>>> Hi JB,
>>> 
>>> In my case the problem occurs using the deploy folder.
>>> 
>>> Exact same code in 4.3.2 works, 4.3.3 does not install the deploy folder 
>>> files.
>>> 
>>> Paul
>>> 
 On 17/9/21 7:04 pm, Jean-Baptiste Onofré wrote:
 Hi,
 
 did you updated the etc location in etc/config.properties (in the 
 felix.fileinstall.dir property) ?
 
 I just tried and it works fine for me. Here's my test case:
 
 1. I created etc/my.config.cfg containing foo=bar
 2. I'm starting karaf
 3. I can see the config loaded:
 
 karaf@root()> config:list "(service.pid=my.config)"
 
 
 
 
 
 Pid:my.config
 BundleLocation: ?
 Properties:
felix.fileinstall.filename = 
 file:/home/jbonofre/Workspace/karaf/assemblies/apache-karaf/target/apache-karaf-4.3.4-SNAPSHOT/etc/my.config.cfg
foo = bar
service.pid = my.config
 
 Can you share your test case ?
 
 Regards
 JB
 
 
 
> On 16/09/2021 14:31, Matthias Leinweber wrote:
> Hello,
> 
> I am having a strange issue after I updated my assembly to 4.3.3. I am 
> using a custom file installer location which I deploy with a feature.
> 
> The strange thing is that the folder is not processed automatically at 
> startup, but if I touch a single file in the folder all others files get 
> processed as well.
> 
> Any ideas?
> 
> br,
> Matthias

[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: Referencing service via component-name

[Jean-Baptiste Onofre]

Hi Andrei,

Service and reference are decoupled as they are in different bundles (most of 
the time).

If you want to « link » via serviceName, just use properties and filter:



   



Then:



Regards
JB

> Le 21 sept. 2021 à 10:44, Andrei Petru Mura  a écrit :
> 
> I have my own bundle deployed in karaf 4.3.2.
> 
> In my blueprint.xml, I have declared a few services, like this:
> 
>  ref="importedSpringBeanName" />
> 
> If I list the services in karaf, I can see that this services are available.
> 
> In another bundle, I want to use this services via reference. Like this:
> 
>interface="some.InterfaceName" />
> 
> But when I deploy my second bundle in karaf, I get this:
> Unable to start container for blueprint bundle my-second-bundle/0.0.1 due to 
> unresolved dependencies 
> [(&(objectClass=some.InterfaceName)(osgi.service.blueprint.compname=serviceName))]
> 
> Am I missing something? Is there a way to reference a service via its ID?
> 
> Thanks,
> Andrei

Re: Karaf feature update without internet connection

[Jean-Baptiste Onofre]

Hi Andre,

You can populate the system maven repository using add-features-to-repo goal of 
the Karaf-maven-plugin.

Regards
JB

> Le 21 sept. 2021 à 08:25, Andre Schlegel-Tylla 
>  a écrit :
> 
> Hello,
> 
> we want to update CXF on some customer systems. This is no problem with an 
> internet connection. We also now how to install a single jar file into the 
> local maven repository. But in this case CXF is based on many features.
> 
> How can we update all the used CXF features? A Karaf update is currently no 
> option.
> 
> Kind regards
> Andre

Re: 4.3.3 bin/karaf debug clean problem

[Jean-Baptiste Onofre]

Hi Paul,

It depends how you « Install » the bundles.

For instance, if you drop the bundles in the deploy folder, Karaf deployer will 
« reinstall » them.

Regards
JB

> Le 20 sept. 2021 à 12:34, Paul Fraser  a écrit :
> 
> Hi,
> 
> If I use "bin/karaf debug clean" the active bundles are removed and the log 
> file is retained.
> 
> If I use "bin/karaf debug clean.all" the data file is removed but the active 
> bundles remain active.
> 
> I have also tried "cleanall" but in reading the jira I think clean.all is the 
> correct option .
> 
> Paul Fraser
> 
> On 19/9/21 3:05 pm, Jean-Baptiste Onofre wrote:
>> Hi Paul,
>> 
>> See https://issues.apache.org/jira/browse/KARAF-7146
>> 
>> Now a simple clean keep the log file. Cleanall removes all.
>> 
>> Regards
>> JB
>> 
>>> Le 19 sept. 2021 à 01:09, Paul Fraser  a écrit :
>>> 
>>> Hi,
>>> 
>>> With my installation of 4.3.3, when running Karaf with bin/karaf debug 
>>> clean  the data cache is cleaned but the karaf log remains.
>>> 
>>> If I delete the data directory before running karaf, the log is a fresh one.
>>> 
>>> Anything changed in 4.3.3 that might cause this?
>>> 
>>> Paul Fraser
>>> 

Re: Karaf 4.3.3 feature:refresh results in StackOverflowError

[Jean-Baptiste Onofre]

Hi Thomas,

Would it be possible to have your features definition ? I will be able to take 
a look.

Thanks
Regards
JB

> Le 20 sept. 2021 à 07:27, Thomas Driessen  a 
> écrit :
> 
> Hi J.B. , hi Francois,
> 
> thanks for your quick answer and sorry for the delay.
> 
> Is there any way to detect such a cycle, i.e. is there a command such as 
> feature:tree like for the dependency tree in maven that could help me 
> identifying such cycles?
> 
> Strange thing is: the exact same setup worked fine with Karaf 4.3.2. So 
> probably one of our referenced features in other feature repositories causes 
> this behavior.
> 
> 
> Kind regards,
> Thomas
> 
> Am Sa., 18. Sept. 2021 um 06:22 Uhr schrieb Jean-Baptiste Onofre 
> :
> Hi Thomas,
> 
> I think you have a loop in your features (a feature A require feature B that 
> require feature A).
> 
> I know that Pax CDI has a cycle like this (I have a fix but not yet released).
> 
> Regards
> JB
> 
> > Le 17 sept. 2021 à 17:00, Thomas Driessen  a 
> > écrit :
> > 
> > Hi,
> > 
> > we just updated to the new Karaf 4.3.3 and suddenly we always get a 
> > StackOverflowError as soon as we try to do a feature:refresh:
> > 
> > 2021-09-17T14:56:44,239 | ERROR | Karaf local console user karaf | 
> > ShellUtil| 44 - org.apache.karaf.shell.core - 4.3.3 
> > | Exception caught while executing command
> > java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> > at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
> > ~[?:?]
> > at java.util.concurrent.FutureTask.get(FutureTask.java:191) ~[?:?]
> > at 
> > org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.run(CommandSessionImpl.java:855)
> >  ~[?:?]
> > 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.StackOverflowError
> > at 
> > org.apache.karaf.features.internal.region.Subsystem.(Subsystem.java:149)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.region.SubsystemResolver.prepare(SubsystemResolver.java:127)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:390)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
> >  ~[?:?]
> > at 
> > org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394)
> >  ~[?:?]
> > 
> > Is this a known bug? Or is there anyone else experiencing this?
> > 
> > Kind regards,
> > Thomas
> 

Re: Decanter and JMX

[Jean-Baptiste Onofre]

Hi Steven,

I’m about to write a quick blog post to give some highlights about this change.

Basically, I did these two other changes:

1. For « descendent » properties (the properties inside a Map for instance), 
the property is now named [MAP_PROPERTY]_[ENTRY_PROPERTY]:

https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L74

2. You can specify the property you want to « render » in the Prometheus 
servlet using prometheus.key.foo in 
etc/org.apache.karaf.decanter.appender.prometheus.cfg:

https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java#L69

I hope it helps.

Regards
JB

> Le 19 sept. 2021 à 10:16, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> I've tested the new 2.8.0 decanter release and I'm pleased to say your fix 
> for https://issues.apache.org/jira/browse/KARAF-7154 works great. Thanks for 
> that !
> 
> However I couldn't figure out from the pull request what changes you made 
> related to my second suggestion, to better identify from which MBean the 
> properties are (or as you put it 'allow user to define the "exported" event 
> properties by configuration'). Can you please explain how I can achieve this ?
> 
> Kind regards,
> Steven
> 
> On Wed, May 12, 2021 at 6:57 PM Steven Huypens  
> wrote:
> Hi Jean-Baptist,
> 
> 1) You mention the Prometheus appender only exposes the numeric metrics. I 
> believe it would be a minor but very useful addition to also expose the 
> Objects in a CompositeDataSupport. For example java.lang.memory has a 
> HeapMemoryUsage-object which contains 4 values (committed, init, max & used) 
> that could easily be exposed as well.
> 
> 2) I also would like to suggest to prefix the outputted name of a property 
> with something that really identifies the MBean, eg. :
> 
> java_lang_Memory_HeapMemoryUsage_committed
> java_lang_Memory_HeapMemoryUsage_init 
> java_lang_Memory_HeapMemoryUsage_max
> java_lang_Memory_HeapMemoryUsage_used
> 
> Currently MBeans having the same properties will have their values overridden 
> in the output.
> 
> Kind regards,
> Steven
> 
> On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre  wrote:
> Hi Daniel,
> 
> JMX collector polls all MBeans attributes. However Prometheus appender only 
> expose metrics (numeric) on the Prometheus servlet:
> 
> http://localhost:8181/decanter/prometheus
> 
> As the generated JMX JSON is "more" than just numeric, it’s possible that you 
> don’t have the metrics.
> 
> You can check the JMX JSON using another kind of appender (like log appender 
> or elasticsearch).
> I can add kind of "json introspection" on the Prometheus appender to "force" 
> some JSON fields as metrics (gauge).
> 
> Regards
> JB
> 
> > Le 2 mai 2021 à 22:24, Daniel Las  a écrit :
> > 
> > Hi,
> > 
> > I installed Decanter 2.7.0 on Karaf 4.2.11 with JMX collector and 
> > Prometheus appender features. I uncommented 
> > "object.name.system=java.lang:*" in 
> > org.apache.karaf.decanter.collector.jmx-local.cfg.
> > 
> > Where can I find JVM metrics like current heap memory usage? 
> > 
> > Regards
> > -- 
> > Daniel Łaś
> > 
> 

Re: Significance of featuresBootAsynchronous - can you explain?

[Jean-Baptiste Onofre]

Hi guys,

The karaf-maven-plugin can take a features.xml as « template » where only the 
actual version will be populated with your pom dependencies set.

Generally speaking, it’s the same as using the maven interpolation (it’s this 
approach we are using in Karaf itself).
IMHO, you have more control and it’s easier to use maven interpolation with 
your features XML:

https://github.com/apache/karaf/tree/main/assemblies/features/standard

Regards
JB

> Le 19 sept. 2021 à 10:16, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> Still interested ;-)
> 
> Kind regards,
> Steven
> 
> On Tue, Sep 14, 2021 at 8:32 AM Stefan Günst  wrote:
> Hi JB,
> 
> we would also be very interested on this
> 
> Regards
> Stefan
> 
> 
>> Am 13.09.2021 um 21:30 schrieb Steven Huypens :
>> 
>> Hi JB,
>> 
>> Thanks for your answer! I'm sorry I have to ask, but can you also explain 
>> what you mean by a 'template file' ?
>> 
>> Kind regards,
>> Steven
>> 
>> On Mon, Sep 13, 2021 at 8:51 PM Jean-Baptiste Onofré  
>> wrote:
>> Hi,
>> 
>> It's not possible directly in the maven plugin (see 
>> https://issues.apache.org/jira/browse/KARAF-7246), the workaround is to 
>> use a template file.
>> 
>> Regards
>> JB
>> 
>> On 13/09/2021 19:03, Steven Huypens wrote:
>> > Hi JB,
>> > 
>> > I could not find how to implement such a 'stage' using the 
>> >  from the karaf-maven-plugin. Do you know where I can find 
>> > an example ?
>> > 
>> > Kind regards,
>> > Steven
>> > 
>> > On Mon, Sep 13, 2021 at 6:22 PM Jean-Baptiste Onofre > > <mailto:j...@nanthrax.net>> wrote:
>> > 
>> > Exactly, you are in the case where stage can help ;)
>> > 
>> > Regards
>> > JB
>> > 
>> >  > Le 13 sept. 2021 à 18:06, Stefan Günst > > <mailto:stefan.gue...@me.com>> a écrit :
>> >  >
>> >  > Hi JB,
>> >  >
>> >  > so the strict order of features guarantees that (in sync mode the
>> > default).
>> >  > That is how we do it at the moment.
>> >  >
>> >  > But: we got situation sometimes on slow systems clean start where
>> > we start feature „war“ and than later the webapp that needed this
>> > but got error unknown protocol „war“ …
>> >  >
>> >  > Regards
>> >  >
>> >  > Stefan
>> >  >
>> >  >
>> >  >
>> >  >
>> >  >> Am 13.09.2021 um 17:50 schrieb Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>>:
>> >  >>
>> >  >> Hi Stefan,
>> >  >>
>> >  >> I guess you mean stage in boot features.
>> >  >>
>> >  >> The use case is when you have boot features that requires
>> > another boot features to start or a specific order.
>> >  >>
>> >  >> The stage allows you to "force" the installation of some
>> > features before others.
>> >  >>
>> >  >> featuresBoot=(A,B),C,D
>> >  >>
>> >  >> We are "sure" that A and B are completely installed before
>> > installing C and D features.
>> >  >>
>> >  >> Classic example is wrap: if you need wrap in your feature, you
>> > have to install wrap before your feature, so you put wrap in the
>> > first stage.
>> >  >>
>> >  >> Regards
>> >  >> JB
>> >  >>
>> >  >> On 13/09/2021 17:24, Stefan Günst wrote:
>> >  >>> Hi JB,
>> >  >>> thank you very much!
>> >  >>>
>> >  >>>> The same applies with stage:
>> >  >>> That is very interesting and i think we dont know the possibility!
>> >  >>> Can you give us a hint/link how to control this in a real 
>> > scenario?
>> >  >>> Regards
>> >  >>> Stefan
>> >  >>>> Am 13.09.2021 um 14:07 schrieb Jean-Baptiste Onofré
>> > mailto:j...@nanthrax.net>>:
>> >  >>>>
>> >  >>>> Hi Stefan,
>> >  >>>>
>> >  >>>> sorry, I missed your message.
>> &g

Re: 4.3.3 bin/karaf debug clean problem

[Jean-Baptiste Onofre]

Hi Paul,

See https://issues.apache.org/jira/browse/KARAF-7146

Now a simple clean keep the log file. Cleanall removes all.

Regards
JB

> Le 19 sept. 2021 à 01:09, Paul Fraser  a écrit :
> 
> Hi,
> 
> With my installation of 4.3.3, when running Karaf with bin/karaf debug clean  
> the data cache is cleaned but the karaf log remains.
> 
> If I delete the data directory before running karaf, the log is a fresh one.
> 
> Anything changed in 4.3.3 that might cause this?
> 
> Paul Fraser
> 

Re: Karaf 4.3.3 feature:refresh results in StackOverflowError

[Jean-Baptiste Onofre]

Hi Thomas,

I think you have a loop in your features (a feature A require feature B that 
require feature A).

I know that Pax CDI has a cycle like this (I have a fix but not yet released).

Regards
JB

> Le 17 sept. 2021 à 17:00, Thomas Driessen  a 
> écrit :
> 
> Hi,
> 
> we just updated to the new Karaf 4.3.3 and suddenly we always get a 
> StackOverflowError as soon as we try to do a feature:refresh:
> 
> 2021-09-17T14:56:44,239 | ERROR | Karaf local console user karaf | ShellUtil  
>   | 44 - org.apache.karaf.shell.core - 4.3.3 | Exception 
> caught while executing command
> java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
> at java.util.concurrent.FutureTask.get(FutureTask.java:191) ~[?:?]
> at 
> org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.run(CommandSessionImpl.java:855)
>  ~[?:?]
> 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.StackOverflowError
> at 
> org.apache.karaf.features.internal.region.Subsystem.(Subsystem.java:149)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.region.SubsystemResolver.prepare(SubsystemResolver.java:127)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:390) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.handlePrerequisites(Deployer.java:1121)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:394) 
> ~[?:?]
> 
> Is this a known bug? Or is there anyone else experiencing this?
> 
> Kind regards,
> Thomas

Re: Significance of featuresBootAsynchronous - can you explain?

[Jean-Baptiste Onofre]

Exactly, you are in the case where stage can help ;)

Regards
JB

> Le 13 sept. 2021 à 18:06, Stefan Günst  a écrit :
> 
> Hi JB,
> 
> so the strict order of features guarantees that (in sync mode the default).
> That is how we do it at the moment.
> 
> But: we got situation sometimes on slow systems clean start where we start 
> feature „war“ and than later the webapp that needed this but got error 
> unknown protocol „war“ …
> 
> Regards
> 
> Stefan
> 
> 
> 
> 
>> Am 13.09.2021 um 17:50 schrieb Jean-Baptiste Onofré :
>> 
>> Hi Stefan,
>> 
>> I guess you mean stage in boot features.
>> 
>> The use case is when you have boot features that requires another boot 
>> features to start or a specific order.
>> 
>> The stage allows you to "force" the installation of some features before 
>> others.
>> 
>> featuresBoot=(A,B),C,D
>> 
>> We are "sure" that A and B are completely installed before installing C and 
>> D features.
>> 
>> Classic example is wrap: if you need wrap in your feature, you have to 
>> install wrap before your feature, so you put wrap in the first stage.
>> 
>> Regards
>> JB
>> 
>> On 13/09/2021 17:24, Stefan Günst wrote:
>>> Hi JB,
>>> thank you very much!
>>> 
 The same applies with stage:
>>> That is very interesting and i think we dont know the possibility!
>>> Can you give us a hint/link how to control this in a real scenario?
>>> Regards
>>> Stefan
 Am 13.09.2021 um 14:07 schrieb Jean-Baptiste Onofré :
 
 Hi Stefan,
 
 sorry, I missed your message.
 
 By default, the boot features are started in sequence (sync) meaning:
 
 featuresBoot=A,B,C
 
 means first A will be installed, and then, once A is completely installed, 
 B will be installed, etc
 
 The same applies with stage:
 
 featuresBoot=(A,C),B
 
 so, A will be installed then C, then once A and C are fully installed, B 
 will be installed.
 
 In async mode, A,B,C will be installed in parallel and the resolver will 
 try to find the optimal order.
 The purpose is to speed up the startup but it's "less" predictable.
 
 Regards
 JB
 
 On 31/08/2021 16:00, Stefan Günst wrote:
> Hi,
> no one can comment ?
>> Am 18.08.2021 um 17:19 schrieb Stefan Günst :
>> 
>> Hello,
>> 
>> can anyone explain what this is for/what it does and why it is default = 
>> false.
>> We have situations where it helps to start our distribution without any 
>> errors if we set this to „true“ in org.apache.karaf.features.cfg
>> 
>> Any risk to set it to true?
>> 
>> 
>> 
>> Stefan
>> 
>> 
>> 
>> 
> 

Re: What is the recommended way to deploy a module with dependencies?

[Jean-Baptiste Onofre]

Hi,

You can take a look on the karaf examples.

Basically, you have two options:

1. You create a feature containing your module/bundle and the dependency 
bundles, playing with import package
2. You create a uber bundle embedding the dependencies (private package or 
embed dependency)

The preferred approach is probably 1.

Regards
JB

> Le 22 août 2021 à 14:28, Xad Kile  a écrit :
> 
> Hello,
> TLDR: What is the recommended way to deploy a module with dependencies?
> 
> I am new to Karaf, and haven't figured out the right way to deploy an 
> application on Karaf.
> 
> Generally an application consists of the application code and dependencies.
> 
> For application code, I think there's only one and reasonable way to deploy, 
> and that is: build the code into bundles and install the bundles (manually or 
> using karaf-maven-plugin)
> 
> For dependencies, there are more than one way to delivery dependencies into 
> Karaf:
> 
> Way 1: pack the dependencies into the application bundle by manually enter 
> the dependencies' packages into  /  of 
> maven-bundle-plugin
> Pros: only one file to install
> Cons: I have to manually manage  /  
> which is very error-prone. Also there is a huge risk of missing transitive 
> dependencies.
> 
> 
> Way 2: use ,  to included the 
> dependencies into the bundle jar.
> Pros: less risky with transitive dependencies. I can control exposure of 
> the dependencies to other modules.
> Cons: Still have to manually manage which dependencies to included, 
> decide which one is public, which one is private.
> 
> Way 3: create a kar file from the project, then install the kar
> Pros: The process is mostly automatic
> Cons: 
> - All the dependencies are public and accessible to all modules
> - I have two files two install for each module: a bundle file and a 
> kar file. 
> - This still cannot handle transitive dependencies of very big 
> libraries such as Google Firebase SDK, but this is not a problem for the time 
> being.
> 
> Way 4: manually create a feature project to install bundles and features I 
> need.
> 
> Currently, I use:
> - "Way 4" to install globally-used dependencies (Apache common libraries, 
> jdbc, etc).
> - "Way 3" to install dependencies of a module that I might want to share with 
> other modules
> - "Way 2" to install private dependencies that I don't want to share with 
> other modules
> 
> I don't know if I am missing anything but this is a lot of work and 
> error-prone, anyone know a better way to do this? Something more automatic, 
> less manual, less typing.
> 
> Thank you,
> 
> Kile

Re: Karaf 4.3.2: Cannot connect to debugger

[Jean-Baptiste Onofre]

Hi Richard,

No, it has not been reported yet. Let me try to plug my IntelliJ as remote 
debugger.

If it fails as well, I will create a Jira to fix that for 4.3.3 (I planned to 
submit 4.3.3 release to vote during the week end, but worth to wait couple of 
more days to fix that).

I will keep you posted in few minutes.

Regards
JB

> Le 13 août 2021 à 15:11, Richard Hierlmeier  a 
> écrit :
> 
> 
> Today I upgraded my Karaf instance on my Laptop from 4.3.1 to 4.3.2.
> After the upgrade I could no longer connect with debugger to this instance (I 
> used Eclipse with hostname localhost and debug port 5005).
> 
> I had to change in karaf.bat the variable:
> 
> set 
> DEFAULT_JAVA_DEBUG_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=127.0.0.1:5005
>  
> 
> The original value is 
> 
> set 
> DEFAULT_JAVA_DEBUG_OPTS=-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
> 
> In Karaf 4.3.1 it is working with the same JDK.
> 
> Is this a known problem?
> 
> 
> Regards
> 
>   Richard
> 
> 

Re: Artifacts from company private maven repository

[Jean-Baptiste Onofre]

Hi Lukasz,

1. I guess it works with you set credentials on the repo URL in 
org.ops4j.pax.url.mvn.repositories (http://foo:bar@url )
2. If the user who runs Karaf has .m2/settings.xml, it should be taken. Else 
you have to define the location of settings.xml via 
org.ops4j.pax.url.mvn.settings
3. Do you have a  part for the repository in your settings.xml ?

Regarding the mailing list, can you try user-subscr...@karaf.apache.org 
 ? You will receive and email to 
confirm you are subscribed or not.

Regards
JB

> Le 19 juil. 2021 à 10:29, Lukasz Lech  a écrit :
> 
> Hello,
>  
> I have problem getting artifacts from private company maven repository.
>  
> The repository and the credentials are defined in my settings.xml, and maven 
> command is definitely picking them. However, it seems that karaf is not.
>  
> If I don't define the repository in org.ops4j.pax.url.mvn.cfg, I see a stack 
> trace that Karaf checks default repositories, but not those defined in 
> settings.xml.
>  
> If I add our repository to the org.ops4j.pax.url.mvn.cfg : 
> org.ops4j.pax.url.mvn.repositories it says: Not authorized, as if Karaf was 
> failing to pull credentials from settings.xml correctly.
>  
> Most of artifacts needed are in 2nd private repository, that requires no 
> auth, and it was configured for Karaf, but some artifacts are not there (from 
> the other part of the organization) and can be available only from repository 
> that requires credentials, so I have a problem if I do a clean start 
> (deleting local repository).
>  
> How to configure karaf so that it pulls credentials correctly? Is it a bug? 
> I'm using 4.2.8
>  
> P.S. I'm sorry if I won't be able to give any fallback, but I'm not able to 
> respond to the topics using Nabble. I can do posts by sending mail to 
> user@karaf.apache.org , but I'm unable to 
> respond, since I get no email from the group to my email account. I've 
> already asked about that issue, but without efford. So most likely I'm able 
> only to post new issues.
>  
> Best regards,
> Lukasz Lech

Re: Camel routeTemplate

[Jean-Baptiste Onofre]

Hi Mathias,

Is it what you are looking for: 
https://github.com/apache/karaf/tree/main/examples/karaf-camel-example/karaf-camel-example-blueprint
 

 ?

Regards
JB

> Le 6 juil. 2021 à 21:57, Matthias Leinweber  a 
> écrit :
> 
>  Hello,
> 
> i am trying to use routeTemplates within karaf with DSL but i  don't find any 
> examples how to create routes with XML DSL. Also 
> https://camel.apache.org/manual/latest/route-template.html#_creating_routes_from_properties_file
>  
> 
>  seems not wo work in karaf.
> 
> Any suggestions?
> 
> br,
> Matthias
> 

Re: Shutdown issue ActiveMq

[Jean-Baptiste Onofre]

It should be fine if your feature installed pax-jms config has prerequisite.

Can you share snippet of your feature referencing activemq-broker ?

Regards
JB

> Le 2 juil. 2021 à 14:21, Jörg Jansen  a 
> écrit :
> 
> It's installed as a prerequisite feature (which is referenced by my 
> customized boot feature). 
> 
> Regards,
> Joerg
> 
> -Original Message-
> From: Jean-Baptiste Onofre  
> Sent: Freitag, 2. Juli 2021 14:07
> To: user@karaf.apache.org
> Subject: Re: Shutdown issue ActiveMq
> 
> Ah the broker is installed as a feature in Karaf ? I thought your broker was 
> outside of Karaf (standalone).
> 
> Does activemq-broker feature installed as boot feature ? Or do you install 
> after startup using feature:install ?
> 
> Regards
> JB
> 
>> Le 2 juil. 2021 à 11:14, Jörg Jansen  a 
>> écrit :
>> 
>> Hi JB,
>> 
>> I'm using the AUTO ack, but switching to CLIENT doesn't make any difference. 
>> How can I change the AMQ pool?
>> From my understanding it should be the preferred way to use pooledjms.
>> 
>> This behavior sounds to me, that it may be be a ordering problem in my 
>> assembly. 
>> The broker should be shutdown after all cliens. 
>> 
>> Regards,
>> Joerg
>> 
>> -Original Message-
>> From: Jean-Baptiste Onofre 
>> Sent: Freitag, 2. Juli 2021 09:52
>> To: user 
>> Subject: Re: Shutdown issue ActiveMq
>> 
>> Hi,
>> 
>> Did you try with another kind of pooler ? Like "native" ActiveMQ pool 
>> instead of wrapped pooledjms ?
>> 
>> What kind of ack do you use in your Camel route ? AUTO (default) or CLIENT ?
>> 
>> Regards
>> JB
>> 
>>> Le 2 juil. 2021 à 08:05, Jörg Jansen  a 
>>> écrit :
>>> 
>>> Hi everybody,
>>> 
>>> I'm facing a problem with our JMS connection, when shutting down the karaf 
>>> container. 
>>> The JMS connectionFactory is provided/configured via ops4j-jms.
>>> When shutting down karaf, I receive the message: "Caught exception trying 
>>> rollback() when putting session back into the pool, will invalidate. 
>>> javax.jms.IllegalStateException: The Session is closed".
>>> 
>>> Does anybody have an idea how to fix it? 
>>> Seaching for a workaround brings up to set the idleTimeout to 0, but this 
>>> has no effect. 
>>> 
>>> The currently used versions are: 
>>> Karaf: 4.3.2
>>> ActiveMq: 5.16.0
>>> Camel: 3.7.4
>>> 
>>> Any help would be really appreciated.
>>> 
>>> Additional details are available below.
>>> 
>>> Thanks in advance,
>>> Joerg
>>> 
>>> 
>>> 
>>> Stacktrace
>>> 
>>> 2021-07-02T07:46:30,260 | WARN  | Camel (gs-os-connector) thread #22 - 
>>> JmsConsumer[AMQ.GSLISA.OS.BUFFERED-SPX] | JmsPoolSession   
>>> | 213 - org.messaginghub.pooled.jms - 1.2.1 | Caught exception trying 
>>> rollback() when putting session back into the pool, will invalidate. 
>>> javax.jms.IllegalStateException: The Session is closed
>>> javax.jms.IllegalStateException: The Session is closed
>>> at 
>>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:772) 
>>> ~[?:?]
>>> at 
>>> org.apache.activemq.ActiveMQSession.rollback(ActiveMQSession.java:597) 
>>> ~[?:?]
>>> at 
>>> org.messaginghub.pooled.jms.JmsPoolSession.close(JmsPoolSession.java:112) 
>>> [!/:?]
>>> at 
>>> org.springframework.jms.support.JmsUtils.closeSession(JmsUtils.java:109) 
>>> [!/:?]
>>> at 
>>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.clearResources(DefaultMessageListenerContainer.java:1289)
>>>  [!/:?]
>>> at 
>>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1135)
>>>  [!/:?]
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
>>> [?:?]
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
>>> [?:?]
>>> at java.lang.Thread.run(Unknown Source) [?:?]
>>> 
>>> 
>>> 
>>> Feature config
>>> *

Re: Shutdown issue ActiveMq

[Jean-Baptiste Onofre]

Ah the broker is installed as a feature in Karaf ? I thought your broker was 
outside of Karaf (standalone).

Does activemq-broker feature installed as boot feature ? Or do you install 
after startup using feature:install ?

Regards
JB

> Le 2 juil. 2021 à 11:14, Jörg Jansen  a 
> écrit :
> 
> Hi JB, 
> 
> I'm using the AUTO ack, but switching to CLIENT doesn't make any difference. 
> How can I change the AMQ pool?
> From my understanding it should be the preferred way to use pooledjms.
> 
> This behavior sounds to me, that it may be be a ordering problem in my 
> assembly. 
> The broker should be shutdown after all cliens. 
> 
> Regards,
> Joerg
> 
> -Original Message-
> From: Jean-Baptiste Onofre  
> Sent: Freitag, 2. Juli 2021 09:52
> To: user 
> Subject: Re: Shutdown issue ActiveMq
> 
> Hi,
> 
> Did you try with another kind of pooler ? Like "native" ActiveMQ pool instead 
> of wrapped pooledjms ?
> 
> What kind of ack do you use in your Camel route ? AUTO (default) or CLIENT ?
> 
> Regards
> JB
> 
>> Le 2 juil. 2021 à 08:05, Jörg Jansen  a 
>> écrit :
>> 
>> Hi everybody,
>> 
>> I'm facing a problem with our JMS connection, when shutting down the karaf 
>> container. 
>> The JMS connectionFactory is provided/configured via ops4j-jms.
>> When shutting down karaf, I receive the message: "Caught exception trying 
>> rollback() when putting session back into the pool, will invalidate. 
>> javax.jms.IllegalStateException: The Session is closed".
>> 
>> Does anybody have an idea how to fix it? 
>> Seaching for a workaround brings up to set the idleTimeout to 0, but this 
>> has no effect. 
>> 
>> The currently used versions are: 
>> Karaf: 4.3.2
>> ActiveMq: 5.16.0
>> Camel: 3.7.4
>> 
>> Any help would be really appreciated.
>> 
>> Additional details are available below.
>> 
>> Thanks in advance,
>> Joerg
>> 
>> 
>> 
>> Stacktrace
>> 
>> 2021-07-02T07:46:30,260 | WARN  | Camel (gs-os-connector) thread #22 - 
>> JmsConsumer[AMQ.GSLISA.OS.BUFFERED-SPX] | JmsPoolSession   | 
>> 213 - org.messaginghub.pooled.jms - 1.2.1 | Caught exception trying 
>> rollback() when putting session back into the pool, will invalidate. 
>> javax.jms.IllegalStateException: The Session is closed
>> javax.jms.IllegalStateException: The Session is closed
>>  at 
>> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:772) 
>> ~[?:?]
>>  at 
>> org.apache.activemq.ActiveMQSession.rollback(ActiveMQSession.java:597) ~[?:?]
>>  at 
>> org.messaginghub.pooled.jms.JmsPoolSession.close(JmsPoolSession.java:112) 
>> [!/:?]
>>  at 
>> org.springframework.jms.support.JmsUtils.closeSession(JmsUtils.java:109) 
>> [!/:?]
>>  at 
>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.clearResources(DefaultMessageListenerContainer.java:1289)
>>  [!/:?]
>>  at 
>> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1135)
>>  [!/:?]
>>  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
>> [?:?]
>>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
>> [?:?]
>>  at java.lang.Thread.run(Unknown Source) [?:?]
>> 
>> 
>> 
>> Feature config
>> 
>> > description="Provide JMS connection factory and ActiveMqBroker" >  
>> jms  spring  
>> activemq-broker-noweb
>> activemq-client
>> > version="${ops4j.pax.jms.version}">pax-jms-pool-pooledjms
>> > version="${ops4j.pax.jms.version}">pax-jms-activemq
>> camel-jms
>> 
>> 
>>   name = lisa-amq
>>   osgi.jndi.service.name = jms/lisa-amq
>>   password = ${activemq.jms.password}
>>   connectionFactoryType = ConnectionFactory
>>   type = activemq
>>   url = ${activemq.url}
>>   user = ${activemq.jms.user}
>> 
>>   # hints for pax-jms-config to use selected 
>> org.ops4j.pax.jms.service.PooledConnectionFactoryFactory
>>   pool = pooledjms
>>   xa = false
>> 
>>   # pooled-jms specific configuration of 
>> org.messaginghub.pooled.jms.JmsPoolConnectionFactory
>>   pool.idleTimeout = 10
>>   pool.maxConnections = 10
>>   pool.blockIfSessionPoolIsFull = true
>>   pax.jms.managed = true
>> 
>> 
>> 
>> 
> 

Re: Shutdown issue ActiveMq

[Jean-Baptiste Onofre]

Hi,

Did you try with another kind of pooler ? Like "native" ActiveMQ pool instead 
of wrapped pooledjms ?

What kind of ack do you use in your Camel route ? AUTO (default) or CLIENT ?

Regards
JB

> Le 2 juil. 2021 à 08:05, Jörg Jansen  a 
> écrit :
> 
> Hi everybody,
> 
> I'm facing a problem with our JMS connection, when shutting down the karaf 
> container. 
> The JMS connectionFactory is provided/configured via ops4j-jms.
> When shutting down karaf, I receive the message: "Caught exception trying 
> rollback() when putting session back into the pool, will invalidate. 
> javax.jms.IllegalStateException: The Session is closed".
> 
> Does anybody have an idea how to fix it? 
> Seaching for a workaround brings up to set the idleTimeout to 0, but this has 
> no effect. 
> 
> The currently used versions are: 
> Karaf: 4.3.2
> ActiveMq: 5.16.0
> Camel: 3.7.4
> 
> Any help would be really appreciated.
> 
> Additional details are available below.
> 
> Thanks in advance,
> Joerg
> 
> 
> 
> Stacktrace
> 
> 2021-07-02T07:46:30,260 | WARN  | Camel (gs-os-connector) thread #22 - 
> JmsConsumer[AMQ.GSLISA.OS.BUFFERED-SPX] | JmsPoolSession   | 
> 213 - org.messaginghub.pooled.jms - 1.2.1 | Caught exception trying 
> rollback() when putting session back into the pool, will invalidate. 
> javax.jms.IllegalStateException: The Session is closed
> javax.jms.IllegalStateException: The Session is closed
>   at 
> org.apache.activemq.ActiveMQSession.checkClosed(ActiveMQSession.java:772) 
> ~[?:?]
>   at 
> org.apache.activemq.ActiveMQSession.rollback(ActiveMQSession.java:597) ~[?:?]
>   at 
> org.messaginghub.pooled.jms.JmsPoolSession.close(JmsPoolSession.java:112) 
> [!/:?]
>   at 
> org.springframework.jms.support.JmsUtils.closeSession(JmsUtils.java:109) 
> [!/:?]
>   at 
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.clearResources(DefaultMessageListenerContainer.java:1289)
>  [!/:?]
>   at 
> org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1135)
>  [!/:?]
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
> [?:?]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> [?:?]
>   at java.lang.Thread.run(Unknown Source) [?:?]
> 
> 
> 
> Feature config
> 
>  description="Provide JMS connection factory and ActiveMqBroker" >
>  jms
>  spring
>  activemq-broker-noweb
>  activemq-client
>  pax-jms-pool-pooledjms
>  pax-jms-activemq
>  camel-jms
> 
>  
>name = lisa-amq
>osgi.jndi.service.name = jms/lisa-amq
>password = ${activemq.jms.password}
>connectionFactoryType = ConnectionFactory
>type = activemq
>url = ${activemq.url}
>user = ${activemq.jms.user}
> 
># hints for pax-jms-config to use selected 
> org.ops4j.pax.jms.service.PooledConnectionFactoryFactory
>pool = pooledjms
>xa = false
> 
># pooled-jms specific configuration of 
> org.messaginghub.pooled.jms.JmsPoolConnectionFactory
>pool.idleTimeout = 10
>pool.maxConnections = 10
>pool.blockIfSessionPoolIsFull = true
>pax.jms.managed = true
>  
> 
> 
> 

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: SSH session not properly closed by Karaf

[Jean-Baptiste Onofre]

Thanks to you !

I will work on release preparation/Jira.

Regards
JB

> Le 29 juin 2021 à 10:32, DUTERTRY Nicolas  a 
> écrit :
> 
> https://issues.apache.org/jira/browse/KARAF-7190 
> <https://issues.apache.org/jira/browse/KARAF-7190>
>  
> Thanks JB !
> --
> Nicolas Dutertry
>  
>  
> C2 – Usage restreint
> De : Jean-Baptiste Onofre  
> Envoyé : mardi 29 juin 2021 10:17
> À : user 
> Objet : Re: SSH session not properly closed by Karaf
>  
> Oh, really. Then, I think I know the issue: it’s probably the SSHD stream 
> handler.
>  
> Can you please create a Jira about that ? I will fix that for 4.3.3/4.2.12.
>  
> Thanks !
>  
> Regards
> JB
>  
> 
> Le 29 juin 2021 à 10:14, DUTERTRY Nicolas  <mailto:nicolas.duter...@soprahr.com>> a écrit :
>  
> No, the issue is the same.
>  
> --
> Nicolas Dutertry
>  
>  
> C2 – Usage restreint
> De : Jean-Baptiste Onofre mailto:j...@nanthrax.net>> 
> Envoyé : mardi 29 juin 2021 09:53
> À : user mailto:user@karaf.apache.org>>
> Objet : Re: SSH session not properly closed by Karaf
>  
> Hi,
>  
> I guess the connexion is cleanly closed when you do:
>  
> $ bin/client
> And then CTRL-D 
>  
> Right ?
>  
> Regards
> JB
>  
> 
> Le 29 juin 2021 à 09:36, DUTERTRY Nicolas  <mailto:nicolas.duter...@soprahr.com>> a écrit :
>  
> Hi,
>  
> After using « client » script, the tcp socket is not closed by karaf (4.3.2) 
> and remains in CLOSE_WAIT state. The session is only closed after ssh timeout 
> is reached.
>  
> For instance with a SSH timeout set to 30 s :
>  
> $ ./client “bundle:list”
>  
> $ netstat | grep 8101
> tcp6   0  0 localhost:8101  localhost:47844 CLOSE_WAIT
>  
> $ tail karaf.log
> INFO  | sshd-SshServer[2f716f77](port=8101)-nio2-thread-1 | ServerSessionImpl 
>| 46 - org.apache.sshd.osgi - 2.5.1 | Session 
> karaf@/127.0.0.1:47844 <mailto:karaf@/127.0.0.1:47844> authenticated
> INFO  | sshd-SshServer[2f716f77](port=8101)-timer-thread-1 | 
> ServerSessionImpl| 46 - org.apache.sshd.osgi - 2.5.1 | 
> Disconnecting(ServerSessionImpl[karaf@/127.0.0.1:47844]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Detected IdleTimeout after 30415/3 ms.
>  
> Do you have a fix for this issue ?
>  
> Regards,
> --
> Nicolas Dutertry
> Sopra HR Software - http://www.soprahr.com/ 
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.soprahr.com%2F=04%7C01%7CNicolas.Dutertry%40soprahr.com%7C9e854f8f41d946def40c08d93ad64673%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C637605514297762233%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=BU%2FJ%2BAilM22esUc007gSQq2leVNf62zfanofYtOTyvc%3D=0>
>  
>  
> C2 – Usage restreint

Re: SSH session not properly closed by Karaf

[Jean-Baptiste Onofre]

Oh, really. Then, I think I know the issue: it’s probably the SSHD stream 
handler.

Can you please create a Jira about that ? I will fix that for 4.3.3/4.2.12.

Thanks !

Regards
JB

> Le 29 juin 2021 à 10:14, DUTERTRY Nicolas  a 
> écrit :
> 
> No, the issue is the same.
>  
> --
> Nicolas Dutertry
>  
>  
> C2 – Usage restreint
> De : Jean-Baptiste Onofre  
> Envoyé : mardi 29 juin 2021 09:53
> À : user 
> Objet : Re: SSH session not properly closed by Karaf
>  
> Hi,
>  
> I guess the connexion is cleanly closed when you do:
>  
> $ bin/client
> And then CTRL-D 
>  
> Right ?
>  
> Regards
> JB
>  
> 
> Le 29 juin 2021 à 09:36, DUTERTRY Nicolas  <mailto:nicolas.duter...@soprahr.com>> a écrit :
>  
> Hi,
>  
> After using « client » script, the tcp socket is not closed by karaf (4.3.2) 
> and remains in CLOSE_WAIT state. The session is only closed after ssh timeout 
> is reached.
>  
> For instance with a SSH timeout set to 30 s :
>  
> $ ./client “bundle:list”
>  
> $ netstat | grep 8101
> tcp6   0  0 localhost:8101  localhost:47844 CLOSE_WAIT
>  
> $ tail karaf.log
> INFO  | sshd-SshServer[2f716f77](port=8101)-nio2-thread-1 | ServerSessionImpl 
>| 46 - org.apache.sshd.osgi - 2.5.1 | Session 
> karaf@/127.0.0.1:47844 <mailto:karaf@/127.0.0.1:47844> authenticated
> INFO  | sshd-SshServer[2f716f77](port=8101)-timer-thread-1 | 
> ServerSessionImpl| 46 - org.apache.sshd.osgi - 2.5.1 | 
> Disconnecting(ServerSessionImpl[karaf@/127.0.0.1:47844]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Detected IdleTimeout after 30415/3 ms.
>  
> Do you have a fix for this issue ?
>  
> Regards,
> --
> Nicolas Dutertry
> Sopra HR Software - http://www.soprahr.com/ 
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.soprahr.com%2F=04%7C01%7CNicolas.Dutertry%40soprahr.com%7C7713128dbc2a4140e2d908d93ad2e8fb%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C637605500396813837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=TAwbcmU%2BBeC6i562OVXe3kyooDE5T9215gSfmR2g7r0%3D=0>
>  
>  
> C2 – Usage restreint

Re: SSH session not properly closed by Karaf

[Jean-Baptiste Onofre]

Hi,

I guess the connexion is cleanly closed when you do:

$ bin/client
And then CTRL-D 

Right ?

Regards
JB

> Le 29 juin 2021 à 09:36, DUTERTRY Nicolas  a 
> écrit :
> 
> Hi,
>  
> After using « client » script, the tcp socket is not closed by karaf (4.3.2) 
> and remains in CLOSE_WAIT state. The session is only closed after ssh timeout 
> is reached.
>  
> For instance with a SSH timeout set to 30 s :
>  
> $ ./client “bundle:list”
>  
> $ netstat | grep 8101
> tcp6   0  0 localhost:8101  localhost:47844 CLOSE_WAIT
>  
> $ tail karaf.log
> INFO  | sshd-SshServer[2f716f77](port=8101)-nio2-thread-1 | ServerSessionImpl 
>| 46 - org.apache.sshd.osgi - 2.5.1 | Session 
> karaf@/127.0.0.1:47844 authenticated
> INFO  | sshd-SshServer[2f716f77](port=8101)-timer-thread-1 | 
> ServerSessionImpl| 46 - org.apache.sshd.osgi - 2.5.1 | 
> Disconnecting(ServerSessionImpl[karaf@/127.0.0.1:47844]): 
> SSH2_DISCONNECT_PROTOCOL_ERROR - Detected IdleTimeout after 30415/3 ms.
>  
> Do you have a fix for this issue ?
>  
> Regards,
> --
> Nicolas Dutertry
> Sopra HR Software - http://www.soprahr.com/ 
>  
> 
> C2 – Usage restreint

Re: Strange NoClassDefFoundError in VaadinServletService

[Jean-Baptiste Onofre]

Hi,

Not yet, just "back in the business" after most of the relocation (still in the 
middle of the boxes).

I will check later tonight or tomorrow.

By the way, are you on Slack if I have questions or so ?

Regards
JB

> Le 28 juin 2021 à 16:03, Richard Hierlmeier  a 
> écrit :
> 
> Hi JB,
> 
> any news from this issue?
> 
> Richard
> 
> Am Mo., 21. Juni 2021 um 08:26 Uhr schrieb Richard Hierlmeier 
> mailto:rhierlme...@googlemail.com>>:
> Hi JB,
> 
> no problem. I am preparing the instance in the cloud. 
> I will send you the connection details in a private message.
> 
> Thank you
> 
>   Richard
> 
> Am Mo., 21. Juni 2021 um 07:58 Uhr schrieb JB Onofré  <mailto:j...@nanthrax.net>>:
> Hi Richard
> 
> I don’t have time before Wednesday this week (off today and tomorrow for 
> relocation). 
> 
> I will try to take a look on Wednesday. 
> 
> Regards 
> JB
> 
>> Le 21 juin 2021 à 07:53, Richard Hierlmeier > <mailto:rhierlme...@googlemail.com>> a écrit :
>> 
>> 
>> I upgraded meanwhile to Karaf 4.3.2, but the problem is still present.
>> 
>> vaadin-server bundle has no dynamic imports. I can see the import in the 
>> vaadin-server bundle:
>> 
>> karaf@root()> la -u | grep vaadin-server
>> 148 | Active   |  80 | 8.13.0  | 
>> mvn:com.vaadin/vaadin-server/8.13.0
>> 
>> karaf@root()> headers 148
>> ...
>> Import-Package =
>> ...
>> org.atmosphere.cpr;resolution:=optional;version=2.4.30.vaadin3,
>> ...
>> 
>> I have the following feature dependencies:
>> vaadin<- ONE <- TWO
>> 
>> karaf@root()> shutdown
>> > bin/karaf.bat clean
>> kara@root()> feature:repo-add ...
>> karaf@root()> feature:install TWO
>> 
>> > grep vaadin-server data/log/karaf.log
>> 2021-06-21T07:23:43,335 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 18 - org.apache.karaf.features.core - 4.3.2 |   
>> mvn:com.vaadin/vaadin-server/8.13.0
>> 2021-06-21T07:23:44,075 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 18 - org.apache.karaf.features.core - 4.3.2 |   
>> mvn:com.vaadin/vaadin-server/8.13.0
>> 
>> In this constellation I get now the NoClassDefFoundError when accessing the 
>> Vaadin UI.
>> 
>> karaf@root()> shutdown
>> > bin/karaf.bat clean
>> karaf@root()> feature:repo-add ...
>> karaf@root()> feature:install ONE
>> 
>> > grep vaadin-server data/log/karaf.log 
>> 2021-06-21T07:28:53,691 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 18 - org.apache.karaf.features.core - 4.3.2 |   
>> mvn:com.vaadin/vaadin-server/8.13.0
>> 2021-06-21T07:28:54,230 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 18 - org.apache.karaf.features.core - 4.3.2 |   
>> mvn:com.vaadin/vaadin-server/8.13.0
>> 
>> Now I can access the Vaadin UI.
>> 
>> kara@root()>  feature:install TWO
>> 
>> Vaadin UI is still working.
>> 
>> Are you interested in analyzing this problem? I can provide an instance in a 
>> public cloud.
>> 
>> Regards
>> 
>>   Richard
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Am Sa., 19. Juni 2021 um 06:39 Uhr schrieb Jean-Baptiste Onofre 
>> mailto:j...@nanthrax.net>>:
>> Hi Richard,
>> 
>> Did you see a refresh when you install feature TWO ?
>> 
>> Do you see org.atmosphere.cpr import in vaadin server bundle or is it a 
>> dynamic import ?
>> 
>> Regards
>> JB
>> 
>>> Le 18 juin 2021 à 18:21, Richard Hierlmeier >> <mailto:rhierlme...@googlemail.com>> a écrit :
>>> 
>>> 
>>> I have a strange error in a Vaadin application running in Karaf 4.3.1. I 
>>> have two features, that use Vaadin. Feature ONE works fine. When feature 
>>> TWO is deployed I get the following error when accessing the Vaadin UI: 
>>> 
>>> java.lang.NoClassDefFoundError: org/atmosphere/cpr/AtmosphereHandler
>>> at 
>>> com.vaadin.server.VaadinServletService.createRequestHandlers(VaadinServletService.java:68)
>>> at com.vaadin.server.VaadinService.init(VaadinService.java:219)
>>> at 
>>> com.vaadin.server.VaadinServlet.createServletService(VaadinServlet.java:380)
>>> at com.vaadin.server.VaadinServlet.init(VaadinServlet.java:210)
>>> at de.hierlmeier.karaf.vaadinsample.UIServlet.init(UIServlet.java:44)
>>> at 
>

Re: Doc of environment variables to modify docker images?

[Jean-Baptiste Onofre]

Do you mean you have a race condition ?

Regards
JB

> Le 20 juin 2021 à 18:11, Jean-Baptiste Onofre  a écrit :
> 
> Just tested with Karaf 4.3.2:
> 
> $ export 
> ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES="foo,mvn:no.priv.bang.sonar.sonar-collector/sonar-collector-webhook/LATEST/xml/features"
> $ bin/karaf
> karaf@root()> config:list "(service.pid=org.apache.karaf.features)"
> 
> Pid:org.apache.karaf.features
> BundleLocation: ?
> Properties:
>   featuresBoot = instance/4.3.2, package/4.3.2, log/4.3.2, ssh/4.3.2, 
> framework/4.3.2, system/4.3.2, eventadmin/4.3.2, feature/4.3.2, shell/4.3.2, 
> management/4.3.2, service/4.3.2, jaas/4.3.2, deployer/4.3.2, 
> diagnostic/4.3.2, wrap/2.6.7, bundle/4.3.2, config/4.3.2, kar/4.3.2
>   featuresBootAsynchronous = false
>   featuresRepositories = 
> foo,mvn:no.priv.bang.sonar.sonar-collector/sonar-collector-webhook/LATEST/xml/features
>   felix.fileinstall.filename = 
> file:/Users/jbonofre/Downloads/apache-karaf-4.3.2/etc/org.apache.karaf.features.cfg
>   service.pid = org.apache.karaf.features
> 
> So, you can see the featuresRepositories contains the env variable value.
> 
> Regards
> JB
> 
>> Le 20 juin 2021 à 18:02, Steinar Bang  a écrit :
>> 
>>>>>>> Steinar Bang :
>> 
>>> The apache/karaf:4.3.0 and apache/karaf:4.3.1 images both start fine in
>>> docker on my dev machine.
>> 
>>> I will try to build my image on top of 4.3.0 (I can't remember offhand
>>> why I couldn't run on 4.3.1...?).  
>> 
>>> Possible complication here is that I have bumbed the karaf BoM to 4.3.2,
>>> so I have built against something that is newer than the runtime...?
>> 
>> This is with an image based on top of apache/karaf:4.3.0
>> 
>> From the output of "docker logs"
>> https://gist.github.com/steinarb/d38767d99831e2816bc9d0a27d5a70ff
>> it looks like the feature repository and boot features I tried to add in
>> the Dockerfile weren't added:
>> https://gist.github.com/steinarb/65225c3a491c0b08a4386778f4c84100
>> 
>> Are my environment variables and their content incorrect?
>> 
> 

Re: Doc of environment variables to modify docker images?

[Jean-Baptiste Onofre]

Just tested with Karaf 4.3.2:

$ export 
ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES="foo,mvn:no.priv.bang.sonar.sonar-collector/sonar-collector-webhook/LATEST/xml/features"
$ bin/karaf
karaf@root()> config:list "(service.pid=org.apache.karaf.features)"

Pid:org.apache.karaf.features
BundleLocation: ?
Properties:
   featuresBoot = instance/4.3.2, package/4.3.2, log/4.3.2, ssh/4.3.2, 
framework/4.3.2, system/4.3.2, eventadmin/4.3.2, feature/4.3.2, shell/4.3.2, 
management/4.3.2, service/4.3.2, jaas/4.3.2, deployer/4.3.2, diagnostic/4.3.2, 
wrap/2.6.7, bundle/4.3.2, config/4.3.2, kar/4.3.2
   featuresBootAsynchronous = false
   featuresRepositories = 
foo,mvn:no.priv.bang.sonar.sonar-collector/sonar-collector-webhook/LATEST/xml/features
   felix.fileinstall.filename = 
file:/Users/jbonofre/Downloads/apache-karaf-4.3.2/etc/org.apache.karaf.features.cfg
   service.pid = org.apache.karaf.features

So, you can see the featuresRepositories contains the env variable value.

Regards
JB

> Le 20 juin 2021 à 18:02, Steinar Bang  a écrit :
> 
>> Steinar Bang :
> 
>> The apache/karaf:4.3.0 and apache/karaf:4.3.1 images both start fine in
>> docker on my dev machine.
> 
>> I will try to build my image on top of 4.3.0 (I can't remember offhand
>> why I couldn't run on 4.3.1...?).  
> 
>> Possible complication here is that I have bumbed the karaf BoM to 4.3.2,
>> so I have built against something that is newer than the runtime...?
> 
> This is with an image based on top of apache/karaf:4.3.0
> 
> From the output of "docker logs"
> https://gist.github.com/steinarb/d38767d99831e2816bc9d0a27d5a70ff
> it looks like the feature repository and boot features I tried to add in
> the Dockerfile weren't added:
> https://gist.github.com/steinarb/65225c3a491c0b08a4386778f4c84100
> 
> Are my environment variables and their content incorrect?
> 

Re: Doc of environment variables to modify docker images?

[Jean-Baptiste Onofre]

Hi Steinar,

With Karaf 4.3.x, you can now use "implicit" env variable.

It’s documented here:

http://karaf.apache.org/manual/latest/#_environment_variables_system_properties 


It means you can set features repositories with:

export 
ORG_APACHE_KARAF_FEATURES_FEATURESREPOSITORIES='${featuresRepositories},mvn:org.apache.karaf.decanter/apache-karaf-decanter/2.5.0/xml/features'

For instance

Regards
JB

> Le 19 juin 2021 à 12:07, Steinar Bang  a écrit :
> 
> I'm in the process of moving my karaf based docker images from karaf
> 4.2.8 to karaf 4.3.2.
> 
> I'm trying to find the enviroment variables that will let me add maven
> repositories, feature repositories and boot features, without copying
> the files from the distro and modifying them.
> 
> But I haven't been able to google up these variables.
> 
> Is there a list of these variables somewhere?
> 
> (I thought they might be implemented by using ${env:xxx} in the .cfg
> files, but there aren't any usage of "env:" in the etc directory of
> karaf 4.3.2)
> 
> Thanks!
> 
> 
> - Steinar
> 

Re: Strange NoClassDefFoundError in VaadinServletService

[Jean-Baptiste Onofre]

Hi Richard,

Did you see a refresh when you install feature TWO ?

Do you see org.atmosphere.cpr import in vaadin server bundle or is it a dynamic 
import ?

Regards
JB

> Le 18 juin 2021 à 18:21, Richard Hierlmeier  a 
> écrit :
> 
> 
> I have a strange error in a Vaadin application running in Karaf 4.3.1. I have 
> two features, that use Vaadin. Feature ONE works fine. When feature TWO is 
> deployed I get the following error when accessing the Vaadin UI: 
> 
> java.lang.NoClassDefFoundError: org/atmosphere/cpr/AtmosphereHandler
> at 
> com.vaadin.server.VaadinServletService.createRequestHandlers(VaadinServletService.java:68)
> at com.vaadin.server.VaadinService.init(VaadinService.java:219)
> at 
> com.vaadin.server.VaadinServlet.createServletService(VaadinServlet.java:380)
> at com.vaadin.server.VaadinServlet.init(VaadinServlet.java:210)
> at de.hierlmeier.karaf.vaadinsample.UIServlet.init(UIServlet.java:44)
> at org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:624)
> at org.eclipse.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:478)
> at org.eclipse.jetty.servlet.ServletHolder.prepare(ServletHolder.java:751)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at 
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> ...
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: 
> org.atmosphere.cpr.AtmosphereHandler not found by com.vaadin.server [159]
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:78)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1950)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 39 more
> 
> I debugged the code down to the class  BundleWiringImpl and found out that 
> when feature TWO is deployed, then the package  org.atmosphere.cpr is no 
> longer in the m_importedPkgs Variable of BundleWiringImpl instance of bundle 
> 159.
> 
> However the Karaf console tells me that the import is available:
> 
> de@root()> imports -b 159 | grep org.atmosphere.cpr
> org.atmosphere.cpr| [2.4.30.vaadin3,) | resolved  
>  | 159 | com.vaadin.server
> 
> The bundle that exports org.atmosphere.cpr is also available:
> 
> de@root()> exports | grep org.atmosphere.cpr
> org.atmosphere.cpr
>  | 2.4.30.vaadin3  | 155 | 
> com.vaadin.external.atmosphere.runtime
> 
> 
> 
> Regards 
> 
>Richard
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: jdk.net requirement for mongodb driver >4.1

[Jean-Baptiste Onofre]

What JDK are you using ?

Regards
JB

> Le 18 juin 2021 à 09:57, Michal Hlavac  a écrit :
> 
> Hi,
> 
> I would like to ask how to solve this error in feature validation in 
> feature maven module.
> MongoDb driver from version 4.1 has dependency on jdk.net package and feature 
> validation says:
> Unable to resolve org.mongodb.driver-core/4.2.3: missing requirement 
> [org.mongodb.driver-core/4.2.3] osgi.wiring.package; 
> filter:="(osgi.wiring.package=jdk.net)"
> 
> I read previous post where you suggest to add this package to jre.properties, 
> but that does not solve problem with feature validation
> 
> thanks, m.
> 
> 

Re: kahadb-store for ActiveMQ on Karaf 4

[Jean-Baptiste Onofre]

If you embed the broker, you can also embed the packages, up to you.

Regards
JB

> Le 16 juin 2021 à 09:31, Richard Hierlmeier  a 
> écrit :
> 
> I found the problem in my application.
> 
> My application embedds ActiveMq via a class that extends the class 
> JmsBrokerService.
> The method JmsBrokerService#getTempDataStore() (see 
> https://github.com/apache/activemq/blob/main/activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java#L1751
>  
> <https://github.com/apache/activemq/blob/main/activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java#L1751>)
> loads the class org.apache.activemq.store.kahadb.plist.PListStoreImpl via 
> reflection over the class loader of concrete class. This leads in my case to 
> a ClassNotFoundException.
> I had to add a manual import to  org.apache.activemq.store.kahadb.plist to 
> this bundle.
> 
> Thank you for your help.
> 
>   Richard
> 
> Am Mi., 9. Juni 2021 um 19:03 Uhr schrieb Jean-Baptiste Onofre 
> mailto:j...@nanthrax.net>>:
> Activemq-kahadb-store is not a bundle. You should rather using activemq-osgi 
> which contain kahadb.
> 
> Regards
> JB
> 
> > Le 9 juin 2021 à 17:08, Richard Hierlmeier  > <mailto:rhierlme...@googlemail.com>> a écrit :
> > 
> > 
> > I have upgraded a Karaf 3 application to Karaf 4.3.2. This application 
> > needs the kahadb-store from ActiveMq.
> > It seems that this store is no longer supported. The  activemq-kahadb-store 
> > is no longer included into the ActiveMq features.
> > 
> > When installing the activemq-kahadb-store bundle manually I get the 
> > following error:
> > 
> > de@root()> bundle:install 
> > mvn:org.apache.activemq/activemq-kahadb-store/5.16.2
> > Bundle IDs:
> > Error executing command: Error installing bundles:
> > Unable to install bundle 
> > mvn:org.apache.activemq/activemq-kahadb-store/5.16.2: 
> > org.osgi.framework.BundleException: OSGi R3 bundle not supported
> > 
> > How can I solve this problem?
> > 
> > Regards 
> > 
> >   Richard
> 

Re: kahadb-store for ActiveMQ on Karaf 4

[Jean-Baptiste Onofre]

Activemq-kahadb-store is not a bundle. You should rather using activemq-osgi 
which contain kahadb.

Regards
JB

> Le 9 juin 2021 à 17:08, Richard Hierlmeier  a 
> écrit :
> 
> 
> I have upgraded a Karaf 3 application to Karaf 4.3.2. This application needs 
> the kahadb-store from ActiveMq.
> It seems that this store is no longer supported. The  activemq-kahadb-store 
> is no longer included into the ActiveMq features.
> 
> When installing the activemq-kahadb-store bundle manually I get the following 
> error:
> 
> de@root()> bundle:install mvn:org.apache.activemq/activemq-kahadb-store/5.16.2
> Bundle IDs:
> Error executing command: Error installing bundles:
> Unable to install bundle 
> mvn:org.apache.activemq/activemq-kahadb-store/5.16.2: 
> org.osgi.framework.BundleException: OSGi R3 bundle not supported
> 
> How can I solve this problem?
> 
> Regards 
> 
>   Richard

Re: new install

[Jean-Baptiste Onofre]

Hi,

Which JDK version are you using ?

Regards
JB

> Le 8 juin 2021 à 19:29, Chuck Davis  a écrit :
> 
> Just installed current version of Karaf.  Get the following error.  What to 
> do?
> 
> chuck@MyDesk:/sata2/Downloads/karaf/apache-karaf-4.3.2> ./bin/karaf 
> failed to access class 
> org.apache.felix.utils.properties.InterpolationHelper$BundleContextSubstitutionCallback
>  from class org.apache.k
> araf.util.config.PropertiesLoader 
> (org.apache.felix.utils.properties.InterpolationHelper$BundleContextSubstitutionCallback
>  and org.apa
> che.karaf.util.config.PropertiesLoader are in unnamed module of loader 'app') 
> Error occurred shutting down framework: java.lang.IllegalAccessError: failed 
> to access class org.apache.felix.utils.properties.Interpo
> lationHelper$BundleContextSubstitutionCallback from class 
> org.apache.karaf.util.config.PropertiesLoader (org.apache.felix.utils.proper
> ties.InterpolationHelper$BundleContextSubstitutionCallback and 
> org.apache.karaf.util.config.PropertiesLoader are in unnamed module of 
> loader 'app') 
> java.lang.IllegalAccessError: failed to access class 
> org.apache.felix.utils.properties.InterpolationHelper$BundleContextSubstitutionCa
> llback from class org.apache.karaf.util.config.PropertiesLoader 
> (org.apache.felix.utils.properties.InterpolationHelper$BundleContextSu
> bstitutionCallback and org.apache.karaf.util.config.PropertiesLoader are in 
> unnamed module of loader 'app') 
>at 
> org.apache.karaf.util.config.PropertiesLoader.loadSystemProperties(PropertiesLoader.java:114)
>  
>at 
> org.apache.karaf.main.ConfigProperties.(ConfigProperties.java:246) 
>at 
> org.apache.karaf.main.Main.updateInstancePidAfterShutdown(Main.java:232) 
>at org.apache.karaf.main.Main.main(Main.java:197)
> 
> 

Re: Decanter and JMX

[Jean-Baptiste Onofre]

Awesome ;)

Honestly, Decanter is a good metric/data collection framework ;)
My $0.01 ;)

Regards
JB

> Le 1 juin 2021 à 15:06, Steven Huypens  a écrit :
> 
> 
> Thanks, that's much better now :-)
> 
> Steven,
> 
> On Tue, Jun 1, 2021 at 1:51 PM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> By the way, you can see filter example on the Decanter documentation: 
> http://karaf.apache.org/manual/decanter/latest-2/html/#_jmx 
> <http://karaf.apache.org/manual/decanter/latest-2/html/#_jmx>
> 
> object.name.system=java.lang:*
> object.name.karaf=org.apache.karaf:type=http,name=*
> object.name.3=org.apache.activemq:*
> 
> Regards
> JB
> 
>> Le 1 juin 2021 à 12:50, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> Hi François,
>> 
>> Thanks, I will try that !
>> 
>> Best regards,
>> Steven
>> 
>> On Tue, Jun 1, 2021 at 11:22 AM Francois Papon > <mailto:francois.pa...@openobject.fr>> wrote:
>> Hi,
>> 
>> You can add a filter on MBean in the cfg file of your collector.
>> 
>> Here an example with Camel MBean only:
>> 
>> https://github.com/apache/karaf-decanter/blob/main/collector/jmx/src/main/cfg/org.apache.karaf.decanter.collector.jmx-camel.cfg
>>  
>> <https://github.com/apache/karaf-decanter/blob/main/collector/jmx/src/main/cfg/org.apache.karaf.decanter.collector.jmx-camel.cfg>
>> regards,
>> 
>> François
>> fpa...@apache.org <mailto:fpa...@apache.org>
>> Le 01/06/2021 à 11:07, Steven Huypens a écrit :
>>> Hi,
>>> 
>>> Enabling the JMX-collector leads to a very high CPU load in our 
>>> application, making it impossible to use. I'm not sure, but I think 
>>> especially the org.apache.karaf MBeans are expensive to harvest, maybe 
>>> because of the size of our application (>900 bundles).
>>> 
>>> It would be very useful if we could configure which MBeans we are 
>>> interested in.
>>> 
>>> Kind regards,
>>> Steven
>>> 
>>> 
>>> On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> wrote:
>>> Hi Daniel,
>>> 
>>> JMX collector polls all MBeans attributes. However Prometheus appender only 
>>> expose metrics (numeric) on the Prometheus servlet:
>>> 
>>> http://localhost:8181/decanter/prometheus 
>>> <http://localhost:8181/decanter/prometheus>
>>> 
>>> As the generated JMX JSON is "more" than just numeric, it’s possible that 
>>> you don’t have the metrics.
>>> 
>>> You can check the JMX JSON using another kind of appender (like log 
>>> appender or elasticsearch).
>>> I can add kind of "json introspection" on the Prometheus appender to 
>>> "force" some JSON fields as metrics (gauge).
>>> 
>>> Regards
>>> JB
>>> 
>>> > Le 2 mai 2021 à 22:24, Daniel Las >> > <mailto:daniel@empirica.io>> a écrit :
>>> > 
>>> > Hi,
>>> > 
>>> > I installed Decanter 2.7.0 on Karaf 4.2.11 with JMX collector and 
>>> > Prometheus appender features. I uncommented 
>>> > "object.name.system=java.lang:*" in 
>>> > org.apache.karaf.decanter.collector.jmx-local.cfg.
>>> > 
>>> > Where can I find JVM metrics like current heap memory usage? 
>>> > 
>>> > Regards
>>> > -- 
>>> > Daniel Łaś
>>> > 
>>> 
> 

Re: Decanter and JMX

[Jean-Baptiste Onofre]

By the way, you can see filter example on the Decanter documentation: 
http://karaf.apache.org/manual/decanter/latest-2/html/#_jmx 
<http://karaf.apache.org/manual/decanter/latest-2/html/#_jmx>

object.name.system=java.lang:*
object.name.karaf=org.apache.karaf:type=http,name=*
object.name.3=org.apache.activemq:*

Regards
JB

> Le 1 juin 2021 à 12:50, Steven Huypens  a écrit :
> 
> Hi François,
> 
> Thanks, I will try that !
> 
> Best regards,
> Steven
> 
> On Tue, Jun 1, 2021 at 11:22 AM Francois Papon  <mailto:francois.pa...@openobject.fr>> wrote:
> Hi,
> 
> You can add a filter on MBean in the cfg file of your collector.
> 
> Here an example with Camel MBean only:
> 
> https://github.com/apache/karaf-decanter/blob/main/collector/jmx/src/main/cfg/org.apache.karaf.decanter.collector.jmx-camel.cfg
>  
> <https://github.com/apache/karaf-decanter/blob/main/collector/jmx/src/main/cfg/org.apache.karaf.decanter.collector.jmx-camel.cfg>
> regards,
> 
> François
> fpa...@apache.org <mailto:fpa...@apache.org>
> Le 01/06/2021 à 11:07, Steven Huypens a écrit :
>> Hi,
>> 
>> Enabling the JMX-collector leads to a very high CPU load in our application, 
>> making it impossible to use. I'm not sure, but I think especially the 
>> org.apache.karaf MBeans are expensive to harvest, maybe because of the size 
>> of our application (>900 bundles).
>> 
>> It would be very useful if we could configure which MBeans we are interested 
>> in.
>> 
>> Kind regards,
>> Steven
>> 
>> 
>> On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi Daniel,
>> 
>> JMX collector polls all MBeans attributes. However Prometheus appender only 
>> expose metrics (numeric) on the Prometheus servlet:
>> 
>> http://localhost:8181/decanter/prometheus 
>> <http://localhost:8181/decanter/prometheus>
>> 
>> As the generated JMX JSON is "more" than just numeric, it’s possible that 
>> you don’t have the metrics.
>> 
>> You can check the JMX JSON using another kind of appender (like log appender 
>> or elasticsearch).
>> I can add kind of "json introspection" on the Prometheus appender to "force" 
>> some JSON fields as metrics (gauge).
>> 
>> Regards
>> JB
>> 
>> > Le 2 mai 2021 à 22:24, Daniel Las > > <mailto:daniel@empirica.io>> a écrit :
>> > 
>> > Hi,
>> > 
>> > I installed Decanter 2.7.0 on Karaf 4.2.11 with JMX collector and 
>> > Prometheus appender features. I uncommented 
>> > "object.name.system=java.lang:*" in 
>> > org.apache.karaf.decanter.collector.jmx-local.cfg.
>> > 
>> > Where can I find JVM metrics like current heap memory usage? 
>> > 
>> > Regards
>> > -- 
>> > Daniel Łaś
>> > 
>> 

Re: Decanter and JMX

[Jean-Baptiste Onofre]

Hi Steven,

1. You can filter the MBeans you want to harvest
2. You can change the scheduling period: by default it’s every minutes, you can 
change it by configuration or using the scheduler:* commands, depending of the 
granularity you want

Regards
JB

> Le 1 juin 2021 à 11:07, Steven Huypens  a écrit :
> 
> Hi,
> 
> Enabling the JMX-collector leads to a very high CPU load in our application, 
> making it impossible to use. I'm not sure, but I think especially the 
> org.apache.karaf MBeans are expensive to harvest, maybe because of the size 
> of our application (>900 bundles).
> 
> It would be very useful if we could configure which MBeans we are interested 
> in.
> 
> Kind regards,
> Steven
> 
> 
> On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi Daniel,
> 
> JMX collector polls all MBeans attributes. However Prometheus appender only 
> expose metrics (numeric) on the Prometheus servlet:
> 
> http://localhost:8181/decanter/prometheus 
> <http://localhost:8181/decanter/prometheus>
> 
> As the generated JMX JSON is "more" than just numeric, it’s possible that you 
> don’t have the metrics.
> 
> You can check the JMX JSON using another kind of appender (like log appender 
> or elasticsearch).
> I can add kind of "json introspection" on the Prometheus appender to "force" 
> some JSON fields as metrics (gauge).
> 
> Regards
> JB
> 
> > Le 2 mai 2021 à 22:24, Daniel Las  > <mailto:daniel@empirica.io>> a écrit :
> > 
> > Hi,
> > 
> > I installed Decanter 2.7.0 on Karaf 4.2.11 with JMX collector and 
> > Prometheus appender features. I uncommented 
> > "object.name.system=java.lang:*" in 
> > org.apache.karaf.decanter.collector.jmx-local.cfg.
> > 
> > Where can I find JVM metrics like current heap memory usage? 
> > 
> > Regards
> > -- 
> > Daniel Łaś
> > 
> 

Re: OpenAPI and CXF issues with Karaf 4.2.11

[Jean-Baptiste Onofre]

Hi Matteo,

At first glance, it seems to be more an issue with CXF hat should extend the 
range.

I will take a look.

Regards
JB

> Le 1 juin 2021 à 00:43, Matteo Rulli  a écrit :
> 
> Hello,
> 
> I recently moved one of our projects from Karaf 4.2.6 to 4.2.11. 
> Unfortunately I got some errors, primarily due to swagger/openapi 
> dependencies.
> 
> I tried to document and reproduce all the problems here 
> https://github.com/mrulli/karaf-4211-cxf-swagger%3E%5D(%3Chttps://github.com/mrulli/karaf-4211-cxf-swagger%3E)>
>  (https://github.com/mrulli/karaf-4211-cxf-swagger 
> ): if you confirm they are 
> bugs I could raise the corresp. issues but I'm not sure where to open them 
> (CXF or Karaf).
> 
> If you want, I can try to add a couple of integration tests as PR: again, I'm 
> not sure Karaf is the right place where these tests should be added.
> 
> Looking forward to your feedbacks,
> Matteo

Re: Karaf console commands in Felix

[Jean-Baptiste Onofre]

Hi Doug, 

Why not just doing your own custom distribution, taking/building only the 
modules you need.
My point is that instead of starting of Felix, adding Karaf shell console, 
blueprint, etc, at the end, you are building a Karaf distribution ;)

I would rather fork Karaf, remove useless module for you, and just build what 
you need.

You can ping me directly if you need some details.

Regards
JB

> Le 25 mai 2021 à 16:25, Jackson, Douglas  a 
> écrit :
> 
> Hi!
> Our organization wants us to build all 3rd party software in-house from 
> source. So, rather than building all of Karaf and it’s 230 dependencies, we 
> are looking to use Felix instead as it only has 3 dependencies. +blueprints, 
> +console(maybe) [may use gogo or none]. We would have to put all components 
> into source control in house and maintain.
> Our product manager was looking around for an organization that would do that 
> for us for a fee – guarantee all was virus free. Maybe your company might be 
> interested?
> Thanks,
> Doug
>  
>  
> From: JB
>  
> Hi,
> You need org.apache.karaf.bundle.core and org.apache.karaf.diagnostic bundles.
> Can I say that I don’t understand what you want to do ? ;)
> Karaf is running Felix Framework, so, why not just using Karaf directly ?
> Regards
> JB
>  
>  
>  
> From: Jackson, Douglas (DI SW LCS CF CLP DEX) 
> Sent: Tuesday, May 25, 2021 8:09 AM
> To: 'user@karaf.apache.org' 
> Subject: Karaf console commands in Felix
>  
> Hi!
> I am trying to drop the karaf console into Apache Felix.
> I have some of the commands working, but not the “bundles:*” and “diag” 
> commands.
> What karaf bundles do I need to add in order to use those commands?
> Thanks!
> -Doug

Re: Missing requirement when using Osgi R7 Http whiteboard annotations

[Jean-Baptiste Onofre]

Hi Richard,

Funny, it has been discussed last week.

The problem is just about the org.osgi.service.http.context version exported by 
Pax Web.

Pax Web 7.3.x still exports org.osgi.service.http.context in version 1.0. This 
is a bug as version 1.1.0 should be exported by Pax Web.

This will be fixed in Pax Web 7.3.17 and so Karaf 4.3.3.

Regards
JB

> Le 25 mai 2021 à 16:10, Richard Hierlmeier  a 
> écrit :
> 
> 
> I tried to deploy an OSGI bundle that uses R7 Http whiteboard annotations.
> However when I deploy this bundle on Karaf 4.3.1  I get the following error:
> 
> missing requirement [SampleR7/1.0.0.SNAPSHOT] osgi.wiring.package; 
> resolution:=required; 
> filter:="(&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(!(version>=2.0.0)))"]]
>  -> [Help 1]
> 
> What are the prerequisits für the new annotations?
> 
> Regards 
> 
>   Richard
> 
> 
> 
> 
> 

Re: Memory usage camel-activemq & karaf 4.3.1

[Jean-Baptiste Onofre]

Hi Joerg,

Thanks for sharing. I will update camel-jms documentation, you are right it’s 
confusing ;)

Regards
JB

> Le 25 mai 2021 à 15:41, Jörg Jansen  a 
> écrit :
> 
> Hi JB,
>  
> once again, thanks for your reply.
> Replacing camel-activemq by camel-jms solved the memory consumption.
>  
> There were only two items, whichI  would like to share, or anyone who might 
> be affected:
>  
> When using pax-jms  in combination with the maven-bundle-plugin, I had to 
> remove the headers Import-Service,Export-Service. Otherwise the connection 
> factory could not be found.
> The camel-jms documentation still recommends to use camel-activemq, which is 
> quite confusing.
>  
> Also the provided example 
> (https://github.com/apache/karaf/tree/main/examples/karaf-jms-example/karaf-jms-example-features
>  
> <https://github.com/apache/karaf/tree/main/examples/karaf-jms-example/karaf-jms-example-features>)
>  was very helpful. 
>  
> Thanks again,
> Joerg
>  
> From: Jörg Jansen 
> Sent: Donnerstag, 20. Mai 2021 08:00
> To: user 
> Subject: RE: Memory usage camel-activemq & karaf 4.3.1
>  
> Hi JB,
>  
> thanks for your feedback.
>  
> Currently, we are using both, camel-activemq and the activemqbroker. 
> But the displayed difference is only when adding the camel-activemq feature.
>  
> As the application was based on servicemix before, this behavior is still an 
> old relict .
> I’ll try to change everything to jms and come back  with the result.
>  
> If camel-activemq is still based on camel2, might it be a good idea, to mark 
> it as deprecated, with the hint to replace it by camel-jms?
>  
> Kind regards,
> Joerg
>  
> From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>> 
> Sent: Donnerstag, 20. Mai 2021 06:06
> To: user mailto:user@karaf.apache.org>>
> Subject: Re: Memory usage camel-activemq & karaf 4.3.1
>  
> Hi Joerg,
>  
> Do you install "just" camel-activemq feature or activemq-broker one as well ?
>  
> I guess it doesn’t happen if you use camel-jms ?
>  
> Generally speaking, I recommend to use camel-jms instead of camel-activemq. 
> The main reason is that camel-activemq is still Camel 2.x and you are using 
> Camel 3.x. You can achieve quite the same thing with camel-jms.
>  
> Regards
> JB
>  
> 
> Le 19 mai 2021 à 20:44, Jörg Jansen  <mailto:joerg.jan...@inform-software.com>> a écrit :
>  
> Good evening everybody, 
>  
> Currently I’m using camel-3.7.4 and karaf 4.3.1.
> I’ve recognized a strange behavior, when using camel-activemq feature.
>  
> It seems, that from karaf version 4.3.1 the memory usage “explodes”, as soon 
> as the temporary data are created during startup.
> After a while, the memory usage is decreasing again but at startup it 
> rexerved up to ~2GB of memory.
>  
> In the picture below, you can see the occupied memory, in case I startup 
> karaf without the camel-activemq feature. Here, the allocated memory is 512MB 
> wihch is fine.
> 
> 
> In the following picture, you can see the startup with camel-activemq as a 
> boo feature.
> 
>  
> I hope this is the correct mailing list, or should belong the camel one?
> In that case please bothering you 
>  
> Wondering if anyone else recognized this behavior.
>  
> Any help would be very appreciated!
>  
> Kind regards,
> Joerg

Re: Karaf console commands in Felix

[Jean-Baptiste Onofre]

Hi,

You need org.apache.karaf.bundle.core and org.apache.karaf.diagnostic bundles.

Can I say that I don’t understand what you want to do ? ;)

Karaf is running Felix Framework, so, why not just using Karaf directly ?

Regards
JB

> Le 25 mai 2021 à 15:09, Jackson, Douglas  a 
> écrit :
> 
> Hi!
> I am trying to drop the karaf console into Apache Felix.
> I have some of the commands working, but not the “bundles:*” and “diag” 
> commands.
> What karaf bundles do I need to add in order to use those commands?
> Thanks!
> -Doug

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Thanks ! Updated to target Karaf runtime 4.2.12 and 4.3.3.

I will keep you posted in the Jira.

Regards
JB

> Le 25 mai 2021 à 10:17, Steven Huypens  a écrit :
> 
> 
> https://issues.apache.org/jira/browse/KARAF-7163 
> <https://issues.apache.org/jira/browse/KARAF-7163>
> 
> Regards
> Steven
> 
> On Tue, May 25, 2021 at 10:06 AM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Ok,
> 
> Can you please create a Jira about that, I will fix/improve that.
> 
> Regards
> JB
> 
>> Le 25 mai 2021 à 09:08, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> Hi,
>> 
>> Apparently our customer needs the version numbers to be alphanumerically 
>> sortable, so we cannot remove the leading zeroes. I'm looking forward to a 
>> solution, let me know how I can help.
>> 
>> 
>> Best regards,
>> Steven
>> 
>> On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi Daniel,
>> 
>> I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
>> (actually, I think it’s "blurry" as there’s no details in one way or 
>> another).
>> 
>> That’s why I said more a "best practice".
>> 
>> Generally speaking (not OSGi related), I don’t see any good reason to use 
>> leading 0 in version ;)
>> 
>> So, as the spec is not very strict about that, we should support it in the 
>> resolver.
>> 
>> Regards
>> JB
>> 
>> > Le 24 mai 2021 à 17:16, Daniel Krügler > > <mailto:daniel.krueg...@gmx.de>> a écrit :
>> > 
>> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> >> Hi Steven,
>> >> 
>> >> Yeah, the state should already contain the "cleaned" versions.
>> >> 
>> >> I will take a look.
>> >> 
>> >> Anyway, as best practice, I would avoid leading 0 ;)
>> > 
>> > I completely agree and I don't understand why there should be additional
>> > work invested to "fix" that. The OSGi specification is clear that any
>> > leading zeros in version numbers are invalid. Anyone attempting to
>> > provide such a bundle should correct the version number and remove the
>> > leading zeros.
>> > 
>> > - Daniel
>> > 
>> 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Ok,

Can you please create a Jira about that, I will fix/improve that.

Regards
JB

> Le 25 mai 2021 à 09:08, Steven Huypens  a écrit :
> 
> Hi,
> 
> Apparently our customer needs the version numbers to be alphanumerically 
> sortable, so we cannot remove the leading zeroes. I'm looking forward to a 
> solution, let me know how I can help.
> 
> 
> Best regards,
> Steven
> 
> On Tue, May 25, 2021 at 6:19 AM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi Daniel,
> 
> I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
> (actually, I think it’s "blurry" as there’s no details in one way or another).
> 
> That’s why I said more a "best practice".
> 
> Generally speaking (not OSGi related), I don’t see any good reason to use 
> leading 0 in version ;)
> 
> So, as the spec is not very strict about that, we should support it in the 
> resolver.
> 
> Regards
> JB
> 
> > Le 24 mai 2021 à 17:16, Daniel Krügler  > <mailto:daniel.krueg...@gmx.de>> a écrit :
> > 
> > Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
> >> Hi Steven,
> >> 
> >> Yeah, the state should already contain the "cleaned" versions.
> >> 
> >> I will take a look.
> >> 
> >> Anyway, as best practice, I would avoid leading 0 ;)
> > 
> > I completely agree and I don't understand why there should be additional
> > work invested to "fix" that. The OSGi specification is clear that any
> > leading zeros in version numbers are invalid. Anyone attempting to
> > provide such a bundle should correct the version number and remove the
> > leading zeros.
> > 
> > - Daniel
> > 
> 

Re: Configuration in Zookeeper

[Jean-Baptiste Onofre]

Hi Daniel,

Cellar config does it in a distributed way (using hazelcast).

You can have configuration sync on the cluster, others specific/local to a node.

Regards
JB

> Le 25 mai 2021 à 07:04, Daniel Las  a écrit :
> 
> Hi,
> 
> I'm looking for the centralized configuration management solution for Apache 
> Karaf 4.2.x. 
> 
> I have multiple Karaf nodes and want to keep configuration in a single place, 
> preferably using Zookeeper as storage backend.  Some config properties should 
> be shared (the same on every node) and some should be node dependent.  
> 
> Is there any ready to use solution or should I go for a custom one?
> 
> Regards
> -- 
> Daniel Łaś

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Daniel,

I don’t think there’s any enforcement in the OSGi spec regarding leading 0 
(actually, I think it’s "blurry" as there’s no details in one way or another).

That’s why I said more a "best practice".

Generally speaking (not OSGi related), I don’t see any good reason to use 
leading 0 in version ;)

So, as the spec is not very strict about that, we should support it in the 
resolver.

Regards
JB

> Le 24 mai 2021 à 17:16, Daniel Krügler  a écrit :
> 
> Am 24.05.2021 um 17:10 schrieb Jean-Baptiste Onofre:
>> Hi Steven,
>> 
>> Yeah, the state should already contain the "cleaned" versions.
>> 
>> I will take a look.
>> 
>> Anyway, as best practice, I would avoid leading 0 ;)
> 
> I completely agree and I don't understand why there should be additional
> work invested to "fix" that. The OSGi specification is clear that any
> leading zeros in version numbers are invalid. Anyone attempting to
> provide such a bundle should correct the version number and remove the
> leading zeros.
> 
> - Daniel
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

Yeah, the state should already contain the "cleaned" versions.

I will take a look.

Anyway, as best practice, I would avoid leading 0 ;)

Regards
JB

> Le 24 mai 2021 à 16:57, Steven Huypens  a écrit :
> 
> Hi,
> 
> No, it's a simple feature.xml file
> 
> The JsonReader class is used to read the cached file state.json, but I now 
> see that that file contains the wrong version already.
> 
> I've taken a better look and I think it's the SubsystemResolver where the 
> zero gets lost, more specifically this line :
> 
> wiring = resolver.resolve(context);
> 
> 
> 
> 
> Kind regards,
> Steven
> 
> On Mon, May 24, 2021 at 1:27 PM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi,
> 
> Does it mean that you are using features repository in json format ?
> 
> Regards
> JB
> 
>> Le 24 mai 2021 à 12:44, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> Hi JB,
>> 
>> I've found a VersionCleaner class in org.apache.felix.utils.version, which 
>> is being used in Karaf. But as far as I can see, this class doesn't 'clean' 
>> leading zeroes.
>> 
>> I did see however that the method readNumber() in 
>> org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This 
>> results in a 'wrong' version number in the list of installedFeatures in 
>> org.apache.karaf.features.internal.service.State I'm assuming that's the 
>> reason why my feature does not get installed.
>> 
>> 
>> 
>> Kind regards,
>> Steven
>> 
>> On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi Steven,
>> 
>> Don’t get me wrong: it’s in the feature/osgi version parser (powered by 
>> Felix utils), not in the spec.
>> 
>> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 
>> <http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html>
>> 
>> The spec allows leading 0, however, I think that the Felix Util version 
>> parser removes it.
>> 
>> Let me check in Felix.
>> 
>> Regards
>> JB
>> 
>>> Le 23 mai 2021 à 19:47, Steven Huypens >> <mailto:steven.huyp...@gmail.com>> a écrit :
>>> 
>>> Hi JB,
>>> 
>>> Thanks for your response. I guess we'll have to change our versioning 
>>> scheme then. Do you have a reference to the OSGi spec stating leading 
>>> zeroes are not allowed ? I might have to convince some people ;-)
>>> 
>>> Also, it would be convenient to have at least a WARN in the logging about 
>>> this, it took us quite some time to figure out what we were doing wrong. 
>>> I'd be happy to create a PR if that would help, but you will have to point 
>>> me to the code where this has to be changed.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> wrote:
>>> Hi Steven,
>>> 
>>> I would consider as "works as designed" ;)
>>> 
>>> The OSGi version parser expects "flat" versioning.
>>> 
>>> Regards
>>> JB
>>> 
>>> > Le 23 mai 2021 à 11:06, Steven Huypens >> > <mailto:steven.huyp...@gmail.com>> a écrit :
>>> > 
>>> > Hi All,
>>> > 
>>> > When using a bootFeature with a leading zero in the version number (eg. 
>>> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting 
>>> > Karaf. All my bundles are OK, it's only the state of the feature that 
>>> > seems wrong. When I remove the leading zero (1.1.1-SNAPSHOT), the feature 
>>> > gets state STARTED, as expected.
>>> > 
>>> > Should I consider this a bug or is there a specification telling us not 
>>> > to use leading zeroes for version numbers ?
>>> > 
>>> > Best regards,
>>> > Steven 
>>> 
>> 
> 

Re: Pax-Exam failure to start Karaf container

[Jean-Baptiste Onofre]

Hi Alex,

That’s weird as it’s what we are using in Karaf itests as well.

It seems related to a missing JDK11 argument (—allow-access).

Do you have something else in the trace/log ?

Regards
JB

> Le 24 mai 2021 à 16:26, Alex Soto  a écrit :
> 
> Hello,
> 
> I am getting the following error running integration tests with Pax-Exam 
> version 4.13.4, and Karaf version 4.3.2, on Java 11.
> 
> 
> 2021-05-19T04:34:09,372 | ERROR | features-3-thread-1 | Felix 
>| 5 - org.ops4j.pax.logging.pax-logging-api - 2.0.9 | Bundle 
> org.apache.felix.framework [0] EventDispatcher: Error during dispatch. 
> (java.lang.IllegalAccessError: class 
> org.apache.karaf.specs.activator.Activator (in unnamed module @0x3fb72de) 
> cannot access class org.apache.karaf.specs.locator.OsgiLocator (in module 
> java.base) because module java.base does not export 
> org.apache.karaf.specs.locator to unnamed module @0x3fb72de)
> java.lang.IllegalAccessError: class 
> org.apache.karaf.specs.activator.Activator (in unnamed module @0x3fb72de) 
> cannot access class org.apache.karaf.specs.locator.OsgiLocator (in module 
> java.base) because module java.base does not export 
> org.apache.karaf.specs.locator to unnamed module @0x3fb72de
> at 
> org.apache.karaf.specs.activator.Activator.register(Activator.java:125) 
> ~[org.apache.karaf.specs.activator-4.3.2.jar:4.3.2]
> at 
> org.apache.karaf.specs.activator.Activator.bundleChanged(Activator.java:97) 
> ~[org.apache.karaf.specs.activator-4.3.2.jar:4.3.2]
> at 
> org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
>  ~[?:?]
> at 
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
>  ~[?:?]
> at 
> org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
>  ~[?:?]
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4817) 
> ~[?:?]
> at 
> org.apache.felix.framework.StatefulResolver.fireResolvedEvents(StatefulResolver.java:1300)
>  ~[?:?]
> at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:512)
>  ~[?:?]
> at org.apache.felix.framework.Felix.resolveBundles(Felix.java:4327) 
> ~[?:?]
> at 
> org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl.resolveBundles(BundleInstallSupportImpl.java:244)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.resolveBundles(FeaturesServiceImpl.java:1175)
>  ~[?:?]
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:1027)
>  ~[?:?]
> 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.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) [?:?]
> 
> My test is based on org.apache.karaf.itests.KarafTestSupport, where the 
> proper JVM options should be set to deal with this module issues. 
> Any idea about what may be going on?
> 
> Best regards,
> Alex soto
> 
> 
> 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi,

Does it mean that you are using features repository in json format ?

Regards
JB

> Le 24 mai 2021 à 12:44, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> I've found a VersionCleaner class in org.apache.felix.utils.version, which is 
> being used in Karaf. But as far as I can see, this class doesn't 'clean' 
> leading zeroes.
> 
> I did see however that the method readNumber() in 
> org.apache.karaf.util.json.JsonReader seems to skip the leading zero. This 
> results in a 'wrong' version number in the list of installedFeatures in 
> org.apache.karaf.features.internal.service.State I'm assuming that's the 
> reason why my feature does not get installed.
> 
> 
> 
> Kind regards,
> Steven
> 
> On Mon, May 24, 2021 at 6:40 AM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi Steven,
> 
> Don’t get me wrong: it’s in the feature/osgi version parser (powered by Felix 
> utils), not in the spec.
> 
> http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 
> <http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html>
> 
> The spec allows leading 0, however, I think that the Felix Util version 
> parser removes it.
> 
> Let me check in Felix.
> 
> Regards
> JB
> 
>> Le 23 mai 2021 à 19:47, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> Hi JB,
>> 
>> Thanks for your response. I guess we'll have to change our versioning scheme 
>> then. Do you have a reference to the OSGi spec stating leading zeroes are 
>> not allowed ? I might have to convince some people ;-)
>> 
>> Also, it would be convenient to have at least a WARN in the logging about 
>> this, it took us quite some time to figure out what we were doing wrong. I'd 
>> be happy to create a PR if that would help, but you will have to point me to 
>> the code where this has to be changed.
>> 
>> Best regards,
>> Steven
>> 
>> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi Steven,
>> 
>> I would consider as "works as designed" ;)
>> 
>> The OSGi version parser expects "flat" versioning.
>> 
>> Regards
>> JB
>> 
>> > Le 23 mai 2021 à 11:06, Steven Huypens > > <mailto:steven.huyp...@gmail.com>> a écrit :
>> > 
>> > Hi All,
>> > 
>> > When using a bootFeature with a leading zero in the version number (eg. 
>> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
>> > All my bundles are OK, it's only the state of the feature that seems 
>> > wrong. When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets 
>> > state STARTED, as expected.
>> > 
>> > Should I consider this a bug or is there a specification telling us not to 
>> > use leading zeroes for version numbers ?
>> > 
>> > Best regards,
>> > Steven 
>> 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

Don’t get me wrong: it’s in the feature/osgi version parser (powered by Felix 
utils), not in the spec.

http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html 
<http://docs.osgi.org/javadoc/r4v41/org/osgi/framework/Version.html>

The spec allows leading 0, however, I think that the Felix Util version parser 
removes it.

Let me check in Felix.

Regards
JB

> Le 23 mai 2021 à 19:47, Steven Huypens  a écrit :
> 
> Hi JB,
> 
> Thanks for your response. I guess we'll have to change our versioning scheme 
> then. Do you have a reference to the OSGi spec stating leading zeroes are not 
> allowed ? I might have to convince some people ;-)
> 
> Also, it would be convenient to have at least a WARN in the logging about 
> this, it took us quite some time to figure out what we were doing wrong. I'd 
> be happy to create a PR if that would help, but you will have to point me to 
> the code where this has to be changed.
> 
> Best regards,
> Steven
> 
> On Sun, May 23, 2021 at 5:11 PM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi Steven,
> 
> I would consider as "works as designed" ;)
> 
> The OSGi version parser expects "flat" versioning.
> 
> Regards
> JB
> 
> > Le 23 mai 2021 à 11:06, Steven Huypens  > <mailto:steven.huyp...@gmail.com>> a écrit :
> > 
> > Hi All,
> > 
> > When using a bootFeature with a leading zero in the version number (eg. 
> > 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
> > All my bundles are OK, it's only the state of the feature that seems wrong. 
> > When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state 
> > STARTED, as expected.
> > 
> > Should I consider this a bug or is there a specification telling us not to 
> > use leading zeroes for version numbers ?
> > 
> > Best regards,
> > Steven 
> 

Re: bootFeature with leading zero in version does not get state STARTED

[Jean-Baptiste Onofre]

Hi Steven,

I would consider as "works as designed" ;)

The OSGi version parser expects "flat" versioning.

Regards
JB

> Le 23 mai 2021 à 11:06, Steven Huypens  a écrit :
> 
> Hi All,
> 
> When using a bootFeature with a leading zero in the version number (eg. 
> 1.01.1-SNAPSHOT), the feature gets state UNINSTALLED after starting Karaf. 
> All my bundles are OK, it's only the state of the feature that seems wrong. 
> When I remove the leading zero (1.1.1-SNAPSHOT), the feature gets state 
> STARTED, as expected.
> 
> Should I consider this a bug or is there a specification telling us not to 
> use leading zeroes for version numbers ?
> 
> Best regards,
> Steven 

Re: Karaf is not finding org.osgi.util.function and fails to start

[Jean-Baptiste Onofre]

Cool, thanks !

Regards
JB

> Le 21 mai 2021 à 06:58, francois.papon  a écrit 
> :
> 
>  ARIES-2047 

Re: Content of Kar Files

[Jean-Baptiste Onofre]

Hi,

I guess you are using the karaf-maven-plugin to create the kar (you can always 
create the kar by hand).

If a bundle or feature is flagged as dependency=true, it should not be included 
(or you have true).

Regards
JB

> Le 21 mai 2021 à 00:01, Paul Fraser  a écrit :
> 
> Hi,
> 
> When creating a kar file for a feature that has prerequisites, all bundles of 
> the prerequisite are included in the kar.
> 
> This can result in large kar files when the kar feature only adds little to 
> the overall system. Most of the requirements of the new kar are already in 
> the karaf system folder.
> 
> Is there a way to not include bundles in a kar that are already in the karaf 
> system folder?
> 
> prerequisite and dependency attributes on the feature make no difference.
> 
> Paul Fraser
> 

Re: How to use configuration placeholders in karaf configs

[Jean-Baptiste Onofre]

Hi,

I’m suspecting the interpolation plugin that we added in 4.3.0.

Let me try to reproduce and fix that.

Regards
JB

> Le 20 mai 2021 à 18:59, João Assunção  a écrit :
> 
> I guess I found the culprit. 
> FeatureConfigInstaller uses TypedProperties to load the properties from the 
> feature config element.
> Apparently TypedProperties performs variable interpolation and replaces my 
> placeholders. I still don't understand why sometimes they are replaced and 
> other times they don't
> 
> João Assunção
> 
> Email: joao.assun...@exploitsys.com <mailto:joao.assun...@exploitsys.com>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.com/>
> 
> 
> 
> 
> On Thu, May 20, 2021 at 4:47 PM João Assunção  <mailto:joao.assun...@exploitsys.com>> wrote:
> Hello JB
> 
> Yes I'm using Karaf 4.3.0
> 
> I tried with override="true", specifying the placeholder value in 
> custom.properties, and with -D. The behavior is the same.
> For the same feature, some cfg files keep the placeholder while others have 
> the placeholder replaced by an empty string.
> Another weird behavior is that this doesn't occur in my machine but occurs in 
> two other machines. All them are Linux machines running openjdk but mine is a 
> bit slower. 
> 
> I will try to use the  element instead of 
> 
> 
> 
> João Assunção
> 
> Email: joao.assun...@exploitsys.com <mailto:joao.assun...@exploitsys.com>
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com <http://www.exploitsys.com/>
> 
> 
> 
> 
> On Thu, May 20, 2021 at 3:54 PM Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> wrote:
> Hi,
> 
> If you want to always take config content from the features, you can user 
> overwrite="true" flag.
> 
> You can override with -D (see http://blog.nanthrax.net/?p=1038 
> <http://blog.nanthrax.net/?p=1038>).
> 
> I guess you are using Karaf 4.3.x right ? 
> 
> Regards
> JB
> 
>> Le 20 mai 2021 à 16:33, João Assunção > <mailto:joao.assun...@exploitsys.com>> a écrit :
>> 
>> Hello all,
>> 
>> I'm trying to use placeholders in configurations but I noticed some weird 
>> behavior. Sometimes the placeholder is replaced by an empty string, in other 
>> situations by the value of the property and in others not replaced at all.
>> 
>> One of my features contains the following configurations:
>> ...
>> > append="false">
>> storageDirectory=${tzc.data}/photos
>> 
>> > name="pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider" 
>> append="false">
>> rrdDefFile = etc/tzc_metrics.xml
>> rrdRepository = ${tzc.data}/rrd
>> reportingInterval = 60
>> 
>> ..
>>
>> When the feature is installed, with tzc.data set to "myData", sometimes i 
>> get the following cfg files:
>> == com.atobe.ort.photo.repository.PhotoRepositoryServiceProvider.cfg ==
>> storageDirectory=${tzc.data}/photos
>> org.apache.karaf.features.configKey = 
>> com.atobe.ort.photo.repository.PhotoRepositoryServiceProvider
>> 
>> == pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider.cfg ==
>> rrdDefFile = etc/tzc_metrics.xml
>> rrdRepository = myData/rrd
>> reportingInterval = 60
>> org.apache.karaf.features.configKey = 
>> pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider
>> 
>> I tried specifying the variable name in config.properties and using  the -D  
>> flag
>> 
>> Ideally I would like the placeholder to be replaced by the actual value only 
>> when the configuration is passed to the service.
>> 
>> What am I doing wrong ?
>> 
>> Thank you in advance.
>> 
>> Best regards,
>> João Assunção
>> 
>> Email: joao.assun...@exploitsys.com <mailto:joao.assun...@exploitsys.com>
>> Mobile: +351 916968984
>> Phone: +351 211933149
>> Web: www.exploitsys.com <http://www.exploitsys.com/>
>> 
>> 
> 

Re: Load failure caused by adding a provided maven dependency

[Jean-Baptiste Onofre]

We should pax-web-api 7.3.x should upgrade osgi.context version to 1.1 to be R7 
compliant.

https://blog.osgi.org/2018/05/osgi-r7-highlights-http-whiteboard.html 
<https://blog.osgi.org/2018/05/osgi-r7-highlights-http-whiteboard.html>

Regards
JB

> Le 20 mai 2021 à 17:10, Steinar Bang  a écrit :
> 
>>>>>> Jean-Baptiste Onofre :
> 
>> The scope has an impact on the maven-bundle-plugin. In your case, it
>> seems that the org.osgi.service.http.context package is not found.
> 
> Yes, I saw that.  Didn't understand why, though.
> 
>> Did you check the version range and the MANIFEST,
> 
> Ah, I said the manifests were identical, but in fact they aren't (I just
> skimmed them visually and looked at the byte count. My bad!)
> 
> Here's the diff from working (without the dependency) and non-working
> (with the dependency):
> 2c2
> < Bnd-LastModified: 1621448235589
> ---
>> Bnd-LastModified: 1621447336157
> 23c23
> <  sgi.service.http.context;version="[1.0,2)"
> ---
>> sgi.service.http.context;version="[1.1,2)"
> 
> So you were correct: it's the version that is different (1.1 as the
> lowest version instead of 1.0).
> 
>> and also if the org.osgi.service.http.context package is not embedded
>> in your bundle ?
> 
> No the package is not embedded in my bundle.  Should it be?
> Where is org.osgi.service.http.context supposed to come from?
> 
> Hm... it does look like something that should be provided by the OSGi
> framework...?  What version(s) do karaf 4.3.0 and 4.3.2 provide?
> 
> Hm... looks like something provided by pax-web...?
> karaf@root()> package:exports | grep org.osgi.service.http.context
> org.osgi.service.http.contextx 1.0.0   x 169 x 
> org.ops4j.pax.web.pax-web-api
> karaf@root()>
> 
> And it looks like the version provided is 1.0.0, which is too old...?
> (this is on karaf 4.3.2, from the binary tgz)
> 
> But why did this happen here?  This is the third project I'm taking up
> to OSGi 7 web whiteboard and I didn't encounter this in the other two.
> 
> Also, this is the only one of three bundles with web whiteboard services
> that triggers the issue.
> 
> This is the bundle that holds the web context helper and the shiro
> filter.
> 
> Maybe the web context helper is the cause of the problem?
> 
>> Does it occur outside of the test, at runtime ?
> 
> If by "it" you mean the load issue, then yes it does.
> 
> I get the same error when trying to load the same feature from the karaf
> 4.3.2 command line (haven't gone back to 4.3.0, but I expect the same
> behaviour there.  The karaf of the pax exam test is 4.3.0).
> 
> Thanks!
> 
> 
> - Steinar
> 

Re: Load failure caused by adding a provided maven dependency

[Jean-Baptiste Onofre]

I think that the problem is especially on the http.context version ;)

I guess that if you put: org.osgi.service.http.context;version="[1,2)" in 
Import-Package it works right ?

The difference is that the dependency used by the maven-bundle-plugin.

Regards
JB

> Le 20 mai 2021 à 17:10, Steinar Bang  a écrit :
> 
>>>>>> Jean-Baptiste Onofre :
> 
>> The scope has an impact on the maven-bundle-plugin. In your case, it
>> seems that the org.osgi.service.http.context package is not found.
> 
> Yes, I saw that.  Didn't understand why, though.
> 
>> Did you check the version range and the MANIFEST,
> 
> Ah, I said the manifests were identical, but in fact they aren't (I just
> skimmed them visually and looked at the byte count. My bad!)
> 
> Here's the diff from working (without the dependency) and non-working
> (with the dependency):
> 2c2
> < Bnd-LastModified: 1621448235589
> ---
>> Bnd-LastModified: 1621447336157
> 23c23
> <  sgi.service.http.context;version="[1.0,2)"
> ---
>> sgi.service.http.context;version="[1.1,2)"
> 
> So you were correct: it's the version that is different (1.1 as the
> lowest version instead of 1.0).
> 
>> and also if the org.osgi.service.http.context package is not embedded
>> in your bundle ?
> 
> No the package is not embedded in my bundle.  Should it be?
> Where is org.osgi.service.http.context supposed to come from?
> 
> Hm... it does look like something that should be provided by the OSGi
> framework...?  What version(s) do karaf 4.3.0 and 4.3.2 provide?
> 
> Hm... looks like something provided by pax-web...?
> karaf@root()> package:exports | grep org.osgi.service.http.context
> org.osgi.service.http.contextx 1.0.0   x 169 x 
> org.ops4j.pax.web.pax-web-api
> karaf@root()>
> 
> And it looks like the version provided is 1.0.0, which is too old...?
> (this is on karaf 4.3.2, from the binary tgz)
> 
> But why did this happen here?  This is the third project I'm taking up
> to OSGi 7 web whiteboard and I didn't encounter this in the other two.
> 
> Also, this is the only one of three bundles with web whiteboard services
> that triggers the issue.
> 
> This is the bundle that holds the web context helper and the shiro
> filter.
> 
> Maybe the web context helper is the cause of the problem?
> 
>> Does it occur outside of the test, at runtime ?
> 
> If by "it" you mean the load issue, then yes it does.
> 
> I get the same error when trying to load the same feature from the karaf
> 4.3.2 command line (haven't gone back to 4.3.0, but I expect the same
> behaviour there.  The karaf of the pax exam test is 4.3.0).
> 
> Thanks!
> 
> 
> - Steinar
> 

Re: How to use configuration placeholders in karaf configs

[Jean-Baptiste Onofre]

Hi,

If you want to always take config content from the features, you can user 
overwrite="true" flag.

You can override with -D (see http://blog.nanthrax.net/?p=1038 
).

I guess you are using Karaf 4.3.x right ? 

Regards
JB

> Le 20 mai 2021 à 16:33, João Assunção  a écrit :
> 
> Hello all,
> 
> I'm trying to use placeholders in configurations but I noticed some weird 
> behavior. Sometimes the placeholder is replaced by an empty string, in other 
> situations by the value of the property and in others not replaced at all.
> 
> One of my features contains the following configurations:
> ...
>  append="false">
> storageDirectory=${tzc.data}/photos
> 
>  name="pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider" 
> append="false">
> rrdDefFile = etc/tzc_metrics.xml
> rrdRepository = ${tzc.data}/rrd
> reportingInterval = 60
> 
> ..
>
> When the feature is installed, with tzc.data set to "myData", sometimes i get 
> the following cfg files:
> == com.atobe.ort.photo.repository.PhotoRepositoryServiceProvider.cfg ==
> storageDirectory=${tzc.data}/photos
> org.apache.karaf.features.configKey = 
> com.atobe.ort.photo.repository.PhotoRepositoryServiceProvider
> 
> == pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider.cfg ==
> rrdDefFile = etc/tzc_metrics.xml
> rrdRepository = myData/rrd
> reportingInterval = 60
> org.apache.karaf.features.configKey = 
> pt.brisa.service.metrics.rrd.internal.RRDPersistenceServiceProvider
> 
> I tried specifying the variable name in config.properties and using  the -D  
> flag
> 
> Ideally I would like the placeholder to be replaced by the actual value only 
> when the configuration is passed to the service.
> 
> What am I doing wrong ?
> 
> Thank you in advance.
> 
> Best regards,
> João Assunção
> 
> Email: joao.assun...@exploitsys.com 
> Mobile: +351 916968984
> Phone: +351 211933149
> Web: www.exploitsys.com 
> 
> 

Re: Load failure caused by adding a provided maven dependency

[Jean-Baptiste Onofre]

Hi Steinar,

The scope has an impact on the maven-bundle-plugin. In your case, it seems that 
the org.osgi.service.http.context package is not found.

Did you check the version range and the MANIFEST, and also if the 
org.osgi.service.http.context package is not embedded in your bundle ?
Does it occur outside of the test, at runtime ?

Regards
JB

> Le 19 mai 2021 à 21:41, Steinar Bang  a écrit :
> 
> Platform: debian 10.9 "buster", amd64, openjdk 11, maven 3.6.0, karaf 4.3.0
> 
> I'm in the process of turning my web whiteboard projects[1] into using
> the (much nicer) OSGi 7 web whiteboard, and I've encountered a curious
> problem:
> 
> Adding the maven dependency
>
>org.osgi
>org.osgi.service.http.whiteboard
>1.1.0
>provided
>
> to the bundles providing web whiteboard services, causes one of these
> bundles[2] to fail during startup:
> https://gist.github.com/steinarb/44dc8e29193ce5b7925761f701da7d12
> 
> The weird thing is that I can't find anything different in the bundle
> with the dependency added, vs. the bundle without the dependency added:
> 1. the manifest.mf files are identical with and without the dependencyb
> 2. the OSGI-INF files are identical with and without the dependencyb
> 3. the karaf feature.xml files are identical with and without the dependencyb
> 
> That these files aren't affected by the added provided dependency wasn't
> surprising.  That's what I expected.
> 
> But the load problem is a mystery.
> 
> Any ideas what causes it?
> 
> Thanks!
> 
> 
> - Steinar
> 
> References:
> [1] 
> [2] 
> 

Re: Memory usage camel-activemq & karaf 4.3.1

[Jean-Baptiste Onofre]

Hi Joerg,

Do you install "just" camel-activemq feature or activemq-broker one as well ?

I guess it doesn’t happen if you use camel-jms ?

Generally speaking, I recommend to use camel-jms instead of camel-activemq. The 
main reason is that camel-activemq is still Camel 2.x and you are using Camel 
3.x. You can achieve quite the same thing with camel-jms.

Regards
JB

> Le 19 mai 2021 à 20:44, Jörg Jansen  a 
> écrit :
> 
> Good evening everybody, 
>  
> Currently I’m using camel-3.7.4 and karaf 4.3.1.
> I’ve recognized a strange behavior, when using camel-activemq feature.
>  
> It seems, that from karaf version 4.3.1 the memory usage “explodes”, as soon 
> as the temporary data are created during startup.
> After a while, the memory usage is decreasing again but at startup it 
> rexerved up to ~2GB of memory.
>  
> In the picture below, you can see the occupied memory, in case I startup 
> karaf without the camel-activemq feature. Here, the allocated memory is 512MB 
> wihch is fine.
> 
> 
> In the following picture, you can see the startup with camel-activemq as a 
> boo feature.
> 
>  
> I hope this is the correct mailing list, or should belong the camel one?
> In that case please bothering you 
>  
> Wondering if anyone else recognized this behavior.
>  
> Any help would be very appreciated!
>  
> Kind regards,
> Joerg

Re: Decanter and JMX

[Jean-Baptiste Onofre]

Hi Steven,

Yes: https://issues.apache.org/jira/browse/KARAF-7154 
<https://issues.apache.org/jira/browse/KARAF-7154>

I will work on Decanter release tonight.

Regards
JB

> Le 19 mai 2021 à 08:19, Steven Huypens  a écrit :
> 
> Hi Jean-Baptist,
> 
> Did you create the Jira already ? I couldn't find it..
> 
> Thanks,
> Steven
> 
> On Wed, May 12, 2021 at 7:04 PM JB Onofré  <mailto:j...@nanthrax.net>> wrote:
> Hi Steven
> 
> I agree, That’s what I proposed before. Keep in mind that jmx is one 
> collector, but we have bunch of other collectors with different data 
> structure. 
> 
> However I think we can improve the Prometheus appender to recursive on 
> array/complex type down to numeric data that we can expose. 
> 
> I will create the Jira. 
> 
> Regards 
> JB
> 
>> Le 12 mai 2021 à 18:58, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> 
>> Hi Jean-Baptist,
>> 
>> 1) You mention the Prometheus appender only exposes the numeric metrics. I 
>> believe it would be a minor but very useful addition to also expose the 
>> Objects in a CompositeDataSupport. For example java.lang.memory has a 
>> HeapMemoryUsage-object which contains 4 values (committed, init, max & used) 
>> that could easily be exposed as well.
>> 
>> 2) I also would like to suggest to prefix the outputted name of a property 
>> with something that really identifies the MBean, eg. :
>> 
>> java_lang_Memory_HeapMemoryUsage_committed
>> java_lang_Memory_HeapMemoryUsage_init 
>> java_lang_Memory_HeapMemoryUsage_max
>> java_lang_Memory_HeapMemoryUsage_used
>> 
>> Currently MBeans having the same properties will have their values 
>> overridden in the output.
>> 
>> Kind regards,
>> Steven
>> 
>> On Mon, May 3, 2021 at 6:14 AM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi Daniel,
>> 
>> JMX collector polls all MBeans attributes. However Prometheus appender only 
>> expose metrics (numeric) on the Prometheus servlet:
>> 
>> http://localhost:8181/decanter/prometheus 
>> <http://localhost:8181/decanter/prometheus>
>> 
>> As the generated JMX JSON is "more" than just numeric, it’s possible that 
>> you don’t have the metrics.
>> 
>> You can check the JMX JSON using another kind of appender (like log appender 
>> or elasticsearch).
>> I can add kind of "json introspection" on the Prometheus appender to "force" 
>> some JSON fields as metrics (gauge).
>> 
>> Regards
>> JB
>> 
>> > Le 2 mai 2021 à 22:24, Daniel Las > > <mailto:daniel@empirica.io>> a écrit :
>> > 
>> > Hi,
>> > 
>> > I installed Decanter 2.7.0 on Karaf 4.2.11 with JMX collector and 
>> > Prometheus appender features. I uncommented 
>> > "object.name.system=java.lang:*" in 
>> > org.apache.karaf.decanter.collector.jmx-local.cfg.
>> > 
>> > Where can I find JVM metrics like current heap memory usage? 
>> > 
>> > Regards
>> > -- 
>> > Daniel Łaś
>> > 
>> 

[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

Re: Felix/OSGi version on Karaf ?

[Jean-Baptiste Onofre]

Hi Vassil,

JVM/OSGi spec versions are listed here: http://karaf.apache.org/download.html 


Each Karaf branch supports specific OSGi spec.

For instance, you can see that Karaf 4.3.x is OSGi R7 (providing corresponding 
Felix and Equinox framework).

FYI, the wiki content is deprecated and you should use the documentation 
(http://karaf.apache.org/manual/latest/ 
).

You can change the framework using karaf.framework property in 
etc/config.properties.
FYI, config.properties is loaded by Karaf Main (including jre.properties and 
custom.properties).

Regards
JB

> Le 15 mai 2021 à 20:18, Васил Зорев  a écrit :
> 
> Hello,
> 
> I know this is probably one of the first questions that comes to a Karaf 
> user, but still:
> 
> Where is defined the Felix framework version that a Karaf installation uses?
> 
> 0 | Active   |   0 | 6.0.4  | System Bundle   
>   | 
> org.apache.felix.framework
> 
> https://cwiki.apache.org/confluence/display/KARAF/How+do+I+choose+between+Felix+and+Equinox
>  
> 
> Based on this Wiki, I found it in etc/config.properties.
> 
> karaf.framework.felix=mvn\:org.apache.felix/org.apache.felix.framework/6.0.4
> Is this how the felix version can be changed ? Can it be changed at all ?
> 
> Also a question on OSGi versions and their backward compatibility. How is the 
> OSGi version related to the Felix (or Equinox) version? In the same config 
> file I found for example:
> 
> org.osgi.framework.system.packages= \
>  ...
>  org.osgi.framework;version="1.9",\
> 
> Does this affect some manifest header or? I am only familiar with major OSGi 
> specification versions - 4,6,7 etc. don't know what 1.9 refers to. Can the 
> Karaf OSGi version be changed (for example to another major release - 4 or 6) 
> or is it fixed and not backward-compatible?
> 
> Sorry for the many questions. If there is documentation regarding this please 
> relate it, I will gladly read it myself.
> 
> Regards,
> Vassil

Re: instance:list causes warning

[Jean-Baptiste Onofre]

Hi Steven,

Thanks for the update, I will try on a Windows VM.

Regards
JB

> Le 14 mai 2021 à 14:00, Steven Huypens  a écrit :
> 
> Hi Eric,
> 
> Thanks for testing. I tried the vanilla Karaf myself now. Downloaded it and 
> used start.bat to start Karaf. Then used client.bat to get the console and 
> executed "instance:list", then executed "log:display" to see the logging.
> 
> - On Windows 10 and Windows 8 I got the exceptionCaught-WARN
> - On Ubuntu there was no warning at all (used the shell scripts)
> 
> It's nog big deal for me, just wanted to let you know..
> 
> Best regards,
> Steven
> 
> On Thu, May 13, 2021 at 6:06 PM Eric Lilja  <mailto:mindcoo...@gmail.com>> wrote:
> I tried this with a vanilla Karaf 4.2.11 under Windows 10, using Cygwin as 
> shell. I've simply unpacked the zip file to the root of my main drive.
> 
> I started Karaf with the "karaf" shell script (not the .bat-file).
> 
> instance:list produced no warning in console itself or in the karaf.log file 
> under data/log
> 
> Unrelated, but FYI JB: However, I did see a weird warning when starting karaf 
> using the shell script, see below:
> 
> $ ./karaf
> : integer expression expected <---
> __ __  
>/ //_/ __ _/ __/
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/
> 
>   Apache Karaf (4.2.11)
> 
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> 
> karaf@root()>
> 
> - Eric L
> 
> 
> On Wed, May 12, 2021 at 7:05 PM JB Onofré  <mailto:j...@nanthrax.net>> wrote:
> Hi
> 
> Forgot to check, sorry about that. I will keep you posted. 
> 
> Regards 
> JB
> 
>> Le 12 mai 2021 à 19:01, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> 
>> Hi Jean-Baptiste,
>> 
>> Did you manage to reproduce this ?
>> 
>> Kind regards,
>> Steven
>> 
>> On Tue, May 4, 2021 at 2:10 PM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi
>> 
>> Thanks for the update. Let me try to reproduce it. I keep you posted.
>> 
>> Regards
>> JB
>> 
>>> Le 4 mai 2021 à 14:07, Steven Huypens >> <mailto:steven.huyp...@gmail.com>> a écrit :
>>> 
>>> Hi,
>>> 
>>> - etc/org.apache.karaf.shell.cfg is the default Karaf file
>>> - In etc/users.properties I had replaced the default Karaf user by my own 
>>> 'admin' with encrypted password. After reverting to the default 
>>> users.properties, and disabling encryption in org.apache.karaf.jaas.cfg, 
>>> the logline still appeared.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Tue, May 4, 2021 at 1:43 PM Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> wrote:
>>> Hi,
>>> 
>>> What do you have in etc/org.apache.karaf.shell.cfg or etc/users.properties ?
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 4 mai 2021 à 12:18, Steven Huypens >>> <mailto:steven.huyp...@gmail.com>> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> When executing the command "instance:list" on our custom Karaf 4.2.11 
>>>> distro (based on 'standard'), we see the following warning in the logfile.
>>>> 
>>>> 2021-05-04 12:07:12,138 - 
>>>> [o.a.s.s.s.ServerSessionImpl][sshd-SshServer[44db67ef](port=8101)-nio2-thread-2]
>>>>  WARN  - 
>>>> exceptionCaught(ServerSessionImpl[null@/127.0.0.1:54060])[state=Opened] 
>>>> IOException: De software op uw hostcomputer heeft een verbinding verbroken
>>>> 
>>>> It looks like an shh-connection is being made with username 'null', which 
>>>> obviously fails.
>>>> 
>>>> This WARN is also logged when accessing the InstancesMBean, for instance 
>>>> by the decanter-collector-jmx.This means we see the WARN regularly in our 
>>>> logs.
>>>> 
>>>> I would like to prevent this WARN-logline from being logged, but didn't 
>>>> find a way to configure the default username, nor to disable the Mbean.
>>>> 
>>>> Any suggestions ?
>>>> 
>>>> Kind regards,
>>>> Steven 
>>> 
>> 

Re: instance:list causes warning

[Jean-Baptiste Onofre]

Hi Eric,

Thanks for the update.

Let me check about the shell warn message.

Regards
JB

> Le 13 mai 2021 à 18:05, Eric Lilja  a écrit :
> 
> I tried this with a vanilla Karaf 4.2.11 under Windows 10, using Cygwin as 
> shell. I've simply unpacked the zip file to the root of my main drive.
> 
> I started Karaf with the "karaf" shell script (not the .bat-file).
> 
> instance:list produced no warning in console itself or in the karaf.log file 
> under data/log
> 
> Unrelated, but FYI JB: However, I did see a weird warning when starting karaf 
> using the shell script, see below:
> 
> $ ./karaf
> : integer expression expected <---
> __ __  
>/ //_/ __ _/ __/
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/
> 
>   Apache Karaf (4.2.11)
> 
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
> 
> karaf@root()>
> 
> - Eric L
> 
> 
> On Wed, May 12, 2021 at 7:05 PM JB Onofré  <mailto:j...@nanthrax.net>> wrote:
> Hi
> 
> Forgot to check, sorry about that. I will keep you posted. 
> 
> Regards 
> JB
> 
>> Le 12 mai 2021 à 19:01, Steven Huypens > <mailto:steven.huyp...@gmail.com>> a écrit :
>> 
>> 
>> Hi Jean-Baptiste,
>> 
>> Did you manage to reproduce this ?
>> 
>> Kind regards,
>> Steven
>> 
>> On Tue, May 4, 2021 at 2:10 PM Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> wrote:
>> Hi
>> 
>> Thanks for the update. Let me try to reproduce it. I keep you posted.
>> 
>> Regards
>> JB
>> 
>>> Le 4 mai 2021 à 14:07, Steven Huypens >> <mailto:steven.huyp...@gmail.com>> a écrit :
>>> 
>>> Hi,
>>> 
>>> - etc/org.apache.karaf.shell.cfg is the default Karaf file
>>> - In etc/users.properties I had replaced the default Karaf user by my own 
>>> 'admin' with encrypted password. After reverting to the default 
>>> users.properties, and disabling encryption in org.apache.karaf.jaas.cfg, 
>>> the logline still appeared.
>>> 
>>> Best regards,
>>> Steven
>>> 
>>> On Tue, May 4, 2021 at 1:43 PM Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> wrote:
>>> Hi,
>>> 
>>> What do you have in etc/org.apache.karaf.shell.cfg or etc/users.properties ?
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 4 mai 2021 à 12:18, Steven Huypens >>> <mailto:steven.huyp...@gmail.com>> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> When executing the command "instance:list" on our custom Karaf 4.2.11 
>>>> distro (based on 'standard'), we see the following warning in the logfile.
>>>> 
>>>> 2021-05-04 12:07:12,138 - 
>>>> [o.a.s.s.s.ServerSessionImpl][sshd-SshServer[44db67ef](port=8101)-nio2-thread-2]
>>>>  WARN  - 
>>>> exceptionCaught(ServerSessionImpl[null@/127.0.0.1:54060])[state=Opened] 
>>>> IOException: De software op uw hostcomputer heeft een verbinding verbroken
>>>> 
>>>> It looks like an shh-connection is being made with username 'null', which 
>>>> obviously fails.
>>>> 
>>>> This WARN is also logged when accessing the InstancesMBean, for instance 
>>>> by the decanter-collector-jmx.This means we see the WARN regularly in our 
>>>> logs.
>>>> 
>>>> I would like to prevent this WARN-logline from being logged, but didn't 
>>>> find a way to configure the default username, nor to disable the Mbean.
>>>> 
>>>> Any suggestions ?
>>>> 
>>>> Kind regards,
>>>> Steven 
>>> 
>> 

Re: Karaf and camel amqp

[Jean-Baptiste Onofre]

Yeah, and my point is that parallelProcessing created new Exchanges, so, as I 
would test with "forcing" the connection factory.

Did you try ?

Regards
JB

> Le 10 mai 2021 à 15:34, michael e  a écrit :
> 
> Ok thanks for the response but first as i explained the connection is used 
> (autoDetectConnectionFactory=true by default) and work but not when i do 
> parallel processing 
> Second even doing that i got the exception
> 
> `"=#pooledConnectionFactoryFactory"`
> 
> interface="org.ops4j.pax.jms.service.PooledConnectionFactoryFactory"
>filter="((pool=pooledjms)(xa=false))"/>
> 
> 
> Michael.
> 
> De : Jean-Baptiste Onofre 
> Envoyé : lundi 10 mai 2021 15:21
> À : user 
> Objet : Re: Karaf and camel amqp
>  
> Just using service is not enough: you have to specify the connection factory 
> on the URI.
> 
> Regards
> JB
> 
>> Le 10 mai 2021 à 14:59, michael e > <mailto:michaelel...@outlook.fr>> a écrit :
>> 
>> karaf@root()> service:list javax.jms.ConnectionFactory
>> [javax.jms.ConnectionFactory]
>> -
>>  connectionFactoryType = ConnectionFactory
>>  felix.fileinstall.filename = 
>> file:/D:/karaf/apache-karaf-4.3.1/etc/org.ops4j.connectionfactory-amqp.cfg
>>  jms.password = admin
>>  jms.url = amqp://localhost:5672 
>> 
>>  jms.username = admin
>>  name = jms/amqp
>>  osgi.jndi.service.name = jms/amqp
>>  pax.jms.managed = true
>>  pool.blockIfSessionPoolIsFull = true
>>  pool.idleTimeout = 100
>>  pool.maxConnections = 123
>>  protocol = amqp
>>  service.bundleid = 268
>>  service.factoryPid = org.ops4j.connectionfactory
>>  service.id <http://service.id/> = 352
>>  service.pid = 
>> org.ops4j.connectionfactory.6fc1ffd0-4842-4237-b7bf-f2fa8038cefe
>>  service.scope = singleton
>>  type = artemis
>> Provided by :
>>  OPS4J Pax JMS Config (268)
>> Used by:
>>  INTEG :: SCHEDULER (140)
>> 
>> By bunle (140) already use the service as i explained in my message i get 
>> exception only when i use parallelProcessing() like there is no pool of 
>> connections i don't see anything in camel amqp or jms that allow to control 
>> producer threads 
>> 
>> Michael.
>> 
>>   
>> De : michael e mailto:michaelel...@outlook.fr>>
>> Envoyé : lundi 10 mai 2021 13:49
>> À : user@karaf.apache.org <mailto:user@karaf.apache.org> 
>> mailto:user@karaf.apache.org>>
>> Objet : Karaf and camel amqp
>>  
>> Hello,
>> 
>> I'm getting in trouble trying to use camel amqp with karaf
>> 
>> I have a simple route when i use parrallel processing i got  Trace: 
>> java.lang.IllegalArgumentException: connectionFactory must be specified.
>> 
>> Some messages are sended 
>> 
>> from(getInput())
>> .routeId(TO_BROKER_ROUTE_ID)
>> 
>> .process().message(ToBrokerProcessor::setContextHeaders)
>> .recipientList("amqp:queue1", 
>> "amqp:queue2").parallelProcessing();
>> 
>> 
>> i use jmsconnectionFactory 
>> 
>> connectionFactoryType = ConnectionFactory
>> name = jms/amqp
>> osgi.jndi.service.name = jms/amqp
>> type = artemis
>> protocol = amqp
>> jms.url = amqp://localhost:5672 
>> 
>> jms.username = admin
>> jms.password = admin
>> pool = pooledjms
>> xa = false
>> pool.idleTimeout = 100
>> pool.maxConnections = 1
>> pool.blockIfSessionPoolIsFull = true
>> 
>> (i use rabbitMq with amqp 1.0)
>> 
>> 
>> 
>> Michael.

Re: Karaf and camel amqp

[Jean-Baptiste Onofre]

Just using service is not enough: you have to specify the connection factory on 
the URI.

Regards
JB

> Le 10 mai 2021 à 14:59, michael e  a écrit :
> 
> karaf@root()> service:list javax.jms.ConnectionFactory
> [javax.jms.ConnectionFactory]
> -
>  connectionFactoryType = ConnectionFactory
>  felix.fileinstall.filename = 
> file:/D:/karaf/apache-karaf-4.3.1/etc/org.ops4j.connectionfactory-amqp.cfg
>  jms.password = admin
>  jms.url = amqp://localhost:5672 
>  jms.username = admin
>  name = jms/amqp
>  osgi.jndi.service.name = jms/amqp
>  pax.jms.managed = true
>  pool.blockIfSessionPoolIsFull = true
>  pool.idleTimeout = 100
>  pool.maxConnections = 123
>  protocol = amqp
>  service.bundleid = 268
>  service.factoryPid = org.ops4j.connectionfactory
>  service.id  = 352
>  service.pid = 
> org.ops4j.connectionfactory.6fc1ffd0-4842-4237-b7bf-f2fa8038cefe
>  service.scope = singleton
>  type = artemis
> Provided by :
>  OPS4J Pax JMS Config (268)
> Used by:
>  INTEG :: SCHEDULER (140)
> 
> By bunle (140) already use the service as i explained in my message i get 
> exception only when i use parallelProcessing() like there is no pool of 
> connections i don't see anything in camel amqp or jms that allow to control 
> producer threads 
> 
> Michael.
> 
> De : michael e 
> Envoyé : lundi 10 mai 2021 13:49
> À : user@karaf.apache.org 
> Objet : Karaf and camel amqp
>  
> Hello,
> 
> I'm getting in trouble trying to use camel amqp with karaf
> 
> I have a simple route when i use parrallel processing i got  Trace: 
> java.lang.IllegalArgumentException: connectionFactory must be specified.
> 
> Some messages are sended 
> 
> from(getInput())
> .routeId(TO_BROKER_ROUTE_ID)
> 
> .process().message(ToBrokerProcessor::setContextHeaders)
> .recipientList("amqp:queue1", "amqp:queue2").parallelProcessing();
> 
> 
> i use jmsconnectionFactory 
> 
> connectionFactoryType = ConnectionFactory
> name = jms/amqp
> osgi.jndi.service.name = jms/amqp
> type = artemis
> protocol = amqp
> jms.url = amqp://localhost:5672
> jms.username = admin
> jms.password = admin
> pool = pooledjms
> xa = false
> pool.idleTimeout = 100
> pool.maxConnections = 1
> pool.blockIfSessionPoolIsFull = true
> 
> (i use rabbitMq with amqp 1.0)
> 
> 
> 
> Michael.

Re: Karaf and camel amqp

[Jean-Baptiste Onofre]

Hi,

Camel-amqp is based on JMS.

The ConnectionFactory can be registered as a service, and then you specify the 
ConnectionFactory on the URI directly:

.recipientList("amqp:queue1?connectionFactory=#connectionFactory")

You register the connection factory on the Camel Context (depending if you use 
Default or OSGi camel context).

Regards
JB

> Le 10 mai 2021 à 13:49, michael e  a écrit :
> 
> Hello,
> 
> I'm getting in trouble trying to use camel amqp with karaf
> 
> I have a simple route when i use parrallel processing i got  Trace: 
> java.lang.IllegalArgumentException: connectionFactory must be specified.
> 
> Some messages are sended 
> 
> from(getInput())
> .routeId(TO_BROKER_ROUTE_ID)
> 
> .process().message(ToBrokerProcessor::setContextHeaders)
> .recipientList("amqp:queue1", "amqp:queue2").parallelProcessing();
> 
> 
> i use jmsconnectionFactory 
> 
> connectionFactoryType = ConnectionFactory
> name = jms/amqp
> osgi.jndi.service.name = jms/amqp
> type = artemis
> protocol = amqp
> jms.url = amqp://localhost:5672 
> jms.username = admin
> jms.password = admin
> pool = pooledjms
> xa = false
> pool.idleTimeout = 100
> pool.maxConnections = 1
> pool.blockIfSessionPoolIsFull = true
> 
> (i use rabbitMq with amqp 1.0)
> 
> 
> 
> Michael.

Re: karaf clean but keeping the data/log?

[Jean-Baptiste Onofre]

Hi Daniel,

For the record: https://issues.apache.org/jira/browse/KARAF-7146 


Regards
JB

> Le 7 mai 2021 à 18:47, Daniel Krügler  a écrit :
> 
> Am 05.05.2021 um 19:18 schrieb Daniel Krügler:
>> Hi,
>> 
>> Thanks, JB, for the quick response. Personally I would strongly speak in
>> favour for such an alternative clean option. I'm aware of the
>> alternative option to define the log folder outside the data folder, but
>> since we use our karaf system with several other programs that rely on
>> the existing structure to some extend, we currently guess that moving
>> the log folder could possibly break these programs.
>> 
>> Thanks again, a Jira issue would be very much appreciated!
> 
> A friendly reminder: It would be great to have such a feature request
> added as Jira issue, JB.
> 
> Thanks again,
> 
> - Daniel
> 
>> 
>> - Daniel
>> 
>> Am 05.05.2021 um 18:59 schrieb JB Onofré:
>>> Hi
>>> 
>>> Unfortunately no. However as a workaround you can move log outside of
>>> the data folder (karaf_log).
>>> 
>>> If you think it would help to add new clean option, please let me
>>> know I will create the jira.
>>> 
>>> Regards
>>> JB
>>> 
 Le 5 mai 2021 à 18:56, Daniel Krügler  a
 écrit :
 
 Hi,
 
 According to the karaf documentation, executing karaf with the "clean"
 command line parameter has the effect to delete the complete data
 folder. Does there exist a "weaker" clean option that has the same
 effect *except* that it leaves the content of the data/log folder
 intact?
 
 Thanks,
 
 - Daniel
>> 
> 

Re: Configuring MDC logging karaf 4 camel 3.7.0

[Jean-Baptiste Onofre]

Hi

Thanks for sharing. It should work anyway without default as soon as you have a 
context available.

Regards
JB

> Le 7 mai 2021 à 11:17, michael e  a écrit :
> 
> Finally using default value fix the situation 
> 
> \$\\\{ctx:camel.contextId:-default\}
> 
> interesting doc: 
> https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499613746/Configuring+Log4J2
>  
> <https://ops4j1.jira.com/wiki/spaces/paxlogging/pages/499613746/Configuring+Log4J2>
> 
> Thanks
> Michael.
> 
> De : michael e mailto:michaelel...@outlook.fr>>
> Envoyé : jeudi 6 mai 2021 17:23
> À : user mailto:user@karaf.apache.org>>
> Objet : RE: Configuring MDC logging karaf 4 camel 3.7.0
>  
> Hello All,
> 
> I still have bugs (by the way is terribly complex configuration with no clear 
> documentation).
> Here my configuration
> 
> log4j2.appender.sift.type = Routing
> log4j2.appender.sift.name = Routing
> log4j2.appender.sift.routes.type = Routes
> log4j2.appender.sift.routes.pattern = \$\$\\\{ctx:camel.contextId\}
> log4j2.appender.sift.routes.bundle.type = Route
> log4j2.appender.sift.routes.bundle.appender.type = RollingRandomAccessFile
> log4j2.appender.sift.routes.bundle.appender.name = 
> Bundle-\$\\\{ctx:camel.contextId\}
> log4j2.appender.sift.routes.bundle.appender.fileName = 
> ${karaf.log}/bundle-\$\\\{ctx:camel.contextId\}.log
> log4j2.appender.sift.routes.bundle.appender.filePattern = 
> ${karaf.log}/bundle-\$\\\{ctx:camel.contextId\}.log.%i
> log4j2.appender.sift.routes.bundle.appender.append = true
> log4j2.appender.sift.routes.bundle.appender.layout.type = PatternLayout
> log4j2.appender.sift.routes.bundle.appender.layout.pattern = ${log4j2.pattern}
> log4j2.appender.sift.routes.bundle.appender.policies.type = Policies
> log4j2.appender.sift.routes.bundle.appender.policies.size.type = 
> SizeBasedTriggeringPolicy
> log4j2.appender.sift.routes.bundle.appender.policies.size.size = 8MB
> 
> The problem is at startup and shutdown all bundle that doesn't have 
> camelContext cause this errors
> ...
> e-${ctx:camel.contextId:bundle.name}.log] with data 
> [org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager$FactoryData@74c3f4fd]
> org.ops4j.pax.logging.pax-logging-api [log4j2] ERROR : Unable to invoke 
> factory method in class 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for 
> element RollingRandomAccessFile: java.lang.IllegalStateException: No factory 
> method found for class 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender
> org.ops4j.pax.logging.pax-logging-api [log4j2] ERROR : Cannot access 
> RandomAccessFile java.io.IOException: La syntaxe du nom de fichier, de 
> répertoire ou de volume est incorrecte
> org.ops4j.pax.logging.pax-logging-api [log4j2] ERROR : Could not create 
> plugin of type class 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for 
> element RollingRandomAccessFile: java.lang.IllegalStateException: 
> ManagerFactory 
> [org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager$RollingRandomAccessFileManagerFactory@69cf227a]
>  unable to create manager for 
> [D:\karaf\apache-karaf-4.3.1\data\log/bundle-${ctx:camel.contextId:bundle.name}.log]
>  with data 
> [org.apache.logging.log4j.core.appender.rolling.RollingRandomAccessFileManager$FactoryData@59ab51cc]
> org.ops4j.pax.logging.pax-logging-api [log4j2] ERROR : Unable to invoke 
> factory method in class 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender for 
> element RollingRandomAccessFile: java.lang.IllegalStateException: No factory 
> method found for class 
> org.apache.logging.log4j.core.appender.RollingRandomAccessFileAppender
> 
> 
> My question is how i can provide default key or something like to avoid this 
> errors in my karaf ?
> Michael.
> 
> De : michael e 
> Envoyé : vendredi 22 janvier 2021 15:16
> À : user 
> Objet : RE: Configuring MDC logging karaf 4 camel 3.7.0
>  
> Hi JB,
> 
> I confirm, (for testing you can use my desktop).
> 
> Regards,
> Michael.
> 
> De : Jean-Baptiste Onofre 
> Envoyé : vendredi 22 janvier 2021 06:09
> À : user 
> Objet : Re: Configuring MDC logging karaf 4 camel 3.7.0
>  
> Hi Michael,
> 
> I’ve resumed my test about Camel MDC.
> 
> So, I created a simple route like this:
> 
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0 
> <http://www.osgi.org/xmlns/blueprint/v1.0.0>">
> 
>   http://camel.apache.org/schema/blueprint 
> <http://camel.apache.org/schema/blueprint>" useMDCLogging="true">
> 
>   
>   Hello World
> 

Re: Weird sshd-SshServer SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after messages

[Jean-Baptiste Onofre]

Hi Oleg,

Thanks for the update ;)

Regards
JB

> Le 6 mai 2021 à 18:01, Oleg Cohen  a écrit :
> 
> Hi JB,
> 
> Definitely my problem :-) Was able to figure it out. Wrong port for the POD 
> monitoring.
> 
> Thank you!
> Oleg
> 
>> On May 6, 2021, at 10:24 AM, Oleg Cohen  wrote:
>> 
>> Hi JB,
>> 
>> I didn’t install anything specific. No Decanter. Is there a way to trace and 
>> see where the SSH requests are coming from?
>> 
>> Thank you!
>> Oleg
>> 
>>> On May 6, 2021, at 10:10 AM, Jean-Baptiste Onofre  wrote:
>>> 
>>> Hi Oleg,
>>> 
>>> Maybe you have a monitoring solution (as Decanter) that pull the MBean, and 
>>> so perform ssh connection when listing the instances in the InstanceMBean.
>>> 
>>> It seems that something tries a ssh connect ;)
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 6 mai 2021 à 15:53, Oleg Cohen  a écrit :
>>>> 
>>>> Greetings,
>>>> 
>>>> I started a new karat instance in a Kubernetes pod from a custom distro.
>>>> 
>>>> I am seeing the following set of messages in the log every few seconds. 
>>>> 
>>>> 2021-05-06T13:49:30,946 | INFO  | 
>>>> sshd-SshServer[7467ccad](port=8101)-timer-thread-1 | ServerSessionImpl 
>>>>| 309 - org.apache.sshd.osgi - 2.5.1 | 
>>>> Disconnecting(ServerSessionImpl[null@/169.254.175.250:49648]): 
>>>> SSH2_DISCONNECT_PROTOCOL_ERROR - Detected AuthTimeout after 120034/12 
>>>> ms.
>>>> 2021-05-06T13:49:30,946 | WARN  | 
>>>> sshd-SshServer[7467ccad](port=8101)-timer-thread-1 | ServerSessionImpl 
>>>>| 309 - org.apache.sshd.osgi - 2.5.1 | 
>>>> disconnect(ServerSessionImpl[null@/169.254.175.250:49648]) operation 
>>>> failed (IOException) for reason=SSH2_DISCONNECT_PROTOCOL_ERROR [Detected 
>>>> AuthTimeout after 120034/12 ms.]: Broken pipe
>>>> 2021-05-06T13:49:30,946 | WARN  | 
>>>> sshd-SshServer[7467ccad](port=8101)-nio2-thread-2 | ServerSessionImpl  
>>>>   | 309 - org.apache.sshd.osgi - 2.5.1 | 
>>>> exceptionCaught(ServerSessionImpl[null@/169.254.175.250:49648])[state=Opened]
>>>>  IOException: Broken pipe
>>>> 
>>>> The pod is completely isolated.
>>>> 
>>>> Wonder if anybody has encountered this behavior before?
>>>> 
>>>> Thank you!
>>>> Oleg
>>> 
>> 
> 

Re: Karaf is not finding org.osgi.util.function and fails to start

[Jean-Baptiste Onofre]

Hi Alex,

Yes, the version is not correct. I would check your feature / pom.xml, maybe 
you don’t have version defined, so it takes the latest one.

Regards
JB

> Le 6 mai 2021 à 18:56, Alex Soto  a écrit :
> 
> 
> I see…  
> 
> Karaf is looking for wrap version 2.6.7, but the version the  framework 
> feature brings  is version is 2.6.2, so it does not find it.
> However, I don’t know who is pulling version 2.6.7.  Will search for that...
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 6, 2021, at 10:15 AM, Alex Soto > <mailto:alex.s...@envieta.com>> wrote:
>> 
>> Thanks, JB, 
>> 
>> but I don’t understand.  When I inspect my 
>> /etc/org.apache.karaf.features.cfg  file:
>> 
>> #
>> # Comma separated list of features repositories to register by default
>> #
>> featuresRepositories = \
>> mvn:org.apache.karaf.features/standard/4.3.0/xml/features, \
>> mvn:org.apache.karaf.features/framework/4.3.0/xml/features, ...
>> 
>> #
>> # Comma separated list of features to install at startup
>> #
>> featuresBoot = \
>> (wrap), \
>> package/4.3.1, \
>> log/4.3.1, \
>> ssh/4.3.1, \
>> framework/4.3.0, \
>> system/4.3.1, \
>>  ...
>> 
>> 
>> 
>> The framework feature is there.
>> 
>> Also there is the jar:  
>> /system/org/osgi/org.osgi.util.function/1.0.0/org.osgi.util.function-1.0.0.jar
>>  
>> 
>> So, what do I need to do?
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On May 6, 2021, at 9:59 AM, Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> wrote:
>>> 
>>> Hi,
>>> 
>>> osgi.function is part of the framework feature:
>>> 
>>> https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml#L34
>>>  
>>> <https://github.com/apache/karaf/blob/main/assemblies/features/framework/src/main/feature/feature.xml#L34>
>>> 
>>> That’s for Karaf 4.3.1/4.3.2.
>>> 
>>> For 4.3.0, it’s there but in version 1.0.0:
>>> 
>>> https://repo1.maven.org/maven2/org/apache/karaf/features/framework/4.3.0/framework-4.3.0-features.xml
>>>  
>>> <https://repo1.maven.org/maven2/org/apache/karaf/features/framework/4.3.0/framework-4.3.0-features.xml>
>>> 
>>> Regards
>>> JB
>>> 
>>>> Le 6 mai 2021 à 17:36, Alex Soto >>> <mailto:alex.s...@envieta.com>> a écrit :
>>>> 
>>>> Hello,
>>>> 
>>>> Using a custom distribution, based on  Karaf version 4.3.0, I am getting 
>>>> the following error, and Karaf would not start:
>>>> 
>>>> 
>>>> $ bin/karaf 
>>>> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: 
>>>> missing requirement [root] osgi.identity; osgi.identity=wrap; 
>>>> type=karaf.feature; version="[2.6.7,2.6.7]"; 
>>>> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=2.6.7)(version<=2.6.7))"
>>>>  [caused by: Unable to resolve wrap/2.6.7: missing requirement 
>>>> [wrap/2.6.7] osgi.identity; osgi.identity=pax-url-wrap; 
>>>> type=karaf.feature; version="[2.6.7,2.6.7]" [caused by: Unable to resolve 
>>>> pax-url-wrap/2.6.7: missing requirement [pax-url-wrap/2.6.7] 
>>>> osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; 
>>>> version="[2.6.7,2.6.7]"; resolution:=mandatory [caused by: Unable to 
>>>> resolve org.ops4j.pax.url.wrap/2.6.7: missing requirement 
>>>> [org.ops4j.pax.url.wrap/2.6.7] osgi.wiring.package; 
>>>> filter:="(&(osgi.wiring.package=org.osgi.util.function)(version>=1.1.0)(!(version>=2.0.0)))"]]]
>>>>at 
>>>> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
>>>>at 
>>>> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:434)
>>>>at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
>>>>at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
>>>>at 
>>>> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
>>>>at 
>>>> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:392)
>>>>at 
>>>> org.a

Re: Karaf is not finding org.osgi.util.function and fails to start

[Jean-Baptiste Onofre]

Hi,

osgi.function is part of the framework feature:

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


That’s for Karaf 4.3.1/4.3.2.

For 4.3.0, it’s there but in version 1.0.0:

https://repo1.maven.org/maven2/org/apache/karaf/features/framework/4.3.0/framework-4.3.0-features.xml
 


Regards
JB

> Le 6 mai 2021 à 17:36, Alex Soto  a écrit :
> 
> Hello,
> 
> Using a custom distribution, based on  Karaf version 4.3.0, I am getting the 
> following error, and Karaf would not start:
> 
> 
> $ bin/karaf 
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=wrap; 
> type=karaf.feature; version="[2.6.7,2.6.7]"; 
> filter:="(&(osgi.identity=wrap)(type=karaf.feature)(version>=2.6.7)(version<=2.6.7))"
>  [caused by: Unable to resolve wrap/2.6.7: missing requirement [wrap/2.6.7] 
> osgi.identity; osgi.identity=pax-url-wrap; type=karaf.feature; 
> version="[2.6.7,2.6.7]" [caused by: Unable to resolve pax-url-wrap/2.6.7: 
> missing requirement [pax-url-wrap/2.6.7] osgi.identity; 
> osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; 
> version="[2.6.7,2.6.7]"; resolution:=mandatory [caused by: Unable to resolve 
> org.ops4j.pax.url.wrap/2.6.7: missing requirement 
> [org.ops4j.pax.url.wrap/2.6.7] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.osgi.util.function)(version>=1.1.0)(!(version>=2.0.0)))"]]]
>   at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
>   at 
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:434)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:421)
>   at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:375)
>   at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:257)
>   at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:392)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1062)
>   at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:998)
>   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)
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve wrap/2.6.7: missing requirement [wrap/2.6.7] osgi.identity; 
> osgi.identity=pax-url-wrap; type=karaf.feature; version="[2.6.7,2.6.7]" 
> [caused by: Unable to resolve pax-url-wrap/2.6.7: missing requirement 
> [pax-url-wrap/2.6.7] osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; 
> type=osgi.bundle; version="[2.6.7,2.6.7]"; resolution:=mandatory [caused by: 
> Unable to resolve org.ops4j.pax.url.wrap/2.6.7: missing requirement 
> [org.ops4j.pax.url.wrap/2.6.7] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.osgi.util.function)(version>=1.1.0)(!(version>=2.0.0)))"]]
>   at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
>   ... 12 more
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve pax-url-wrap/2.6.7: missing requirement [pax-url-wrap/2.6.7] 
> osgi.identity; osgi.identity=org.ops4j.pax.url.wrap; type=osgi.bundle; 
> version="[2.6.7,2.6.7]"; resolution:=mandatory [caused by: Unable to resolve 
> org.ops4j.pax.url.wrap/2.6.7: missing requirement 
> [org.ops4j.pax.url.wrap/2.6.7] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.osgi.util.function)(version>=1.1.0)(!(version>=2.0.0)))"]
>   at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
>   ... 13 more
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve org.ops4j.pax.url.wrap/2.6.7: missing requirement 
> [org.ops4j.pax.url.wrap/2.6.7] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.osgi.util.function)(version>=1.1.0)(!(version>=2.0.0)))"
>   at 
> org.apache.felix.resolver.Candidates$MissingRequirementError.toException(Candidates.java:1341)
>   ... 14 more
> 
> 
> 
> Java version is:  openjdk version "11.0.11" 2021-04-20 LTS
> OS:  Linux version 3.10.0-1127.el7.x86_64 (mockbu...@kbuilder.bsys.centos.org 
> ) (gcc version 4.8.5 20150623 (Red 
> Hat 4.8.5-39) (GCC) ) #1 SMP Tue Mar 31 23:36:51 UTC 2020
> 
> 
> I have