Re: Karaf 4.4.5 with camel freemarker

[Jean-Baptiste Onofré]

Hi

I will take a look.

Thanks
Regards
JB

Le sam. 20 avr. 2024 à 23:21, michael e  a écrit :

> I wasn't clear so I just open a ticket here
> https://issues.apache.org/jira/browse/KARAF-7826?orderby=affectedVersion+DESC%2C+cf%5B12310271%5D+ASC%2C+priority+DESC%2C+updated+DESC
>
> Michael.
>
> --
> *From:* michael e 
> *Sent:* Friday, April 19, 2024 6:47:58 PM
> *To:* user@karaf.apache.org 
> *Subject:* Karaf 4.4.5 with camel freemarker
>
> Hello,
>
> I use latest Karaf with latest camel available 3.22.1 + camel freemarker
> (3.22.1) and when i do
>
> <#list ['a', 'b', 'c'] as i>
>   ${i?counter}: ${i}
> 
>
>
> in my template the counter is just blank wich is work in Unit Test
> everything print well just not loop counter (i also try index and other)
> why ? I think is buggy just on Karaf run ?
>
> Michael.
>
>

Re: ClassNotFoundException => HttpOperationFailedException

[Jean-Baptiste Onofré]

Hi Michael

It's because of bnd: it can detect the import based on byte code. The
problem is that wildcard matches only for clearly defined import and
sometime failed to find the package (especially with split package).
Using a fully qualified package actually import the package.

Regards
JB


On Sun, Apr 7, 2024 at 10:15 PM Michael Elbaz  wrote:
>
> Ok I finally found that maven-bundle-plugin when using Import-Package * just 
> ignore this class don't understand why maybe because is related to excpetion 
> handling so i finally do
>
> org.apache.camel.http.base, *
>
> Wich it not ideal but work
>
> Le 07/04/2024 à 19:04, Michael Elbaz a écrit :
>
> Hello since many year i encounter this error: Caused by: 
> org.apache.camel.RuntimeCamelException: java.lang.ClassNotFoundException: 
> org.apache.camel.http.base.HttpOperationFailedException when using karaf + 
> camel (also see that 
> https://stackoverflow.com/questions/62170631/how-to-solve-java-lang-classnotfoundexceptionorg-apache-camel-http-common-httpo)
>  maybe i miss something ?
> I'm just trying to do this
>
> import org.apache.camel.http.base.HttpOperationFailedException;
>
> onException(HttpOperationFailedException.class)
>...
> .handled(true);
>
> But when i run my http route i see this exception happen and when i do some 
> seach using classes |grep 
> org.apache.camel.http.base.HttpOperationFailedException
>
> i see that class with exported true, so what the point ?
>
> Regards,
> Michael.
>
>

Re: Race between fileinstall and configadmin?

[Jean-Baptiste Onofré]

Thanks for the details Jim.

Does it happen in a docker container or directly on a machine ? How
performant is the machine ? (in order for me to reproduce).

Thanks !
Regards
JB

On Thu, Mar 28, 2024 at 1:44 PM James Ziesig  wrote:
>
> Hi JB,
>
> Thanks for looking into this.  Yes, I know that some of the files are immune 
> to the problem.  I could see that only some of the files in the etc directory 
> were modified between startup and the timestamp of the first log with ms 
> precision:
>
> "INFO  | s4j.pax.logging) | 2024-03-27T20:25:52,051 | 
> EventAdminConfigurationNotifier | .EventAdminConfigurationNotifier   48 | 
> gging.pax-logging-log4j2 |   | Sending Event Admin notification 
> (configuration successful) to org/ops4j/pax/logging/Configuration"
>
> I couldn't figure out how to enable fileinstall debug logging to see if it 
> was the one modifying the files, though.
>
> I've seen the problem happen with jmx, command, logging, feature service, and 
> our own configuration files.
>
> Hopefully you can identify the problem.
>
> Thanks again!
>
> Jim Ziesig
>
> On Thu, Mar 28, 2024 at 1:23 AM Jean-Baptiste Onofré  
> wrote:
>>
>> Hi Jim
>>
>> We did some improvements of potential race conditions between features
>> and config admin services. Remember some files in etc are not managed
>> by config admin (for instance startup.properties is used before the
>> services are actually started and not managed by config admin).
>>
>> Let me try to reproduce your test case and I will let you know.
>>
>> Thanks,
>> Regards
>> JB
>>
>> On Thu, Mar 28, 2024 at 4:48 AM James Ziesig  
>> wrote:
>> >
>> > Hello,
>> >
>> > I have been tracking a problem in recent versions of Karaf where random 
>> > configuration files in the etc directory are corrupted (or re-initialized) 
>> > during karaf initialization.  Most of the times that the problem occurs 
>> > all of the property settings are removed from the file, but sometimes the 
>> > file is re-initialized with properties in it (just not the values that 
>> > were present before startup).  This only seems to happen when the 
>> > apache-karaf-4.x.x/data directory is cleared out prior to startup 
>> > (something we do on install/upgrade or after an ungraceful shutdown).  The 
>> > issue seems to occur 3-5% of the time that Karaf is re-initialized.
>> >
>> > I have seen https://issues.apache.org/jira/browse/KARAF-6866 which covers 
>> > an example of the problem, but doesn't cover all cases.  It led me to try 
>> > a "fix" where I alter startup.properties to start fileinstall at level 9 
>> > so it starts before configadmin.  I have had 100% success with well over 
>> > 300 restarts with this configuration, but I don't know if that 
>> > rearrangement may lead to some other issue.  Is this a valid solution?
>> >
>> > This problem has occurred on various versions of CentOS/RHEL/Rocky Linux 
>> > (primarily 8.x).  My testing was done on Rocky Linux release 8.9 (Green 
>> > Obsidian), using OpenJDK 64-Bit Server VM Temurin-17.0.10+7.
>> >
>> > I have attached a simple bash script for reproduction.
>> >
>> > Reproduction steps:
>> > Extract apache-karaf-4.4.3.tar.gz.
>> > cd apache-karaf-4.4.3
>> > cp -r etc etc_orig
>> > rm -Rf data/*
>> > bin/start
>> > diff -r -w etc etc_orig/
>> > check if anything was already overwritten and reset etc with etc_orig if 
>> > it was and then repeat until etc looks good.
>> > cp -r etc etc_backup (for use by script)
>> > copy loop.sh to apache-karaf-4.4.3
>> > execute loop.sh
>> >
>> > Please let me know if you need any additional info.
>> >
>> > Thanks in advance,
>> >
>> > Jim Ziesig
>> >
>> > This electronic communication and the information and any files 
>> > transmitted with it, or attached to it, are confidential and are intended 
>> > solely for the use of the individual or entity to whom it is addressed and 
>> > may contain information that is confidential, legally privileged, 
>> > protected by privacy laws, or otherwise restricted from disclosure to 
>> > anyone else. If you are not the intended recipient or the person 
>> > responsible for delivering the e-mail to the intended recipient, you are 
>> > hereby notified that any use, copying, distributing, dissemination, 
>> > forwarding, printing, or copying of this e-mail is strictly prohibited.

Re: Race between fileinstall and configadmin?

[Jean-Baptiste Onofré]

Hi

KARAF-7389 should be fixed on Karaf 4.4.1, but Jim seems to have the
issue with 4.4.3.

So let me try to reproduce first.

Regards
JB

On Thu, Mar 28, 2024 at 8:17 AM Grzegorz Grzybek  wrote:
>
> Hello
>
> I can't check right now (Easter holidays) , but I can point you to similar 
> (same?) issue: https://issues.apache.org/jira/browse/KARAF-7389
>
> regards
> Grzegorz Grzybek
>
> czw., 28 mar 2024 o 06:23 Jean-Baptiste Onofré  napisał(a):
>>
>> Hi Jim
>>
>> We did some improvements of potential race conditions between features
>> and config admin services. Remember some files in etc are not managed
>> by config admin (for instance startup.properties is used before the
>> services are actually started and not managed by config admin).
>>
>> Let me try to reproduce your test case and I will let you know.
>>
>> Thanks,
>> Regards
>> JB
>>
>> On Thu, Mar 28, 2024 at 4:48 AM James Ziesig  
>> wrote:
>> >
>> > Hello,
>> >
>> > I have been tracking a problem in recent versions of Karaf where random 
>> > configuration files in the etc directory are corrupted (or re-initialized) 
>> > during karaf initialization.  Most of the times that the problem occurs 
>> > all of the property settings are removed from the file, but sometimes the 
>> > file is re-initialized with properties in it (just not the values that 
>> > were present before startup).  This only seems to happen when the 
>> > apache-karaf-4.x.x/data directory is cleared out prior to startup 
>> > (something we do on install/upgrade or after an ungraceful shutdown).  The 
>> > issue seems to occur 3-5% of the time that Karaf is re-initialized.
>> >
>> > I have seen https://issues.apache.org/jira/browse/KARAF-6866 which covers 
>> > an example of the problem, but doesn't cover all cases.  It led me to try 
>> > a "fix" where I alter startup.properties to start fileinstall at level 9 
>> > so it starts before configadmin.  I have had 100% success with well over 
>> > 300 restarts with this configuration, but I don't know if that 
>> > rearrangement may lead to some other issue.  Is this a valid solution?
>> >
>> > This problem has occurred on various versions of CentOS/RHEL/Rocky Linux 
>> > (primarily 8.x).  My testing was done on Rocky Linux release 8.9 (Green 
>> > Obsidian), using OpenJDK 64-Bit Server VM Temurin-17.0.10+7.
>> >
>> > I have attached a simple bash script for reproduction.
>> >
>> > Reproduction steps:
>> > Extract apache-karaf-4.4.3.tar.gz.
>> > cd apache-karaf-4.4.3
>> > cp -r etc etc_orig
>> > rm -Rf data/*
>> > bin/start
>> > diff -r -w etc etc_orig/
>> > check if anything was already overwritten and reset etc with etc_orig if 
>> > it was and then repeat until etc looks good.
>> > cp -r etc etc_backup (for use by script)
>> > copy loop.sh to apache-karaf-4.4.3
>> > execute loop.sh
>> >
>> > Please let me know if you need any additional info.
>> >
>> > Thanks in advance,
>> >
>> > Jim Ziesig
>> >
>> > This electronic communication and the information and any files 
>> > transmitted with it, or attached to it, are confidential and are intended 
>> > solely for the use of the individual or entity to whom it is addressed and 
>> > may contain information that is confidential, legally privileged, 
>> > protected by privacy laws, or otherwise restricted from disclosure to 
>> > anyone else. If you are not the intended recipient or the person 
>> > responsible for delivering the e-mail to the intended recipient, you are 
>> > hereby notified that any use, copying, distributing, dissemination, 
>> > forwarding, printing, or copying of this e-mail is strictly prohibited. If 
>> > you received this e-mail in error, please return the e-mail to the sender, 
>> > delete it from your computer, and destroy any printed copy of it.

Re: Race between fileinstall and configadmin?

[Jean-Baptiste Onofré]

Hi Jim

We did some improvements of potential race conditions between features
and config admin services. Remember some files in etc are not managed
by config admin (for instance startup.properties is used before the
services are actually started and not managed by config admin).

Let me try to reproduce your test case and I will let you know.

Thanks,
Regards
JB

On Thu, Mar 28, 2024 at 4:48 AM James Ziesig  wrote:
>
> Hello,
>
> I have been tracking a problem in recent versions of Karaf where random 
> configuration files in the etc directory are corrupted (or re-initialized) 
> during karaf initialization.  Most of the times that the problem occurs all 
> of the property settings are removed from the file, but sometimes the file is 
> re-initialized with properties in it (just not the values that were present 
> before startup).  This only seems to happen when the apache-karaf-4.x.x/data 
> directory is cleared out prior to startup (something we do on install/upgrade 
> or after an ungraceful shutdown).  The issue seems to occur 3-5% of the time 
> that Karaf is re-initialized.
>
> I have seen https://issues.apache.org/jira/browse/KARAF-6866 which covers an 
> example of the problem, but doesn't cover all cases.  It led me to try a 
> "fix" where I alter startup.properties to start fileinstall at level 9 so it 
> starts before configadmin.  I have had 100% success with well over 300 
> restarts with this configuration, but I don't know if that rearrangement may 
> lead to some other issue.  Is this a valid solution?
>
> This problem has occurred on various versions of CentOS/RHEL/Rocky Linux 
> (primarily 8.x).  My testing was done on Rocky Linux release 8.9 (Green 
> Obsidian), using OpenJDK 64-Bit Server VM Temurin-17.0.10+7.
>
> I have attached a simple bash script for reproduction.
>
> Reproduction steps:
> Extract apache-karaf-4.4.3.tar.gz.
> cd apache-karaf-4.4.3
> cp -r etc etc_orig
> rm -Rf data/*
> bin/start
> diff -r -w etc etc_orig/
> check if anything was already overwritten and reset etc with etc_orig if it 
> was and then repeat until etc looks good.
> cp -r etc etc_backup (for use by script)
> copy loop.sh to apache-karaf-4.4.3
> execute loop.sh
>
> Please let me know if you need any additional info.
>
> Thanks in advance,
>
> Jim Ziesig
>
> This electronic communication and the information and any files transmitted 
> with it, or attached to it, are confidential and are intended solely for the 
> use of the individual or entity to whom it is addressed and may contain 
> information that is confidential, legally privileged, protected by privacy 
> laws, or otherwise restricted from disclosure to anyone else. If you are not 
> the intended recipient or the person responsible for delivering the e-mail to 
> the intended recipient, you are hereby notified that any use, copying, 
> distributing, dissemination, forwarding, printing, or copying of this e-mail 
> is strictly prohibited. If you received this e-mail in error, please return 
> the e-mail to the sender, delete it from your computer, and destroy any 
> printed copy of it.

Re: Karaf 4.4.5 bouncycastle dependency bug

[Jean-Baptiste Onofré]

Hi Anthony

Good catch.
A simple workaround is to update bc bundles in the system repo and
update the features (a little painful but do-able).
I will fix that for 4.4.6 (I will create a Jira).

Thanks !
Regards
JB

On Thu, Mar 21, 2024 at 2:45 AM Anthony Wood  wrote:
>
> Hi,
>
> There seems to be a mismatch between the requirements of sshd-osgi 2.11.0 
> (via the ‘ssh’ feature) and the version of bouncycastle in Karaf 4.4.5, which 
> is 1.75:
>
> sshd-osgi 2.11.0 imports:
>   org.bouncycastle.asn1.pkcs {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.crypto.prng   {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.jce.provider  {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.openssl   {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.openssl.jcajce{version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.operator  {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.pkcs  {version=[1.76,2), 
> resolution:=optional}
>   org.bouncycastle.pkcs.jcajce   {version=[1.76,2), 
> resolution:=optional}
>
> Bouncycastle jars included in karaf 4.4.5:
>
> apache-karaf-4.4.5/system/org/bouncycastle/bcprov-jdk18on/1.75/bcprov-jdk18on-1.75.jar
> apache-karaf-4.4.5/system/org/bouncycastle/bcutil-jdk18on/1.75/bcutil-jdk18on-1.75.jar
> apache-karaf-4.4.5/system/org/bouncycastle/bcpkix-jdk18on/1.75/bcpkix-jdk18on-1.75.jar
>
> The result is that an RSA host key cannot be generated due to: 
> NoClassDefFoundError for org/bouncycastle/openssl/jcajce/JcaPEMWriter, even 
> when bcpkix-jdk18on 1.75 is installed by the feature.
>
> We have worked around it by overriding the feature, but it would be great for 
> this to be addressed in a 4.4.6 release.
>
> Thanks,
> Anthony

Re: Can a DS component expose multiple services?

[Jean-Baptiste Onofré]

Hi,

Yes, it' possible to have several services by component (imho, it
should be avoided when possible to avoid unexpected cascading
refresh).

A component can implement multiple interfaces, and the @Component
annotation accepts the list of exposed interfaces.

Regards
JB

On Sat, Mar 16, 2024 at 7:44 AM Steinar Bang  wrote:
>
> Can a Java class implementing a DS component expose more than one
> OSGi service?
>
> My usecase is that I have a DS component implementing a servlet Filter,
> plugging into the web whiteboard.
>  
> https://github.com/steinarb/oldalbum/blob/master/oldalbum.web.security/src/main/java/no/priv/bang/oldalbum/web/security/OldAlbumShiroFilter.java#L35
>
> And then I would like a way to retrigger configuration of the filter and
> the simplest way would be if the filter could expose a service with a
> method that could be used to trigger reconfiguration.
>
> What if I subtype the Filter interface with a new interface and expose
> that interface from the component, would still be able to "find" the web
> whiteboard? (I think not, because if I remember correctly if a class
> does not directly implement an interface, the interface for the service
> must be specified in @Component annotation...?)
>
> Hm... looks like the service parameter of @Component can be an array...?
>  
> https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#org.osgi.service.component.annotations.Component.service--
>
> I'll try.
>
> Hm... looks like the Filter interface has an init() method...?
>  
> https://docs.oracle.com/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/javax/servlet/Filter.html#init(javax.servlet.FilterConfig)
>
> Could that be used, I wonder?
>
> No, implemented by shiro AbstractFilter, probably best not to mess with
> that...?
>
> So: I will try a new interface with a single callback method and inject
> that service into a REST endpoint and see if I can make the filter
> reconfigure itself.
>

Re: Programmatically restart bundle and/or component?

[Jean-Baptiste Onofré]

Hi Steinar,

You can create a controller for instance by leveraging event admin (to
send an event triggering the reload, and the bundle decides what he
wants to reload). Pros, you control exactly what you want to reload.
Cons, you need to implement your Event handler.
Another option would be to define a dependency between components (via
@Reference). That's probably the cleaner option, but it will do a full
refresh.

Regards
JB

On Fri, Mar 15, 2024 at 5:37 PM Steinar Bang  wrote:
>
> I have this bundle:
>  https://github.com/steinarb/oldalbum/tree/master/oldalbum.web.security
>
> which contains two DS/SCR components:
>
>  1. A component implementing ServletContextHelper used to define the
> servlet context
>  
> https://github.com/steinarb/oldalbum/blob/master/oldalbum.web.security/src/main/java/no/priv/bang/oldalbum/web/security/OldAlbumServletContextHelper.java
>
>  2. A component implementing a Shiro servlet Filter
>  
> https://github.com/steinarb/oldalbum/blob/master/oldalbum.web.security/src/main/java/no/priv/bang/oldalbum/web/security/OldAlbumShiroFilter.java#L35
>
> I would like to reload the shiro servlet filter programmatically when
> its configuration changes.
>
> What's the best way of doing that?
>
> Reload the entire bundle?
>
> Reload just the filter component?
>
> Make the filter reinitialize itself without reloading?
>
> Has anyone done anything similar?
>
> Suggestions? Ideas? All are welcome!
>
> Thanks!
>
>
> - Steinar
>

Re: java.lang.NoClassDefFoundError: javax/net/ssl/TrustManager

[Jean-Baptiste Onofré]

Hi Michael

It looks like a ClassLoading issue (the import is there but the class
comes from another classloader).

Did you try to set the TCCL just before creating the vertx HttpServer ?

Regards
JB

On Sun, Mar 17, 2024 at 5:54 PM Michael Elbaz  wrote:
>
> Hello i use vertx on Karaf everything is ok but when i want to run an vertx 
> http server (just http)
>
> vertx.createHttpServer()
> .requestHandler(router)
> .listen(8080)
> .onSuccess(LOGGER::error)
> .onFailure(LOGGER::error);
>
>
> i get this error java.lang.NoClassDefFoundError: javax/net/ssl/TrustManager 
> (i also get this one in karaf log:  Using the default address resolver as the 
> dns resolver could not be loaded)

Re: Dependency Flag in feature tag of feature.xml

[Jean-Baptiste Onofré]

Hi Matthias,

By default, the features are installed asynchronously (in different threads).

1/
The prerequisite flag "forces" the dependency feature to be fully
installed before continuing the current feature.
So it means basically, that:

  bar
  b


The bar feature will be fully installed and started before the
installation of bundle b.

2/
dependency flag is a way to avoid to install a feature if there are
already other features or bundles installed providing the same
capabilities.
Imagine, you have a feature provide Capability:foo, if you have a
second feature with the same Capability, it's not necessary to install
it.
A good example is the way we manage the HTTP provider (Jetty, Tomcat,
Undertow). In your feature, you define you need a capability
http-provider.
If you have a feature already providing this capability (let's say
pax-web-jetty), then the pax-web-tomcat feature won't be installed.
So it means, that:

  pax-web-tomcat
  b

pax-web-tomcat feature will be installed only if pax-web-jetty is not
already installed.

Regards
JB

On Wed, Mar 13, 2024 at 8:52 AM Matthias Koch  wrote:
>
> Hi
>
> we are currently building more and more features for our custom assembly
> and we have problems of understanding the differences of:
>
> 1. A depending feature
> 2. A depending feature with prerequisite=true
> 3. A depending feature with dependency=true
>
>
> Here is what we understand (or at least think we understand) so far.
>
> 1.
> 
>  bar
> 
> The feature foo depends on feature bar. So if you install feature foo,
> then feature bar is also installed.
> Additionally when we create feature foo via maven plugin, no bundle that
> already exists in feature bar we be added to the bundle list.
>
> 2.
> 
>  bar
> 
> The feature bar is prerequisite of feature foo and will therefore be
> 'started' before feature foo is installed.
>
> 3.
> 
>  bar
> 
> We can't figure out what this configuration does.
>
> Please tell me if we are understanding the 1. and 2. part correctly and
> help me understand what the 3. part means.
>
> Kind regards
> Matthias
>

Re: Performance Degrade with apache karaf 4.3.10 and Java 17

[Jean-Baptiste Onofré]

Hi Chandan,

I would not recommend the wrapper with large heap and new JDK. The
reason is because the Tanuki Java Wrapper used by the Karaf wrapper is
super old (due to license issue).

Do you see the same problem using the bin/karaf script ?

I would also recommend using G1 GC instead of CMS with Java 17.

Regards
JB

On Tue, Mar 12, 2024 at 8:21 AM Chandan Singh
 wrote:
>
> Hi All ,
>
> We upgraded from  Karaf 4.3.7 (Java 11) to Karaf 4.3.10 ( Java 17 )  . but we 
> are noticing some degradation in performance during load testing .   These 
> were the setting we have kept in wrapper in Java 11
>
> wrapper.java.additional.12=-XX:+UseConcMarkSweepGC
> wrapper.java.additional.13=-XX:NewRatio=2
> wrapper.java.additional.14=-Xmx20480M
> wrapper.java.additional.15=-Xms5120M
>
> which now as UseConcMarkSweepGC  has been removed in Java 17 .  We modified 
> it below  but we still don't see any improvements .
>
> wrapper.java.additional.12=-XX:+UseG1GC
> wrapper.java.additional.13=-XX:NewRatio=2
> wrapper.java.additional.14=- Xmx20480M
> wrapper.java.additional.15=-Xms5120M
>
> Any recommendations on the same ?
>
>
> regards
> Chandan

Re: Karaf log4j conflict

[Jean-Baptiste Onofré]

Hi Will

Did you take a look on
https://github.com/apache/karaf/tree/main/examples/karaf-log-appender-example
?

Generally speaking, the org.apache.logging* packages should be
imported in your bundle. The fragment would extend an existing bundle
classloader with your classes.

Maybe if you share a test case bundle, I can show you how to do this.

Regards
JB

On Wed, Mar 13, 2024 at 6:28 PM Will Hartung  wrote:
>
>
>
> On Mon, Mar 11, 2024 at 11:33 PM Grzegorz Grzybek  
> wrote:
>>
>> Hello
>>
>> Pax Logging (where pax-logging-api contains and exports Logging APIs, while 
>> pax-logging-log4j2 is the Log4j2-based implementation) has enormous amount 
>> of effort put into integration of very different logging packages and it is 
>> used by Apache Karaf among others.
>>
>> The team developed Pax Logging for many years trying to maintain old APIs 
>> and include new ones. Among others, there's one consequence of this - either 
>> you use Pax Logging and accept some (workarounds possible) limitation or you 
>> craft your own set of bundles approaching what Pax Logging does anyway.
>>
>> Your issue is simple - your "caterwaul-connect-core" bundle imports 
>> "org.apache.logging.log4j.core" which is simply NOT exported by 
>> pax-logging-log4j2. This (at first glance) means you NEED actual Log4j2 
>> bundles installed.
>>
>> However - are you sure your "caterwaul-connect-core" bundle really needs 
>> this package? is it implementing custom appenders/layouts/plugins? If so, 
>> it's better (and Pax Logging contains relevant examples) to create a 
>> fragment bundle attached to pax-logging-log4j2 bundle.
>>
> Hi, thanks for getting back.
>
> Yes, it seems that the code is doing a couple of things. One is creating its 
> own appender, and another it seems to be looking at different kinds of events 
> that contain raw logging information, so it's using some of the classes to 
> extract information from those.
>
> So, for this fragment, do I simply need to make a fragment containing the 
> extra log4j information, or do I need to extract the code that is using those 
> log4j pieces and put that into a fragment. That seems to be a much taller 
> order. Compared to bolting the necessary log4j.core classes onto the pax 
> bundle so that those classes are then available to everyone from the pax 
> bundles classloader.
>
> Thanks!
>
> Regards,
>
> Will Hartung
>

Re: Is Karaf compatible with Windows Server 2022, Version: 10.0 ?

[Jean-Baptiste Onofré]

Hi Jose

Karaf 4.2.14 is pretty old :) Assuming you have a JDK8 on your Windows
Server 2022, bin/karaf should work fine.
However, I don't think the wrapper will work out of the box.

Regards
JB

On Thu, Mar 7, 2024 at 5:25 PM jose.garn...@toshibagcs.com
 wrote:
>
> Hi Karaf team,
>
>
>
> Do you know if Karaf 4.2.14 is compatible with Windows Server 2022, Version: 
> 10.0 ?
>
>
>
>
>
> Regards
>
> Jose Garnica.

Re: Jetty(Jetty 9.4.52) vulnerability in Karaf 4.3.10

[Jean-Baptiste Onofré]

In that case, please double check first if you are actually impacted by the CVE.

It's possible to tweak your karaf version by updating, but you have to
do it "cold".

Regards
JB

On Mon, Mar 4, 2024 at 6:21 AM Chandan Singh
 wrote:
>
> Hi JB ,
>
> Can you please share how to upgrade just  PAxweb/Jetty in the 4.3.10 version? 
> We are already in prod and I cannot upgrade to a new Karaf version .
>
> Regards
> Chandan
>
> On Fri, Mar 1, 2024 at 12:41 PM Jean-Baptiste Onofré  
> wrote:
>>
>> Hi
>>
>> You can create your own custom Karaf distribution upgrading PaxWeb/Jetty.
>>
>> Or you can update to the latest Karaf version.
>>
>> Regards
>> JB
>>
>> On Tue, Feb 27, 2024 at 12:57 PM Chandan Singh 
>>  wrote:
>>>
>>> Is there any way we can upgrade the jetty version in Karaf 4.3.10 to the 
>>> latest jetty version ?
>>>
>>> Regards
>>> Chandan
>>>
>>> On Thu, Feb 22, 2024 at 7:12 PM Grzegorz Grzybek  
>>> wrote:
>>>>
>>>> Hello
>>>>
>>>> Karaf 4.3.x uses Pax Web 7.x and there exists pax-jetty-http2 feature. It 
>>>> comes with a warning:
>>>>
>>>> Please beware, for this feature to run properly you'll need to add the 
>>>> alpn-boot.jar to the
>>>> lib/ext folder of Karaf in some cases of your JVM.
>>>>
>>>> So it's kind of not working by default. But it depends on how smart (or 
>>>> dumb, which is more often probably...) the scanner is. When you start 
>>>> fresh Karaf you don't even have HTTP server running at all. So it's kind 
>>>> of "safe by default". But you can install any bundle there - whether or 
>>>> not it comes from standard Karaf features.
>>>>
>>>> In other words - I don't have good answer... I just wanted to communicate 
>>>> that it's not an easy question ;)
>>>>
>>>> regards
>>>> Grzegorz Grzybek
>>>>
>>>> czw., 22 lut 2024 o 13:47 Richard Hierlmeier  
>>>> napisał(a):
>>>>>
>>>>> We did already a security scan, it detected  CVE-2023-36478 and 
>>>>> CVE-2023-44487
>>>>>
>>>>> Both CVEs are related to HTTP2. I have thought that HTTP2 is not possible 
>>>>> in Karaf 4.3.
>>>>>
>>>>> Can someone confirm this assumption.
>>>>>
>>>>> Regards
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>>> Am Do., 22. Feb. 2024 um 11:23 Uhr schrieb Chandan Singh 
>>>>> :
>>>>>>
>>>>>> Hi All ,
>>>>>>
>>>>>> During a recent Security Scan  we found a vulnerability  reported 
>>>>>> regarding the Jetty  version in  Apache Karaf 4.3.10 .  Does anyone have 
>>>>>> any recommendations on the same ?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Chandan

Re: Jetty(Jetty 9.4.52) vulnerability in Karaf 4.3.10

[Jean-Baptiste Onofré]

Hi

You can create your own custom Karaf distribution upgrading PaxWeb/Jetty.

Or you can update to the latest Karaf version.

Regards
JB

On Tue, Feb 27, 2024 at 12:57 PM Chandan Singh <
mailbox.chandansi...@gmail.com> wrote:

> Is there any way we can upgrade the jetty version in Karaf 4.3.10 to the
> latest jetty version ?
>
> Regards
> Chandan
>
> On Thu, Feb 22, 2024 at 7:12 PM Grzegorz Grzybek 
> wrote:
>
>> Hello
>>
>> Karaf 4.3.x uses Pax Web 7.x and there exists pax-jetty-http2 feature. It
>> comes with a warning:
>>
>> Please beware, for this feature to run properly you'll need to add the
>> alpn-boot.jar to the
>> lib/ext folder of Karaf in some cases of your JVM.
>>
>> So it's kind of not working by default. But it depends on how smart (or
>> dumb, which is more often probably...) the scanner is. When you start fresh
>> Karaf you don't even have HTTP server running at all. So it's kind of "safe
>> by default". But you can install any bundle there - whether or not it comes
>> from standard Karaf features.
>>
>> In other words - I don't have good answer... I just wanted to communicate
>> that it's not an easy question ;)
>>
>> regards
>> Grzegorz Grzybek
>>
>> czw., 22 lut 2024 o 13:47 Richard Hierlmeier 
>> napisał(a):
>>
>>> We did already a security scan, it detected  CVE-2023-36478 and
>>> CVE-2023-44487
>>>
>>> Both CVEs are related to HTTP2. I have thought that HTTP2 is not
>>> possible in Karaf 4.3.
>>>
>>> Can someone confirm this assumption.
>>>
>>> Regards
>>>
>>> Richard
>>>
>>>
>>> Am Do., 22. Feb. 2024 um 11:23 Uhr schrieb Chandan Singh <
>>> mailbox.chandansi...@gmail.com>:
>>>
 Hi All ,

 During a recent Security Scan  we found a vulnerability  reported
 regarding the Jetty  version in  Apache Karaf 4.3.10 .  Does anyone have
 any recommendations on the same ?

 [image: image.png]


 Regards
 Chandan

>>>

Re: Realm created via jaas:realm-add go away after karaf restart

[Jean-Baptiste Onofré]

Hi Paul

It's not a bug, that's an expected behavior: the JAAS configuration
created by the commands is stored "in memory".
If you want to persist, you have to use blueprint jaas namespace (in
the deploy folder for instance).

I plan to remove this "requirement" for Karaf 4.5.x using another
storage layer that the shell commands can populate/read and also the
security feature at bootstrap.

Regards
JB

On Tue, Jan 30, 2024 at 9:21 PM Paul Spencer  wrote:
>
> Karaf 4.4.5
> JVM  OpenJDK 64-Bit Server VM version 11.0.2+9
>
> A realm created via jaas:realm-add is not listed after karaf restart.  This 
> may be related to KARAF-7602.
>
> - Create the realm using the following commands:
>
> jaas:realm-add myrealm 
> org.apache.karaf.jaas.modules.properties.PropertiesLoginModule users 
> "etc/bugdataRestUser.properties"
> jaas:realm-manage --realm myrealm --module 
> org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
> jaas:update
>
> -  The command jaas:realm-list will include the realm myrealm
>
> karaf@root()> jaas:realm-list
> Index │ Realm Name │ Login Module Class Name
> ──┼┼───
> 1 │ karaf  │ 
> org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
> 2 │ karaf  │ 
> org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
> 3 │ karaf  │ org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
> 4 │ karaf  │ org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
> 5 │ karaf  │ 
> org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
> 6 │ myrealm│ 
> org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
>
> - Restart the karaf instance
> The new realm is not listed by the command jaas:realm-list
>
> karaf@root()> jaas:realm-list
> Index │ Realm Name │ Login Module Class Name
> ──┼┼───
> 1 │ karaf  │ 
> org.apache.karaf.jaas.modules.properties.PropertiesLoginModule
> 2 │ karaf  │ 
> org.apache.karaf.jaas.modules.publickey.PublickeyLoginModule
> 3 │ karaf  │ org.apache.karaf.jaas.modules.audit.FileAuditLoginModule
> 4 │ karaf  │ org.apache.karaf.jaas.modules.audit.LogAuditLoginModule
> 5 │ karaf  │ 
> org.apache.karaf.jaas.modules.audit.EventAdminAuditLoginModule
> karaf@root()>
>
> Is this bug?
>
> Paul Spencer

Re: Change in SSH server session close when going from 4.3.10 to 4.4.5

[Jean-Baptiste Onofré]

Hi Martin

I think we already have a Jira about that. Let me find it.

I will reproduce and fix that.

Thanks,
Regards
JB

On Wed, Jan 24, 2024 at 2:25 PM Martin Lichtin via user
 wrote:
>
> Hi all, I noticed a change in SSH server session close behavior, as I
> upgraded from 4.3.10 to 4.4.5.
> Doing calls such as
>
> ssh -p 8101 karaf@localhost feature:list
>
> still works fine. However with 4.4.5, the ssh client now sporadically
> reports
>
> Connection to localhost closed by remote host.
>
> The difference seems in the session shutdown.
>
> In the "good" case it is:
>
> debug2: channel 0: rcvd eof
> debug2: channel 0: output open -> drain
> debug2: channel 0: obuf empty
> debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
> debug2: channel 0: output drain -> closed
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug2: channel 0: rcvd close
> debug2: channel 0: chan_shutdown_read (i0 o3 sock -1 wfd 4 efd 6 [write])
> debug2: channel 0: input open -> closed
> debug2: channel 0: almost dead
> debug2: channel 0: gc: notify user
> debug2: channel 0: gc: user detached
> debug2: channel 0: send close
> debug2: channel 0: is dead
> debug2: channel 0: garbage collecting
> debug1: channel 0: free: client-session, nchannels 1
> Transferred: sent 2064, received 28800 bytes, in 0.1 seconds
> Bytes per second: sent 23511.4, received 328065.6
> debug1: Exit status 0
>
> In the "bad" case it is:
>
> debug2: channel 0: rcvd eof
> debug2: channel 0: output open -> drain
> debug2: channel 0: obuf empty
> debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
> debug2: channel 0: output drain -> closed
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: channel 0: free: client-session, nchannels 1
> Connection to localhost closed by remote host.
> Transferred: sent 2048, received 28768 bytes, in 0.0 seconds
> Bytes per second: sent 41302.3, received 580168.6
> debug1: Exit status 0
>
> Seems a timing issue, interacting with the new SSHD code?
>
> - Martin
>

Re: Karaf running Camel 4

[Jean-Baptiste Onofré]

Hi,

Yes, that's the goal :)

Regards
JB

On Tue, Jan 16, 2024 at 3:49 PM Ephemeris Lappis
 wrote:
>
> Hello !
>
> Do you mean JB that Camel blueprint contexts are going to work again
> with Camel 4, on Karaf at runtime, and for testing too ?
>
> Thanks.
>
> Regards.
>
> Le mar. 16 janv. 2024 à 10:29, Jean-Baptiste Onofré  a 
> écrit :
> >
> > Hi
> >
> > I guess you missed my message on the Camel dev mailing list.
> > If today Camel 4 doesn't support OSGi/Karaf anymore, I'm working to re-add 
> > it.
> >
> > I'm working on the branch:
> > https://github.com/jbonofre/camel-karaf/tree/REFACTORE
> >
> > So, please, give me some time, and we will have Camel 4 working on Karaf 4 
> > :)
> >
> > Regards
> > JB
> >
> > On Wed, Jan 10, 2024 at 2:21 PM Martin Lichtin via user
> >  wrote:
> > >
> > > Hi
> > >
> > > Wanted to understand if anyone has Camel 4 running in Karaf 4.3 or 4.4?
> > >
> > > Also reading that Camel Karaf is being moved to Karaf as a subproject, 
> > > but I can't figure out the details..
> > >
> > > Any wisdom is much appreciated :)
> > >
> > > - Martin

Re: Karaf running Camel 4

[Jean-Baptiste Onofré]

Hi

I guess you missed my message on the Camel dev mailing list.
If today Camel 4 doesn't support OSGi/Karaf anymore, I'm working to re-add it.

I'm working on the branch:
https://github.com/jbonofre/camel-karaf/tree/REFACTORE

So, please, give me some time, and we will have Camel 4 working on Karaf 4 :)

Regards
JB

On Wed, Jan 10, 2024 at 2:21 PM Martin Lichtin via user
 wrote:
>
> Hi
>
> Wanted to understand if anyone has Camel 4 running in Karaf 4.3 or 4.4?
>
> Also reading that Camel Karaf is being moved to Karaf as a subproject, but I 
> can't figure out the details..
>
> Any wisdom is much appreciated :)
>
> - Martin

Re: Karaf version with Jdk 21

[Jean-Baptiste Onofré]

l.java:1069)
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:1004)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1583)
>
> 2.  Status: Failure
> Blueprint
> 1/11/24, 12:13 PM
> Exception:
> null
> java.util.concurrent.TimeoutException
> at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:393)
> at 
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45)
> at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
> at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
> at java.base/java.lang.Thread.run(Thread.java:1583)
>
> Missing dependencies:
> (objectClass=//)
> CdiOsgi
>
>
> Regards,
>
> Yunji Lee
> 
> From: yunji@toshibagcs.com 
> Sent: Monday, January 8, 2024 12:10 PM
> To: user@karaf.apache.org 
> Subject: Re: Karaf version with Jdk 21
>
>
> CAUTION:  This email originated from outside our organization. Do not click 
> links or open attachments unless you validate the sender.
>
>
>
> Hi Jean,
>
> Thank you!
> Well, I do not have a test case.
> But I think the issue is regarding SCR feature.
> This is the feature.
>
> 
>  start-level="30">mvn:org.osgi/org.osgi.util.function/1.2.0
>  start-level="30">mvn:org.osgi/org.osgi.util.promise/1.2.0
>  start-level="30">mvn:org.osgi/org.osgi.service.component/1.5.0
>  start-level="30">mvn:org.apache.felix/org.apache.felix.metatype/1.2.4
>  start-level="30">mvn:org.apache.felix/org.apache.felix.scr/2.2.6
> 
> management
>  start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.management/4.4.4
> 
> 
> webconsole
>  start-level="30">mvn:org.apache.felix/org.apache.felix.inventory/1.1.0
>  start-level="30">mvn:org.apache.felix/org.apache.felix.webconsole.plugins.ds/2.2.0
> 
> 
> bundle
>  start-level="30">mvn:org.apache.karaf.scr/org.apache.karaf.scr.state/4.4.4
> 
> 
> 
> osgi.service;effective:=active;objectClass=org.apache.felix.scr.ScrService,
> 
> osgi.extender;osgi.extender="osgi.component";uses:="org.osgi.service.component";version:Version="1.2.1"
> 
> 
>
>
> And this is the error I'm facing while running karaf.
> org.apache.felix.resolver.reason.ReasonException: Unable to resolve root: 
> missing requirement [root] osgi.identity; 
> osgi.identity=7db4b9c9-5d8b-4144-a2b3-2162c2867296; type=karaf.feature; 
> version="[0,0.0.0]"; 
> filter:="(&(osgi.identity=7db4b9c9-5d8b-4144-a2b3-2162c2867296)(type=karaf.feature)(version>=0.0.0)(version<=0.0.0))"
> Caused by: org.apache.felix.resolver.reason.ReasonException: Unable to 
> resolve cloudforwarder-log-config/1.6.0.0003: missing requirement 
> ["modulename"] osgi.extender; 
> filter:="(&(osgi.extender=osgi.component)(version>=1.4.0)(!(version>=2.0.0)))"
>
>
> Regards,
>
> 
> From: Jean-Baptiste Onofré 
> Sent: Saturday, January 6, 2024 9:46 AM
> To: user@karaf.apache.org 
> Subject: Re: Karaf version with Jdk 21
>
> CAUTION:  This email originated from outside our organization. Do not click 
> links or open attachments unless you validate the sender.
>
>
>
> Hi
>
> 4.4.5 will be in vote today with better support of JDK21 (we build and
> test using JDK20, I will setup JDK21).
>
> Regarding 4.5.0 (including Jakarta EE namespace), I plan to work on it
> in the coming days. I hope to submit 4.5.0 to vote in a couple of
> weeks.
>
> Do you have specific test cases with JDK21 ? I would like to check
> with Karaf 4.4.5.
>
> Regards
> JB
>
> On Fri, Jan 5, 2024 at 9:12 PM yunji..

Re: Deploy bundle using karaf maven plugin

[Jean-Baptiste Onofré]

Hi

By default, the authentication (user) is disabled in Karaf standard
distribution. Did you uncommment the karaf user in
etc/users.properties ?

Regards
JB

On Sat, Jan 13, 2024 at 1:17 AM jose.garn...@toshibagcs.com
 wrote:
>
> I am trying to deploy a bundle using the Karaf maven plugin to my local karaf 
> instance,
>
>
>
> 
> org.apache.karaf.tooling
> karaf-maven-plugin
> 
> 
> 
> features-generate-descriptor
> 
> 
> true
> 
> 
>
> 
> deploy
> install
> 
> deploy
> 
> 
> 8101
> localhost
> karaf-root
> 
> 
> 
> 
>
>
>
>
>
> But I am getting this error message
>
>
>
> [ERROR] Failed to execute goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.4.5:deploy (deploy) on project 
> admin-portal: No more authentication methods available: 
> org.apache.sshd.common.SshException: No more authentication methods available 
> -> [Help 1]
>
>
>
>
>
> Any idea about how to resolve it?  I am using a custom distribution of Karaf 
> 4.4.5
>
> Just FYI I have attached the karaf/maven logs
>
>
>
>

Re: Custom distributions of a custom Karaf distribution

[Jean-Baptiste Onofré]

Hi Cédric,

You have the documentation about custom distributions:
https://karaf.apache.org/manual/latest/#_custom_distributions

FYI, the karaf distribution is built this way:
https://github.com/apache/karaf/tree/main/assemblies/apache-karaf
So you can mimic the Karaf distribution to match your needs.

FYI, Karaf 4.5.0 will provide a new "integration" distribution (we
have "standard" and "minimal" distributions today).

Regards
JB

On Sun, Jan 14, 2024 at 7:38 PM Cédric Jonas  wrote:
>
> Hi,
>
> In the company I'm working for we have the following use case: provide a
> central customized (branding, configuration, so called "platform
> features", ...) Karaf distribution for other development teams. These
> other dev teams would add further features depending on their needs.
>
> There is much documentation around about how to build a customized
> distribution (for example
> https://fpapon.github.io/2020/03/21/karaf-custom-distribution/), and
> that works like a charm till now.
>
> But I was not able to find an easy way to be able to customize such a
> customized distribution once more. I played around with the
> karaf-maven-plugin, "custom", "distribution" and
> "karafDistribution" properties, but finally that did not work as it
> requires a KAR and I didn't found a way to build a KAR from our platform
> distribution.
>
> Is there any official / supported way to do this?
>
> Thanks!
>
> --
> Cédric Jonas
>
> E-Mail: ced...@c84.eu

[ANN] Apache Karaf OSGi Runtime 4.4.5 has been released!

[Jean-Baptiste Onofré]

The Apache Karaf team is pleased to announce the Apache Karaf OSGi
Runtime 4.4.5 release.

Apache Karaf runtime 4.4.5 is a maintenance release, bringing a lot of
dependency updates and fixes, especially:
-i solate config shell commands in a dedicated bundle to avoid refresh
and race condition at startup
- better JDK21 support with new ASM version (9.6)
- upgrade to Jetty 9.4.53.v20231009 and Pax Web 8.0.24
- upgrade to Pax Logging 2.2.6 supporting Log4j 2.22.1 and commons-logging 1.3.0
- fix webconsole plugins loading
- upgrade to sshd 2.11.0 fixing ecdsa key support
- ...

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

Apache Karaf OSGi Runtime 4.4.5 is available on Maven Central or here:
https://karaf.apache.org/download.html

Enjoy !
The Apache Karaf team

Re: Is the karaf 4.4.4 docker image arm only?

[Jean-Baptiste Onofré]

Hi,

yes, the docker image is arm based. I'm adding multi-arch image
support (to have x86 images as well).
I will upload new images soon.

Regards
JB

On Mon, Jan 8, 2024 at 7:36 PM Steinar Bang  wrote:
>
> >>>>> Jean-Baptiste Onofré :
>
> > Hi Steinar
> > Let me check about the image type.
>
> Did you find out anything?
>
> The docker-maven-plugin I've been using (the one created by spotify),
> was abandoned a couple of years back:
>  https://github.com/spotify/docker-maven-plugin
>
> So I've been trying to to use a docker-maven-plugin that is maintained:
>  https://github.com/fabric8io/docker-maven-plugin
>
> I've succeeded in building a sonar-collector docker image using the new
> docker-maven-plugin, but I end up with an arm64 image here as well (even
> though I'm building and running on amd64):
>  
> https://github.com/fabric8io/docker-maven-plugin/issues/1739#issuecomment-1881260436
>

Re: Karaf version with Jdk 21

[Jean-Baptiste Onofré]

Hi

4.4.5 will be in vote today with better support of JDK21 (we build and
test using JDK20, I will setup JDK21).

Regarding 4.5.0 (including Jakarta EE namespace), I plan to work on it
in the coming days. I hope to submit 4.5.0 to vote in a couple of
weeks.

Do you have specific test cases with JDK21 ? I would like to check
with Karaf 4.4.5.

Regards
JB

On Fri, Jan 5, 2024 at 9:12 PM yunji@toshibagcs.com
 wrote:
>
> Hi Jean,
>
> Thank you for providing the information.
>
> I'm currently in the process of migrating from Karaf 4.2 to 4.4 due to our 
> migration from Java 8 to Java 21.
> However, I've encountered some errors while running Karaf, seemingly related 
> to the OSGi component (likely associated with the SCR feature).
> Could you please provide information on the scheduled release date for Karaf 
> 4.5?
>
> Thanks again for your assistance.
>
> Best regards,
>
> Yunji Lee
>
>
>
> 
> From: Jean-Baptiste Onofré 
> Sent: Wednesday, December 13, 2023 8:36 AM
> To: user@karaf.apache.org 
> Subject: Re: Karaf version with Jdk 21
>
> CAUTION:  This email originated from outside our organization. Do not click 
> links or open attachments unless you validate the sender.
>
>
>
> Hi Yunji
>
> I'm preparing 4.4.5 right now, but a better JDK 21 support (but not
> yet complete due to third parties like Aries *).
>
> About Karaf 4.5.0, I plan to submit it to release just after Christmas.
>
> Regards
> JB
>
> On Mon, Dec 11, 2023 at 5:03 PM yunji@toshibagcs.com
>  wrote:
> >
> > Hello good day,
> >
> > I hope this email finds you well.
> > I was trying to compile and run karaf 4.4.4 on jdk21.
> >
> > And I came across information in the mailing list that there will be a 
> > Karaf 4.5.x version with full JDK 21 support.
> > I'm interested to know when this release is scheduled.
> >
> > Thank you for your time and assistance.
> >
> > Best regards,
> > Yunji Lee

Re: Is the karaf 4.4.4 docker image arm only?

[Jean-Baptiste Onofré]

Hi Steinar

Let me check about the image type.

Regards
JB

On Fri, Dec 22, 2023 at 5:44 PM Steinar Bang  wrote:
>
> > Steinar Bang :
> [snip!]
> > Or try out the, completely different, docker-maven-plugin that comes up
> > first on google searches?
> >  https://github.com/fabric8io/docker-maven-plugin
>
> > I guess try out the new one.
>
> Not much luck with the new one, so far:
>  https://github.com/fabric8io/docker-maven-plugin/issues/1739
>
> The command it tries to run doesn't seem like one my docker recognizes.
>
> Does anyone else have a better maven docker plugin to try?
>

Re: Karaf version with Jdk 21

[Jean-Baptiste Onofré]

Hi Yunji

I'm preparing 4.4.5 right now, but a better JDK 21 support (but not
yet complete due to third parties like Aries *).

About Karaf 4.5.0, I plan to submit it to release just after Christmas.

Regards
JB

On Mon, Dec 11, 2023 at 5:03 PM yunji@toshibagcs.com
 wrote:
>
> Hello good day,
>
> I hope this email finds you well.
> I was trying to compile and run karaf 4.4.4 on jdk21.
>
> And I came across information in the mailing list that there will be a Karaf 
> 4.5.x version with full JDK 21 support.
> I'm interested to know when this release is scheduled.
>
> Thank you for your time and assistance.
>
> Best regards,
> Yunji Lee

Re: OSGi managed service factory / Events on changes ?

[Jean-Baptiste Onofré]

Hi,

You can use a ConfigListener, similar to what we do in Cellar Config:

https://github.com/apache/karaf-cellar/blob/main/config/src/main/java/org/apache/karaf/cellar/config/LocalConfigurationListener.java

Regards
JB

On Thu, Nov 30, 2023 at 9:19 AM Ephemeris Lappis
 wrote:
>
> Hello.
>
> To manage some kind of dynamic configuration, I've used a managed
> service factory. It works as expected, and I can add, update or remove
> instances deploying or undeploying files in the etc folder.
>
> The simple blueprint is like that :
>
> 
>  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0;
> xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
> https://www.osgi.org/xmlns/blueprint/v1.0.0/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;>
>
>  factory-pid="com.together.ms"
> interface="com.together.MyService">
>  class="com.together.component.MyServiceManagedComponent">
>  persistent-id=""
> update-strategy="container-managed" />
> 
> 
> 
>
> In another bundle, I'd like to know when an instance has been updated
> or removed (new ones don't really matter). What's the best way to do
> it, if possible ? Are there some kind of events and listeners to spy
> managed services ?
>
> Thanks for your help.
>
> Regards.

Re: Karaf version java Compatibility

[Jean-Baptiste Onofré]

Hi,

Karaf 4.3.x/4.4.x should be able to run with Java 8 (maybe with a rebuild).
I can give it a try.

Regards
JB

On Wed, Nov 15, 2023 at 4:30 PM yunji@toshibagcs.com <
yunji@toshibagcs.com> wrote:

> Hi,
> Thank you for the response!
> I have another question: Is it possible to use Karaf 4.3.x or 4.4.x with
> Java 8?
> I am curious if there is a version that supports both Java 8 and 17.
>
> Appreciate your assistance.
> Regards,
> Yunji Lee
> ------
> *From:* Jean-Baptiste Onofré 
> *Sent:* Wednesday, November 15, 2023 4:40 AM
> *To:* user@karaf.apache.org 
> *Subject:* Re: Karaf version java Compatibility
>
>
> *CAUTION: * * This email originated from outside our organization. Do not
> click links or open attachments unless you validate the sender. *
>
>
> Hi Yunji
>
> Karaf 4.2.x only supports Java up to 11 (mostly due to the third parties).
>
> If you need JDK17, you have to upgrade to Karaf 4.3.x or 4.4.x (even
> better).
>
> Karaf 4.5.0 will be released soon with additional JDK 20 & 21 support.
>
> Regards
> JB
>
> On Mon, Nov 13, 2023 at 7:32 PM yunji@toshibagcs.com <
> yunji@toshibagcs.com> wrote:
>
> To whom it may concern,
>
> Hello, my name is Yunji Lee.
>
> Currently, I am utilizing version 4.2 of Karaf for our operations.
> And I am reaching out to inquire about the compatibility of Karaf version
> 4.2 with Java 17.
>
> Thanks in advance for your assistance.
>
> Best regards,
>
>
>
> *Yunji Lee*
>
> TOSHIBA Global Commerce Solutions
>
> Systems Management
>
> Software Engineer I
>
> *commerce.toshiba.com <https://commerce.toshiba.com/>*
>
> Find us on: Twitter <https://twitter.com/toshibagcs> | Facebook
> <http://www.facebook.com/ToshibaGlobalCommerceSolutions> | YouTube
> <http://www.youtube.com/RetailHardened>
>
>
>
> Amado Nervo #2200,Torre BIO piso 5,
>
> CP 45050, Ciudad del Sol,
>
> Zapopan, Jalisco
>
> Mexico
>
>
>
>

Re: Karaf version java Compatibility

[Jean-Baptiste Onofré]

Hi Yunji

Karaf 4.2.x only supports Java up to 11 (mostly due to the third parties).

If you need JDK17, you have to upgrade to Karaf 4.3.x or 4.4.x (even
better).

Karaf 4.5.0 will be released soon with additional JDK 20 & 21 support.

Regards
JB

On Mon, Nov 13, 2023 at 7:32 PM yunji@toshibagcs.com <
yunji@toshibagcs.com> wrote:

> To whom it may concern,
>
> Hello, my name is Yunji Lee.
>
> Currently, I am utilizing version 4.2 of Karaf for our operations.
> And I am reaching out to inquire about the compatibility of Karaf version
> 4.2 with Java 17.
>
> Thanks in advance for your assistance.
>
> Best regards,
>
>
>
> *Yunji Lee*
>
> TOSHIBA Global Commerce Solutions
>
> Systems Management
>
> Software Engineer I
>
> *commerce.toshiba.com *
>
> Find us on: Twitter  | Facebook
>  | YouTube
> 
>
>
>
> Amado Nervo #2200,Torre BIO piso 5,
>
> CP 45050, Ciudad del Sol,
>
> Zapopan, Jalisco
>
> Mexico
>
>
>

Re: Local repositories and snapshot bundles

[Jean-Baptiste Onofré]

Hi,

Do you want to watch remote repositories ?
Currently, Karaf is only to watch local repository. We have a Jira about that.

Regards
JB

On Thu, Nov 2, 2023 at 2:55 PM Pavel Perikov  wrote:
>
> I’d like to comment  on what my goal is.
>
> I’d like to have a bunch of Karaf instances running in a cluster watching the 
> development repo for new -SNAPSHOT bundles and updating the bundle as newer 
> snapshot is available. I’m currently out of ideas. It seems that since the 
> bundle is installed it is cached in local repo. And there’s no way at all to 
> update this bundle because it is always present in local repository and the 
> dev repo is never checked.
>
>
>
> On 2 Nov 2023, at 16:01, Pavel Perikov  wrote:
>
> Hi everybody.
>
> I’m using apache karaf-4.4.4.
>
> In clean configuration I made a single modification to
>
> org.ops4j.pax.url.mvn.repositories= \
> http://beelink:4000/snapshots@id=perikov@snapshots@noreleases, \
>
> to add my own repository.
>
> Then I install the bundle org.name.0.1.0-SNAPSHOT from this repository.
>
> It seems like the bundle immediately gets cached to local ~/.m2 repo and 
> there’s no way to get newer snapshot.
>
> Neither bundle:update nor bundle:watch nor bundle:uninstall/bundle:install 
> again do not work (they use local repository, getting the old version).
>
> The only way to go is to delete the bundle from the local repo.
>
> Is there a way to get the correct behaviour (preferably the bundle should get 
> updated via bundle:watch)?
>
> Best regards,
> Pavel
>
>

Re: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4

[Jean-Baptiste Onofré]

Yes, it's planned as part of the dependency updates process.

Thanks,
Regards
JB

On Wed, Oct 18, 2023 at 12:59 PM Jakub Herkel  wrote:
>
> Hello,
>
> Could you also update bouncycastle to version 1.76 for Karaf 4.4.5?
>
> with best regards
>
> Jakub Herkel
>
>
>
> On Wed, Oct 18, 2023 at 9:36 AM Grzegorz Grzybek  wrote:
> >
> > Hello
> >
> > A little updated - because of CVE-2023-44487 (HTTP/2 rapid reset attack) I 
> > was waiting for updates to Undertow, Jetty and Tomcat. Undertow has been 
> > released few hours ago, so I'm releasing new Pax Web today.
> > But I found new version of Log4j2 (2.21.0) and I'm releasing Pax Logging 
> > first.
> >
> > kind regards
> > Grzegorz Grzybek
> >
> > śr., 18 paź 2023 o 07:43 Jean-Baptiste Onofré  
> > napisał(a):
> >>
> >> Hey guys
> >>
> >> As we have new pax web releases now, I’m resuming fixes and upgrade in 
> >> preparation for releases.
> >>
> >> Regards
> >> JB
> >>
> >> Le dim. 1 oct. 2023 à 18:39, Jean-Baptiste Onofré  a 
> >> écrit :
> >>>
> >>> Hi Robert
> >>>
> >>> Sure, I will (I have other stuff to include anyway :)).
> >>>
> >>> Regards
> >>> JB
> >>>
> >>> On Sun, Oct 1, 2023 at 8:32 AM Robert Varga  wrote:
> >>> >
> >>> > Hey JB,Can you also look at including aries-proxy-1.1.14? It needs the 
> >>> > usual ASM bump to not fail when run on Java 21.Thanks,Robert Sent from 
> >>> > my Galaxy
> >>> >  Original message From: Jean-Baptiste Onofré 
> >>> >  Date: 10/1/23  07:33  (GMT+01:00) To: dev 
> >>> > , user  Subject: [UPDATE] 
> >>> > Karaf WebConsole has issues with Karaf 4.4.4 Hi guys,I created 
> >>> > https://issues.apache.org/jira/browse/KARAF-7769Since the Felix 
> >>> > WebConsole update, the Karaf WebConsole plugins(features, gogo, ...) 
> >>> > don't load correctly.I'm fixing that and I will quickly submit Karaf 
> >>> > 4.4.5 to vote.Sorry for the inconvenience;RegardsJB

Re: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4

[Jean-Baptiste Onofré]

Hey guys

As we have new pax web releases now, I’m resuming fixes and upgrade in
preparation for releases.

Regards
JB

Le dim. 1 oct. 2023 à 18:39, Jean-Baptiste Onofré  a
écrit :

> Hi Robert
>
> Sure, I will (I have other stuff to include anyway :)).
>
> Regards
> JB
>
> On Sun, Oct 1, 2023 at 8:32 AM Robert Varga  wrote:
> >
> > Hey JB,Can you also look at including aries-proxy-1.1.14? It needs the
> usual ASM bump to not fail when run on Java 21.Thanks,Robert Sent from my
> Galaxy
> > ---- Original message From: Jean-Baptiste Onofré <
> j...@nanthrax.net> Date: 10/1/23  07:33  (GMT+01:00) To: dev <
> d...@karaf.apache.org>, user  Subject: [UPDATE]
> Karaf WebConsole has issues with Karaf 4.4.4 Hi guys,I created
> https://issues.apache.org/jira/browse/KARAF-7769Since the Felix
> WebConsole update, the Karaf WebConsole plugins(features, gogo, ...) don't
> load correctly.I'm fixing that and I will quickly submit Karaf 4.4.5 to
> vote.Sorry for the inconvenience;RegardsJB
>

Re: Errors in karaf 4.4.4 when using the "karaf-jpa-example-datasource" feature.

[Jean-Baptiste Onofré]

Hi Luis

Let me try to reproduce. It seems Hibernate is not able to retrieve
the meta from the database (especially for the dialect and so). The
database is h2 (via pax-jdbc-h2) in the example.

It could be related to h2 wrapping in pax-jdbc.

Regards
JB

On Mon, Oct 9, 2023 at 11:20 PM Luis Lozano  wrote:
>
> Good afternoon.
>
> Linux openSUSE Tumbleweed
> VERSION_ID="20230902"
> apache-karaf-4.4.4
>
> I have performed the following test:
>
> I download apache karaf 4.4.4.tar.gz and extract it.
> I modify setenv with the following data:
>
> export JAVA_HOME=/home/desarrollo/tools/jdk11.0.17
> export EXTRA_JAVA_OPTS=-Djava.locale.providers=COMPAT,CLDR
>
> I run "apache-karaf-4.4.4/bin/karaf" and inside the console, I execute:
>
> karaf@root()> feature:repo-add 
> mvn:org.apache.karaf.examples/karaf-jpa-example-features/LATEST/xml
> karaf@root()> feature:install karaf-jpa-example-datasource
> karaf@root()> feature:install karaf-jpa-example-command
> karaf@root()> feature:install karaf-jpa-example-provider-ds-hibernate
> karaf@root()> booking:add Doe AF520
> karaf@root()> booking:list
> ID  │ Flight │ Customer
> ┼┼─
> 1   │ AF520  │ Doe
>
> In the karaf.log, I get:
>
> 2023-10-09T23:06:27,402 | WARN  | features-3-thread-1 | 
> JdbcEnvironmentInitiator | 108 - org.hibernate.orm.core - 5.6.7.Final 
> | HHH000342: Could not obtain connection to query metadata
> java.lang.NullPointerException: null
> at 
> org.hibernate.engine.jdbc.env.internal.ExtractedDatabaseMetaDataImpl$Builder.apply(ExtractedDatabaseMetaDataImpl.java:183)
>  ~[?:?]
> at 
> org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentImpl.(JdbcEnvironmentImpl.java:272)
>  ~[?:?]
> at 
> org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:114)
>  ~[?:?]
> at 
> org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator.initiateService(JdbcEnvironmentInitiator.java:35)
>  ~[?:?]
> at 
> org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.initiateService(StandardServiceRegistryImpl.java:101)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.createService(AbstractServiceRegistryImpl.java:263)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:237)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214)
>  ~[?:?]
> at 
> org.hibernate.id.factory.internal.DefaultIdentifierGeneratorFactory.injectServices(DefaultIdentifierGeneratorFactory.java:175)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.injectDependencies(AbstractServiceRegistryImpl.java:286)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:243)
>  ~[?:?]
> at 
> org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:214)
>  ~[?:?]
> at 
> org.hibernate.boot.internal.InFlightMetadataCollectorImpl.(InFlightMetadataCollectorImpl.java:173)
>  ~[?:?]
> ...
>
> I close with Ctrl-D.
>
> I run again:
> apache-karaf-4.4.4/bin/karaf
> karaf@root()> booking:list
> ID  │ Flight │ Customer
> ┼┼─
> karaf@root()>
>
> (No data)
>
> And in karaf.log, I have the same error.
> --
> Saludos:
> Luis Lozano.

Re: Camel kubernetes

[Jean-Baptiste Onofré]

Hi Matthias,

it sounds like a missing import/classloader issue. I will try to
reproduce myself and fix.

Thanks for the test case,
Regards
JB

On Fri, Oct 6, 2023 at 3:30 PM Matthias Leinweber
 wrote:
>
> Long long time has passed...
>
>
> I just tested camel-3.20.5. with karaf 4.4.3 (3.21.1 was not installable)
> and i get a  java.util.concurrent.ExecutionException: 
> java.lang.NoClassDefFoundError: io/fabric8/kubernetes/client/KubernetesClient
>
>
> Steps to reproduce:
> download karaf & start
> repo-add mvn:org.apache.camel.karaf/apache-camel/3.20.5/xml/feature
> feature:install camel-kubernetes camel-blueprint
>
>
> and drop this xml into deploy (kubernetes.master.url = 
> https://kubernetes.default)
>
>
> 
> 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 
> https://camel.apache.org/schema/blueprint/camel-blueprint.xsd
>  http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 
> https://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd;>
>
> 
>
>
>  xmlns="http://camel.apache.org/schema/blueprint;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
> xsi:schemaLocation="http://camel.apache.org/schema/blueprint 
> https://camel.apache.org/schema/blueprint/camel-blueprint-3.20.5.xsd;>
> 
> 
>  uri="kubernetes-job:///{{kubernetes.master.url}}?operation=createJob"/>
> 
>
> 
>
> 
>
>
> br,
> Matthias
>
>
> Am Fr., 11. Aug. 2023 um 13:22 Uhr schrieb Matthias Leinweber 
> :
>>
>> HI Jb,
>>
>> I was sick and on vacation, do you have a link to a running example? Maybe I 
>> can see my mistake, directly.
>>
>> br,
>> Matthias
>>
>> Am So., 16. Juli 2023 um 14:30 Uhr schrieb Matthias Leinweber 
>> :
>>>
>>> Thanks JB,
>>>
>>> I will setup a test case in vanilla Karaf tomorrow... Getting leader 
>>> election working, would be great too.
>>>
>>>
>>> Jean-Baptiste Onofré  schrieb am Sa., 15. Juli 2023, 
>>> 13:10:
>>>>
>>>> Hi Matthias
>>>>
>>>> Using private package, yes I'm using it with Cellar. Can you share the
>>>> exception and eventually the test case ? I will reproduce and improve
>>>> this.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On Fri, Jul 14, 2023 at 9:20 AM Matthias Leinweber
>>>>  wrote:
>>>> >
>>>> > Hello Karaf User,
>>>> >
>>>> > I tried to get camel-kubernetes component working in blueprint xml, but 
>>>> > unfortunately there are class loader issues with fabric8 kubernetes 
>>>> > client (Karaf 4.3.3 camel 3.20.5)
>>>> >
>>>> > Then I tried to get the official client working. And After some real 
>>>> > strange behaviour of the gson library a second library needed a package 
>>>> > what is not exported.
>>>> >
>>>> > Does anyone got a (recent) kubernetes client working in Karaf? I could 
>>>> > use http and the kubeapi directly but it would be nicer to have a 
>>>> > component.
>>>> >
>>>> > Br
>>>> > Matthias
>>
>>
>>
>> --
>>
>> Matthias Leinweber
>>
>> Telefon: +49 ‪69 50955684‬
>> Mobil: +49 176 810 24580
>> E-Mail: m.leinwe...@datatactics.de
>> Internet: http://www.datatactics.de
>>
>> datatactics GmbH, Sitz der Gesellschaft: Frankfurt am Main, Registergericht: 
>> Amtsgericht Frankfurt am Main, HRB 121394, Geschäftsführer Matthias Leinweber
>
>
>
> --
>
> Matthias Leinweber
>
> Telefon: +49 ‪69 50955684‬
> Mobil: +49 176 810 24580
> E-Mail: m.leinwe...@datatactics.de
> Internet: http://www.datatactics.de
>
> datatactics GmbH, Sitz der Gesellschaft: Frankfurt am Main, Registergericht: 
> Amtsgericht Frankfurt am Main, HRB 121394, Geschäftsführer Matthias Leinweber

Re: [UPDATE] Karaf WebConsole has issues with Karaf 4.4.4

[Jean-Baptiste Onofré]

Hi Robert

Sure, I will (I have other stuff to include anyway :)).

Regards
JB

On Sun, Oct 1, 2023 at 8:32 AM Robert Varga  wrote:
>
> Hey JB,Can you also look at including aries-proxy-1.1.14? It needs the usual 
> ASM bump to not fail when run on Java 21.Thanks,Robert Sent from my Galaxy
>  Original message ----From: Jean-Baptiste Onofré 
>  Date: 10/1/23  07:33  (GMT+01:00) To: dev 
> , user  Subject: [UPDATE] Karaf 
> WebConsole has issues with Karaf 4.4.4 Hi guys,I created 
> https://issues.apache.org/jira/browse/KARAF-7769Since the Felix WebConsole 
> update, the Karaf WebConsole plugins(features, gogo, ...) don't load 
> correctly.I'm fixing that and I will quickly submit Karaf 4.4.5 to vote.Sorry 
> for the inconvenience;RegardsJB

[UPDATE] Karaf WebConsole has issues with Karaf 4.4.4

[Jean-Baptiste Onofré]

Hi guys,

I created https://issues.apache.org/jira/browse/KARAF-7769

Since the Felix WebConsole update, the Karaf WebConsole plugins
(features, gogo, ...) don't load correctly.
I'm fixing that and I will quickly submit Karaf 4.4.5 to vote.

Sorry for the inconvenience;
Regards
JB

Re: Karaf 4.4.4: resolver problem with multiple versions of bouncycastle / jackson

[Jean-Baptiste Onofré]

Hi Jochen

Not sure if KARAF-6068 is exactly the same, but it seems pretty close.
Let me create a test case to improve it (at least with WARN message).

Thanks
Regards
JB

On Sat, Sep 23, 2023 at 10:52 AM Jochen Walz
 wrote:
>
> Hi JB,
>
> Would of course be great if versions would always be in sync, but may be 
> difficult to achieve. My solution is currently to create small projects with 
> adapted feature files and use these for a custom assembly. Of course, that 
> means relying on libraries strictly following the rules of semantic 
> versioning and not introducing breaking changes when incrementing the minor 
> version.
>
> I may have found an old ticket for that: 
> https://issues.apache.org/jira/browse/KARAF-6068. Could it be that when 
> running into the timeout mentioned there, some package exports may also be 
> missing? Is so, a log output at least on WARN level would be helpful.
>
> Thanks & Regards
> Jochen
>
>
>
> Am 21. September 2023 10:41:19 MESZ schrieb "Jean-Baptiste Onofré" 
> :
>>
>> Hi,
>>
>> I think you have two options:
>> - you can blacklist from the features.
>> - you can override the features
>>
>> Generally speaking, it would be great that third parties features
>> leverage the Karaf spec features to avoid such kind of issue.
>>
>> I will do a pass (it's weird that our unit tests passed without problem).
>>
>> Regards
>> JB
>>
>> On Wed, Sep 20, 2023 at 7:45 PM Jochen Walz
>>  wrote:
>>>
>>>
>>>  Hello,
>>>
>>>  with Karaf 4.4.4, the bouncycastle version has changed to 1.75. CXF
>>>  still uses 1.70, i.e. when installing the CXF 3.6.2 feature, two
>>>  versions of bcprov are installed. With a debug level log appender
>>>  defined for org.apache.felix.resolver or setting the log level of the
>>>  root logger to DEBUG,  this leads to multiple log entries like
>>>
>>>
>>>  2023-09-20T12:46:12,788 | DEBUG | features-3-thread-1 |
>>>  ResolverImpl | 17 - org.apache.karaf.features.core -
>>>  4.4.4 | Candidate permutation failed due to a conflict between imports;
>>>  will try another if possible. (Uses constraint violation. Unable to
>>>  resolve resource io.netty.handler [io.netty.handler/4.1.97.Final]
>>>  because it is exposed to package 'org.bouncycastle.asn1.pkcs' from
>>>  resources bcprov [bcprov/1.70.0] and bcprov [bcprov/1.75.0] via two
>>>  dependency chains.
>>>
>>>  Chain 1:
>>> io.netty.handler [io.netty.handler/4.1.97.Final]
>>>   import:
>>>  
>>> (&(osgi.wiring.package=org.bouncycastle.asn1.pkcs)(version>=1.69.0)(!(version>=2.0.0)))
>>>|
>>>   export: osgi.wiring.package: org.bouncycastle.asn1.pkcs
>>> bcprov [bcprov/1.70.0]
>>>
>>>  Chain 2:
>>> io.netty.handler [io.netty.handler/4.1.97.Final]
>>>   import:
>>>  
>>> (&(osgi.wiring.package=org.bouncycastle.cert)(version>=1.69.0)(!(version>=2.0.0)))
>>>|
>>>   export: osgi.wiring.package=org.bouncycastle.cert;
>>>  uses:=org.bouncycastle.asn1.x509
>>> bcpkix [bcpkix/1.75.0]
>>>   import:
>>>  (&(osgi.wiring.package=org.bouncycastle.asn1.x509)(version>=1.72.0))
>>>|
>>>   export: osgi.wiring.package: org.bouncycastle.asn1.x509;
>>>  uses:=org.bouncycastle.asn1.pkcs
>>>   export: osgi.wiring.package=org.bouncycastle.asn1.pkcs
>>> bcprov [bcprov/1.75.0]) ...
>>>
>>>
>>>  and
>>>
>>>
>>>  2023-09-20T12:46:13,779 | DEBUG | features-3-thread-1 |
>>>  ResolverImpl | 17 - org.apache.karaf.features.core -
>>>  4.4.4 | Candidate permutation failed due to a conflict between imports;
>>>  will try another if possible. (Uses constraint violation. Unable to
>>>  resolve resource com.fasterxml.jackson.core.jackson-databind
>>>  [com.fasterxml.jackson.core.jackson-databind/2.14.1] because it is
>>>  exposed to package 'com.fasterxml.jackson.core.base' from resources
>>>  com.fasterxml.jackson.core.jackson-core
>>>  [com.fasterxml.jackson.core.jackson-core/2.14.1] and
>>>  com.fasterxml.jackson.core.jackson-core
>>>  [com.fasterxml.jackson.core.jackson-core/2.15.2] via two dependency chains.
>>>
>>>  Chain 1:
>>> com.fasterxml.jackson.core.jackson-databind
>>>  [com.fasterxml.jackson.core.jackson-databind/2.14.

[ANN] Apache Karaf OSGi runtime 4.3.10 has been released!

[Jean-Baptiste Onofré]

The Karaf team is pleased to announce Apache Karaf OSGi runtime 4.3.10 release.

This is a maintenance release, bringing fixes, new features and
dependency updates:
- fix race condition between the FeaturesService and FeatureDeploymentListener
- fix --patch-module on Instance startup
- add exec:groovy shell command
- dependency updates including CVE fixes (Johnzon, BouncyCastle,
Commons FileUpload, ...)
- and much more!

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

You can download this release here: https://karaf.apache.org/download.html

Enjoy!
The Apache Karaf team

Re: Karaf 4.4.4: resolver problem with multiple versions of bouncycastle / jackson

[Jean-Baptiste Onofré]

Hi,

I think you have two options:
- you can blacklist from the features.
- you can override the features

Generally speaking, it would be great that third parties features
leverage the Karaf spec features to avoid such kind of issue.

I will do a pass (it's weird that our unit tests passed without problem).

Regards
JB

On Wed, Sep 20, 2023 at 7:45 PM Jochen Walz
 wrote:
>
> Hello,
>
> with Karaf 4.4.4, the bouncycastle version has changed to 1.75. CXF
> still uses 1.70, i.e. when installing the CXF 3.6.2 feature, two
> versions of bcprov are installed. With a debug level log appender
> defined for org.apache.felix.resolver or setting the log level of the
> root logger to DEBUG,  this leads to multiple log entries like
>
>
> 2023-09-20T12:46:12,788 | DEBUG | features-3-thread-1 |
> ResolverImpl | 17 - org.apache.karaf.features.core -
> 4.4.4 | Candidate permutation failed due to a conflict between imports;
> will try another if possible. (Uses constraint violation. Unable to
> resolve resource io.netty.handler [io.netty.handler/4.1.97.Final]
> because it is exposed to package 'org.bouncycastle.asn1.pkcs' from
> resources bcprov [bcprov/1.70.0] and bcprov [bcprov/1.75.0] via two
> dependency chains.
>
> Chain 1:
>io.netty.handler [io.netty.handler/4.1.97.Final]
>  import:
> (&(osgi.wiring.package=org.bouncycastle.asn1.pkcs)(version>=1.69.0)(!(version>=2.0.0)))
>   |
>  export: osgi.wiring.package: org.bouncycastle.asn1.pkcs
>bcprov [bcprov/1.70.0]
>
> Chain 2:
>io.netty.handler [io.netty.handler/4.1.97.Final]
>  import:
> (&(osgi.wiring.package=org.bouncycastle.cert)(version>=1.69.0)(!(version>=2.0.0)))
>   |
>  export: osgi.wiring.package=org.bouncycastle.cert;
> uses:=org.bouncycastle.asn1.x509
>bcpkix [bcpkix/1.75.0]
>  import:
> (&(osgi.wiring.package=org.bouncycastle.asn1.x509)(version>=1.72.0))
>   |
>  export: osgi.wiring.package: org.bouncycastle.asn1.x509;
> uses:=org.bouncycastle.asn1.pkcs
>  export: osgi.wiring.package=org.bouncycastle.asn1.pkcs
>bcprov [bcprov/1.75.0]) ...
>
>
> and
>
>
> 2023-09-20T12:46:13,779 | DEBUG | features-3-thread-1 |
> ResolverImpl | 17 - org.apache.karaf.features.core -
> 4.4.4 | Candidate permutation failed due to a conflict between imports;
> will try another if possible. (Uses constraint violation. Unable to
> resolve resource com.fasterxml.jackson.core.jackson-databind
> [com.fasterxml.jackson.core.jackson-databind/2.14.1] because it is
> exposed to package 'com.fasterxml.jackson.core.base' from resources
> com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.14.1] and
> com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.15.2] via two dependency chains.
>
> Chain 1:
>com.fasterxml.jackson.core.jackson-databind
> [com.fasterxml.jackson.core.jackson-databind/2.14.1]
>  import:
> (&(osgi.wiring.package=com.fasterxml.jackson.core.base)(version>=2.14.0)(!(version>=3.0.0)))
>   |
>  export: osgi.wiring.package: com.fasterxml.jackson.core.base
>com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.14.1]
>
> Chain 2:
>com.fasterxml.jackson.core.jackson-databind
> [com.fasterxml.jackson.core.jackson-databind/2.14.1]
>  import:
> (&(osgi.wiring.package=com.fasterxml.jackson.core)(version>=2.14.0)(!(version>=3.0.0)))
>   |
>  export: osgi.wiring.package=com.fasterxml.jackson.core;
> uses:=com.fasterxml.jackson.core.json
>com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.15.2]
>  import:
> (&(osgi.wiring.package=com.fasterxml.jackson.core.json)(version>=2.15.0)(!(version>=3.0.0)))
>   |
>  export: osgi.wiring.package=com.fasterxml.jackson.core.json;
> uses:=com.fasterxml.jackson.core.base
>com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.15.2]
>  import:
> (&(osgi.wiring.package=com.fasterxml.jackson.core.base)(version>=2.15.0)(!(version>=3.0.0)))
>   |
>  export: osgi.wiring.package: com.fasterxml.jackson.core.base
>com.fasterxml.jackson.core.jackson-core
> [com.fasterxml.jackson.core.jackson-core/2.15.2]) ...
>
>
> It may take very long until the resolver finishes. In some cases, it
> obviously fails at this point, and later I receive some FileNotFound
> exceptions because some packages are not exported - I have observed
> this, e.g., for the Datastax Cassandra driver, version 4.17, when
> jackson-databind 2.14.1 and 2.15.2 are both installed. The behavior is
> not always reproducible. E.g., for a feature with a bundle importing
> some bouncycastle packages, installation of the feature takes very long
> and/or finally fails, while installing and starting the bundles one by
> one succeeds.
>
> I don't think this is specifically related to 4.4.4 - only showed up in
> my case due to the upgraded dependencies while other features are still
> 

Re: Minho Qusetion

[Jean-Baptiste Onofré]

Hi John,

IMHO, Camel 4 dropped OSGi support because we lack contributors and
it's very hard to "maintain" the dependencies in the OSGi way. I plan
to work on Camel 4 OSGi support but I can't take any commitment
because I'm doing it in my spare time only :)

I agree with Greg's points anyway.

Regards
JB

On Tue, Sep 19, 2023 at 5:14 AM John Taylor  wrote:
>
> Hi JB,
>
> >> . If we have clear signs that people are interested in colocation and 
> >> Minho runtime paradigm, it could change :)
> This probably isn't exactly what you're referring to, but I'll express 
> interest as I'm concerned that I won't be able to do things like I have 
> preferred to and Minho might(?) somehow be a solution. My preference has been 
> to run all my Camel routes in the Karaf OSGi runtime and not have to go the 
> multiple spring boot/whatever apps for each context. It's not a sophisticated 
> setup for sure, but it looks like Camel on OSGi support was dropped entirely 
> in Camel 4 (components are no longer built with OSGi) so I won't be able to 
> keep doing that as simply.
>
> Sorry, probably out in left field for the discussion.  :)
>
> -John

Re: Building custom Karaf distribution with Karaf 4.4.4 not working

[Jean-Baptiste Onofré]

Hi Andre

Thanks for the update, we gonna fix that.

Regards
JB

On Tue, Sep 19, 2023 at 2:52 PM Andre Schlegel-Tylla
 wrote:
>
> I have created an issue for pax-web 
> https://github.com/ops4j/org.ops4j.pax.web/issues/1895
>
> Without this feature we can't use the RewriteHandler.
>
> regards
> Andre

Re: Spring Deployer

[Jean-Baptiste Onofré]

Hi,

If you talk about the "pure" spring deployer, it's still there:
https://github.com/apache/karaf/tree/main/deployer/spring (and you can
install it via feature).

On the other hand, the Spring DM "deployer" doesn't exist anymore as
it has been replaced by Blueprint.

Regards
JB

On Tue, Sep 19, 2023 at 1:52 PM Svend Ole Nielsen  wrote:
>
> Hi - I have been looking all over the internet and also the local library, 
> but have not found any information on why/when the spring deployer was left 
> behind and removed from the 'deployer' feature.
>
> For a migration project it is required, and I can install it from the console 
> which makes it all tick. However, I would like to have it startup during boot 
> time, but I'm having a hard time putting it in the right place.
>
> Any help would be greatly appreciated
>

[ANN] Apache Karaf OSGi runtime 4.4.4 has been released!

[Jean-Baptiste Onofré]

The Karaf team is pleased to announce Apache Karaf OSGi runtime 4.4.4 release.

This is a a maintenance release, bringing a lot of dependency updates
and fixes, especially:
- fix race condition between the FeatureService and FeatureDeploymentListener
- fix --patch-module on Instance startup
- add exec:groovy shell command
- a lot of dependency updated including CVE fixes (Johnzon,
BouncyCastle, Commons FileUpload, and much more !)
- better JDK20+ support
- and much more!

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

You can download this release here: https://karaf.apache.org/download.html

Enjoy !
The Apache Karaf team

Re: Minho Qusetion

[Jean-Baptiste Onofré]

Hi Paul,

Yes, that's the idea: having a central/shared registry gathering beans
from OSGi, Spring Boot, CDI, whatever.
The "dynamic" approach (adding/removing applications managed by a app
manager like Spring Boot, OSGi, ...) is also a target.

To be honest, currently, Minho is not moving forward due to the low
interest we got. If we have clear signs that people are interested in
colocation and Minho runtime paradigm, it could change :)

Regards
JB

On Mon, Sep 18, 2023 at 6:29 AM Paul Fraser  wrote:
>
> Hi,
>
> Cannot quite get my head around Apache Minho but--
>
> Can OSGi services be somehow added to the Spring Boot application at
> runtime or even at Spring Boot restart?
>
> In effect having Spring Boot acting like an OSGi runtime with services
> being added and removed as required.
>
> Is Minho going to proceed?
>
> Paul Fraser
>
>

Re: Karaf 4.3.7 Java 17 Support

[Jean-Baptiste Onofré]

The improvements are more for JDK 20/21: new ASM version, etc.
Regarding JDK17, I'm cleaning and fixing couple of missing packages in
jre.properties.

Regards
JB

On Wed, Sep 6, 2023 at 3:45 PM Kevin Schmidt  wrote:
>
> What are the improvements?  We are using Java 17 already with an earlier 
> 4.3.x and would like to know what moving to 4.3.10 will give us.  Thanks!
>
> On Wed, Sep 6, 2023 at 2:38 AM Jean-Baptiste Onofré  wrote:
>>
>> Hi,
>>
>> Yes, Karaf 4.3.x supports Java 17. I recommend to wait Karaf 4.3.10
>> (currently in preparation) that includes few improvements for JDK17+.
>>
>> Regards
>> JB
>>
>> On Tue, Sep 5, 2023 at 2:09 PM Chandan Singh
>>  wrote:
>> >
>> > Hi Team ,
>> >
>> > Can anyone please confirm if  Karaf 4.3.7  supports Java 17 .  We are 
>> > currently on Java 11 and Planning to upgrade to Java 17 . Also Please 
>> > suggest any config changes needed ?
>> >
>> >
>> > Regards
>> > Chandan

Re: Karaf 4.3.7 Java 17 Support

[Jean-Baptiste Onofré]

Hi,

Yes, Karaf 4.3.x supports Java 17. I recommend to wait Karaf 4.3.10
(currently in preparation) that includes few improvements for JDK17+.

Regards
JB

On Tue, Sep 5, 2023 at 2:09 PM Chandan Singh
 wrote:
>
> Hi Team ,
>
> Can anyone please confirm if  Karaf 4.3.7  supports Java 17 .  We are 
> currently on Java 11 and Planning to upgrade to Java 17 . Also Please suggest 
> any config changes needed ?
>
>
> Regards
> Chandan

Re: Karaf 4.3.10

[Jean-Baptiste Onofré]

Hi Jérémie

I'm working on 4.4.x and 4.3.x next releases. I think I will be ready
by the end of next week, so with the vote period, hopefully 4.3.10
should be available in 2 or 3 weeks.

Regards
JB

On Tue, Aug 22, 2023 at 5:03 PM Jérémie  wrote:
>
> Hello,
>
> Is there an ETA for a release of Karaf in the branch 4.3.x ?
> I'd like to test the Fix for [KARAF-6074] Race condition between the 
> FeaturesService and FeatureDeploymentListener - ASF JIRA (apache.org) (I 
> can't upgrade Karaf since v4.3.6 ^^)
>
> Thanks!
>
> Regards
> Jérémie

Re: Show reverse depends of a bundle on console

[Jean-Baptiste Onofré]

Hi,

It sounds like a change in exports command between Karaf 2 & 3.

Can you please create a ticket ? I will re-add the option on the shell
command (and probably corresponding MBean).

Thanks !
Regards
JB

On Tue, Aug 15, 2023 at 9:44 PM Anthony Wood  wrote:
>
> Hi Paul,
>
> I am looking for a way to find which bundles are importing packages from a 
> *given* bundle.
>
> In karaf 2.x, if I have a bundle dependency network in which both bundles 1 
> and 2 import a package exported from bundle 3, this command shows me exactly 
> which bundles depend on 3 (i.e., 1 and 2):
>
> karaf> exports -i 3
>  ID Packages   Imported by
>  3  org.foo.bar; version=1.0   Bundle One (1)
>  3  org.foo.baz; version=1.0   Bundle Two (2)
>
> In karaf 4.x, so far I cannot duplicate this.  The best I have found is to 
> use “tree-show” on every bundle and search/grep for the bundle 3 that I care 
> about.  The “imports” command only shows me the packages, not the bundles 
> satisfying them.  I am open to suggestions for recovering the functionality 
> loss.
>
> Thanks,
> Anthony
>

Re: OAuth2 in Karaf

[Jean-Baptiste Onofré]

Hi Jaap

Can you please create a ticket on issue.apache.org ? We can add some
utils methods in the JAAS module.

Thanks !
Regards
JB

On Mon, Aug 21, 2023 at 8:17 PM f...@gordijn.org  wrote:
>
> Hi Matt,
>
>
>
> Can you enlighten me?
>
> What is a JIRA?
>
>
>
> I know Jira from Atlassian very well, but that is probably not what you mean 
> .
>
>
>
> Thanks,
>
>
>
> -- Jaap
>
>
>
> From: Matt Pavlovich 
> Sent: Monday, August 21, 2023 6:07 PM
> To: user@karaf.apache.org
> Subject: Re: OAuth2 in Karaf
>
>
>
> Adding a client-aide JAAS provider would be useful.
>
>
>
> Perhaps a JIRA?
>
>
>
> > On Aug 20, 2023, at 3:16 PM, f...@gordijn.org wrote:
>
> >
>
> > Hi all,
>
> >
>
> > Are there any examples on how to do OAuth2 in Karaf?
>
> >
>
> > Best,
>
> >
>
> > -- Jaap
>
> >

Re: Karaf training

[Jean-Baptiste Onofré]

Hi,

Yes, you can take a look on https://karaf.apache.org/community.html in
the "Commercial Support" section.

Yupiik provides training for instance about Karaf.

Regards
JB

On Wed, Aug 2, 2023 at 6:28 PM jose.garnica.lomeli
 wrote:
>
> Do you know if exists any official Karaf training offered for companies?
>
> Sent with Proton Mail secure email.

Re: Query for way to use Karaf 4.4.3 Jaas with jasypt encryption

[Jean-Baptiste Onofré]

Hi

Do you have the jasypt feature installed ?

Regards
JB

On Fri, Jul 21, 2023 at 10:35 AM Patange, Sneha via user
 wrote:
>
> Hello Team,
>
>  I am using Karaf 4.4.3 version for my application. My 
> application is java(17) based which is using the karaf osgi environment for 
> deployment and running. Recently there is a requirement for securing 
> sensitive information of bundle configuration files which contains mainly 
> password. From analysis, I came to know that we can use karaf jaas for 
> encryption and decryption as well.
>
>
>
> To enable encryption via jaas using jasypt encryption I have done the 
> following things,
>
>
>
> Added dependency of jaas jasypt to karaf pom.xml
>
>
>
> 
>
> org.apache.karaf.jaas
>
> org.apache.karaf.jaas.jasypt
>
> 4.4.3
>
> test
>
> 
>
>
>
> Also changed the properties of /etc/org.apache.karaf.jaas.cfg file as follows,
>
>
>
>   encryption.name=jasypt
>
>   encryption.algorithm = SHA-256
>
>   encryption.encoding = hexadecimal
>
>   encryption.prefix = {CRYPT}
>
>   encryption.suffix = {CRYPT}
>
> config.file = /opt/icom/conf/myconfig.cfg
>
>
>
> Changed the configuration file property for which the encryption is required 
> such as,
>
>
>
> # /opt/icom/conf/myconfig.cfg
>
> password=ENC(SHA-256:password)
>
>
>
> I have built the karaf assembly with the added dependency and started the 
> karaf.
>
>
>
> Got the below issue in karaf shell,
>
>
>
> Exception in thread "encryption-2-thread-1" Exception in thread 
> "encryption-1-thread-1" java.lang.IllegalStateException: Encryption service 
> jasypt not found. Please check that the encryption service is correctly set 
> up.
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryptionInternal(EncryptionSupport.java:137)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryption(EncryptionSupport.java:123)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.encrypt(EncryptionSupport.java:74)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.encryptedPassword(AutoEncryptionSupport.java:138)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:90)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>
> at java.base/java.lang.Thread.run(Thread.java:833)
>
> java.lang.IllegalStateException: Encryption service jasypt not found. Please 
> check that the encryption service is correctly set up.
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryptionInternal(EncryptionSupport.java:137)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryption(EncryptionSupport.java:123)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.encrypt(EncryptionSupport.java:74)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.encryptedPassword(AutoEncryptionSupport.java:138)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:90)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>
> at java.base/java.lang.Thread.run(Thread.java:833)
>
> Exception in thread "encryption-3-thread-1" java.lang.IllegalStateException: 
> Encryption service jasypt not found. Please check that the encryption service 
> is correctly set up.
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryptionInternal(EncryptionSupport.java:137)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.getEncryption(EncryptionSupport.java:123)
>
> at 
> org.apache.karaf.jaas.modules.encryption.EncryptionSupport.encrypt(EncryptionSupport.java:74)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.encryptedPassword(AutoEncryptionSupport.java:138)
>
> at 
> org.apache.karaf.jaas.modules.properties.AutoEncryptionSupport.run(AutoEncryptionSupport.java:90)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>
> at java.base/java.lang.Thread.run(Thread.java:833)
>
>
>
> I have dug down more to resolve the issue. Come to know that I also need to 
> define and register a StringEncryptor service. How can I register it without 
> blueprint.xml configuration?
>
>
>
> am I missing something to do? Please let me know the exact way of doing it. 
> Please help me to resolve the issue. I am 

Re: Camel kubernetes

[Jean-Baptiste Onofré]

Hi Matthias

Using private package, yes I'm using it with Cellar. Can you share the
exception and eventually the test case ? I will reproduce and improve
this.

Regards
JB

On Fri, Jul 14, 2023 at 9:20 AM Matthias Leinweber
 wrote:
>
> Hello Karaf User,
>
> I tried to get camel-kubernetes component working in blueprint xml, but 
> unfortunately there are class loader issues with fabric8 kubernetes client 
> (Karaf 4.3.3 camel 3.20.5)
>
> Then I tried to get the official client working. And After some real strange 
> behaviour of the gson library a second library needed a package what is not 
> exported.
>
> Does anyone got a (recent) kubernetes client working in Karaf? I could use 
> http and the kubeapi directly but it would be nicer to have a component.
>
> Br
> Matthias

Re: karaf newbie question.

[Jean-Baptiste Onofré]

Hi,

I would need the full trace but it seems the problem is not about the
import/export packages, but more about a service requirement.
It seems your bundle MANIFEST contains a required service
(JaxRsEventAdapter) but no bundle provides this capability.

I would suggest to check your headers (and eventually remove the
require service header).

Regards
JB

On Thu, Jul 6, 2023 at 6:20 AM Onder SEZGIN  wrote:
>
> OK i am not very to karaf, i hadjust not gone beyond experimenting except 
> recent times.
> i have 3 repositories.
>
> one of them if called a-common bundle.
>
> it basically imports packages of dependency and since i dont specify anything 
> extra, it exports its packages as expected.
>
> this bundle is imported by another bundle called b-bundle let's say.
>
> for some reason, the package is getting exported twice
>
> there is no explicit export of a-common in b-bundle.
>
> admin@root()> bundle:classes | grep -i jaxrseve
> 251 | xyz.JaxRsEventAdapter.class | exported: true
> 252 | xyz.JaxRsEventAdapter.class | exported: false
> 254 | xyz.JaxRsEventAdapter.class | exported: false
>
>
> -
> Status: Failure
> Blueprint
> 7/5/23 10:53 PM
> Exception:
> null
> java.util.concurrent.TimeoutException
> at 
> org.apache.aries.blueprint.container.BlueprintContainerImpl$1.run(BlueprintContainerImpl.java:393)
> at 
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:45)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:750)
>
> Missing dependencies:
> (objectClass=xyz.JaxRsEventAdapter)
> Declarative Services
>
> i have tried quite a lot of combinations.
> couldn't yet come up with proper solution even though the problem sounds 
> awful easy.
>
>   Any idea is appreciated.
>

Re: Jar libraries as wrap in the Karaf console

[Jean-Baptiste Onofré]

Hi,

You can provide Bundle-SymbolicName on the wrap URL (provided by
features or manually).

Instead of using wrap, you have basically two options:
1. You create a "real" OSGi bundle for the dependencies (or you ask
ServiceMix to do so)
2. You embed the dependency as private package in your bundle

Regards
JB

On Tue, Jul 4, 2023 at 6:20 PM jose.garnica.lomeli
 wrote:
>
> Hi everyone,
>
> The karaf console in my application is displaying many libraries as wrap
> I know it is a way to make compatible karaf to non-osgi java libraries
>
> is there any way to remove those wrap of the console?
>
>
>
> Sent with Proton Mail secure email.

Re: Karaf5

[Jean-Baptiste Onofré]

Hi,

I guess you didn't follow the latest discussion.

Karaf5 (as the initial intention) changed to Karaf Minho:
https://github.com/apache/karaf-minho

The latest fixes/improvements has been made on Minho (Karaf "runtime"
stays the OSGi runtime).

Can you please try with Minho ?

Regards
JB

On Mon, Jul 3, 2023 at 11:28 AM Millieret, Xavier via user
 wrote:
>
> Hi Karaf5 team,
>
> I would like to try to use the demo sample with the 
> pet-clinic/spring-boot-app.
> I am very interested by this feature, i.e. Using a pure spring-boot 
> application inside the runtime karaf5.
> And having the control on it, like karaf 4 and OSGI application. I am not 
> sure than it's the case now, but it's what I undesrstood on
> https://www.youtube.com/watch?v=mhqgPXoJXCk
> So I am on the DEMO branch, I compile and run the following command:
> java -jar demo/pet-clinic/runtime/target/multi-apps-runtime-5.0-SNAPSHOT.jar
> Karaf5 runs, BUT exit just after
> 2023-07-03 11:06:37.222992118 INFO [ 
> org.apache.karaf.boot.service.KarafLifeCycleService start ] : Starting 
> lifecycle service
>
> What I missing on the purpose for this?
> I think than this initiative, having karaf (like we know for OSGI 
> application) with pure spring-boot application, it's very interesting
>
> Regards
>
> Xavier Millieret for Eaton
>
>
>
> 
> Eaton Industries (France) S.A.S ~ Siège social: 110 Rue Blaise Pascal, 
> Immeuble Le Viséo - Bâtiment A Innovallée, 38330, Montbonnot-St.-Martin, 
> France ~ Lieu d'enregistrement au registre du commerce: Grenoble ~ Numéro 
> d'enregistrement: 509 653 176 ~ Capital social souscrit et liberé:€ 16215441 
> ~ Numéro de TVA: FR47509653176
>
> 
>
>

Re: Karaf seems to ignore new files in folder etc if flag x is not set

[Jean-Baptiste Onofré]

Hi

Catcha :)

Are you sure it's on the file itself ? It makes sense to have x for
the etc folder (or subfolder) itself, but surprising for the file.

I checked in FileInstall, and the WatcherScanner doesn't define
anything special on the filesystem attribute. However, it could be
related to ENTRY_CREATE in FileInstall Watcher where he checks if it
has to go subfolder, so checking the attribute there. I can do a
reproducer.

Regards
JB

On Thu, Jun 29, 2023 at 4:28 PM Ephemeris Lappis
 wrote:
>
> Hello
>
> I was talking about the Unix files flags/atttributes : we've observed
> that when new files are dropped into the etc folder, if the owner
> attributes are only "rw", the file is not taken into account and the
> expected configuration is not loaded ; "rwx" seems to be required, and
> I have no explanation for that.
>
> Is it clearer ?
>
> Thanks.
>
> Regards.
>
> Le jeu. 29 juin 2023 à 14:04, Jean-Baptiste Onofré  a 
> écrit :
> >
> > Hi,
> >
> > What's the flag "x" ? :)
> >
> > Can you please elaborate a bit ?
> >
> > Thanks,
> > Regards
> > JB
> >
> > On Wed, Jun 28, 2023 at 3:49 PM Ephemeris Lappis
> >  wrote:
> > >
> > > Hello.
> > >
> > > If I'm not wrong, it seems that Karaf (4.4.3 in our last works)
> > > ignores new files copied into the folder "etc" if these files do not
> > > have the flag "x" set.
> > >
> > > I don't see any documentation about this, and a confirmation should be
> > > welcome (and an explanation if it's confirmed
> > >
> > > Thanks in advance.
> > >
> > > Regards.

Re: Autocommit is happening even within a transaction manager

[Jean-Baptiste Onofré]

Hi Ash,

What kind of datasource are you using ?

Regards
JB

On Wed, Jun 28, 2023 at 7:58 PM Ash Williams  wrote:

> Hi,
>
>
>
> We have an issue where sql statements executed by hibernate are being
> immediately committed, despite the fact that the entity manager is managed
> by a (local) transaction. It's my understanding that hibernate and the
> transaction manager should together ensure that auto commit is disabled on
> the obtained connection. My environment is Karaf 4.4.3 on Java 8 and
> hibernate 5.6.7.
>
>
>
> # Here is the persistence.xml file:
>
>
>
> 
>
>   
>
> 
>
>
>
> # Here is a self-contained class that demonstrates the problem:
>
>
>
> import java.io.IOException;
>
> import java.sql.SQLException;
>
> import java.util.HashMap;
>
> import java.util.Map;
>
> import java.util.Properties;
>
>
>
> import javax.persistence.EntityManager;
>
> import javax.persistence.Query;
>
> import javax.sql.DataSource;
>
>
>
> import org.apache.commons.lang3.RandomStringUtils;
>
> import org.osgi.service.component.annotations.Activate;
>
> import org.osgi.service.component.annotations.Component;
>
> import org.osgi.service.component.annotations.Reference;
>
> import org.osgi.service.jdbc.DataSourceFactory;
>
> import org.osgi.service.jpa.EntityManagerFactoryBuilder;
>
> import org.osgi.service.transaction.control.TransactionControl;
>
> import
> org.osgi.service.transaction.control.jdbc.JDBCConnectionProviderFactory;
>
> import org.osgi.service.transaction.control.jpa.JPAEntityManagerProvider;
>
> import
> org.osgi.service.transaction.control.jpa.JPAEntityManagerProviderFactory;
>
>
>
> @Component(immediate = true)
>
> public class AcmeTest {
>
>
>
>@Activate
>
>public AcmeTest(
>
>
>
>   @Reference(target = "(osgi.unit.name=acme.pu)")
>
>  EntityManagerFactoryBuilder emfb,
>
>
>
>   @Reference(target = "(&(osgi.jdbc.driver.name
> =oracle)(osgi.jdbc.driver.class=oracle.jdbc.OracleDriver))")
>
>  DataSourceFactory dsf,
>
>
>
>   @Reference(target = "(osgi.local.enabled=true)")
>
>  JPAEntityManagerProviderFactory providerFactory,
>
>
>
>   @Reference(target = "(osgi.local.enabled=true)")
>
>  TransactionControl txControl
>
>
>
>) throws IOException, SQLException {
>
>
>
>   // create datasource from factory
>
>
>
>   Properties dsfProps = new Properties();
>
>   dsfProps.put("user", "xxx-withheld-xxx");
>
>   dsfProps.put("password", "xxx-withheld-xxx");
>
>   dsfProps.put("url", "xxx-withheld-xxx");
>
>
>
>   DataSource datasource = dsf.createDataSource(dsfProps);
>
>
>
>   // create jpa entity manager provider from datasource and pool props
>
>
>
>   Map jpaProperties = new HashMap<>();
>
>   jpaProperties.put("javax.persistence.dataSource", datasource);
>
>   jpaProperties.put("hibernate.dialect",
> "org.hibernate.dialect.Oracle10gDialect");
>
>
>
>   Map resourceProviderProperties = new HashMap<>();
>
>
> resourceProviderProperties.put(JDBCConnectionProviderFactory.CONNECTION_POOLING_ENABLED,
> false);
>
>
>
>   JPAEntityManagerProvider provider =
> providerFactory.getProviderFor(emfb, jpaProperties,
> resourceProviderProperties);
>
>
>
>   // test it out by updating a test_column to a random string
>
>
>
>   EntityManager entityManager = provider.getResource(txControl);
>
>   txControl.required(() -> {
>
>
>
>  String newValue = RandomStringUtils.random(10, true,
> false);
>
>
>
>  Query query = entityManager.createNativeQuery("update test_table
> set test_column = ? where test_name = 'test'");
>
>  query.setParameter(1, newValue);
>
>
>
>  query.executeUpdate();
>
>
>
>  // ***
>
>   // CONNECTION HAS BEEN COMMITTED SINCE WE
> CAN SEE UPDATED VALUE OF
>
>   // TEST_COLUMN IN THE DATABASE WHILST WE ARE
> STILL IN THIS LAMBDA
>
>  // ***
>
>
>
>  return null;
>
>
>
>   });
>
>
>
>}
>
>
>
> }
>
>
>
> # This information about the transaction services running on the platform
> might be important:
>
>
>
> admin@root()> bundle:services -p 281
>
>
>
> pax-transx-tm-geronimo (281) provides:
>
> --
>
> objectClass = [org.osgi.service.cm.ManagedService]
>
> service.bundleid = 281
>
> service.id = 335
>
> service.pid = org.ops4j.pax.transx.tm.geronimo
>
> service.scope = singleton
>
> 
>
> objectClass = [javax.transaction.TransactionManager,
> javax.transaction.TransactionSynchronizationRegistry,
> javax.transaction.UserTransaction,
> org.apache.geronimo.transaction.manager.RecoverableTransactionManage
>
> r, org.springframework.transaction.PlatformTransactionManager]
>
> service.bundleid = 281
>
> service.id = 360
>
> service.scope = singleton
>
> 
>
> objectClass = [org.ops4j.pax.transx.tm.TransactionManager]
>
> 

Re: Are released features picked over SNAPSHOT when installing features from maven?

[Jean-Baptiste Onofré]

Hi Steinar,

do you use the default etc/org.ops4j.pax.maven.url.cfg ?

Regards
JB

On Wed, Jun 28, 2023 at 8:56 PM Steinar Bang  wrote:
>
> I am working on version 1.15.8-SNAPSHOT of authservice:
>  https://github.com/steinarb/authservice
>
> My problem with testing release 1.15.8-SNAPSHOT is that 1.15.7 is picked
> instead, when I load feature repositories from maven using version
> LATEST.
>
> Version 1.15.7 is found on external repos (maven central in this case),
> while 1.15.8-SNAPSHOT is built locally and installed in the local maven
> cache (~/.m2/repository/).
>
> My questions are:
>  1. Are released versions being picked over SNAPSHOT releases?
>  2. Is this the expected behaviour?
>  3. Is there a simple way to make local feature installs pick SNAPSHOTs
> over released version?
>
> I'm running on karaf 4.4.3 on java 17 (openjdk) on debian 12 "bookworm"
> on amd64.
>
>
> - Steinar
>

Re: Karaf seems to ignore new files in folder etc if flag x is not set

[Jean-Baptiste Onofré]

Hi,

What's the flag "x" ? :)

Can you please elaborate a bit ?

Thanks,
Regards
JB

On Wed, Jun 28, 2023 at 3:49 PM Ephemeris Lappis
 wrote:
>
> Hello.
>
> If I'm not wrong, it seems that Karaf (4.4.3 in our last works)
> ignores new files copied into the folder "etc" if these files do not
> have the flag "x" set.
>
> I don't see any documentation about this, and a confirmation should be
> welcome (and an explanation if it's confirmed
>
> Thanks in advance.
>
> Regards.

Re: Service PID for a JSON configuration

[Jean-Baptiste Onofré]

Good point. Can you please create a Jira, I will improve this part ?

Thanks,
Regards
JB

On Wed, Jun 14, 2023 at 7:22 PM Jakub Herkel  wrote:
>
> I checked ConfigurationPID and pid is create by this method :
>
> public static ConfigurationPID parseFilename(final String filename) {
> final String pid = filename.substring(0, filename.lastIndexOf('.'));
> return parsePid(pid);
> }
>
> As for me it would be better if parseFilename created pid also from a
> file extension, what do you mean? Pid will be the same i.e .cfg
> .config .cfg.json all will have the same pid.
>
> Jakub
>
> On Wed, Jun 14, 2023 at 7:30 AM Jean-Baptiste Onofré  
> wrote:
> >
> > Hi
> >
> > Yes, by default the suffix is .cfg.json
> > (https://github.com/apache/karaf/blob/main/config/src/main/java/org/apache/karaf/config/core/impl/JsonConfigInstaller.java#L49).
> >
> > You can override the suffix by using karaf.json.config.extension
> > system property (in the etc/config.properties for instance) or
> > KARAF_JSON_CONFIG_EXTENSION env variable.
> >
> > Regards
> > JB
> >
> > On Tue, Jun 13, 2023 at 8:45 PM Jakub Herkel  wrote:
> > >
> > > Hello,
> > >
> > > I tried to use a  json configuration with Karaf 4.4.3. For example I
> > > created a test.cfg.json:
> > > {
> > >   "test1":"testString",
> > >   "test2":false
> > > }
> > >
> > > I can see that Karaf read this config viac config:list
> > >
> > > Pid:test.cfg
> > > BundleLocation: ?
> > > Properties:
> > >felix.fileinstall.filename =
> > > file:/home/jakub/java/apache-karaf-4.4.3/etc/test.cfg.json
> > >service.pid = test.cfg
> > >test1 = testString
> > >test2 = false
> > >
> > > But what is little surprise for me is that a service pid is
> > > "test.cfg". I assume that cfg.json is an extension for json files in
> > > the Karaf and the service pid is constructed as .cfg.json. We
> > > have lot of blueprints where config (with cfg extension) is referenced
> > > with ".cfg" scheme. That is why I will have to change lot of
> > > files if it is necessary to append .cfg for every
> > > cm:managed-properties elements.
> > > So is there any way how to create json configuration with service pid
> > > without .cfg suffix? I.e service.pid = test.
> > >
> > > Thanks for any advice
> > >
> > > with best regards
> > >
> > > Jakub

Re: Persist bundle status in karaf

[Jean-Baptiste Onofré]

Hi

it depends what you do in your activator. If the activator doesn't
start by default, you can check a config in the activator and start or
not.

Regards
JB

On Mon, Jun 12, 2023 at 6:00 PM jose.garnica.lomeli
 wrote:
>
> Hello everyone,
>
> Currently I have some bundles in my karaf solution starting by default as 
> resolved, in just in specific scenarios when we need active them we execute 
> the command bundle:start  but we want a find a option to persisit 
> that configuration, to avoid re-start the bundle manually when the karaf 
> instance is restarted.
>
>
> Maybe we can use a property file in the CFG file to save the status of 
> bundle(active or resolved) but I am not sure if this the best approach or 
> karaf provide a way to do it?
>
>
>
> Sent with Proton Mail secure email.

Re: Service PID for a JSON configuration

[Jean-Baptiste Onofré]

Hi

Yes, by default the suffix is .cfg.json
(https://github.com/apache/karaf/blob/main/config/src/main/java/org/apache/karaf/config/core/impl/JsonConfigInstaller.java#L49).

You can override the suffix by using karaf.json.config.extension
system property (in the etc/config.properties for instance) or
KARAF_JSON_CONFIG_EXTENSION env variable.

Regards
JB

On Tue, Jun 13, 2023 at 8:45 PM Jakub Herkel  wrote:
>
> Hello,
>
> I tried to use a  json configuration with Karaf 4.4.3. For example I
> created a test.cfg.json:
> {
>   "test1":"testString",
>   "test2":false
> }
>
> I can see that Karaf read this config viac config:list
>
> Pid:test.cfg
> BundleLocation: ?
> Properties:
>felix.fileinstall.filename =
> file:/home/jakub/java/apache-karaf-4.4.3/etc/test.cfg.json
>service.pid = test.cfg
>test1 = testString
>test2 = false
>
> But what is little surprise for me is that a service pid is
> "test.cfg". I assume that cfg.json is an extension for json files in
> the Karaf and the service pid is constructed as .cfg.json. We
> have lot of blueprints where config (with cfg extension) is referenced
> with ".cfg" scheme. That is why I will have to change lot of
> files if it is necessary to append .cfg for every
> cm:managed-properties elements.
> So is there any way how to create json configuration with service pid
> without .cfg suffix? I.e service.pid = test.
>
> Thanks for any advice
>
> with best regards
>
> Jakub

Re: issue with Declarative Service and blueprint?

[Jean-Baptiste Onofré]

Hi

In blueprint, a bean () is searched inside the blueprint container.

If you want to use a service declared outside of the blueprint
container (DS in your case), you have to use : it will
create a bean proxying the OSGi service available in the OSGi registry
(registered with OSGi "classic" code, DS, blueprint, whatever).

Regards
JB

On Fri, Jun 9, 2023 at 5:21 PM z8sbk.yahoo.com.ar via user
 wrote:
>
> Hi,
> I'm trying to understand how declarative service works. In a bundle, I have 
> these two clasess, very basic:
>
> @Component
> public class App implements IApp {
>
> @Reference
> private IConf conf;
>
> public App() {}
>
> public void doIt() {
>
> System.out.println("foo=" + conf.getFoo());
>
> }
>
> }
>
> @Component(name = "Conf", immediate = true, configurationPid = "confByDS")
> public class Conf implements IConf {
>
> private String foo = "bar";
>
>
> public Conf() {}
> @Override
>
> public String getFoo() {
>
> return foo;
>
> }
>
> @Activate
> @Modified
> public void activate(ComponentContext context) {
>
> foo = context.getProperties().get("foo") != null ? (String) 
> context.getProperties().get("foo") : this.foo;
>
> }
>
> }
>
> Then, I have this blueprint/camel route:
>
> 
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
>
> 
> http://camel.apache.org/schema/blueprint;>
> 
> 
> 
> 
> 
>
> 
>
> After deploying the bundle, when I put the blueprint in /deploy, throws a 
> NullPointerException in conf.getFoo(), which means that the Conf reference is 
> not injected:
>
> Message History
> ---
> RouteId  ProcessorId  Processor   
>  Elapsed (ms)
> [route3] [route3] [timer://simple?period=5000 
>] [ 7]
> [route3] [to2   ] [bean:app?method=doIt   
>] [ 0]
>
> Stacktrace
> ---
> java.lang.NullPointerException: null
> at com.app.App.doIt(App.java:17) ~[!/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> ~[?:1.8.0_321]
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
> ~[?:1.8.0_321]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  ~[?:1.8.0_321]
>
> I think I'm misunderstanding how the DI in Karaf works plus DS, could you 
> please tell me what am I missing? Does DS work with Camel XML DSL routes?
>
> Thanks in advanced.
> Nick.
>
>

Re: Debugging karaf feature pax exam test in eclipse, possible?

[Jean-Baptiste Onofré]

Hi,

As pax-exam can fork the JVM to start Karaf, you need remote debugger.
Is it what you are doing ?

Regards
JB

On Sat, Jun 3, 2023 at 4:41 PM Steinar Bang  wrote:
>
> Platform: debian 11.7 "bullseye", amd64
>   openjdk-17-jdk:amd64 17.0.6+10-1~deb11u1 (ie. java 17)
>   karaf 4.4.3
>   pax-exam 4.13.5
>   eclipse  2023-03 (4.27.0)
>
> When I set breakpoints in a pax exam test and run the test in debug in
> eclipse, the breakpoints are never triggered.
>
> Is it possible to debug a pax exam test in eclipse?
>

Re: Enable/Disable Kar dependency

[Jean-Baptiste Onofré]

Hi,

you have the KarService where you can control Kar provisioning.

Regards
JB

On Wed, May 31, 2023 at 5:57 PM jose.garnica.lomeli
 wrote:
>
> Hi everyone,
>
> In my current solution I have a maven submodule providing KAR in my custom 
> Karaf distribution
>
>
> 
> com.company.mysolution
> mysolution-kar
> 1.0
> kar
> runtime
> 
>
>
> Currently the kar is starting automatically and I don't want that, I looking 
> for a way to enable it through a  configuration file or in the Karaf console.
>
>
>
>
>
>
>
> Sent with Proton Mail secure email.

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

[Jean-Baptiste Onofré]

Good catch.

I remember we investigated some race condition issues with Greg.

Let me check if the name matches.

Regards
JB

On Wed, May 31, 2023 at 4:45 PM Jesse White  wrote:
>
> Good find Ben, and thanks Grzegorz.
>
> Reverting that commit does solve the problem, so it must be related.
>
> I also found that this change does the trick:
>
> diff --git 
> a/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>  
> b/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
> index 40bb666a34..fce2c1221c 100644
> --- 
> a/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
> +++ 
> b/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
> @@ -68,9 +68,7 @@ public class FeatureConfigInstaller {
>  if (n > 0) {
>  cid.isFactoryPid = true;
>  cid.factoryPid = pid.substring(0, n);
> -if (pid.contains("~")) {
> -cid.name = pid.substring(n + 1);
> -}
> +cid.name = pid.substring(n + 1);
>  }
>  return cid;
>  }
>
> I guess there's some mismatch about the "name" of the config, so it gets 
> treated as two distinct objects.
>
> Best,
> Jesse
> 
> From: Grzegorz Grzybek 
> Sent: Wednesday, May 31, 2023 10:33 AM
> To: user@karaf.apache.org 
> Subject: Re: same configuration registered with multiple PIDs in 
> ManagedServiceFactory
>
>
> EXTERNAL EMAIL DON'T BE QUICK TO CLICK
>
> If you believe this email is suspicious, report via ‘Phish Alert Report’ 
> button
>
> 
> Hello
>
> I remember adding some safety logic related to feature-embedded 
> configuration. Because you're using dash ("-") in the PID, you're actually 
> adding a factory PID. And there may be some hidden race condition here.
>
> Let me check this problem tomorrow.
>
> regards
> Grzegorz Grzybek
>
> śr., 31 maj 2023 o 16:29 ran...@opennms.org  napisał(a):
>
> Looking at a diff between 4.3.6 and 4.3.7, the only thing that seems relevant 
> is this change, maybe the issue with multiple threads writing the config at 
> the same time needs to be solved in a different way?
>
>
>
> My guess is this fixed the race condition by making it atomic, but it doesn’t 
> stop it from happening twice in quick succession.
>
> commit 1221b0158d2494523cf94cc3f223bd552a2467c7
>
> Author: Grzegorz Grzybek gr.grzy...@gmail.com
>
> Date:   Wed Feb 9 11:53:33 2022 +0100
>
>
>
> [KARAF-7389] Prevent two threads (feature installer, CM Event Dispatcher 
> through fileinstall) writing the same config file
>
>
>
> (cherry picked from commit f3260d5ab641cdbf1bbd594875c07d974ed470a0)
>
>
>
> diff --git 
> a/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>  
> b/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>
> index ba46eb3a2d..40bb666a34 100644
>
> --- 
> a/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>
> +++ 
> b/features/core/src/main/java/org/apache/karaf/features/internal/service/FeatureConfigInstaller.java
>
> @@ -139,2 +139,3 @@ public class FeatureConfigInstaller {
>
>  properties.put(CONFIG_KEY, cid.pid);
>
> +cfg.update(cfgProps);
>
>  if (storage != null && configCfgStore) {
>
> @@ -142,3 +143,2 @@ public class FeatureConfigInstaller {
>
>  }
>
> -cfg.update(cfgProps);
>
>  try {
>
> @@ -327,7 +327,9 @@ public class FeatureConfigInstaller {
>
>  if (!cfgFile.exists()) {
>
> +File tmpCfgFile = File.createTempFile(cfgFile.getName(), 
> ".tmp", cfgFile.getParentFile());
>
>  if (jsonFormat) {
>
> -Configurations.buildWriter().build(new 
> FileWriter(cfgFile)).writeConfiguration(convertToDict(props));
>
> +Configurations.buildWriter().build(new 
> FileWriter(tmpCfgFile)).writeConfiguration(convertToDict(props));
>
>  } else {
>
> -props.save(cfgFile);
>
> +props.save(tmpCfgFile);
>
>  }
>
> +tmpCfgFile.renameTo(cfgFile);
>
>  } else {
>
>
>
> From: Jesse White 
> Date: Tuesday, May 30, 2023 at 7:11 PM
> To: user@karaf.apache.org 
> Subject: same configuration registered with multiple PIDs in 
> ManagedServiceFactory
>
> Hey folks,
>
>
>
> I've encountered some odd behavior with Karaf 4.4.3, and I'd like to confirm 
> if this is a bug or if there are some settings I can tune to alter the 
> behavior.
>
>
>
> Here's how to reproduce:
>
> Start Karaf 4.4.3 w/ JDK 11
> Install the managed factory example
>
> feature:repo-add 
> 

Re: Frameworks dropping OSGi support

[Jean-Baptiste Onofré]

Hi Jochen,

That's a fair question.

OSGi group is working on the OSGi version of the spec as part of the
cmpn scope. In the past, we also wrapped some specs in ServiceMix
Specs bundle.

So, even if it's long process, there are several works around the
specs that will help CXF, Vaadin, etc.

Regards
JB

On Wed, May 31, 2023 at 1:31 PM Jochen Walz
 wrote:
>
> Hello,
>
> Recently, some frameworks have dropped support for OSGi/Karaf in their latest 
> versions (CXF 4.0, Vaadin 24.0), because some of their dependencies are no 
> longer supported. E.g., servlet 6.
>
> I know that we still have some time left before older versions run out of 
> support (March 24 for Vaadin 23, at least when you don't have a commercial 
> license). Anyways: does anybody have a crystal ball which tells how that 
> story will go, i.e., when OSGi and Karaf will be ready to regain support by 
> these frameworks?
>
> Thanks & Regards,
>
> Jochen

Re: How Uninstall kar file in karaf application

[Jean-Baptiste Onofré]

Hi,

you can use kar:uninstall which is basically doing feature:repo-remove -u.

Regards
JB

On Sat, May 13, 2023 at 8:44 PM jose.garnica.lomeli
 wrote:
>
> I have a karaf application Where is deployed a kar file and everything works 
> fine, I would like to know what is the best way to uninstall the kar and all 
> dependencies ?
>
> Is enough use the command kar:uninstall? Or I need to something else to do a 
> proper uninstallation?
>
> Thanks in advance
>

Re: Feature XML generation

[Jean-Baptiste Onofré]

Hi Paul,

fair enough, but as soon as you need a "complex/detailed" features
repo, you need a XML template, so basically writing the repo by hand
:)

Regards
JB

On Thu, May 11, 2023 at 8:50 PM Paul Fraser  wrote:
>
> Hi JB,
>
> "I'm thinking about removing the generate mojo as some point."
>
> Please do not remove it, it is most useful when using Vaadin which pulls in 
> many bundles.
>
> Paul Fraser
>
> On 12/05/2023 3:00 am, Jean-Baptiste Onofré wrote:
> > Hi Ryan
> >
> > IMHO, it's always better to create the features XML by hand (and verify).
> >
> > I'm thinking about removing the generate mojo as some point.
> >
> > Regards
> > JB
> >
> > On Tue, May 9, 2023 at 3:58 PM Ryan Moquin  wrote:
> >> I've been getting the same error as mentioned in KARAF-5999 
> >> (https://issues.apache.org/jira/browse/KARAF-5999), but I'm just trying to 
> >> generate the features xml for a subproject.  This of course happened after 
> >> I upgraded everything to Camel 3 due to the CXF feature range usage.  Is 
> >> this going to be fixed soon?  I need to decide if I need to either revert 
> >> back to the older Camel or figure out another solution to this error:
> >>
> >> Failed to execute goal 
> >> org.apache.karaf.tooling:karaf-maven-plugin:4.2.16:features-generate-descriptor
> >>  (create-features) on project dp-processor: Unable to create features.xml 
> >> file: org.apache.maven.plugin.MojoExecutionException: Cannot locate file 
> >> for feature: org.apache.cxf.karaf:apache-cxf:xml:features:[3,4) at null -> 
> >> [Help 1]
> >>
> >> Hopefully it's something that can be rectified soon.
> >>
> >> Thanks!
> >> Ryan

Re: How to integrate a kar file into existing karaf application

[Jean-Baptiste Onofré]

Hi,

The best option is probably to use directly features instead of kar.

For kar, you can use the deploy folder or directly the kar service.

So, IMHO:
1. You app should provide a features repo XML and upload artifacts on a repo
2. You can create a custom karaf distro including your features repo

Regards
JB

On Thu, May 11, 2023 at 4:10 AM jose.garnica.lomeli
 wrote:
>
> I have a git project that generate a kar file using jenkins pipelines, when 
> we deploy the kar file we need move it manually into the deploy folder of our 
> karaf application(the karaf application use accurev instead git)
>
> In your opinion, what is the best way to improve the process?
>
> I have some ideas
>
> 1- move the existing code of kar project into the same repository of the 
> karaf application as a maven module
>
> 2- inject the kar file as a maven dependecy
>
> I think the last one is better but I getting some issues pulling the 
> artifactory from our nexus repository
>
> So besides the options already mentioned, is there another alternative?
>
> My goal is avoid to deploy/install the kar file manually into my karaf 
> application.
>
>
> Sent from Proton Mail mobile
>
>

Re: Feature XML generation

[Jean-Baptiste Onofré]

Hi Ryan

IMHO, it's always better to create the features XML by hand (and verify).

I'm thinking about removing the generate mojo as some point.

Regards
JB

On Tue, May 9, 2023 at 3:58 PM Ryan Moquin  wrote:
>
> I've been getting the same error as mentioned in KARAF-5999 
> (https://issues.apache.org/jira/browse/KARAF-5999), but I'm just trying to 
> generate the features xml for a subproject.  This of course happened after I 
> upgraded everything to Camel 3 due to the CXF feature range usage.  Is this 
> going to be fixed soon?  I need to decide if I need to either revert back to 
> the older Camel or figure out another solution to this error:
>
> Failed to execute goal 
> org.apache.karaf.tooling:karaf-maven-plugin:4.2.16:features-generate-descriptor
>  (create-features) on project dp-processor: Unable to create features.xml 
> file: org.apache.maven.plugin.MojoExecutionException: Cannot locate file for 
> feature: org.apache.cxf.karaf:apache-cxf:xml:features:[3,4) at null -> [Help 
> 1]
>
> Hopefully it's something that can be rectified soon.
>
> Thanks!
> Ryan

Re: Karaf 4.4.3 / Remote JMX configuration

[Jean-Baptiste Onofré]

Hi,

Sorry, I'm traveling this week and I have limited time to answer. I
will reply during the weekend.

Regards
JB

On Tue, Apr 25, 2023 at 8:08 AM Ephemeris Lappis
 wrote:
>
> Hello.
>
> I'm trying to configure remote JMX access to Karaf instances running
> inside containers.
>
> I've found a working configuration, but it produces some warning or
> error logs at startup.
>
> I've adapted the etc/org.apache.karaf.management.cfg to set 0.0.0.0
> instead of 127.0.0.1 for both rmiRegistryHost and rmiServerHost.
>
> When Karaf is launched, I've added this to JAVA_OPTS :
> -Djava.rmi.server.hostname=localhost \
> -Dcom.sun.management.jmxremote \
> -Dcom.sun.management.jmxremote.port=1089 \
> -Dcom.sun.management.jmxremote.rmi.port=1099 \
> -Dcom.sun.management.jmxremote.local.only=false \
> -Dcom.sun.management.jmxremote.authenticate=false \
> -Dcom.sun.management.jmxremote.ssl=false
>
> The "java.rmi.server.hostname=localhost" is needed since I have to
> access JMX through a ssh tunnel, and the name server must be
> localhost. But I have this warning in the logs :
>
> 2023-04-25T16:11:23,244 | WARN  | activator-1-thread-1 | Activator
>| 40 - org.apache.karaf.management.server - 4.4.3 |
>  | java.rmi.server.hostname system property is already set to
> localhost. Apache Karaf doesn't override it
>
> I suppose that as a simple warning, it doesn't matter. Which name does
> Karaf try to set without my property ?
>
> In the Karaf's management cfg file, port 1099 for the RMI server seems
> to be already defined, but if I don't add
> "com.sun.management.jmxremote.rmi.port=1099", external access doesn't
> work. But with my property, Karaf produces this log at startup :
>
> 2023-04-25T16:11:23,278 | ERROR | activator-1-thread-1 | Activator
>| 40 - org.apache.karaf.management.server - 4.4.3 |
>  | Can't init JMXConnectorServer: Port already in use: 1099; nested
> exception is: \n java.net.BindException: Adresse déjà utilisée
>
> How karaf handles JMX is not very clear for me... Somebody has a clearer idea 
> ?
>
> Thanks for your help.
>
> Regards.

Re: Patch for stopping karaf

[Jean-Baptiste Onofré]

No worries, I will create one for you.

Regards
JB

On Mon, Apr 3, 2023 at 8:32 AM dieder  wrote:
>
> Hi,
>
> I'd love to create a Jira ticket, but I cannot seem to get a Jira
> account, so I cannot do that.
>
> kind regards
>    Dieder Timmers
>
> Jean-Baptiste Onofré schreef op 2023-03-31 07:37:
> > Hi,
> >
> > Yes, that's weird: we might have a regression here as the
> > karaf.shutdown.port.file property should be commented by default.
> >
> > Can you please create a Jira, I will fix that.
> >
> > Regards
> > JB
> >
> > On Wed, Mar 29, 2023 at 3:14 PM dieder  wrote:
> >>
> >> Hi,
> >>
> >> I could be wrong but looking at the code a bit more and downloading
> >> the
> >> karaf 4.4.3 binary distribution the default setting for the karaf
> >> shutdown is using loopback.
> >> the config.properties still defines the property:
> >> karaf.shutdown.port.file
> >> The default configuration results in the creation of a listening
> >> loopback shutdown port. Shouldn't we change the default configuration
> >> to
> >> use the PID. I've tested this and it works correctly if I remove the
> >> karaf.shutdown.port.file property.
> >>
> >> kind regards
> >>Dieder Timmers
> >>
> >>
> >>
> >> Jean-Baptiste Onofré schreef op 2023-03-29 08:48:
> >> > Hi,
> >> >
> >> > some info:
> >> > 1. for security reason, the command loopback port has been disabled
> >> > while ago. It now use the PID.
> >> > 2. which version are you using?
> >> >
> >> > Regards
> >> > JB
> >> >
> >> > On Mon, Mar 27, 2023 at 11:50 AM dieder  wrote:
> >> >>
> >> >> Hi All,
> >> >>
> >> >> Recently I restarted using Karaf. We got an old project and started
> >> >> upgrading it.
> >> >> Now I think I've discovered a bug in shutting down Karaf from the
> >> >> loopback port. Sometimes Karaf does not stop after issuing the stop
> >> >> command. I've analyzed it and created a fix. Now I'd like to follow
> >> >> the
> >> >> correct path for submitting a Jira issue and after that al pull
> >> >> request.
> >> >> However I cannot seem to get approved for the Jira. I've requested
> >> >> access last week and still no response.
> >> >> What is the best way forward, retry to get on jira or create a pull
> >> >> request for the fix (without an issue that feels ugly).
> >> >>
> >> >> kind regards
> >> >>Dieder Timmers

Re: Patch for stopping karaf

[Jean-Baptiste Onofré]

Hi,

Yes, that's weird: we might have a regression here as the
karaf.shutdown.port.file property should be commented by default.

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

Regards
JB

On Wed, Mar 29, 2023 at 3:14 PM dieder  wrote:
>
> Hi,
>
> I could be wrong but looking at the code a bit more and downloading the
> karaf 4.4.3 binary distribution the default setting for the karaf
> shutdown is using loopback.
> the config.properties still defines the property:
> karaf.shutdown.port.file
> The default configuration results in the creation of a listening
> loopback shutdown port. Shouldn't we change the default configuration to
> use the PID. I've tested this and it works correctly if I remove the
> karaf.shutdown.port.file property.
>
> kind regards
>    Dieder Timmers
>
>
>
> Jean-Baptiste Onofré schreef op 2023-03-29 08:48:
> > Hi,
> >
> > some info:
> > 1. for security reason, the command loopback port has been disabled
> > while ago. It now use the PID.
> > 2. which version are you using?
> >
> > Regards
> > JB
> >
> > On Mon, Mar 27, 2023 at 11:50 AM dieder  wrote:
> >>
> >> Hi All,
> >>
> >> Recently I restarted using Karaf. We got an old project and started
> >> upgrading it.
> >> Now I think I've discovered a bug in shutting down Karaf from the
> >> loopback port. Sometimes Karaf does not stop after issuing the stop
> >> command. I've analyzed it and created a fix. Now I'd like to follow
> >> the
> >> correct path for submitting a Jira issue and after that al pull
> >> request.
> >> However I cannot seem to get approved for the Jira. I've requested
> >> access last week and still no response.
> >> What is the best way forward, retry to get on jira or create a pull
> >> request for the fix (without an issue that feels ugly).
> >>
> >> kind regards
> >>Dieder Timmers

Re: Patch for stopping karaf

[Jean-Baptiste Onofré]

Hi,

some info:
1. for security reason, the command loopback port has been disabled
while ago. It now use the PID.
2. which version are you using?

Regards
JB

On Mon, Mar 27, 2023 at 11:50 AM dieder  wrote:
>
> Hi All,
>
> Recently I restarted using Karaf. We got an old project and started
> upgrading it.
> Now I think I've discovered a bug in shutting down Karaf from the
> loopback port. Sometimes Karaf does not stop after issuing the stop
> command. I've analyzed it and created a fix. Now I'd like to follow the
> correct path for submitting a Jira issue and after that al pull request.
> However I cannot seem to get approved for the Jira. I've requested
> access last week and still no response.
> What is the best way forward, retry to get on jira or create a pull
> request for the fix (without an issue that feels ugly).
>
> kind regards
>Dieder Timmers

Re: Is it possible to have multiple tests in a KarafTestSupport test class, all using the same service?

[Jean-Baptiste Onofré]

Yes, it sounds good to me :)

The purpose of providing KarafTestSupport is to simplify the
dependency (a kind of bom) and use.

Regards
JB

On Fri, Mar 24, 2023 at 10:12 PM Steinar Bang  wrote:
>
> > Steinar Bang :
>
> > No, provisioning once with @Configuration will be fine, if that
> > actually loads the feature I'm adding.
>
> > I just wasn't sure if @Configuration would work here, since the base
> > class was different, and the example didn't use it, and I have never
> > investigated how the setup of KarafTestSupport classes actually work.
>
> > I thought maybe the installAndAssertFeature() function was necessary to
> > load the feature? (but I have never investigated)
>
> Well... that turned out to be much easier than I thought.
>
> The BaseTest in
>  
> https://github.com/apache/karaf/blob/main/itests/test/src/test/java/org/apache/karaf/itests/DiagnosticTest.java
> wasn't very mysterious...
>  
> https://github.com/apache/karaf/blob/main/itests/test/src/test/java/org/apache/karaf/itests/BaseTest.java
>
> It's just a KarafTestSupport subclass that adds a @Configuration.
>
> So what I did, was:
>  1. Add the feaure to the feature repo option, ie change
>  features(modelstoreFeatureRepo)
> to
>  features(modelstoreFeatureRepo, "modelstore.backend")
>  2. Remove the following from all tests
>  installAndAssertFeature("modelstore.backend");
>
> and then all tests went green!
>
> Amazing!
>
> Looks like I was overcomplicating things?
>
> Thanks all!
>

Re: Custom Karaf hangs on first boot if containing folder is renamed

[Jean-Baptiste Onofré]

n
>
> at
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.parseURL(URLHandlersStreamHandlerProxy.java:362)
>
> at java.base/java.net.URL.(URL.java:703)
>
> ... 13 more
>
>
>
> *Van:* Steven Huypens 
> *Verzonden:* donderdag 23 maart 2023 18:10
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
>  *CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
>
>
> For what it's worth, we faced an issue which this reminded me of. We
> concluded that the start order of bundles with the same start level depends
> on the full path of each bundle. As a result, renaming the karaf folder
> will have an impact on the boot procedure of your Karaf distro.
>
>
>
> We experienced this on both Windows and Linux.
>
>
>
> Kind regards,
>
> Steven
>
>
>
> On Thu, Mar 23, 2023 at 5:37 PM Jean-Baptiste Onofré 
> wrote:
>
> OK, that's what I thought: it's windows platform related issue.
>
>
>
> As Apache contributor, I should have access to Windows ISO to test ;)
>
>
>
> Thanks,
>
> Regards
>
> JB
>
>
>
> On Thu, Mar 23, 2023 at 8:48 AM Maurice Betzel 
> wrote:
>
> JB,
>
>
>
> Good luck with your search. The Linux build does not display this behavior
> btw.
>
>
>
> *Van:* Jean-Baptiste Onofré 
> *Verzonden:* woensdag 22 maart 2023 09:44
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
>  *CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi Maurice,
>
>
>
> It's highly possible that the problem is related to Windows platform,
> updating the path.
>
>
>
> I have to find a Windows to test it :)
>
>
>
> Regards
>
> JB
>
>
>
> On Tue, Mar 21, 2023 at 12:13 PM Maurice Betzel 
> wrote:
>
> Hi JB,
>
>
>
> I extracted the zip from the build, renamed the folder and deleted the
> data folder (which had nothing in it except the readme).
>
> The result is the same, the shell displays:
>
>
>
> platform.bat: KARAF_LOG doesn't exist:
> "C:\Users\User\Downloads\runtime5\bin\..\data\log"
>
> platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
>
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>
>
>
> But no ascii art, logging as mentioned below. If I stop and restart all is
> working as it should.
>
>
>
> *Van:* Jean-Baptiste Onofré 
> *Verzonden:* dinsdag 21 maart 2023 11:03
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
>  *CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Did you try to remove the data folder ?
>
>
>
> Not only Karaf is using caching, Felix FileInstall/ConfigAdmin does too.
>
>
>
> Regards
>
> JB
>
>
>
> On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
> wrote:
>
> Dear community,
>
>
>
> Having built several custom Karaf distributions the past 10 years, we now
> face a strange behavior not seen before.
>
> Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded
> pax-web 8.0.17 component.
>
> If I extract the runtime ZIP after build and start it from the default
> containing folder, all works well. But if I rename the folder before first
> start, Karaf hangs on disabling logging, see below.
>
> If I start and stop Karaf from its original folder and then rename this
> folder, all is well.
>
> Seems that Karaf home gets cached somewhere? I cannot find it so I am
> hoping this behavior has been noticed before?
>
>
>
> 2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 | Starting bundles:
>
> 2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util/9.4.50.v20221201
>
> 2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.jmx/9.4.50.v20221201
>
> 2023-03-20T14:28:48,409 

Re: Is it possible to have multiple tests in a KarafTestSupport test class, all using the same service?

[Jean-Baptiste Onofré]

Hi Steinar,

Like this one:

https://github.com/apache/karaf/blob/main/itests/test/src/test/java/org/apache/karaf/itests/DiagnosticTest.java

For example, in this class we have several tests using a single Karaf
instance (depending of the @ExamReactorStrategy(PerClass.class)
annotation, PerClass meaning a single Karaf instance for all test
methods in the class).

Regards
JB

On Thu, Mar 23, 2023 at 10:11 PM Steinar Bang  wrote:
>
> I am trying to rewrite an old pax exam test into being based on
> KarafTestSupport.
>
> The old test fired up a karaf instance with a feature that exposes a
> service, and then injected that service into the test class and used the
> service in multiple @Test methods.
>
> However the class based on KarafTestSupport seems to only work with a
> single @Test method.
>
> If I try to have more than one @Test methods, all tests fail with
> ClassNotFoundException on the service interface.
>
> Is it possible to have more than one @Test method in a KarafTestSuppor
> class.
>
> I could break up the test class into multiple test classes, but then I
> would have to boot karaf once for each test class, and that's kind of
> costly.
>
> I would prefer to boot karaf only once for all tests.
>
> Is it possible?
>
> Thanks!
>
>
> - Steinar
>

Re: Custom Karaf hangs on first boot if containing folder is renamed

[Jean-Baptiste Onofré]

OK, that's what I thought: it's windows platform related issue.

As Apache contributor, I should have access to Windows ISO to test ;)

Thanks,
Regards
JB

On Thu, Mar 23, 2023 at 8:48 AM Maurice Betzel 
wrote:

> JB,
>
>
>
> Good luck with your search. The Linux build does not display this behavior
> btw.
>
>
>
> *Van:* Jean-Baptiste Onofré 
> *Verzonden:* woensdag 22 maart 2023 09:44
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
> * CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi Maurice,
>
>
>
> It's highly possible that the problem is related to Windows platform,
> updating the path.
>
>
>
> I have to find a Windows to test it :)
>
>
>
> Regards
>
> JB
>
>
>
> On Tue, Mar 21, 2023 at 12:13 PM Maurice Betzel 
> wrote:
>
> Hi JB,
>
>
>
> I extracted the zip from the build, renamed the folder and deleted the
> data folder (which had nothing in it except the readme).
>
> The result is the same, the shell displays:
>
>
>
> platform.bat: KARAF_LOG doesn't exist:
> "C:\Users\User\Downloads\runtime5\bin\..\data\log"
>
> platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
>
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>
>
>
> But no ascii art, logging as mentioned below. If I stop and restart all is
> working as it should.
>
>
>
> *Van:* Jean-Baptiste Onofré 
> *Verzonden:* dinsdag 21 maart 2023 11:03
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
> * CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Did you try to remove the data folder ?
>
>
>
> Not only Karaf is using caching, Felix FileInstall/ConfigAdmin does too.
>
>
>
> Regards
>
> JB
>
>
>
> On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
> wrote:
>
> Dear community,
>
>
>
> Having built several custom Karaf distributions the past 10 years, we now
> face a strange behavior not seen before.
>
> Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded
> pax-web 8.0.17 component.
>
> If I extract the runtime ZIP after build and start it from the default
> containing folder, all works well. But if I rename the folder before first
> start, Karaf hangs on disabling logging, see below.
>
> If I start and stop Karaf from its original folder and then rename this
> folder, all is well.
>
> Seems that Karaf home gets cached somewhere? I cannot find it so I am
> hoping this behavior has been noticed before?
>
>
>
> 2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 | Starting bundles:
>
> 2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util/9.4.50.v20221201
>
> 2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.jmx/9.4.50.v20221201
>
> 2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.io/9.4.50.v20221201
>
> 2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.http/9.4.50.v20221201
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   jakarta.servlet-api/4.0.0
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-api/8.0.17
>
> 2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-spi/8.0.17
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.server/9.4.50.v20221201
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - or

Re: Using Decanter log appender/collector and mail alerting fails with "javax.activation.UnsupportedDataTypeException: text/plain"

[Jean-Baptiste Onofré]

nter.alerting.email.cfg
> > >
> > > # Send an event the alerter
> > > event:send decanter/alert/ERROR “foo=bar”
> > >
> > > # Display the karaf.log
> > > log:display
> > >
> > > 10:52:25.772 INFO [features-3-thread-1] Registering commands for bundle 
> > > org.apache.karaf.decanter.alerting.service/2.10.0
> > > 10:52:25.772 INFO [features-3-thread-1]   com.sun.mail.javax.mail/1.6.2
> > > 10:52:25.773 INFO [features-3-thread-1]   
> > > org.apache.karaf.decanter.marshaller.raw/2.10.0
> > > 10:52:25.775 INFO [features-3-thread-1]   
> > > org.apache.karaf.decanter.alerting.email/2.10.0
> > > 10:52:25.777 INFO [features-3-thread-1] Done.
> > > 10:52:48.142 ERROR [pipe-event:send decanter/alert/ERROR "foo=bar"] Can't 
> > > send the alert e-mail
> > > javax.mail.MessagingException: IOException while sending message
> > > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1365) 
> > > ~[?:?]
> > > at javax.mail.Transport.send0(Transport.java:255) ~[?:?]
> > > at javax.mail.Transport.send(Transport.java:174) ~[?:?]
> > > at 
> > > org.apache.karaf.decanter.alerting.email.EmailAlerter.handleEvent(EmailAlerter.java:140)
> > >  ~[?:?]
> > > at 
> > > org.apache.felix.eventadmin.impl.handler.EventHandlerProxy.sendEvent(EventHandlerProxy.java:432)
> > >  ~[?:?]
> > > at 
> > > org.apache.felix.eventadmin.impl.tasks.HandlerTask.runWithoutDenylistTiming(HandlerTask.java:82)
> > >  ~[?:?]
> > > at 
> > > org.apache.felix.eventadmin.impl.tasks.SyncDeliverTasks.execute(SyncDeliverTasks.java:107)
> > >  ~[?:?]
> > > at 
> > > org.apache.felix.eventadmin.impl.handler.EventAdminImpl.sendEvent(EventAdminImpl.java:196)
> > >  ~[?:?]
> > > at 
> > > org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.sendEvent(EventAdminSecurityDecorator.java:96)
> > >  ~[?:?]
> > > at 
> > > org.apache.karaf.event.command.EventSendCommand.execute(EventSendCommand.java:49)
> > >  ~[?:?]
> > > at 
> > > org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84)
> > >  ~[?:?]
> > > at 
> > > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68)
> > >  ~[?:?]
> > > at 
> > > org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86)
> > >  ~[?:?]
> > > at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) 
> > > ~[?:?]
> > > at 
> > > org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) 
> > > ~[?:?]
> > > at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) ~[?:?]
> > > at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) ~[?:?]
> > > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) ~[?:?]
> > > at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) ~[?:?]
> > > at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
> > > at 
> > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> > >  ~[?:?]
> > > at 
> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> > >  ~[?:?]
> > > at java.lang.Thread.run(Thread.java:833) ~[?:?]
> > > Caused by: javax.activation.UnsupportedDataTypeException: text/plain
> > > at javax.activation.DataHandler.writeTo(DataHandler.java:75) 
> > > ~[org.apache.servicemix.specs.activation-api-1.2.1-1.2.1_3.jar:1.2.1_3]
> > > at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1694) ~[?:?]
> > > at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1913) ~[?:?]
> > > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1315) 
> > > ~[?:?]
> > > ... 22 more
> > >
> > > karaf@root()>
> > >
> > >
> > >
> > > > On Mar 21, 2023, at 6:01 AM, Jean-Baptiste Onofré  
> > > > wrote:
> > > >
> > > > Hi Bert
> > > >
> > > > Let me try to reproduce. Do you use a mail template ?
> > > >
> > > > Regards
> > > > JB
> > > >
> > > > On Sat, Mar 18, 2023 at 11:27 AM Speckels, Bert
> > > >  wrote:
> > > >>
> > > >> Hello everyone
> > > >>
> > > >> Maybe you have a hint for me where to look for a solution.

Re: JDK 20 and Karaf

[Jean-Baptiste Onofré]

Hi,

It's already planned on Karaf runtime releases.

Regards
JB

On Wed, Mar 22, 2023 at 6:33 AM Mark Derricutt  wrote:
>
> Hey all,
>
> With todays release of JDK 20, will we likely to see a patch release of karaf 
> adding it into jre.properties soon?
>
> I have no issue patching it myself in our distribution, but I'm sure there's 
> some new updates/fixes to be found?
>
> Cheers
> Mark
>
> 
>
> "The ease with which a change can be implemented has no relevance at all to 
> whether it is the right change for the (Java) Platform for all time." — Mark 
> Reinhold.
>
> Mark Derricutt
> http://www.chaliceofblood.net
> http://www.theoryinpractice.net
> http://twitter.com/talios
> http://facebook.com/mderricutt

Re: Using Decanter log appender/collector and mail alerting fails with "javax.activation.UnsupportedDataTypeException: text/plain"

[Jean-Baptiste Onofré]

To(DataHandler.java:75) 
> ~[org.apache.servicemix.specs.activation-api-1.2.1-1.2.1_3.jar:1.2.1_3]
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1694) ~[?:?]
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1913) ~[?:?]
> at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1315) ~[?:?]
> ... 22 more
>
> karaf@root()>
>
>
>
> > On Mar 21, 2023, at 6:01 AM, Jean-Baptiste Onofré  wrote:
> >
> > Hi Bert
> >
> > Let me try to reproduce. Do you use a mail template ?
> >
> > Regards
> > JB
> >
> > On Sat, Mar 18, 2023 at 11:27 AM Speckels, Bert
> >  wrote:
> >>
> >> Hello everyone
> >>
> >> Maybe you have a hint for me where to look for a solution.
> >> I started to use "decanter" to send emails for error logging.
> >>
> >> I started to use the following features:
> >>   decanter-collector-log
> >>   decanter-appender-log
> >>   decanter-alerting-email
> >>
> >> ... configured a simple rule in 
> >> "org.apache.karaf.decanter.alerting.service.cfg"
> >>   rule.error="{'condition':'message:*','level':'ERROR'}"
> >>
> >> ... and configured my email server in 
> >> "org.apache.karaf.decanter.alerting.email.cfg"
> >>
> >> But when decanter tries to send an email the following error is logged:
> >>
> >> Caused by: javax.activation.UnsupportedDataTypeException: text/plain
> >> at javax.activation.DataHandler.writeTo(DataHandler.java:75) 
> >> ~[org.apache.servicemix.specs.activation-api-1.2.1-1.2.1_3.jar:1.2.1_3]
> >> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1694) ~[?:?]
> >> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1913) ~[?:?]
> >> at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1315) 
> >> ~[?:?]
> >>
> >>
> >> Does anyone have an idea what is missing?
> >> I am a little bit confused and could not find any source of information 
> >> about this problem.
> >>
> >> I am using karaf 4.4.3, decanter 2.10.0, camel 3.20.2
> >>
> >> karaf@root()> feature:list | grep decanter | grep Started
> >> decanter-common (0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter API
> >> decanter-collector-log  (0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Log 
> >> Messages Collector
> >> decanter-appender-log   (0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Log 
> >> Appender
> >> decanter-alerting-core  (0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Alerting 
> >> core
> >> decanter-alerting-email-core(0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter alerting 
> >> email alerter core
> >> decanter-alerting-email (0x 2.10.0   │  │ 
> >> Started │ karaf-decanter-2.10.0 │ Karaf Decanter alerting 
> >> email alerter
> >>
> >> Thanx for any help
> >> Bert Speckels
>

Re: Custom Karaf hangs on first boot if containing folder is renamed

[Jean-Baptiste Onofré]

Hi Maurice,

It's highly possible that the problem is related to Windows platform,
updating the path.

I have to find a Windows to test it :)

Regards
JB

On Tue, Mar 21, 2023 at 12:13 PM Maurice Betzel 
wrote:

> Hi JB,
>
>
>
> I extracted the zip from the build, renamed the folder and deleted the
> data folder (which had nothing in it except the readme).
>
> The result is the same, the shell displays:
>
>
>
> platform.bat: KARAF_LOG doesn't exist:
> "C:\Users\User\Downloads\runtime5\bin\..\data\log"
>
> platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
>
> Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
>
>
>
> But no ascii art, logging as mentioned below. If I stop and restart all is
> working as it should.
>
>
>
> *Van:* Jean-Baptiste Onofré 
> *Verzonden:* dinsdag 21 maart 2023 11:03
> *Aan:* user@karaf.apache.org
> *Onderwerp:* Re: Custom Karaf hangs on first boot if containing folder is
> renamed
>
>
>
> * CAUTION:* This email originated from outside of Gaston Schul. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Did you try to remove the data folder ?
>
>
>
> Not only Karaf is using caching, Felix FileInstall/ConfigAdmin does too.
>
>
>
> Regards
>
> JB
>
>
>
> On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
> wrote:
>
> Dear community,
>
>
>
> Having built several custom Karaf distributions the past 10 years, we now
> face a strange behavior not seen before.
>
> Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded
> pax-web 8.0.17 component.
>
> If I extract the runtime ZIP after build and start it from the default
> containing folder, all works well. But if I rename the folder before first
> start, Karaf hangs on disabling logging, see below.
>
> If I start and stop Karaf from its original folder and then rename this
> folder, all is well.
>
> Seems that Karaf home gets cached somewhere? I cannot find it so I am
> hoping this behavior has been noticed before?
>
>
>
> 2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 | Starting bundles:
>
> 2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util/9.4.50.v20221201
>
> 2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.jmx/9.4.50.v20221201
>
> 2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.io/9.4.50.v20221201
>
> 2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.http/9.4.50.v20221201
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   jakarta.servlet-api/4.0.0
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-api/8.0.17
>
> 2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-spi/8.0.17
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.server/9.4.50.v20221201
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.security/9.4.50.v20221201
>
> 2023-03-20T14:28:48,414 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util.ajax/9.4.50.v20221201
>
> 2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.servlet/9.4.50.v20221201
>
> 2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.xml/9.4.50.v20221201
>
> 2023-03-20T14:28:48,416 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jet

Re: EventAdmin RejectedExecutionException

[Jean-Baptiste Onofré]

Hi Steven,

The refresh doesn't occur on Karaf standard distribution, so I think
you have another feature that triggers the refresh.

Can you please share the karaf.log and eventually your assembly pom.xml ?

Thanks
Regards
JB

On Tue, Mar 21, 2023 at 11:31 AM Steven Huypens
 wrote:
>
> Hi,
>
> When starting our custom Karaf distribution, we regularly see the error 
> below. I'm not sure I understand it OK, but it looks like the Felix 
> ConfigurationManager tries to log something, but an exception is thrown, 
> stopping the update-Thread. Maybe the eventAdmin bundle is restarted somehow 
> during boot, which makes it unavailable for a short period, but I feel that a 
> logLine should never have this kind of impact. At the bottom you can find the 
> configuration of our karaf-maven-plugin.
>
> Can I prevent the eventAdmin bundle from being restarted, or should the 
> exception be handled differently somewhere ?
>
>
>
> RejectedExecutionException: Task java.util.concurrent.FutureTask@616ff6e9[Not 
> completed, task = 
> java.util.concurrent.Executors$RunnableAdapter@35bad341[Wrapped task = 
> org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter@6de671aa]]
>  rejected from java.util.concurrent.ThreadPoolExecutor@20fbc2ac[Shutting 
> down, pool size = 4, active threads = 0, queued tasks = 0, completed tasks = 
> 176]
>  java.util.concurrent.RejectedExecutionException: Task 
> java.util.concurrent.FutureTask@616ff6e9[Not completed, task = 
> java.util.concurrent.Executors$RunnableAdapter@35bad341[Wrapped task = 
> org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks$TaskExecuter@6de671aa]]
>  rejected from java.util.concurrent.ThreadPoolExecutor@20fbc2ac[Shutting 
> down, pool size = 4, active threads = 0, queued tasks = 0, completed tasks = 
> 176]
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1350)
> at 
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
> at 
> org.apache.felix.eventadmin.impl.tasks.DefaultThreadPool.executeTask(DefaultThreadPool.java:134)
> at 
> org.apache.felix.eventadmin.impl.tasks.AsyncDeliverTasks.execute(AsyncDeliverTasks.java:102)
> at 
> org.apache.felix.eventadmin.impl.handler.EventAdminImpl.postEvent(EventAdminImpl.java:180)
> at 
> org.apache.felix.eventadmin.impl.security.EventAdminSecurityDecorator.postEvent(EventAdminSecurityDecorator.java:79)
> at 
> org.ops4j.pax.logging.spi.support.EventAdminTracker.deliver(EventAdminTracker.java:103)
> at 
> org.ops4j.pax.logging.spi.support.EventAdminTracker.postEvent(EventAdminTracker.java:65)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl.handleEvents(PaxLoggingServiceImpl.java:417)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog0(PaxLoggerImpl.java:1127)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.doLog(PaxLoggerImpl.java:1098)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggerImpl.debug(PaxLoggerImpl.java:252)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl.logImpl(PaxLoggingServiceImpl.java:402)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl.access$000(PaxLoggingServiceImpl.java:70)
> at 
> org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl$1ManagedPaxLoggingService.log(PaxLoggingServiceImpl.java:678)
> at org.apache.felix.cm.impl.Log.log(Log.java:186)
> at org.apache.felix.cm.impl.Log.log(Log.java:168)
> at 
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1383)
> at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
> 
> org.apache.karaf.tooling
> karaf-maven-plugin
> ${karaf.plugin.version}
> 
> 
> false
> 
> 
> http
> pax-web-*
>
> 
> diagnostic
>
> 
> 
> 
> transaction
> 
>
> 
> 
> 
> mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.jaxb-api-2.2/2.9.0
> 
> 
> 
> mvn:org.apache.karaf.features/spring/${karaf.runtime.version}/xml/features
> 
> 
> eventadmin
> 
> 

Re: Custom Karaf hangs on first boot if containing folder is renamed

[Jean-Baptiste Onofré]

Did you try to remove the data folder ?

Not only Karaf is using caching, Felix FileInstall/ConfigAdmin does too.

Regards
JB

On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
wrote:

> Dear community,
>
>
>
> Having built several custom Karaf distributions the past 10 years, we now
> face a strange behavior not seen before.
>
> Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded
> pax-web 8.0.17 component.
>
> If I extract the runtime ZIP after build and start it from the default
> containing folder, all works well. But if I rename the folder before first
> start, Karaf hangs on disabling logging, see below.
>
> If I start and stop Karaf from its original folder and then rename this
> folder, all is well.
>
> Seems that Karaf home gets cached somewhere? I cannot find it so I am
> hoping this behavior has been noticed before?
>
>
>
> 2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 | Starting bundles:
>
> 2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util/9.4.50.v20221201
>
> 2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.jmx/9.4.50.v20221201
>
> 2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.io/9.4.50.v20221201
>
> 2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.http/9.4.50.v20221201
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   jakarta.servlet-api/4.0.0
>
> 2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-api/8.0.17
>
> 2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-spi/8.0.17
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.server/9.4.50.v20221201
>
> 2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.security/9.4.50.v20221201
>
> 2023-03-20T14:28:48,414 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.util.ajax/9.4.50.v20221201
>
> 2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.servlet/9.4.50.v20221201
>
> 2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.xml/9.4.50.v20221201
>
> 2023-03-20T14:28:48,416 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.jaas/9.4.50.v20221201
>
> 2023-03-20T14:28:48,417 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.servlets/9.4.50.v20221201
>
> 2023-03-20T14:28:48,418 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-jetty/8.0.17
>
> 2023-03-20T14:28:48,419 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.continuation/9.4.50.v20221201
>
> 2023-03-20T14:28:48,420 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-tomcat-common/8.0.17
>
> 2023-03-20T14:28:48,421 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.ops4j.pax.web.pax-web-runtime/8.0.17
>
> 2023-03-20T14:28:48,421 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.eclipse.jetty.client/9.4.50.v20221201
>
> 2023-03-20T14:28:48,422 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.apache.karaf.http.core/4.4.3
>
> 2023-03-20T14:28:48,423 | INFO  | features-2-thread-1 |
> FeaturesServiceImpl  | 17 - org.apache.karaf.features.core -
> 4.4.3 |   org.jolokia.osgi/1.7.1
>
> 2023-03-20T14:28:48,424 | INFO  | features-2-thread-1 |

Re: Using Decanter log appender/collector and mail alerting fails with "javax.activation.UnsupportedDataTypeException: text/plain"

[Jean-Baptiste Onofré]

Hi Bert

Let me try to reproduce. Do you use a mail template ?

Regards
JB

On Sat, Mar 18, 2023 at 11:27 AM Speckels, Bert
 wrote:
>
> Hello everyone
>
> Maybe you have a hint for me where to look for a solution.
> I started to use "decanter" to send emails for error logging.
>
> I started to use the following features:
>decanter-collector-log
>decanter-appender-log
>decanter-alerting-email
>
> ... configured a simple rule in 
> "org.apache.karaf.decanter.alerting.service.cfg"
>rule.error="{'condition':'message:*','level':'ERROR'}"
>
> ... and configured my email server in 
> "org.apache.karaf.decanter.alerting.email.cfg"
>
> But when decanter tries to send an email the following error is logged:
>
> Caused by: javax.activation.UnsupportedDataTypeException: text/plain
> at javax.activation.DataHandler.writeTo(DataHandler.java:75) 
> ~[org.apache.servicemix.specs.activation-api-1.2.1-1.2.1_3.jar:1.2.1_3]
> at javax.mail.internet.MimeBodyPart.writeTo(MimeBodyPart.java:1694) ~[?:?]
> at javax.mail.internet.MimeMessage.writeTo(MimeMessage.java:1913) ~[?:?]
> at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1315) ~[?:?]
>
>
> Does anyone have an idea what is missing?
> I am a little bit confused and could not find any source of information about 
> this problem.
>
> I am using karaf 4.4.3, decanter 2.10.0, camel 3.20.2
>
> karaf@root()> feature:list | grep decanter | grep Started
> decanter-common (0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter API
> decanter-collector-log  (0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Log Messages 
> Collector
> decanter-appender-log   (0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Log Appender
> decanter-alerting-core  (0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter Alerting core
> decanter-alerting-email-core(0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter alerting 
> email alerter core
> decanter-alerting-email (0x 2.10.0   │  │ 
> Started │ karaf-decanter-2.10.0 │ Karaf Decanter alerting 
> email alerter
>
> Thanx for any help
> Bert Speckels

Re: Missing error logs when running in Docker

[Jean-Baptiste Onofré]

Hi,

OK I will check on 4.2.x (let me complete ActiveMQ release first).
I will keep you posted.

Regards
JB

On Mon, Mar 13, 2023 at 11:59 AM Daniel Las  wrote:
>
> Hi,
>
> I didn't try Karaf 4.4.x, I need to solve this issue in Karaf 4.2.x. Could 
> you please take a look at 4.2.x? Thanks in advance.
>
> Best regards
>
> pon., 13 mar 2023 o 09:56 Jean-Baptiste Onofré  napisał(a):
>>
>> Did you try with Karaf 4.4.x ? I can take a look on 4.2.x but it's
>> supposed to be "inactive".
>>
>> Regards
>> JB
>>
>> On Sun, Mar 12, 2023 at 11:16 AM Daniel Las  wrote:
>> >
>> > Hi,
>> >
>> > This is karaf run used.
>> >
>> > Best regards
>> >
>> > niedz., 12 mar 2023 o 07:47 Jean-Baptiste Onofré  
>> > napisał(a):
>> >>
>> >> Hi,
>> >>
>> >> What command are you using to run karaf ?
>> >>
>> >> In docker, karaf run is probably the best option as it outputs the log
>> >> on the console.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On Sun, Mar 12, 2023 at 6:48 AM Daniel Las  wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > We are running a custom Kafaf 4.2.11 distribution as a Docker container 
>> >> > using console logging appender with the JSON layout. All is working 
>> >> > fine except missing some error logs. For example, bundles start 
>> >> > failures are not logged in Docker logs but are visible with log::tail 
>> >> > command. What might be the reason?
>> >> >
>> >> > Best regards
>> >> > --
>> >> > Daniel Łaś
>> >
>> >
>> >
>> > --
>> > Daniel Łaś
>
>
>
> --
> Daniel Łaś
>

Re: Missing error logs when running in Docker

[Jean-Baptiste Onofré]

Did you try with Karaf 4.4.x ? I can take a look on 4.2.x but it's
supposed to be "inactive".

Regards
JB

On Sun, Mar 12, 2023 at 11:16 AM Daniel Las  wrote:
>
> Hi,
>
> This is karaf run used.
>
> Best regards
>
> niedz., 12 mar 2023 o 07:47 Jean-Baptiste Onofré  
> napisał(a):
>>
>> Hi,
>>
>> What command are you using to run karaf ?
>>
>> In docker, karaf run is probably the best option as it outputs the log
>> on the console.
>>
>> Regards
>> JB
>>
>> On Sun, Mar 12, 2023 at 6:48 AM Daniel Las  wrote:
>> >
>> > Hi,
>> >
>> > We are running a custom Kafaf 4.2.11 distribution as a Docker container 
>> > using console logging appender with the JSON layout. All is working fine 
>> > except missing some error logs. For example, bundles start failures are 
>> > not logged in Docker logs but are visible with log::tail command. What 
>> > might be the reason?
>> >
>> > Best regards
>> > --
>> > Daniel Łaś
>
>
>
> --
> Daniel Łaś

Re: "system:property --unset" is not removing the property.

[Jean-Baptiste Onofré]

Hi,

Yes please, I will take a look.

Regards
JB

On Thu, Mar 9, 2023 at 7:03 PM Paul Spencer  wrote:
>
> Karaf 4.4.3
> OpenJDK 64-Bit Server VM version 17.0.2+8-86
>
> The command "system:property --unset" is not removing the property. Should I 
> open a JIRA?
>
> karaf@root()> system:property | grep foo
> karaf@root()> system:property foo bar
> karaf@root()> system:property | grep foo
> foo=bar
> karaf@root()> system:property --unset foo
> bar
> karaf@root()> system:property | grep foo  
>   
>foo=bar
> karaf@root()>
>
>
> Paul Spencer
>

Re: Missing error logs when running in Docker

[Jean-Baptiste Onofré]

Hi,

What command are you using to run karaf ?

In docker, karaf run is probably the best option as it outputs the log
on the console.

Regards
JB

On Sun, Mar 12, 2023 at 6:48 AM Daniel Las  wrote:
>
> Hi,
>
> We are running a custom Kafaf 4.2.11 distribution as a Docker container using 
> console logging appender with the JSON layout. All is working fine except 
> missing some error logs. For example, bundles start failures are not logged 
> in Docker logs but are visible with log::tail command. What might be the 
> reason?
>
> Best regards
> --
> Daniel Łaś

Re: Existence of a "Minimal Distribution" is documented, but its location is not.

[Jean-Baptiste Onofré]

Hi,

It's "documented" in https://karaf.apache.org/manual/latest/ (at least
the maven coordinates).

However, I agree with you, we can give "room" to minimal distribution
on the download page, especially we plan to add a new "integration"
distribution.
Please, can you create a Jira, I will fix that.

Regards
JB

On Mon, Feb 27, 2023 at 3:37 PM Paul Spencer  wrote:
>
> The documentation describes "minimal distribution"[1], but neither the 
> referenced download page[2] nor the archive page[3] makes no mention of 
> minimal distributions. I was able to find the distribution via the "Main 
> Distribution Directory"[4] listed on the "Verify the integrity of the files" 
> section of the download page[2].
>
> I do not have a suggestion on how to document the location of the "minimal 
> distribution" files, but it is needed.
>
> Should I open a JIRA?
>
> Paul Spencer
>
> [1] 
> https://karaf.apache.org/manual/latest/#_using_apache_karaf_binary_distributions
> [2] https://karaf.apache.org/download.html
> [3] https://karaf.apache.org/archives.html
> [4] https://downloads.apache.org/karaf/

Re: Should standard-n.n.n-feature.xml reference the minimum version of pax-web?

[Jean-Baptiste Onofré]

Hi,

Actually, standard features (and all other Karaf features) should not
use inner  definition but instead use resolution at
runtime. I already started to clean up (in Camel, ActiveMQ, Karaf
Decanter, Karaf itself). I will remove pax-web ref in standard
features repo.

Regards
JB

On Sat, Feb 25, 2023 at 5:04 PM Paul Spencer  wrote:
>
> Should standard-n.n.n-feature.xml reference the minimum version of pax-web 
> instead of the exact version?
>
> I ask this because the current implementation prevent upgrading pax-web 
> without manually editing the distribution or creating a custom distribution.
>
> Paul Spencer

[ANN] Apache Karaf Decanter 2.10.0 has been released!

[Jean-Baptiste Onofré]

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

This release is a maintenance release on the Decanter 2.x series,
bringing a lot of changes, especially:
- a new config allows to define default key in the split parser
- fix a ClassCastException in split parser
- a bunch of dependency updates

You can find details on the Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12351427

You can find source distribution and installation instructions here:
https://karaf.apache.org/download.html

Enjoy !

Regards
---
The Apache Karaf team

Re: How to use Pax Web 8.0.16 in karaf 4.4.3?

[Jean-Baptiste Onofré]

Do you have pax-web features installed ? You can "force" the removal
(feature:repo-remove -u).

Regards
JB

On Sat, Feb 25, 2023 at 2:18 AM Paul Spencer  wrote:
>
> Grzegoz,
>
> Removing the pax-web 8.0.15 repo does not remove the repository.  Below is 
> from a fresh install of karaf.
>
> Karaf 4.4.3
> Java 1.8.0_172
> Mac OS X 10.16 x86_64
>
>
> karaf@root()> feature:repo-remove 
> mvn:org.ops4j.pax.web/pax-web-features/8.0.15/xml/features
> Removing features repository: 
> mvn:org.ops4j.pax.web/pax-web-features/8.0.15/xml/features
> karaf@root()> feature:repo-list
> Repository│ URL
> ──┼─
> org.ops4j.pax.jdbc-1.5.5  │ 
> mvn:org.ops4j.pax.jdbc/pax-jdbc-features/1.5.5/xml/features
> org.ops4j.pax.web-8.0.15  │ 
> mvn:org.ops4j.pax.web/pax-web-features/8.0.15/xml/features
> openjpa-3.2.2 │ 
> mvn:org.apache.openjpa/openjpa-features/3.2.2/xml/features
> aries-jpa-2.7.3   │ 
> mvn:org.apache.aries.jpa/jpa-features/2.7.3/xml/features
> framework-4.4.3   │ 
> mvn:org.apache.karaf.features/framework/4.4.3/xml/features
> hibernate-validator-osgi-features │ 
> mvn:org.hibernate.validator/hibernate-validator-osgi-karaf-features/7.0.2.Final/xml/features
> standard-4.4.3│ 
> mvn:org.apache.karaf.features/standard/4.4.3/xml/features
> spring-4.4.3  │ 
> mvn:org.apache.karaf.features/spring/4.4.3/xml/features
> specs-4.4.3   │ 
> mvn:org.apache.karaf.features/specs/4.4.3/xml/features
> pax-transx-0.5.3  │ 
> mvn:org.ops4j.pax.transx/pax-transx-features/0.5.3/xml/features
> enterprise-4.4.3  │ 
> mvn:org.apache.karaf.features/enterprise/4.4.3/xml/features
> org.ops4j.pax.cdi-1.1.4   │ 
> mvn:org.ops4j.pax.cdi/pax-cdi-features/1.1.4/xml/features
> pax-jms-1.1.2 │ 
> mvn:org.ops4j.pax.jms/pax-jms-features/1.1.2/xml/features
> karaf@root()>
>
> > On Feb 24, 2023, at 2:50 PM, Grzegorz Grzybek  wrote:
> >
> > Hello
> >
> > Just replace them ;)
> >
> > karaf@root()> feature:repo-remove 
> > mvn:org.ops4j.pax.web/pax-web-features/8.0.15/xml/features
> > Removing features repository: 
> > mvn:org.ops4j.pax.web/pax-web-features/8.0.15/xml/features
> >
> > karaf@root()> feature:repo-add 
> > mvn:org.ops4j.pax.web/pax-web-features/8.0.16/xml/features
> > Adding feature url 
> > mvn:org.ops4j.pax.web/pax-web-features/8.0.16/xml/features
> >
> > And then the features you install will come from 8.0.16.
> >
> > regards
> > Grzegoz Grzybek
> >
> > pt., 24 lut 2023 o 20:48 Paul Spencer  
> > napisał(a):
> > I see that Pax Web version 8.0.16 has been released.  How do I utilize the 
> > version 8.0.16 in Karaf 4.4.3?
> >
> > Paul Spencer
>

Re: How to use Pax Web 8.0.16 in karaf 4.4.3?

[Jean-Baptiste Onofré]

If possible, wait Karaf 4.4.4 that will include it :)

Else the cleanest way is probably to create custom build or to replace
at runtime.

Regards
JB

On Fri, Feb 24, 2023 at 8:48 PM Paul Spencer  wrote:
>
> I see that Pax Web version 8.0.16 has been released.  How do I utilize the 
> version 8.0.16 in Karaf 4.4.3?
>
> Paul Spencer

Re: Custom distribution with Maven assembly has no license

[Jean-Baptiste Onofré]

Hi Andre,

Karaf distribution itself is created this way, including LICENSE/NOTICE files.
You can add LICENSE in the resources, it should be part of the distribution.

Regards
JB

On Fri, Feb 24, 2023 at 10:02 AM Andre Schlegel-Tylla
 wrote:
>
> Hello,
>
> We create a custom Karaf distribution with Maven assembly 
> (https://karaf.apache.org/manual/latest/#_custom_distributions). But in the 
> resulting archives the Apache license file is not included. Is this intended? 
> I think the license have to be included to match the Apache license 
> requirements. Or am I missing something?
>
> Regards
> Andre
>

Re: Service org.springframework.transaction.PlatformTransactionManager missing after restart

[Jean-Baptiste Onofré]

Hi,

Did you check the start-level in the features ?

Regards
JB

On Tue, Feb 14, 2023 at 10:50 AM Ephemeris Lappis
 wrote:
>
> Hello again.
>
> After testing "refresh" or "restart" of bundles around transaction
> management, with no success, I've tried a "feature:refresh" that seems
> to have restarted the PlatformManager that was missing, and the
> bundles that were waiting for it. In fact, I don't understand neither
> what was failing nor why this "feature:refresh" has fixed it...
>
> An explanation should really be welcome : I think these days I'm going
> to see and learn more things than ever in many years using SMX, Fuse
> or karaf :) ...
>
> Thanks in advance.
>
> Regards.
>
> Le mar. 14 févr. 2023 à 10:07, Ephemeris Lappis
>  a écrit :
> >
> > Hello.
> >
> > When installing our applicative features that pull the dependent
> > transaction features the service
> > "org.springframework.transaction.PlatformTransactionManager" is up,
> > provided by the Geronimo TM, and our bundles resolve it and work as
> > expected.
> >
> > After stopping and restarting Karaf, the same bundles fail because the
> > service is missing. Indeed, listing services do not show it anymore.
> >
> > I've seen very old messages about similar issues on Fuse. Is this
> > issue still impacting Karaf 4.4.3, and in this case, what can we do to
> > ensure all the services are present after a reboot ?
> >
> > Thanks for your help.
> >
> > Regards.

Re: Installing feature with Jolokia fails because of HTTP unexpected restart

[Jean-Baptiste Onofré]

Hi,

I bet the refresh is due to optional import.

Let me check the resolver output.

Regards
JB

On Tue, Feb 14, 2023 at 2:55 PM Ephemeris Lappis
 wrote:
>
> Hello.
>
> After pax-jdbc-config, we've found another feature that restarts the
> HTTP and that makes Jolokia fail : camel-bindy. I don't understand
> why...
>
> To avoid the side-effect of installing pax-jdbc-config, we've added it
> to the Karaf's boot feature as we know it's available from "raw"
> install. This is an acceptable workaround.
>
> But for camel-bindy, as the Camel repository is not available at the
> moment of the first install, we can't do the same. It's important for
> us not to couple the version of Camel to Keraf image, and decide for
> it later at deployment time.
>
> So, what feedback do you have on Jolokia's uses for deployments when
> Jolokia itself can be impacted by side effects of someactions, and
> fail during its own execution ?
>
> Thanks again for help !
>
> Regards.
>
> Le lun. 13 févr. 2023 à 17:10, Ephemeris Lappis
>  a écrit :
> >
> > Hello.
> >
> > Reading my mail I see that the logs are missing. I added them at the
> > end of this message...
> >
> > After more tests, it seems that the guilty module is pax-jdbc-config
> > that registers something with http. Perhaps someone knows what and
> > why...
> > Adding manually this feature before produces the same side effect, and
> > installing our feature with jolokia after doesn't fail anymore.
> >
> > The question is still how can we deploy with jolokia something that
> > breaks the http request/response :( ?
> >
> > The missing logs :
> >
> > 15:28:56.947 INFO  [qtp312812427-203] Adding features:
> > caterpillar-system-jdbc/[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]
> > 15:28:57.481 INFO  [features-3-thread-1] Changes to perform:
> > 15:28:57.482 INFO  [features-3-thread-1]   Region: root
> > 15:28:57.482 INFO  [features-3-thread-1] Bundles to install:
> > 15:28:57.483 INFO  [features-3-thread-1]
> > mvn:jakarta.el/jakarta.el-api/3.0.3
> > 15:28:57.483 INFO  [features-3-thread-1]
> > mvn:javax.enterprise/cdi-api/2.0.SP1
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:javax.interceptor/javax.interceptor-api/1.2.2
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:javax.transaction/javax.transaction-api/1.2
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:org.apache.commons/commons-dbcp2/2.9.0
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:org.apache.commons/commons-pool2/2.11.1
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1
> > 15:28:57.484 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1
> > 15:28:57.485 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3
> > 15:28:57.485 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5
> > 15:28:57.485 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5
> > 15:28:57.485 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5
> > 15:28:57.486 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.transx/pax-transx-tm-api/0.5.3
> > 15:28:57.486 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3
> > 15:28:57.486 INFO  [features-3-thread-1]
> > mvn:org.osgi/org.osgi.service.jdbc/1.0.1
> > 15:28:57.486 INFO  [features-3-thread-1]
> > mvn:org.apache.aries.tx-control/tx-control-service-local/1.0.1
> > 15:28:57.486 INFO  [features-3-thread-1]
> > mvn:org.apache.aries.tx-control/tx-control-service-xa/1.0.1
> > 15:28:57.487 INFO  [features-3-thread-1] Installing bundles:
> > 15:28:57.488 INFO  [features-3-thread-1]   
> > mvn:jakarta.el/jakarta.el-api/3.0.3
> > 15:28:57.490 INFO  [features-3-thread-1]   
> > mvn:javax.enterprise/cdi-api/2.0.SP1
> > 15:28:57.493 INFO  [features-3-thread-1]
> > mvn:javax.interceptor/javax.interceptor-api/1.2.2
> > 15:28:57.494 INFO  [features-3-thread-1]
> > mvn:javax.transaction/javax.transaction-api/1.2
> > 15:28:57.496 INFO  [features-3-thread-1]
> > mvn:org.apache.commons/commons-dbcp2/2.9.0
> > 15:28:57.498 INFO  [features-3-thread-1]
> > mvn:org.apache.commons/commons-pool2/2.11.1
> > 15:28:57.500 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/3.3.0_1
> > 15:28:57.502 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1
> > 15:28:57.505 INFO  [features-3-thread-1]
> > mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.javax-inject/1_3
> > 15:28:57.506 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-config/1.5.5
> > 15:28:57.508 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/1.5.5
> > 15:28:57.509 INFO  [features-3-thread-1]
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-dbcp2/1.5.5
> > 15:28:57.510 INFO  

Re: PAX JMS & Camel consumer produce warnings

[Jean-Baptiste Onofré]

Are you using camel-jms ? What's the camel endpoint URI ?

Regards
JB

On Mon, Feb 13, 2023 at 7:17 PM Ephemeris Lappis
 wrote:
>
> Hello.
>
> I've changed a handmade JMS Connection factory to use PAX JMS with pooling.
> Now I've strange warning messages that come after some time :
>
> DefaultJmsMessageListenerContainer | 209 -
> org.apache.servicemix.bundles.spring-jms - 5.3.23.1 |  | Setup of JMS
> message listener invoker failed for destination
> 'bbbmmm999-f902.internal.queue' - trying to recover. Cause: The
> Consumer is closed
>
> Each time, I have a message for every Camel route consumer.
>
> Is it a configuration issue on PAX JMS ? For now I've not set any
> parameters about idle time and so on : only maximum connections...
>
> pool=pooledjms
> pool.maxConnections=256
>
> Thanks for your help.
>
> Thanks.