RE: Karaf 5

[jgfrm]

Perhaps.

I want to be able to use a bean in other Spring module.

What is also an issue it that two (or more) modules obviously result in two 
sockets to be opened, in my case both 8400.
A solution could be to open a different socket per module, e.g. negotiated with 
a module for that purpose that also routes traffic for a particular endpoint to 
the socket of the module handling that endpoint.

In https://github.com/hank-cp/sbp (based on pf4j) they have a different 
strategy; there they have one socket for REST calls, and specific endpoints are 
forwarded to the appropriate plugin.

Best,

-- Jaap


|-Oorspronkelijk bericht-
|Van: JB Onofré 
|Verzonden: woensdag 29 september 2021 22:17
|Aan: user@karaf.apache.org
|Onderwerp: Re: Karaf 5
|
|I started a service bridge allowing to implicit push some spring bean to the k5
|registry and so that can be used from other modules running in k5. It’s a local
|branch for now but I can push it on main.
|
|Is it what you are looking for ?
|
|Regards
|JB
|
|> Le 29 sept. 2021 à 21:43, jgfrm  a écrit :
|>
|> Is there already something working for exporting functionality of a Spring
|modules to other modules?
|>
|> |-Oorspronkelijk bericht-
|> |Van: Jean-Baptiste Onofré 
|> |Verzonden: woensdag 29 september 2021 17:26
|> |Aan: user@karaf.apache.org
|> |Onderwerp: Re: Karaf 5
|> |
|> |Thanks for the update.
|> |
|> |I'm happy to say you are the first one to "use/launch" Karaf 5 ;)
|> |
|> |About the TomcatURLStreamHandlerFactory is known "issue":
|> |
|> |https://github.com/jbonofre/karaf5/blob/main/services/spring-boot-
|> |application-
|> |manager/src/main/java/org/apache/karaf/springboot/SpringBootApplicati
|> |on
|> |ManagerService.java#L110
|> |
|> |I have to improve this ;)
|> |
|> |Regards
|> |JB
|> |
|> |On 29/09/2021 17:19, jgfrm wrote:
|> |> The following works:
|> |>
|> |> Karaf.json:
|> |> 
|> |> {
|> |>"applications": [
|> |>  {
|> |>"name": "e3web",
|> |>"url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
|> |>"type": "spring-boot",
|> |>"properties": {
|> |>  "enableHttp": true,
|> |>  "enablePrometheus": true
|> |>}
|> |>  }
|> |>]
|> |> }
|> |> 
|> |>
|> |> Add to Spring boot application:
|> |> 
|> |> @SpringBootApplication
|> |> @ComponentScan
|> |> public class E3webApplication {
|> |>
|> |>   ...
|> |>  public static void main(String[] args) {
|> |>  TomcatURLStreamHandlerFactory.disable();  // see
|> |https://github.com/spring-projects/spring-boot/issues/21535
|> |>  SpringApplication.run(E3webApplication.class, args);
|> |>  }
|> |> 
|> |>
|> |> Start with
|> |> java --add-modules jdk.security.jgss -cp
|> |> ../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-tes
|> |> t-1
|> |> .0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/
|> |> tar get/spring-boot-application-manager-5.0-SNAPSHOT.jar
|> |> -Dkaraf.config=src/main/resources/karaf.json
|> |> org.apache.karaf.boot.Main
|> |>
|> |> |-Oorspronkelijk bericht-
|> |> |Van: JB Onofré 
|> |> |Verzonden: dinsdag 28 september 2021 06:34
|> |> |Aan: user@karaf.apache.org
|> |> |Onderwerp: Re: Karaf 5
|> |> |
|> |> |Hi
|> |> |
|> |> |No it’s not this because k5 don’t use OSGi for the spring boot
|> |> |launcher. I still think it’s a missing add modules as Jvm arg. I
|> |> |will check
|> |today.
|> |> |
|> |> |Regards
|> |> |JB
|> |> |
|> |> |> Le 27 sept. 2021 à 23:39, jgfrm  a écrit :
|> |> |>
|> |> |> While Googling, I came across on of your blogs
|> |> |(http://nanthrax.blogspot.com/2021/04/whats-new-in-apache-karaf-
|> |> |431.html) that one of the changes in Karaf was to export the
|> |> |java.*
|> |packages.
|> |> |Could that be the cause?
|> |> |>
|> |> |> |-Oorspronkelijk bericht-
|> |> |> |Van: Jean-Baptiste Onofre 
|> |> |> |Verzonden: zondag 26 september 2021 18:02
|> |> |> |Aan: user@karaf.apache.org
|> |> |> |Onderwerp: Re: Karaf 5
|> |> |> |
|> |> |> |Hi
|> |> |> |
|> |> |> |No sure, it’s only class loader issue. I remember this issue in
|> |> |> |pure spring boot with JDK11.
|> |> |> |
|> |> |> |Let me check.
|> |> |> |
|> |> |> |Regards
|> |> |> |JB
|> |> |> |
|> |> |> |> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
|> |> |> |>
|> |> |> |> Hi JB,
|> |> |> |>
|> |> |> |> Fully understand that it is still work in progress.
|> |> |> |>
|> |> |> |> Regarding the .NoClassDefFoundError:
|> |> |> |> org/ietf/jgss/GSSException --add-modules java.security.jgss does
|not solve it?
|> |> |> |> Is it a class loader problem?
|> |> |> |>
|> |> |> |> Best,
|> |> |> |>
|> |> |> |> -- Jaap
|> |> |> |>
|> |> |> |>
|> |> |> |> |-Oorspronkelijk bericht-
|> |> |> |> |Van: Jean-Baptiste Onofre 
|> |> |> |> |Verzonden: zondag 26 september 2021 14:20
|> |> |> |> |Aan: user@karaf.apache.org
|> |> |> |> |Onderwerp: Re: Karaf 5
|> |> |> |> |
|> |> |> |> |Hi Jaap,
|> |> |> |> |
|> |> |> |> |First, maybe I was not clean in my presentation: K

Re: Karaf 4.3.3 feature:refresh results in StackOverflowError

[Łukasz Dywicki]

Hey Thomas,
I just got stack overflow myself and began to look for solution of my issue.

From my past experiences I can tell you that stack overflow prior 4.3.x 
was usually result of multiple feature repositories (uris) delivering 
same feature. This might happen if you have several KARs/generated 
feature sets pulled into another feature/final assembly. All works 
separatelly but breaks when paths are crossed and packed together.


You can search for it manually or simply with bash helper:
find . -name "*.xml" -exec grep -C 4 -i "name=\"co7io-chrono" "{}" \; -print

In my case I know issue is related to co7io-chrono feature because I 
attached debugger to see what is at the very top of stack overflow 
listed in .. stack trace. Turns out to be this feature.


With above command I see that same feature is listed in few places.

./features/org.co7io.addons.feature.openhab/target/feature/feature.xml
./features/org.co7io.addons.feature.profile/target/feature/feature.xml
./bundles/org.co7io.chrono/target/test-classes/feature.xml (source)

Situation for me is rather obvious the "chrono" stuff brings own feature 
descriptor which reffered in "openhab" and "profile" feature sets. Quite 
natural, isn't it? Yet due to use of feature aggregation the chrono 
feature is embedded into openhab and profile feature descriptors. 
Effectively I got 3 "co7io-chrono" features defined in three descriptors.


After looking at dependency tree I found that all three feature sets are 
reffered in one build which might confuse resolver.


Can you do similar deduction for your build and see if similar situation 
occurs there too?


Best regards,
Łukasz


On 27.09.2021 15:25, Thomas Driessen wrote:

Hi J.B. :)

just wanted to ask if you did find some spare time to have a look at 
that issue?


Kind regards,
Thomas

Am Mo., 20. Sept. 2021 um 07:50 Uhr schrieb Thomas Driessen 
mailto:thomas.driessen...@gmail.com>>:


Hi J.B.,

I've sent you the contents directly to your email :)

Am Mo., 20. Sept. 2021 um 07:43 Uhr schrieb Jean-Baptiste Onofre
mailto:j...@nanthrax.net>>:

Hi Thomas,

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

Thanks
Regards
JB

 > Le 20 sept. 2021 à 07:27, Thomas Driessen
mailto:thomas.driessen...@gmail.com>> a écrit :
 >
 > Hi J.B. , hi Francois,
 >
 > thanks for your quick answer and sorry for the delay.
 >
 > Is there any way to detect such a cycle, i.e. is there a
command such as feature:tree like for the dependency tree in
maven that could help me identifying such cycles?
 >
 > Strange thing is: the exact same setup worked fine with Karaf
4.3.2. So probably one of our referenced features in other
feature repositories causes this behavior.
 >
 >
 > Kind regards,
 > Thomas
 >
 > Am Sa., 18. Sept. 2021 um 06:22 Uhr schrieb Jean-Baptiste
Onofre mailto:j...@nanthrax.net>>:
 > Hi Thomas,
 >
 > I think you have a loop in your features (a feature A require
feature B that require feature A).
 >
 > I know that Pax CDI has a cycle like this (I have a fix but
not yet released).
 >
 > Regards
 > JB
 >
 > > Le 17 sept. 2021 à 17:00, Thomas Driessen
mailto:thomas.driessen...@gmail.com>> a écrit :
 > >
 > > Hi,
 > >
 > > we just updated to the new Karaf 4.3.3 and suddenly we
always get a StackOverflowError as soon as we try to do a
feature:refresh:
 > >
 > > 2021-09-17T14:56:44,239 | ERROR | Karaf local console user
karaf | ShellUtil                        | 44 -
org.apache.karaf.shell.core - 4.3.3 | Exception caught while
executing command
 > > java.util.concurrent.ExecutionException:
java.lang.StackOverflowError
 > >         at
java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
 > >         at
java.util.concurrent.FutureTask.get(FutureTask.java:191) ~[?:?]
 > >         at

org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.run(CommandSessionImpl.java:855)
~[?:?]
 > >         at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
~[?:?]
 > >         at
java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
 > >         at

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
 > >         at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
 > >         at java.lang.Thread.run(Thread.java:829) [?:?]
 > > Caused by: java.lang.StackOverflowError
 > >         at
   

Re: Karaf 5

[JB Onofré]

I started a service bridge allowing to implicit push some spring bean to the k5 
registry and so that can be used from other modules running in k5. It’s a local 
branch for now but I can push it on main. 

Is it what you are looking for ?

Regards 
JB

> Le 29 sept. 2021 à 21:43, jgfrm  a écrit :
> 
> Is there already something working for exporting functionality of a Spring 
> modules to other modules?
> 
> |-Oorspronkelijk bericht-
> |Van: Jean-Baptiste Onofré 
> |Verzonden: woensdag 29 september 2021 17:26
> |Aan: user@karaf.apache.org
> |Onderwerp: Re: Karaf 5
> |
> |Thanks for the update.
> |
> |I'm happy to say you are the first one to "use/launch" Karaf 5 ;)
> |
> |About the TomcatURLStreamHandlerFactory is known "issue":
> |
> |https://github.com/jbonofre/karaf5/blob/main/services/spring-boot-
> |application-
> |manager/src/main/java/org/apache/karaf/springboot/SpringBootApplication
> |ManagerService.java#L110
> |
> |I have to improve this ;)
> |
> |Regards
> |JB
> |
> |On 29/09/2021 17:19, jgfrm wrote:
> |> The following works:
> |>
> |> Karaf.json:
> |> 
> |> {
> |>"applications": [
> |>  {
> |>"name": "e3web",
> |>"url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
> |>"type": "spring-boot",
> |>"properties": {
> |>  "enableHttp": true,
> |>  "enablePrometheus": true
> |>}
> |>  }
> |>]
> |> }
> |> 
> |>
> |> Add to Spring boot application:
> |> 
> |> @SpringBootApplication
> |> @ComponentScan
> |> public class E3webApplication {
> |>
> |>   ...
> |>  public static void main(String[] args) {
> |>  TomcatURLStreamHandlerFactory.disable();  // see
> |https://github.com/spring-projects/spring-boot/issues/21535
> |>  SpringApplication.run(E3webApplication.class, args);
> |>  }
> |> 
> |>
> |> Start with
> |> java --add-modules jdk.security.jgss -cp
> |> ../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1
> |> .0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/tar
> |> get/spring-boot-application-manager-5.0-SNAPSHOT.jar
> |> -Dkaraf.config=src/main/resources/karaf.json
> |> org.apache.karaf.boot.Main
> |>
> |> |-Oorspronkelijk bericht-
> |> |Van: JB Onofré 
> |> |Verzonden: dinsdag 28 september 2021 06:34
> |> |Aan: user@karaf.apache.org
> |> |Onderwerp: Re: Karaf 5
> |> |
> |> |Hi
> |> |
> |> |No it’s not this because k5 don’t use OSGi for the spring boot
> |> |launcher. I still think it’s a missing add modules as Jvm arg. I will 
> check
> |today.
> |> |
> |> |Regards
> |> |JB
> |> |
> |> |> Le 27 sept. 2021 à 23:39, jgfrm  a écrit :
> |> |>
> |> |> While Googling, I came across on of your blogs
> |> |(http://nanthrax.blogspot.com/2021/04/whats-new-in-apache-karaf-
> |> |431.html) that one of the changes in Karaf was to export the java.*
> |packages.
> |> |Could that be the cause?
> |> |>
> |> |> |-Oorspronkelijk bericht-
> |> |> |Van: Jean-Baptiste Onofre 
> |> |> |Verzonden: zondag 26 september 2021 18:02
> |> |> |Aan: user@karaf.apache.org
> |> |> |Onderwerp: Re: Karaf 5
> |> |> |
> |> |> |Hi
> |> |> |
> |> |> |No sure, it’s only class loader issue. I remember this issue in
> |> |> |pure spring boot with JDK11.
> |> |> |
> |> |> |Let me check.
> |> |> |
> |> |> |Regards
> |> |> |JB
> |> |> |
> |> |> |> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
> |> |> |>
> |> |> |> Hi JB,
> |> |> |>
> |> |> |> Fully understand that it is still work in progress.
> |> |> |>
> |> |> |> Regarding the .NoClassDefFoundError: org/ietf/jgss/GSSException
> |> |> |> --add-modules java.security.jgss does not solve it?
> |> |> |> Is it a class loader problem?
> |> |> |>
> |> |> |> Best,
> |> |> |>
> |> |> |> -- Jaap
> |> |> |>
> |> |> |>
> |> |> |> |-Oorspronkelijk bericht-
> |> |> |> |Van: Jean-Baptiste Onofre 
> |> |> |> |Verzonden: zondag 26 september 2021 14:20
> |> |> |> |Aan: user@karaf.apache.org
> |> |> |> |Onderwerp: Re: Karaf 5
> |> |> |> |
> |> |> |> |Hi Jaap,
> |> |> |> |
> |> |> |> |First, maybe I was not clean in my presentation: Karaf 5 is
> |> |> |> |still under development and so, everything is not yet ready.
> |> |> |> |As said, I will “move” the code to Apache Karaf repo as soon as
> |> |> |> |I consider I have something clean and running.
> |> |> |> |
> |> |> |> |Anyway, about your email, I will check. Today my focus is on
> |> |> |> |the OsgiApplicationManager to be Karaf 4 compliant.
> |> |> |> |I also have to improve the Karaf Config service.
> |> |> |> |
> |> |> |> |By the way, you don’t need your own Main, just use the
> |> |> |> |repackage with regular provided Main (you can take a look on
> |> |> |> |the K4 assembly repackage as an example). I will create a
> |> |> |> |gradle/maven plugin with
> |> |> |repackage.
> |> |> |> |
> |> |> |> |Regarding your issue, as you are running with JDK11, I guess
> |> |> |> |you have to add -- add-modules java.security.jgss to avoid the
> |> |> |NoClassDefFoundException.
> |> |> |> 

RE: Karaf 5

[jgfrm]

Is there already something working for exporting functionality of a Spring 
modules to other modules?

|-Oorspronkelijk bericht-
|Van: Jean-Baptiste Onofré 
|Verzonden: woensdag 29 september 2021 17:26
|Aan: user@karaf.apache.org
|Onderwerp: Re: Karaf 5
|
|Thanks for the update.
|
|I'm happy to say you are the first one to "use/launch" Karaf 5 ;)
|
|About the TomcatURLStreamHandlerFactory is known "issue":
|
|https://github.com/jbonofre/karaf5/blob/main/services/spring-boot-
|application-
|manager/src/main/java/org/apache/karaf/springboot/SpringBootApplication
|ManagerService.java#L110
|
|I have to improve this ;)
|
|Regards
|JB
|
|On 29/09/2021 17:19, jgfrm wrote:
|> The following works:
|>
|> Karaf.json:
|> 
|> {
|>"applications": [
|>  {
|>"name": "e3web",
|>"url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
|>"type": "spring-boot",
|>"properties": {
|>  "enableHttp": true,
|>  "enablePrometheus": true
|>}
|>  }
|>]
|> }
|> 
|>
|> Add to Spring boot application:
|> 
|> @SpringBootApplication
|> @ComponentScan
|> public class E3webApplication {
|>
|>   ...
|>  public static void main(String[] args) {
|>  TomcatURLStreamHandlerFactory.disable();  // see
|https://github.com/spring-projects/spring-boot/issues/21535
|>  SpringApplication.run(E3webApplication.class, args);
|>  }
|> 
|>
|> Start with
|> java --add-modules jdk.security.jgss -cp
|> ../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1
|> .0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/tar
|> get/spring-boot-application-manager-5.0-SNAPSHOT.jar
|> -Dkaraf.config=src/main/resources/karaf.json
|> org.apache.karaf.boot.Main
|>
|> |-Oorspronkelijk bericht-
|> |Van: JB Onofré 
|> |Verzonden: dinsdag 28 september 2021 06:34
|> |Aan: user@karaf.apache.org
|> |Onderwerp: Re: Karaf 5
|> |
|> |Hi
|> |
|> |No it’s not this because k5 don’t use OSGi for the spring boot
|> |launcher. I still think it’s a missing add modules as Jvm arg. I will check
|today.
|> |
|> |Regards
|> |JB
|> |
|> |> Le 27 sept. 2021 à 23:39, jgfrm  a écrit :
|> |>
|> |> While Googling, I came across on of your blogs
|> |(http://nanthrax.blogspot.com/2021/04/whats-new-in-apache-karaf-
|> |431.html) that one of the changes in Karaf was to export the java.*
|packages.
|> |Could that be the cause?
|> |>
|> |> |-Oorspronkelijk bericht-
|> |> |Van: Jean-Baptiste Onofre 
|> |> |Verzonden: zondag 26 september 2021 18:02
|> |> |Aan: user@karaf.apache.org
|> |> |Onderwerp: Re: Karaf 5
|> |> |
|> |> |Hi
|> |> |
|> |> |No sure, it’s only class loader issue. I remember this issue in
|> |> |pure spring boot with JDK11.
|> |> |
|> |> |Let me check.
|> |> |
|> |> |Regards
|> |> |JB
|> |> |
|> |> |> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
|> |> |>
|> |> |> Hi JB,
|> |> |>
|> |> |> Fully understand that it is still work in progress.
|> |> |>
|> |> |> Regarding the .NoClassDefFoundError: org/ietf/jgss/GSSException
|> |> |> --add-modules java.security.jgss does not solve it?
|> |> |> Is it a class loader problem?
|> |> |>
|> |> |> Best,
|> |> |>
|> |> |> -- Jaap
|> |> |>
|> |> |>
|> |> |> |-Oorspronkelijk bericht-
|> |> |> |Van: Jean-Baptiste Onofre 
|> |> |> |Verzonden: zondag 26 september 2021 14:20
|> |> |> |Aan: user@karaf.apache.org
|> |> |> |Onderwerp: Re: Karaf 5
|> |> |> |
|> |> |> |Hi Jaap,
|> |> |> |
|> |> |> |First, maybe I was not clean in my presentation: Karaf 5 is
|> |> |> |still under development and so, everything is not yet ready.
|> |> |> |As said, I will “move” the code to Apache Karaf repo as soon as
|> |> |> |I consider I have something clean and running.
|> |> |> |
|> |> |> |Anyway, about your email, I will check. Today my focus is on
|> |> |> |the OsgiApplicationManager to be Karaf 4 compliant.
|> |> |> |I also have to improve the Karaf Config service.
|> |> |> |
|> |> |> |By the way, you don’t need your own Main, just use the
|> |> |> |repackage with regular provided Main (you can take a look on
|> |> |> |the K4 assembly repackage as an example). I will create a
|> |> |> |gradle/maven plugin with
|> |> |repackage.
|> |> |> |
|> |> |> |Regarding your issue, as you are running with JDK11, I guess
|> |> |> |you have to add -- add-modules java.security.jgss to avoid the
|> |> |NoClassDefFoundException.
|> |> |> |
|> |> |> |Thanks anyway for your feedback, much appreciated.
|> |> |> |
|> |> |> |Regards
|> |> |> |JB
|> |> |> |
|> |> |> |> Le 26 sept. 2021 à 12:00, jgfrm  a écrit :
|> |> |> |>
|> |> |> |> Hi Jean-Baptiste,
|> |> |> |>
|> |> |> |> I managed to start (well not completely) my spring application.
|> |> |> |> However, while starting up, I get an exception:
|> |> |> |>
|> |> |> |> 11:43:03.148 [main] ERROR o.s.boot.SpringApplication:837 -
|> |> |> |> Application run failed
|> |> |> |> org.springframework.context.ApplicationContextException:
|> |> |> |> Unable to start web server; nested except

Re: Karaf 5

[Jean-Baptiste Onofré]

Thanks for the update.

I'm happy to say you are the first one to "use/launch" Karaf 5 ;)

About the TomcatURLStreamHandlerFactory is known "issue":

https://github.com/jbonofre/karaf5/blob/main/services/spring-boot-application-manager/src/main/java/org/apache/karaf/springboot/SpringBootApplicationManagerService.java#L110

I have to improve this ;)

Regards
JB

On 29/09/2021 17:19, jgfrm wrote:

The following works:

Karaf.json:

{
   "applications": [
 {
   "name": "e3web",
   "url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
   "type": "spring-boot",
   "properties": {
 "enableHttp": true,
 "enablePrometheus": true
   }
 }
   ]
}


Add to Spring boot application:

@SpringBootApplication
@ComponentScan
public class E3webApplication {

  ...
 public static void main(String[] args) {
 TomcatURLStreamHandlerFactory.disable();  // see 
https://github.com/spring-projects/spring-boot/issues/21535
 SpringApplication.run(E3webApplication.class, args);
 }


Start with
java --add-modules jdk.security.jgss -cp 
../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1.0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/target/spring-boot-application-manager-5.0-SNAPSHOT.jar
 -Dkaraf.config=src/main/resources/karaf.json org.apache.karaf.boot.Main

|-Oorspronkelijk bericht-
|Van: JB Onofré 
|Verzonden: dinsdag 28 september 2021 06:34
|Aan: user@karaf.apache.org
|Onderwerp: Re: Karaf 5
|
|Hi
|
|No it’s not this because k5 don’t use OSGi for the spring boot launcher. I 
still
|think it’s a missing add modules as Jvm arg. I will check today.
|
|Regards
|JB
|
|> Le 27 sept. 2021 à 23:39, jgfrm  a écrit :
|>
|> While Googling, I came across on of your blogs
|(http://nanthrax.blogspot.com/2021/04/whats-new-in-apache-karaf-
|431.html) that one of the changes in Karaf was to export the java.* packages.
|Could that be the cause?
|>
|> |-Oorspronkelijk bericht-
|> |Van: Jean-Baptiste Onofre 
|> |Verzonden: zondag 26 september 2021 18:02
|> |Aan: user@karaf.apache.org
|> |Onderwerp: Re: Karaf 5
|> |
|> |Hi
|> |
|> |No sure, it’s only class loader issue. I remember this issue in pure
|> |spring boot with JDK11.
|> |
|> |Let me check.
|> |
|> |Regards
|> |JB
|> |
|> |> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
|> |>
|> |> Hi JB,
|> |>
|> |> Fully understand that it is still work in progress.
|> |>
|> |> Regarding the .NoClassDefFoundError: org/ietf/jgss/GSSException
|> |> --add-modules java.security.jgss does not solve it?
|> |> Is it a class loader problem?
|> |>
|> |> Best,
|> |>
|> |> -- Jaap
|> |>
|> |>
|> |> |-Oorspronkelijk bericht-
|> |> |Van: Jean-Baptiste Onofre 
|> |> |Verzonden: zondag 26 september 2021 14:20
|> |> |Aan: user@karaf.apache.org
|> |> |Onderwerp: Re: Karaf 5
|> |> |
|> |> |Hi Jaap,
|> |> |
|> |> |First, maybe I was not clean in my presentation: Karaf 5 is still
|> |> |under development and so, everything is not yet ready.
|> |> |As said, I will “move” the code to Apache Karaf repo as soon as I
|> |> |consider I have something clean and running.
|> |> |
|> |> |Anyway, about your email, I will check. Today my focus is on the
|> |> |OsgiApplicationManager to be Karaf 4 compliant.
|> |> |I also have to improve the Karaf Config service.
|> |> |
|> |> |By the way, you don’t need your own Main, just use the repackage
|> |> |with regular provided Main (you can take a look on the K4 assembly
|> |> |repackage as an example). I will create a gradle/maven plugin with
|> |repackage.
|> |> |
|> |> |Regarding your issue, as you are running with JDK11, I guess you
|> |> |have to add -- add-modules java.security.jgss to avoid the
|> |NoClassDefFoundException.
|> |> |
|> |> |Thanks anyway for your feedback, much appreciated.
|> |> |
|> |> |Regards
|> |> |JB
|> |> |
|> |> |> Le 26 sept. 2021 à 12:00, jgfrm  a écrit :
|> |> |>
|> |> |> Hi Jean-Baptiste,
|> |> |>
|> |> |> I managed to start (well not completely) my spring application.
|> |> |> However, while starting up, I get an exception:
|> |> |>
|> |> |> 11:43:03.148 [main] ERROR o.s.boot.SpringApplication:837 -
|> |> |> Application run failed
|> |> |> org.springframework.context.ApplicationContextException: Unable
|> |> |> to start web server; nested exception is
|java.lang.NoClassDefFoundError:
|> |> |> org/ietf/jgss/GSSException
|> |> |>
|> |> |> Any ideas?
|> |> |>
|> |> |> Also, I had to make modifications in
|> |> |SpringBootApplicationManagerService/start:
|> |> |>
|> |> |> try {
|> |> |>Thread.currentThread().setContextClassLoader(classLoader);
|> |> |>// disable tomcat stream handler
|> |> |>/* There is no TomcatURLStreamHandlerFactory in my spring 
jar
|> |> |>final Method tomcat =
|> |> |classLoader.loadClass("org.apache.catalina.webresources.TomcatURLS
|> |> |tre am HandlerFactory").getMethod("disable");
|> |> |>if (!tomcat.isBridge()) {
|> |> |>to

RE: Karaf 5

[jgfrm]

The following works:

Karaf.json:

{
  "applications": [
{
  "name": "e3web",
  "url": "file:///home/jaap/Karaf5Test/e3web-dev.jar",
  "type": "spring-boot",
  "properties": {
"enableHttp": true,
"enablePrometheus": true
  }
}
  ]
}


Add to Spring boot application:

@SpringBootApplication
@ComponentScan
public class E3webApplication {

 ...
public static void main(String[] args) {
TomcatURLStreamHandlerFactory.disable();  // see 
https://github.com/spring-projects/spring-boot/issues/21535
SpringApplication.run(E3webApplication.class, args);
}


Start with 
java --add-modules jdk.security.jgss -cp 
../karaf5/assemblies/k4/target/k4-5.0-SNAPSHOT.jar:target/e3web-test-1.0-SNAPSHOT.jar:../karaf5/services/spring-boot-application-manager/target/spring-boot-application-manager-5.0-SNAPSHOT.jar
 -Dkaraf.config=src/main/resources/karaf.json org.apache.karaf.boot.Main

|-Oorspronkelijk bericht-
|Van: JB Onofré 
|Verzonden: dinsdag 28 september 2021 06:34
|Aan: user@karaf.apache.org
|Onderwerp: Re: Karaf 5
|
|Hi
|
|No it’s not this because k5 don’t use OSGi for the spring boot launcher. I 
still
|think it’s a missing add modules as Jvm arg. I will check today.
|
|Regards
|JB
|
|> Le 27 sept. 2021 à 23:39, jgfrm  a écrit :
|>
|> While Googling, I came across on of your blogs
|(http://nanthrax.blogspot.com/2021/04/whats-new-in-apache-karaf-
|431.html) that one of the changes in Karaf was to export the java.* packages.
|Could that be the cause?
|>
|> |-Oorspronkelijk bericht-
|> |Van: Jean-Baptiste Onofre 
|> |Verzonden: zondag 26 september 2021 18:02
|> |Aan: user@karaf.apache.org
|> |Onderwerp: Re: Karaf 5
|> |
|> |Hi
|> |
|> |No sure, it’s only class loader issue. I remember this issue in pure
|> |spring boot with JDK11.
|> |
|> |Let me check.
|> |
|> |Regards
|> |JB
|> |
|> |> Le 26 sept. 2021 à 17:59, jgfrm  a écrit :
|> |>
|> |> Hi JB,
|> |>
|> |> Fully understand that it is still work in progress.
|> |>
|> |> Regarding the .NoClassDefFoundError: org/ietf/jgss/GSSException
|> |> --add-modules java.security.jgss does not solve it?
|> |> Is it a class loader problem?
|> |>
|> |> Best,
|> |>
|> |> -- Jaap
|> |>
|> |>
|> |> |-Oorspronkelijk bericht-
|> |> |Van: Jean-Baptiste Onofre 
|> |> |Verzonden: zondag 26 september 2021 14:20
|> |> |Aan: user@karaf.apache.org
|> |> |Onderwerp: Re: Karaf 5
|> |> |
|> |> |Hi Jaap,
|> |> |
|> |> |First, maybe I was not clean in my presentation: Karaf 5 is still
|> |> |under development and so, everything is not yet ready.
|> |> |As said, I will “move” the code to Apache Karaf repo as soon as I
|> |> |consider I have something clean and running.
|> |> |
|> |> |Anyway, about your email, I will check. Today my focus is on the
|> |> |OsgiApplicationManager to be Karaf 4 compliant.
|> |> |I also have to improve the Karaf Config service.
|> |> |
|> |> |By the way, you don’t need your own Main, just use the repackage
|> |> |with regular provided Main (you can take a look on the K4 assembly
|> |> |repackage as an example). I will create a gradle/maven plugin with
|> |repackage.
|> |> |
|> |> |Regarding your issue, as you are running with JDK11, I guess you
|> |> |have to add -- add-modules java.security.jgss to avoid the
|> |NoClassDefFoundException.
|> |> |
|> |> |Thanks anyway for your feedback, much appreciated.
|> |> |
|> |> |Regards
|> |> |JB
|> |> |
|> |> |> Le 26 sept. 2021 à 12:00, jgfrm  a écrit :
|> |> |>
|> |> |> Hi Jean-Baptiste,
|> |> |>
|> |> |> I managed to start (well not completely) my spring application.
|> |> |> However, while starting up, I get an exception:
|> |> |>
|> |> |> 11:43:03.148 [main] ERROR o.s.boot.SpringApplication:837 -
|> |> |> Application run failed
|> |> |> org.springframework.context.ApplicationContextException: Unable
|> |> |> to start web server; nested exception is
|java.lang.NoClassDefFoundError:
|> |> |> org/ietf/jgss/GSSException
|> |> |>
|> |> |> Any ideas?
|> |> |>
|> |> |> Also, I had to make modifications in
|> |> |SpringBootApplicationManagerService/start:
|> |> |>
|> |> |> try {
|> |> |>Thread.currentThread().setContextClassLoader(classLoader);
|> |> |>// disable tomcat stream handler
|> |> |>/* There is no TomcatURLStreamHandlerFactory in my spring 
jar
|> |> |>final Method tomcat =
|> |> |classLoader.loadClass("org.apache.catalina.webresources.TomcatURLS
|> |> |tre am HandlerFactory").getMethod("disable");
|> |> |>if (!tomcat.isBridge()) {
|> |> |>tomcat.setAccessible(true);
|> |> |>}
|> |> |>tomcat.invoke(null, null);
|> |> |> */
|> |> |>// invoke spring boot main
|> |> |>final Method main =
|> |> |classLoader.loadClass("org.springframework.boot.loader.JarLauncher").
|> |> |getM
|> |> |ethod("main", String[].class);
|> |> |>main.setAccessible(true);
|> |> |>log.info("Call J

Re: Possible to replace Classloader of a Bundle

[Jean-Baptiste Onofré]

Hi,

No it's not really possible without a framework extension.
Bundle classloader is directly managed by the framework.

However, you can create/federate/control classloader. It's what we do in 
Cellar using the ClassLoaderService:


https://github.com/apache/karaf-cellar/blob/main/core/src/main/java/org/apache/karaf/cellar/core/utils/CombinedClassLoader.java

You can create groovy classloader and extend it.

NB: a similar ClassLoader service is in preparation in K5: 
https://github.com/jbonofre/karaf5/blob/main/boot/src/main/java/org/apache/karaf/boot/service/ClassLoaderService.java 
(WIP)


Regards
JB

On 29/09/2021 14:42, Matthias Leinweber wrote:

Hello,

Is it possible to replace the bundle classloader with another? The idea 
behind this is that you have a groovy class loader which uses the bundle 
class loader as a parent. Then after the initialization of the groovy 
class loader this class loader loads additional classes during runtime.


When I add dynamic-import to a bundle which is using my groovy dynamic 
bundle it should be possible to use the dynamically loaded classes in 
the other bundle.


But unfortunately i don't find a way to replace the bundle class loader 
.. any ideas about this?


best regards
Matthias

Possible to replace Classloader of a Bundle

[Matthias Leinweber]

Hello,

Is it possible to replace the bundle classloader with another? The idea
behind this is that you have a groovy class loader which uses the bundle
class loader as a parent. Then after the initialization of the groovy class
loader this class loader loads additional classes during runtime.

When I add dynamic-import to a bundle which is using my groovy dynamic
bundle it should be possible to use the dynamically loaded classes in the
other bundle.

But unfortunately i don't find a way to replace the bundle class loader ..
any ideas about this?

best regards
Matthias

Re: Problems with javax.annotation package

[Jean-Baptiste Onofré]

That's a good point for Karaf 5 ;) (the OSGi headers/test/kwonledges ;)).

Regards
JB

On 29/09/2021 10:46, Richard Hierlmeier wrote:
The point is that the fix of issue 1616 in jsoup is sufficient for me. 
It does not fix the problem in jsr305, it just does not use it.

I can wait until jsoup 1.14.3 is released.

Yes, you can't fix these issues. The problem is that most artifacts do 
not run on OSGI primarily.

They have OSGI definitions in the manifest, but the are not really tested.
An upgrade to a newer versions ends often in fixing these issues by 
wrapping the artifact.


Regards

   Richard


Am Mi., 29. Sept. 2021 um 08:20 Uhr schrieb JB Onofré >:


So what’s the point in your previous email ? If the third party
fixed their issue already that’s fine right ?

Karaf can’t fix whole world issue ;)

Regards
JB


Le 29 sept. 2021 à 08:04, Richard Hierlmeier
mailto:rhierlme...@googlemail.com>> a
écrit :



Wrapping the bundle is not necessary for my use case. The bug is
already fixed in jsoup.
See https://github.com/jhy/jsoup/issues/1616

Unfortunately the release of jsoup 1.14.3  is yet not available.

The original findbugs development is no longer active. The newer
project is named spotbugs. It does not
use the javax.annotation package.
See
https://github.com/spotbugs/spotbugs/issues/421



Regards

  Richard




Am Mi., 29. Sept. 2021 um 06:07 Uhr schrieb Jean-Baptiste Onofre
mailto:j...@nanthrax.net>>:

Hi Richard

Sorry I misread the trace especially this part:

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

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

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

Regards
JB

> Le 28 sept. 2021 à 20:19, Richard Hierlmeier
mailto:rhierlme...@googlemail.com>> a écrit :
>
> Hi J.B,
>
> The javax.annotation package is exported by
>
> mvn:com.google.code.findbugs/jsr305/3.0.2 (dependency of jsoup)
> and by
> mvn:jakarta.annotation/jakarta.annotation-api/1.3.5 (from
cxf-specs feature)
>
> None of them comes from Vaadin. vaadin-server has a
dependency to jsoup that was upgraded with Vaadin 8.14.0 to
version 1.14.2.
> The jsr305 bundle imports to javax.annotation;version=[3.0.2,4)
> My vaadin8osgi Bundle imports javax.annotation;version=[1.3.5,2)
>
> It seems that the jsr305 bundle ist the problem:
>

https://stackoverflow.com/questions/64568455/why-does-findbugs-jsr305-break-osgi-package-export-of-javax-annotations-in-redha


>
> Richard
>
>
>
>
> Am Di., 28. Sept. 2021 um 17:35 Uhr schrieb Jean-Baptiste
Onofre mailto:j...@nanthrax.net>>:
> Hi Richard,
>
> It seems that vaadin.annotations bundle is just wrong as it
exports javax.annotation whereas it should not.
>
> You have basically three options:
> 1. Fix vaadin.annotations ;)
> 2. Wrap vaadin.annotations to remove the “bad” export
> 3. Don’t use six annotation-api-1.3 and use
vaadin.annotations instead but it means changing the core features
>
> Regards
> JB
>
> > Le 28 sept. 2021 à 17:27, Richard Hierlmeier
mailto:rhierlme...@googlemail.com>> a écrit :
> >
> >
> > After upgrading  the Vaadin OSGI demo to VAADIN 8.14.0 it
tried
> > to integrate a jax-rs resource into this application.
> >
> > I used the rest whiteboard examples from the Karaf 4.3.3
distribution. It worked in a first step fine.
> >
> > Finally I tried to implement a JAX-RS authentication
filter for this application.
> >
> > I implemented this class:

https://github.com/rhierlmeier/vaadin8_karaf_demo/blob/jaxrs-integration/src/main/java/de/rhierlmeier/vaadin8osgi/rest/AuthenticationFilter.java


> >
> > I needs the javax.annotation.Priority annotation.
> >

Re: Problems with javax.annotation package

[Richard Hierlmeier]

The point is that the fix of issue 1616 in jsoup is sufficient for me. It
does not fix the problem in jsr305, it just does not use it.
I can wait until jsoup 1.14.3 is released.

Yes, you can't fix these issues. The problem is that most artifacts do not
run on OSGI primarily.
They have OSGI definitions in the manifest, but the are not really tested.
An upgrade to a newer versions ends often in fixing these issues by
wrapping the artifact.

Regards

  Richard


Am Mi., 29. Sept. 2021 um 08:20 Uhr schrieb JB Onofré :

> So what’s the point in your previous email ? If the third party fixed
> their issue already that’s fine right ?
>
> Karaf can’t fix whole world issue ;)
>
> Regards
> JB
>
> Le 29 sept. 2021 à 08:04, Richard Hierlmeier 
> a écrit :
>
> 
>
> Wrapping the bundle is not necessary for my use case. The bug is already
> fixed in jsoup.
> See https://github.com/jhy/jsoup/issues/1616
> Unfortunately the release of jsoup 1.14.3  is yet not available.
>
> The original findbugs development is no longer active. The newer project
> is named spotbugs. It does not
> use the javax.annotation package.
> See
> https://github.com/spotbugs/spotbugs/issues/421
>
>
> Regards
>
>   Richard
>
>
>
>
> Am Mi., 29. Sept. 2021 um 06:07 Uhr schrieb Jean-Baptiste Onofre <
> j...@nanthrax.net>:
>
>> Hi Richard
>>
>> Sorry I misread the trace especially this part:
>>
>> export: osgi.wiring.package=org.atmosphere.cpr; uses:=javax.annotation
>>   com.vaadin.external.atmosphere.runtime
>> [com.vaadin.external.atmosphere.runtime [141](R 141.0)]
>> import: (osgi.wiring.package=javax.annotation)
>>
>> AFAIR we already discuss about google findbugs bundle that cause an issue
>> (it should not export Java.annotation package as it’s not a spec).
>>
>> Maybe I can wrap this bundle in SMX to avoid issue in the future.
>> Thoughts ?
>>
>> Regards
>> JB
>>
>> > Le 28 sept. 2021 à 20:19, Richard Hierlmeier <
>> rhierlme...@googlemail.com> a écrit :
>> >
>> > Hi J.B,
>> >
>> > The javax.annotation package is exported by
>> >
>> > mvn:com.google.code.findbugs/jsr305/3.0.2 (dependency of jsoup)
>> > and by
>> > mvn:jakarta.annotation/jakarta.annotation-api/1.3.5 (from cxf-specs
>> feature)
>> >
>> > None of them comes from Vaadin. vaadin-server has a dependency to jsoup
>> that was upgraded with Vaadin 8.14.0 to version 1.14.2.
>> > The jsr305 bundle imports to javax.annotation;version=[3.0.2,4)
>> > My vaadin8osgi Bundle imports javax.annotation;version=[1.3.5,2)
>> >
>> > It seems that the jsr305 bundle ist the problem:
>> >
>> https://stackoverflow.com/questions/64568455/why-does-findbugs-jsr305-break-osgi-package-export-of-javax-annotations-in-redha
>> >
>> > Richard
>> >
>> >
>> >
>> >
>> > Am Di., 28. Sept. 2021 um 17:35 Uhr schrieb Jean-Baptiste Onofre <
>> j...@nanthrax.net>:
>> > Hi Richard,
>> >
>> > It seems that vaadin.annotations bundle is just wrong as it exports
>> javax.annotation whereas it should not.
>> >
>> > You have basically three options:
>> > 1. Fix vaadin.annotations ;)
>> > 2. Wrap vaadin.annotations to remove the “bad” export
>> > 3. Don’t use six annotation-api-1.3 and use vaadin.annotations instead
>> but it means changing the core features
>> >
>> > Regards
>> > JB
>> >
>> > > Le 28 sept. 2021 à 17:27, Richard Hierlmeier <
>> rhierlme...@googlemail.com> a écrit :
>> > >
>> > >
>> > > After upgrading  the Vaadin OSGI demo to VAADIN 8.14.0 it tried
>> > > to integrate a jax-rs resource into this application.
>> > >
>> > > I used the rest whiteboard examples from the Karaf 4.3.3
>> distribution. It worked in a first step fine.
>> > >
>> > > Finally I tried to implement a JAX-RS authentication filter for this
>> application.
>> > >
>> > > I implemented this class:
>> https://github.com/rhierlmeier/vaadin8_karaf_demo/blob/jaxrs-integration/src/main/java/de/rhierlmeier/vaadin8osgi/rest/AuthenticationFilter.java
>> > >
>> > > I needs the javax.annotation.Priority annotation.
>> > >
>> > > When I start now the bundle, I get following error:
>> > >
>> > > Error executing command: Error executing command on bundles:
>> > > Error starting bundle 148: Uses constraint violation. Unable
>> to resolve resource de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi
>> [148](R 148.2)] because it is exposed to package 'javax.annotation' from
>> resources org.apache.servicemix.specs.annotation-api-1.3
>> [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)] and
>> org.apache.felix.framework [org.apache.felix.framework [0](R 0)] via two
>> dependency chains.
>> > >
>> > > Chain 1:
>> > >   de.rhierlmeier.vaadin8osgi [de.rhierlmeier.vaadin8osgi [148](R
>> 148.2)]
>> > > import:
>> (&(osgi.wiring.package=javax.annotation)(version>=1.3.0)(!(version>=2.0.0)))
>> > >  |
>> > > export: osgi.wiring.package: javax.annotation
>> > >   org.apache.servicemix.specs.annotation-api-1.3
>> [org.apache.servicemix.specs.annotation-api-1.3 [164](R 164.0)]
>> > >
>> > > Chain 2:
>> > >   de.rhierlmeier.vaadin8

Re: FileInstaller with 4.3.3

[Jean-Baptiste Onofré]

It's what I said in my previous email: "you have to change the core 
feature".


If you want, I can provide a forked specific version to you.

Regards
JB

On 29/09/2021 09:01, Matthias Leinweber wrote:

Hello,

I tried to downgrade to 3.6.8 and blacklisted to 3.7.0 but 
deployer/4.3.3 has package dependency on 3.7.0 :*(


br,
Matthias

Am Mi., 29. Sept. 2021 um 08:28 Uhr schrieb JB Onofré >:


Yes: we can downgrade FileInstall to 3.6.8

That’s the only way or force startup order in your custom distro


Le 29 sept. 2021 à 08:26, Matthias Leinweber
mailto:m.leinwe...@datatactics.de>> a
écrit :


Well, do you have an idea for a workaround?

Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
schrieb am Di., 28. Sep. 2021, 17:38:

FYI

https://issues.apache.org/jira/browse/FELIX-6461


Regards
JB

> Le 28 sept. 2021 à 17:27, Matthias Leinweber
mailto:m.leinwe...@datatactics.de>> a écrit :
>
> I am pretty sure its the same reason:
>
>

https://github.com/apache/felix-dev/commit/101a360248311817e1ad4645c549ea3b0481#diff-263cdbacfd163ef5ce31dcbb1db83138f78d88eab353f1f587a10199e8ef3817L315


>
> This isEmpty() change breaks the retry logic with the files
stored in processingFailures after more ArtifactListeners are
added.
>
> Best regards,
> Matthias
>
>
>
>
> Am Di., 28. Sept. 2021 um 16:51 Uhr schrieb Jean-Baptiste
Onofré mailto:j...@nanthrax.net>>:
> Hi Matthias,
>
> Thanks for the update, the order should be fine by default
in the
> features set.
>
> However, I might have identify a change that may cause issue
(related to
> FELIX-6229, on some environment).
>
> Just give me time to investigate and I will get back to you.
>
> Regards
> JB
>
> On 28/09/2021 16:35, Matthias Leinweber wrote:
> > Hello,
> >
> > i debugged a bit and it looks like that die file installer
is started
> > before the artifact listeners are added.
> > During processing these files are added to the
processingFailures list.
> > This list is reprocessed everytime and has a retry, but
only if at least
> > one file is changed see
> >    public void run() {
> > ...
> >            Set files = this.scanner.scan(false);
> >            if (!files.isEmpty()) { //<- this was if (files
!= null)  in
> > 3.6.8 and has changed and causing the problem
> >              this.process(files);
> >            }
> > ...
> >
> >
> > How could i enforce that my fileinstaller is added after
my artifact
> > liesternes (also after blueprint listener is added)
> >
> > Best regards,
> > Matthias
> >
> >
> >
> >
> >
> > Am Mo., 27. Sept. 2021 um 17:55 Uhr schrieb Matthias
Leinweber
> > mailto:m.leinwe...@datatactics.de>
>>:
> >
> >     Sure ..shared desktop or github project (depends on 2
other github
> >     projects not in maven central yet)
> >
> >     Best regards,
> >     Matthias
> >
> >     Am Mo., 27. Sept. 2021 um 17:09 Uhr schrieb
Jean-Baptiste Onofré
> >     mailto:j...@nanthrax.net>
>>:
> >
> >         OK, maybe it's due to your custom distro.
> >
> >         Any chance I can check your distro ?
> >
> >         Regards
> >         JB
> >
> >         On 27/09/2021 16:49, Matthias Leinweber wrote:
> >          > I tested it with the downloaded karaf binary
distribution and
> >         it works.
> >          > With a custom distribution there seems to be a
problem. I
> >         tested with my
> >          > own as well as with the custom dynamic dist
from examples.
> >         Pls test it
> >          > with a xml file not only with cfg+jar.
> >          >
> >          > br,
> >          > Matthias
> >          >
> >          > Am Mo., 27. Sept. 2021 um 15:04 Uhr schrieb
Jean-Baptiste Onofré
> >          > mailto:j...@nanthrax.net>