date:20230531

Frameworks dropping OSGi support

2023-05-31 Thread Jochen Walz

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: Frameworks dropping OSGi support

2023-05-31 Thread Grzegorz Grzybek

Hello

Initially (and more precisely 1-2 years ago) when the javax → jakarta
migration started to get momentum (partially because of Spring Boot 3 /
Spring Framework 6 announcement) I was thinking that the Enterprise OSGi
specifications which touch JakartaEE would have to be released all-at-once
(JPA, Web, transactions, ...) and I thought it'd be vry hard for the
implementations to quickly get new jakarta.* releases.

I was imagining a lot of problems related to compatibility to existing
libraries. Karaf features cover a lot of dependencies and there is simply
not enough (IMO) manpower to be quick here.

However recently I was tracking OSGi CMPN progress and for example there
already exist new Whiteboard specification (
https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.servlet.html)
(called "Servlet service" now), so OSGi world is not going to lag behind
too much.

I think (or I'm biased) that the web parts are the most important here. And
Pax Web doesn't yet have a Jakarta friendly release, so I have a branch
ready (with slow progress). See
https://github.com/ops4j/org.ops4j.pax.web/issues/1802

The point is that there will be NO version the ancient HttpService
specification based on jakarta.servlet package. Pax Web has this support
deep in its core, so there's fundamental decision to be made - probably Pax
Web's extension to org.osgi.service.http.HttpService is going to simply
swallow the methods from this interface.

This interface however is used by CXF (cxf-rt-transports-http) and Jolokia
and Camel Servlet and these will have to switch to Whiteboard (called
"Servlet" in OSGi CMPN 8.1).

I can't tell anything however about JPA for example. These specs in 8.1
(which contains migrated Whiteboard specification) do NOT yet moved from
javax to jakarta:

   - JPA:
   https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jpa.html
   - Transaction Control:
   
https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.transaction.control.html
   - JTA:
   https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jta.html

So it's still the beginning of the road... Not only there are not CMPN
jakarta versions of the above specs, I have no idea about progress at RI
side (Apache Aries).

I hope this clears at least some of the confusion here.

regards
Grzegorz Grzybek

śr., 31 maj 2023 o 13:32 Jochen Walz 
napisał(a):

> 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: Frameworks dropping OSGi support

2023-05-31 Thread Jochen Walz


Hello Grzegorz,

So, in short: some big chunks of work in progress (or yet to be started) 
in different places.


Thanks for the detailed answer! With this, it is at least clear where to 
look at for checking the progress.


Regards

Jochen


Am 31.05.2023 um 13:55 schrieb Grzegorz Grzybek:

Hello

Initially (and more precisely 1-2 years ago) when the javax → jakarta 
migration started to get momentum (partially because of Spring Boot 3 
/ Spring Framework 6 announcement) I was thinking that the Enterprise 
OSGi specifications which touch JakartaEE would have to be released 
all-at-once (JPA, Web, transactions, ...) and I thought it'd be 
vry hard for the implementations to quickly get new jakarta.* 
releases.


I was imagining a lot of problems related to compatibility to existing 
libraries. Karaf features cover a lot of dependencies and there is 
simply not enough (IMO) manpower to be quick here.


However recently I was tracking OSGi CMPN progress and for example 
there already exist new Whiteboard specification 
(https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.servlet.html) 
(called "Servlet service" now), so OSGi world is not going to lag 
behind too much.


I think (or I'm biased) that the web parts are the most important 
here. And Pax Web doesn't yet have a Jakarta friendly release, so I 
have a branch ready (with slow progress). See 
https://github.com/ops4j/org.ops4j.pax.web/issues/1802


The point is that there will be NO version the ancient HttpService 
specification based on jakarta.servlet package. Pax Web has this 
support deep in its core, so there's fundamental decision to be made - 
probably Pax Web's extension to org.osgi.service.http.HttpService is 
going to simply swallow the methods from this interface.


This interface however is used by CXF (cxf-rt-transports-http) and 
Jolokia and Camel Servlet and these will have to switch to Whiteboard 
(called "Servlet" in OSGi CMPN 8.1).


I can't tell anything however about JPA for example. These specs in 
8.1 (which contains migrated Whiteboard specification) do NOT yet 
moved from javax to jakarta:


  * JPA:
https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jpa.html
  * Transaction Control:

https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.transaction.control.html
  * JTA:
https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jta.html

So it's still the beginning of the road... Not only there are not CMPN 
jakarta versions of the above specs, I have no idea about progress at 
RI side (Apache Aries).


I hope this clears at least some of the confusion here.

regards
Grzegorz Grzybek

śr., 31 maj 2023 o 13:32 Jochen Walz  
napisał(a):


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: same configuration registered with multiple PIDs in ManagedServiceFactory

2023-05-31 Thread ran...@opennms.org

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 
mvn:org.apache.karaf.examples/karaf-config-example-features/4.4.3/xml

 *   feature:install karaf-config-example-managed-factory

  *   Copy the attached 'config.xml' file to the 'deploy/' directory
  *   Wait about 5 seconds, and notice the following output to the console
New configuration with pid 
org.apache.karaf.example.config.04388423-2d46-4308-8214-3dcd1e0b8fd0
key1 = value1
key2 = value2
org.apache.karaf.features.configKey = org.apache.karaf.example.config-abc
service.factoryPid = org.apache.karaf.example.config
service.pid = 
org.apache.karaf.example.config.04388423-2d46-4308-8214-3dcd1e0b8fd0
18:42:02.131 INFO [features-3-thread-1] Done.
18:42:10.999 INFO [fileinstall-/Users/jesse/labs/karaf/apache-karaf-4.4.3/etc] 
Creating configuration {org.apache.karaf.example.config~abc} from 
/Users/jesse/labs/karaf/apache-karaf-4.4.3/etc/org.apache.karaf.example.config-abc.cfg
New configuration with pid org.apache.karaf.example.config~abc
felix.fileinstall.filename = 
file:/Users/jesse/labs/karaf/apache-karaf-4.4.3/etc/org.apache.karaf.example.config-abc.cfg
key1 = value1
key2 = value2
org.apache.karaf.features.configKey = org.apache.karaf.example.config-abc
service.factoryPid = org.apache.karaf.example.config
service.pid = org.apache.karaf.example.config~abc


Note that the single config results in multiple callbacks under two separate 
pids. This seems isolated to cases where the deploy/ folder is used to write 
the config, and doesn't happen when the configuration is manually placed in 
etc/.

Following the same instructions with Karaf 4.3.6 has the expected behavior. 
Karaf 4.3.7 and later experience this issue though.

Any ideas?

Thanks,
Jesse



CONFIDENTIALITY NOTICE
This e-mail message and any attachments are only for the use of the intended 
recipient and may contain information that is privileged, confidential or 
exempt from disclosure under applicable law. If you are not the intended 
recipient, any disclosure, distribution or other use of this e-mail message or 
attachments is prohibited. If you have received this e-mail message in error, 
please delete and notify the sender immediately. Thank you.

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

2023-05-31 Thread Grzegorz Grzybek

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
>   mvn:org.apache.karaf.examples/karaf-config-example-features/4.4.3/xml
>
>
>- feature:install karaf-config-example-managed-factory
>
>
>- Copy the attached 'config.xml' file to the 'deploy/' directory
>- Wait about 5 seconds, and notice the following output to the console
>
> New configuration with pid
> org.apache.karaf.example.config.04388423-2d46-4308-8214-3dcd1e0b8fd0
>
> key1 = value1
>
> key2 = value2
>
> org.apache.karaf.features.configKey = org.apache.karaf.example.config-abc
>
> service.factoryPid = org.apache.karaf.example.config
>
> service.pid =
> org.apache.karaf.example.config.04388423-2d46-4308-8214-3dcd1e0b8fd0
>
> 18:42:02.131 INFO [features-3-thread-1] Done.
>
> 18:42:10.999 INFO
> [fileinstall-/Users/jesse/labs/karaf/apache-karaf-4.4.3/etc] Creating
> configuration {org.apache.karaf.example.config~abc} from
> /Users/jesse/labs/karaf/apache-karaf-4.4.3/etc/org.apache.karaf.example.config-abc.cfg
>
> New configuration with pid org.apache.karaf.example.config~abc
>
> felix.fileinstall.filename =
> file:/Users/jesse/labs/karaf/apache-karaf-4.4.3/etc/org.apache.karaf.example.config-abc.cfg
>
> key1 = value1
>
> key2 = value2
>
> org.apache.karaf.features.configKey = org.apache.karaf.example.config-abc
>
> service.factoryPid = org.apache.karaf.example.config
>
> service.pid = org.apache.karaf.example.config~abc
>
>
>
>
>
> Note that the single config results in multiple callbacks under two
> separate pids. This seems isolated to cases where the deploy/ folder is
> used to write the config, and doesn't happen when the configuration is
> manually placed in etc/.
>
>
>
> Following the same instructions with Karaf 4.3.6 has the expected
> behavior. Karaf 4.3.7 and later experience this issue though.
>
>
>
> Any ideas?
>
>
>
> Thanks,
>

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

2023-05-31 Thread Jesse White

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 
mailto: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 mailto:je...@opennms.com>>
Date: Tuesday, May 30, 2023 at 7:11 PM
To: user@karaf.apache.org 
mailto: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 
mvn:org.apache.karaf.examples/karaf-config-example-features/4.4.3/xml

 *   feature:install karaf-config-example-managed-factory

  *   Copy the attached 'config.xml' file to the 'deploy/' directory
  *   Wait about 5 seconds, and notice the following output to the console

New configuration with pid 
or

Re: Frameworks dropping OSGi support

2023-05-31 Thread 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: Frameworks dropping OSGi support

2023-05-31 Thread Jean-Baptiste Onofré

Sorry I missed the answer from Greg :)

I second obviously :)

Regards
JB

On Wed, May 31, 2023 at 1:55 PM Grzegorz Grzybek  wrote:
>
> Hello
>
> Initially (and more precisely 1-2 years ago) when the javax → jakarta 
> migration started to get momentum (partially because of Spring Boot 3 / 
> Spring Framework 6 announcement) I was thinking that the Enterprise OSGi 
> specifications which touch JakartaEE would have to be released all-at-once 
> (JPA, Web, transactions, ...) and I thought it'd be vry hard for the 
> implementations to quickly get new jakarta.* releases.
>
> I was imagining a lot of problems related to compatibility to existing 
> libraries. Karaf features cover a lot of dependencies and there is simply not 
> enough (IMO) manpower to be quick here.
>
> However recently I was tracking OSGi CMPN progress and for example there 
> already exist new Whiteboard specification 
> (https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.servlet.html) 
> (called "Servlet service" now), so OSGi world is not going to lag behind too 
> much.
>
> I think (or I'm biased) that the web parts are the most important here. And 
> Pax Web doesn't yet have a Jakarta friendly release, so I have a branch ready 
> (with slow progress). See 
> https://github.com/ops4j/org.ops4j.pax.web/issues/1802
>
> The point is that there will be NO version the ancient HttpService 
> specification based on jakarta.servlet package. Pax Web has this support deep 
> in its core, so there's fundamental decision to be made - probably Pax Web's 
> extension to org.osgi.service.http.HttpService is going to simply swallow the 
> methods from this interface.
>
> This interface however is used by CXF (cxf-rt-transports-http) and Jolokia 
> and Camel Servlet and these will have to switch to Whiteboard (called 
> "Servlet" in OSGi CMPN 8.1).
>
> I can't tell anything however about JPA for example. These specs in 8.1 
> (which contains migrated Whiteboard specification) do NOT yet moved from 
> javax to jakarta:
>
> JPA: https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jpa.html
> Transaction Control: 
> https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.transaction.control.html
> JTA: https://docs.osgi.org/specification/osgi.cmpn/8.1.0/service.jta.html
>
> So it's still the beginning of the road... Not only there are not CMPN 
> jakarta versions of the above specs, I have no idea about progress at RI side 
> (Apache Aries).
>
> I hope this clears at least some of the confusion here.
>
> regards
> Grzegorz Grzybek
>
> śr., 31 maj 2023 o 13:32 Jochen Walz  
> napisał(a):
>>
>> 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: same configuration registered with multiple PIDs in ManagedServiceFactory

2023-05-31 Thread 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 
> mvn:org.apache.karaf.examples/karaf-config-example-

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

2023-05-31 Thread Grzegorz Grzybek

I personally didn't check with factory pids (dash in the name).
I remember I spotted the problem when dealing with FeatureDeployer (deploy/
folder) for Fuse - https://issues.apache.org/jira/browse/KARAF-6074 (but
not necessarily related to this config problem).

Also from quick search of my history,
https://issues.apache.org/jira/browse/KARAF-7389 was needed to prevent
reading half-written file.

More - tomorrow (CEST) ;)

regards
Grzegorz Grzybek

śr., 31 maj 2023 o 17:25 Jean-Baptiste Onofré  napisał(a):

> 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 {
> >
> > -

Enable/Disable Kar dependency

2023-05-31 Thread jose.garnica.lomeli

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](https://proton.me/) secure email.

Re: Enable/Disable Kar dependency

2023-05-31 Thread 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.

Frameworks dropping OSGi support

Re: Frameworks dropping OSGi support

Re: Frameworks dropping OSGi support

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

Re: Frameworks dropping OSGi support

Re: Frameworks dropping OSGi support

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

Re: same configuration registered with multiple PIDs in ManagedServiceFactory

Enable/Disable Kar dependency

Re: Enable/Disable Kar dependency

12 matches

Site Navigation

Mail list logo

Footer information