Re: Change to bin/karaf clean
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
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
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 >
Change to bin/karaf clean
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
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 >
apache-karaf with logback
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
Hello JB, thank you for your help! The application is built with Java 8 and deploys fine if the Karaf runtime is Java 11, but runs into the deployment issue if the Karaf runtime is Java 8. We specifically picked Karaf 4.2 as it is supposed to support Java 8. And Camel 2.25 is Java 8 only as well. Which is why I am a bit confused about how we end up with a dependency to a javax API implementation that requires Java 9 as the runtime. There should be a way to force the use of the JDK implementation of the javax APIs? Apparently that worked alright with Karaf 4.0 from which I am trying to upgrade the application. Thanks again! Ralf On 22.12.21 08:18, Jean-Baptiste Onofre wrote: 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
