RE: Multi-release jar bundles

[Leschke, Scott]

Ok, thx.  I’ll do that before COB.

From: Jean-Baptiste Onofre 
Sent: Friday, March 19, 2021 8:45 AM
To: user@karaf.apache.org
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

Yes, good idea to submit a Jira at Felix. I will check there ;)

Thanks,
Regards
JB


Le 19 mars 2021 à 14:22, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

JB,

I’m curious how to proceed on this.  Should I submit a Jira against Felix?

Regards,
Scott

From: Leschke, Scott mailto:slesc...@medline.com>>
Sent: Wednesday, February 24, 2021 7:31 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi JB,

Just following up on the issue below. I realize this is really a Felix issue, 
so would it be best for me to submit a Jira to that project?  I realize you’re 
attached to that project as well so I don’t want to submit a Jira if it’s 
already been done at some level.

Regards,

Scott

From: Jean-Baptiste Onofre
Sent: Tuesday, January 19, 2021 11:08 AM
To: user
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,

Understood, I will try to submit a PR for them.

Regards
JB

Le 19 janv. 2021 à 15:46, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

SAP is claiming it’s a Karaf/platform issue, (Lack of support for MRJars). For 
what it’s worth, you can find the JDBC driver here: 
https://mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc<https://urldefense.com/v3/__https:/mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc__;!!PoMpmxQzTok3!u96K7v6YQfqnV0XMYyZg1U_V3cdYSocWCHRKbjj-c1MP5P3pKA26R6_i-zwqciM$>
To be clear, the bundle resolves but the AssertionError mentioned occurs when 
you try to run a query.
Scott
From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Tuesday, January 19, 2021 12:23 AM
To: user mailto:user@karaf.apache.org>>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
Not yet, but it looks like SAP driver issue. I guess you can create a Jira at 
SAP.
Regards
JB



Le 19 janv. 2021 à 04:07, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
Hi JB,
I was wondering if you had a chance to takle a look at the issue I mentioned 
previously below? The JDBC driver in question is SAP HANAm file ngdbc-2.7.7.jar 
(or ngdbc-2.5.52.jar as well). Karaf 4.30, openjdk-14.0.2, Windows Server 2016.
Should I create a Felix Jira issue for this?
Regards,
Scott Leschke
From: Leschke, Scott mailto:slesc...@medline.com>>
Sent: Wednesday, December 30, 2020 9:12 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I think you should be able to reproduce it if you can get hold of the driver.
From: Jean-Baptiste Onofre
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
You can try to wrap settings the TCCL, but it seems more a driver issue.
Can I reproduce it easily (just installingg SAP driver for instance) ?
Regards
JB
Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11. It works fine when I run Karaf using JDK 
1.8, but if I try to use a more recent JDK, the driver throws the following
Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]
An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently trie

RE: Multi-release jar bundles

[Leschke, Scott]

JB,

I’m curious how to proceed on this.  Should I submit a Jira against Felix?

Regards,
Scott

From: Leschke, Scott 
Sent: Wednesday, February 24, 2021 7:31 PM
To: user@karaf.apache.org
Subject: RE: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi JB,

Just following up on the issue below. I realize this is really a Felix issue, 
so would it be best for me to submit a Jira to that project?  I realize you’re 
attached to that project as well so I don’t want to submit a Jira if it’s 
already been done at some level.

Regards,

Scott

From: Jean-Baptiste Onofre
Sent: Tuesday, January 19, 2021 11:08 AM
To: user
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,

Understood, I will try to submit a PR for them.

Regards
JB

Le 19 janv. 2021 à 15:46, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

SAP is claiming it’s a Karaf/platform issue, (Lack of support for MRJars). For 
what it’s worth, you can find the JDBC driver here: 
https://mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc<https://urldefense.com/v3/__https:/mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc__;!!PoMpmxQzTok3!u96K7v6YQfqnV0XMYyZg1U_V3cdYSocWCHRKbjj-c1MP5P3pKA26R6_i-zwqciM$>
To be clear, the bundle resolves but the AssertionError mentioned occurs when 
you try to run a query.
Scott
From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Tuesday, January 19, 2021 12:23 AM
To: user mailto:user@karaf.apache.org>>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
Not yet, but it looks like SAP driver issue. I guess you can create a Jira at 
SAP.
Regards
JB


Le 19 janv. 2021 à 04:07, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
Hi JB,
I was wondering if you had a chance to takle a look at the issue I mentioned 
previously below? The JDBC driver in question is SAP HANAm file ngdbc-2.7.7.jar 
(or ngdbc-2.5.52.jar as well). Karaf 4.30, openjdk-14.0.2, Windows Server 2016.
Should I create a Felix Jira issue for this?
Regards,
Scott Leschke
From: Leschke, Scott mailto:slesc...@medline.com>>
Sent: Wednesday, December 30, 2020 9:12 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I think you should be able to reproduce it if you can get hold of the driver.
From: Jean-Baptiste Onofre
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
You can try to wrap settings the TCCL, but it seems more a driver issue.
Can I reproduce it easily (just installingg SAP driver for instance) ?
Regards
JB
Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11. It works fine when I run Karaf using JDK 
1.8, but if I try to use a more recent JDK, the driver throws the following
Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]
An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x. Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?
Thanks and regards,
Scott Leschke

RE: Multi-release jar bundles

[Leschke, Scott]

Hi JB,

Just following up on the issue below. I realize this is really a Felix issue, 
so would it be best for me to submit a Jira to that project?  I realize you’re 
attached to that project as well so I don’t want to submit a Jira if it’s 
already been done at some level.

Regards,

Scott

From: Jean-Baptiste Onofre 
Sent: Tuesday, January 19, 2021 11:08 AM
To: user 
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,

Understood, I will try to submit a PR for them.

Regards
JB


Le 19 janv. 2021 à 15:46, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

SAP is claiming it’s a Karaf/platform issue, (Lack of support for MRJars). For 
what it’s worth, you can find the JDBC driver here: 
https://mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc<https://urldefense.com/v3/__https:/mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc__;!!PoMpmxQzTok3!u96K7v6YQfqnV0XMYyZg1U_V3cdYSocWCHRKbjj-c1MP5P3pKA26R6_i-zwqciM$>
To be clear, the bundle resolves but the AssertionError mentioned occurs when 
you try to run a query.
Scott
From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Tuesday, January 19, 2021 12:23 AM
To: user mailto:user@karaf.apache.org>>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
Not yet, but it looks like SAP driver issue. I guess you can create a Jira at 
SAP.
Regards
JB



Le 19 janv. 2021 à 04:07, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
Hi JB,
I was wondering if you had a chance to takle a look at the issue I mentioned 
previously below? The JDBC driver in question is SAP HANAm file ngdbc-2.7.7.jar 
(or ngdbc-2.5.52.jar as well). Karaf 4.30, openjdk-14.0.2, Windows Server 2016.
Should I create a Felix Jira issue for this?
Regards,
Scott Leschke
From: Leschke, Scott mailto:slesc...@medline.com>>
Sent: Wednesday, December 30, 2020 9:12 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I think you should be able to reproduce it if you can get hold of the driver.
From: Jean-Baptiste Onofre
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Multi-release jar bundles
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,
You can try to wrap settings the TCCL, but it seems more a driver issue.
Can I reproduce it easily (just installingg SAP driver for instance) ?
Regards
JB
Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :
I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11. It works fine when I run Karaf using JDK 
1.8, but if I try to use a more recent JDK, the driver throws the following
Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]
An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x. Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?
Thanks and regards,
Scott Leschke

RE: Multi-release jar bundles

[Leschke, Scott]

SAP is claiming it’s a Karaf/platform issue, (Lack of support for MRJars).  For 
what it’s worth, you can find the JDBC driver here:  
https://mvnrepository.com/artifact/com.sap.cloud.db.jdbc/ngdbc

To be clear, the bundle resolves but the AssertionError mentioned occurs when 
you try to run a query.

Scott

From: Jean-Baptiste Onofre 
Sent: Tuesday, January 19, 2021 12:23 AM
To: user 
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

Not yet, but it looks like SAP driver issue. I guess you can create a Jira at 
SAP.

Regards
JB


Le 19 janv. 2021 à 04:07, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Hi JB,

I was wondering if you had a chance to takle a look at the issue I mentioned 
previously below? The JDBC driver in question is SAP HANAm file ngdbc-2.7.7.jar 
(or ngdbc-2.5.52.jar as well).  Karaf 4.30, openjdk-14.0.2, Windows Server 2016.

Should I create a Felix Jira issue for this?

Regards,

Scott Leschke

From: Leschke, Scott mailto:slesc...@medline.com>>
Sent: Wednesday, December 30, 2020 9:12 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I think you should be able to reproduce it if you can get hold of the driver.

From: Jean-Baptiste Onofre
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

You can try to wrap settings the TCCL, but it seems more a driver issue.

Can I reproduce it easily (just installingg SAP driver for instance) ?

Regards
JB

Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11. It works fine when I run Karaf using JDK 
1.8, but if I try to use a more recent JDK, the driver throws the following

Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]

An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x. Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?

Thanks and regards,

Scott Leschke

RE: Multi-release jar bundles

[Leschke, Scott]

Hi JB,

I was wondering if you had a chance to takle a look at the issue I mentioned 
previously below? The JDBC driver in question is SAP HANAm file ngdbc-2.7.7.jar 
(or ngdbc-2.5.52.jar as well).  Karaf 4.30, openjdk-14.0.2, Windows Server 2016.

Should I create a Felix Jira issue for this?

Regards,

Scott Leschke

From: Leschke, Scott 
Sent: Wednesday, December 30, 2020 9:12 AM
To: user@karaf.apache.org
Subject: RE: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I think you should be able to reproduce it if you can get hold of the driver.

From: Jean-Baptiste Onofre
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

You can try to wrap settings the TCCL, but it seems more a driver issue.

Can I reproduce it easily (just installingg SAP driver for instance) ?

Regards
JB

Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11. It works fine when I run Karaf using JDK 
1.8, but if I try to use a more recent JDK, the driver throws the following

Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]

An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x. Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?

Thanks and regards,

Scott Leschke

RE: Multi-release jar bundles

[Leschke, Scott]

I think you should be able to reproduce it if you can get hold of the driver.

From: Jean-Baptiste Onofre 
Sent: Wednesday, December 30, 2020 12:09 AM
To: user@karaf.apache.org
Subject: Re: Multi-release jar bundles

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

You can try to wrap settings the TCCL, but it seems more a driver issue.

Can I reproduce it easily (just installingg SAP driver for instance) ?

Regards
JB


Le 29 déc. 2020 à 19:31, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11.  It works fine when I run Karaf using 
JDK 1.8, but if I try to use a more recent JDK, the driver throws the following

Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at 
com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at 
com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]

An SAP person says they think the classloader isn’t MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x.  Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?

Thanks and regards,

Scott Leschke

Multi-release jar bundles

[Leschke, Scott]

I have a JDBC driver jar (SAP HANA), that is build both as a bundle and an 
MRJar file supporting JDKs 1.8, 9, 11.  It works fine when I run Karaf using 
JDK 1.8, but if I try to use a more recent JDK, the driver throws the following

Caused by: java.lang.AssertionError: Unexpected Java class loaded under Java 
version 11 (maximum supported version is 8)
at 
com.sap.db.jdbc.DriverSapDB._checkJavaVersion(DriverSapDB.java:2055) ~[?:?]
at 
com.sap.db.jdbc.DriverSapDB.checkJavaVersionMaximum8(DriverSapDB.java:2030) 
~[?:?]
at com.sap.db.jdbc.Driver.(Driver.java:17) ~[?:?]

An SAP person says they think the classloader isn't MRJar aware and is loading 
the incorrect class. I most recently tried this with OpenJDK 14.x.  Since OSGi 
involves lots of classloader magic, might that be the case or might something 
else be going on here?

Thanks and regards,

Scott Leschke

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

JB, here’s the scr .xml.  I will try to put together simplified bundle that 
exhibits the behavior by the weekend.

Thx, Scott


http://www.osgi.org/xmlns/scr/v1.3.0; 
name="com.medline.bam.schedule.ScheduleFactory" immediate="true">
  
  

  
  


From: Jean-Baptiste Onofre 
Sent: Monday, December 14, 2020 11:25 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,

The MANIFEST doesn’t look good to me. For instance, Private-Package doesn’t 
really exists from a framework standpoint.

A the issue comes directly from the framework when it tries to load the bundle 
(nothing related with Karaf here), and I don’t see java.lang import at all in 
your bundle. Can you check the content of SCR XML ?

You mentioned you didn’t change etc/jre.properties or etc/config.properties, so 
java.lang is exported by bundle 0 for sure (the framework).

IMHO, something wrong with bndtools here (I don’t use it).

Can you create a very simple bundle with bndtools and provide to me ? I will 
test.

Regards
JB


Le 15 déc. 2020 à 01:21, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Today, I tried to update one of the bundle on my 4.2.8 installation (my 
production). This if running on Java 1.8 on Windows.  It failed to deploy with 
the following :

2020-12-14T12:14:57,125 | ERROR | fileinstall-C:/BAM | Felix
| 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle 
medline.bam.schedule [167] Unable to update the bundle. 
(org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang)
org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang
   at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) 
[org.apache.felix.framework-5.6.12.jar:?]
….

What this and the issue using 4.3.0 have is that I’m using BndTools 5.2.0 in 
both to generate my bundles.  This is the manifest of the bundle that failed.  
Looks OK to me but perhaps there’s something subtle that shouldn’t be there?  
All input appreciated.

Regards,
Scott

Manifest-Version: 1.0
Bnd-LastModified: 1607977206683
Bundle-ManifestVersion: 2
Bundle-Name: Medline BAM Model Schedule
Bundle-SymbolicName: medline.bam.schedule
Bundle-Version: 1.0.0.202012142020
Created-By: 14.0.2 (Oracle Corporation)
Export-Package: com.medline.bam.api;version="1.0.0";uses:="com.medline
.bam.api.metric,com.medline.bam.api.provider,com.medline.bam.api.repo
rt,com.medline.util.model.identifier,com.medline.util.query.jdbc,com.
medline.util.service,org.slf4j",com.medline.bam.api.metric;version="1
.0.0";uses:="com.medline.bam.api.provider",com.medline.bam.api.provid
er;version="1.0.0";uses:="com.medline.bam.api,com.medline.bam.api.met
ric,com.medline.bam.api.rule,com.medline.bam.api.schedule,com.medline
.util.query.api,com.medline.util.service,org.slf4j",com.medline.bam.a
pi.report;version="1.0.0";uses:="com.medline.bam.api,com.medline.util
.query.api,com.medline.util.query.http,com.medline.util.query.jdbc,co
m.medline.util.service",com.medline.bam.api.rule;version="1.0.0";uses
:="com.medline.bam.api,com.medline.bam.api.metric,com.medline.bam.api
.provider,com.medline.bam.api.schedule",com.medline.bam.api.schedule;
version="1.0.0";uses:="com.medline.util.model"
Git-Descriptor: 23996f2-dirty
Git-SHA: 23996f202ab9237416af1a4c35c209751d907c47
Import-Package: com.medline.bam.api;version="[1.0,2)",com.medline.bam.
api.metric;version="[1.0,2)",com.medline.bam.api.provider;version="[1
.0,2)",com.medline.bam.api.report;version="[1.0,2)",com.medline.bam.a
pi.rule;version="[1.0,2)",com.medline.bam.api.schedule;version="[1.0,
2)",com.medline.util,com.medline.util.model;version="[1.0,2)",com.med
line.util.model.identifier;version="[1.0,2)",com.medline.util.query.a
pi,com.medlin

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Today, I tried to update one of the bundle on my 4.2.8 installation (my 
production). This if running on Java 1.8 on Windows.  It failed to deploy with 
the following :

2020-12-14T12:14:57,125 | ERROR | fileinstall-C:/BAM | Felix
| 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle 
medline.bam.schedule [167] Unable to update the bundle. 
(org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang)
org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang
   at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) 
[org.apache.felix.framework-5.6.12.jar:?]
….

What this and the issue using 4.3.0 have is that I’m using BndTools 5.2.0 in 
both to generate my bundles.  This is the manifest of the bundle that failed.  
Looks OK to me but perhaps there’s something subtle that shouldn’t be there?  
All input appreciated.

Regards,
Scott

Manifest-Version: 1.0
Bnd-LastModified: 1607977206683
Bundle-ManifestVersion: 2
Bundle-Name: Medline BAM Model Schedule
Bundle-SymbolicName: medline.bam.schedule
Bundle-Version: 1.0.0.202012142020
Created-By: 14.0.2 (Oracle Corporation)
Export-Package: com.medline.bam.api;version="1.0.0";uses:="com.medline
.bam.api.metric,com.medline.bam.api.provider,com.medline.bam.api.repo
rt,com.medline.util.model.identifier,com.medline.util.query.jdbc,com.
medline.util.service,org.slf4j",com.medline.bam.api.metric;version="1
.0.0";uses:="com.medline.bam.api.provider",com.medline.bam.api.provid
er;version="1.0.0";uses:="com.medline.bam.api,com.medline.bam.api.met
ric,com.medline.bam.api.rule,com.medline.bam.api.schedule,com.medline
.util.query.api,com.medline.util.service,org.slf4j",com.medline.bam.a
pi.report;version="1.0.0";uses:="com.medline.bam.api,com.medline.util
.query.api,com.medline.util.query.http,com.medline.util.query.jdbc,co
m.medline.util.service",com.medline.bam.api.rule;version="1.0.0";uses
:="com.medline.bam.api,com.medline.bam.api.metric,com.medline.bam.api
.provider,com.medline.bam.api.schedule",com.medline.bam.api.schedule;
version="1.0.0";uses:="com.medline.util.model"
Git-Descriptor: 23996f2-dirty
Git-SHA: 23996f202ab9237416af1a4c35c209751d907c47
Import-Package: com.medline.bam.api;version="[1.0,2)",com.medline.bam.
api.metric;version="[1.0,2)",com.medline.bam.api.provider;version="[1
.0,2)",com.medline.bam.api.report;version="[1.0,2)",com.medline.bam.a
pi.rule;version="[1.0,2)",com.medline.bam.api.schedule;version="[1.0,
2)",com.medline.util,com.medline.util.model;version="[1.0,2)",com.med
line.util.model.identifier;version="[1.0,2)",com.medline.util.query.a
pi,com.medline.util.query.http,com.medline.util.query.jdbc,com.medlin
e.util.service,org.apache.commons.lang3;version="[3.4,4)",org.slf4j
Private-Package: com.medline.bam.schedule
Provide-Capability: osgi.service;objectClass:List="com.medline
.bam.api.schedule.IScheduleFactory";uses:="com.medline.bam.api.schedu
le"
Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.compo
nent)(version>=1.3.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.e
e=JavaSE)(version=1.8))"
Service-Component: OSGI-INF/com.medline.bam.schedule.ScheduleFactory.x
ml
Tool: Bnd-5.2.0.202010142003

From: Jean-Baptiste Onofre 
Sent: Thursday, December 03, 2020 9:52 AM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.
____
Hi Scott,

I’m not able to reproduce your issue (neither on MacOS or Linux (Debian, 
Ubuntu), nor on Jenkins).

I tested with adatjdk and oracle jdk. I will download test with OpenJDK (it 
should be pretty close to Adapt).

Regards
JB


Le 3 déc. 2020 à 16:04, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Hi JB,
I’m curious if you have any info on the is

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Hi JB,

I’m curious if you have any info on the issue below.  I tested using HotSpot 
and got the same result.  As I’ve mentioned, I find this particularly 
perplexing as one of the packages that gets flagged is java.lang.

Is there anything you’d like me to try on my end regarding this?

Scott Leschke

From: Leschke, Scott 
Sent: Monday, November 16, 2020 7:54 AM
To: user@karaf.apache.org
Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM.  Perhaps 
it’s J9.  When I saw this issue previously, with 4.2.10 I believe, I think I 
was using openjdk 11 and J9.

Scott

From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Monday, November 16, 2020 1:13 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I just checked on java.specification.version is 14, so it’s fine.

I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf 
examples).

I’m checking on Windows VM.

Regards
JB

Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]]
 Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
….

Scott

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Yes, I apologize. I’m running openjdk 14.whatever and the OpenJ9 VM.  Perhaps 
it’s J9.  When I saw this issue previously, with 4.2.10 I believe, I think I 
was using openjdk 11 and J9.

Scott

From: Jean-Baptiste Onofre 
Sent: Monday, November 16, 2020 1:13 AM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

I just checked on java.specification.version is 14, so it’s fine.

I also checked with JDK 14.0.1 on Mac and it works fine (at least for Karaf 
examples).

I’m checking on Windows VM.

Regards
JB


Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!q6M6Du7f0xiSnnAzLzvUs3aLfck7r20ezWQc7Q_why5WXrRefvh1fiGcgNFV4xk$>)]]
 Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
….

Scott

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Hi JB,

I was wondering if you have any insight into the issue below?

Scott

From: Leschke, Scott 
Sent: Tuesday, November 03, 2020 10:58 AM
To: user@karaf.apache.org
Subject: RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Yes, this is a relatively recent issue that I also saw after 4.2.8, in 4.2.10 I 
think.

Scott

From: Jean-Baptiste Onofre
Sent: Monday, November 02, 2020 11:19 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

It’s very surprising as Karaf bundles themselves use 
java.io<https://urldefense.com/v3/__http:/java.io__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7k7TB8HGI$>
 (and other JDK packages).

Let me try with a simple bundle dropped in deploy folder.

Regards
JB

Le 2 nov. 2020 à 17:50, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Hi JB,

Sorry for the confusion. The trace is a bit misleading. Yes, that is one of my 
bundles. I added the trace as an example (arbitrarily chosen) since Felix 
outputs the same trace for all bundles the fail to resolve. The bundle I’m 
referring to is a utilities library that sits at the top of the dependency tree 
so the other bundles that refer to that one also can’t resolve as a result.

In the case of the medline.util bundle which I’m referring to, the bundle:diag 
shows a long list of unresolved java.* packages.

2020-11-01T18:47:06,499 | WARN | fileinstall-E:/BAM | fileinstall | 17 - 
org.apache.felix.fileinstall - 3.6.8 | Error while starting bundle: 
file:/E:/BAM/medline.util.jar
org.osgi.framework.BundleException: Unable to resolve medline.util [163](R 
163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)
 Unresolved requirements: [[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)]
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) 
~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) ~[?:?]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260)
 [!/:3.6.8]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233)
 [!/:3.6.8]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221)
 [!/:3.6.8]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515)
 [!/:3.6.8]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
 [!/:3.6.8]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
 [!/:3.6.8]

Scott

From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Sunday, November 01, 2020 11:08 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

In the log, it seems that it’s the package com.medline.osgi which is not 
resolved.

Is it one of your package ?

Regards
JB


Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14. All java.* packages, including java.lang, show 
as Unsatisfied Requriements in bundle:diag output. Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

There was another thing I noticed. I had submitted a Jira on this on an earlier 
release. I think it may even still be open.

In the hot deploy case, I’m on Windows so may just be a Windows thing, the 
“pseudo” bundles get create with version 0.0.0 that map to a folder in the 
deployment hierarchy. So for my application, the deployment hierarchy is at 
E:\BAM.  It has 3 subfolders that contains bundles and/or .cfg files, I’ll call 
them F1, F2, and F3.

For each subfolder, a bundle is created with the names, E_BAM_F1, E_BAM_F2, 
E_BAM_F3. Previous experience shows that these bundles can be uninstalled 
without problems but I believe the issue disappeared and has now come back.

Thanks and regards,

Scott

From: Jean-Baptiste Onofre 
Sent: Monday, November 02, 2020 11:19 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

It’s very surprising as Karaf bundles themselves use 
java.io<https://urldefense.com/v3/__http:/java.io__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7k7TB8HGI$>
 (and other JDK packages).

Let me try with a simple bundle dropped in deploy folder.

Regards
JB


Le 2 nov. 2020 à 17:50, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Hi JB,

Sorry for the confusion. The trace is a bit misleading. Yes, that is one of my 
bundles.  I added the trace as an example (arbitrarily chosen) since Felix 
outputs the same trace for all bundles the fail to resolve. The bundle I’m 
referring to is a utilities library that sits at the top of the dependency tree 
so the other bundles that refer to that one also can’t resolve as a result.

In the case of the medline.util bundle which I’m referring to, the bundle:diag 
shows a long list of unresolved java.* packages.

2020-11-01T18:47:06,499 | WARN  | fileinstall-E:/BAM | fileinstall  
| 17 - org.apache.felix.fileinstall - 3.6.8 | Error while starting 
bundle: file:/E:/BAM/medline.util.jar
org.osgi.framework.BundleException: Unable to resolve medline.util [163](R 
163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)
 Unresolved requirements: [[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
   at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
 [!/:3.6.8]

Scott

From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Sunday, November 01, 2020 11:08 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

In the log, it seems that it’s the package com.medline.osgi which is not 
resolved.

Is it one of your package ?

Regards
JB



Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Yes, this is a relatively recent issue that I also saw after 4.2.8, in 4.2.10 I 
think.

Scott

From: Jean-Baptiste Onofre 
Sent: Monday, November 02, 2020 11:19 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

It’s very surprising as Karaf bundles themselves use 
java.io<https://urldefense.com/v3/__http:/java.io__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7k7TB8HGI$>
 (and other JDK packages).

Let me try with a simple bundle dropped in deploy folder.

Regards
JB


Le 2 nov. 2020 à 17:50, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Hi JB,

Sorry for the confusion. The trace is a bit misleading. Yes, that is one of my 
bundles.  I added the trace as an example (arbitrarily chosen) since Felix 
outputs the same trace for all bundles the fail to resolve. The bundle I’m 
referring to is a utilities library that sits at the top of the dependency tree 
so the other bundles that refer to that one also can’t resolve as a result.

In the case of the medline.util bundle which I’m referring to, the bundle:diag 
shows a long list of unresolved java.* packages.

2020-11-01T18:47:06,499 | WARN  | fileinstall-E:/BAM | fileinstall  
| 17 - org.apache.felix.fileinstall - 3.6.8 | Error while starting 
bundle: file:/E:/BAM/medline.util.jar
org.osgi.framework.BundleException: Unable to resolve medline.util [163](R 
163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)
 Unresolved requirements: [[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!p5QOKC-0IGXdkzWH3NoHzAhyMBpPpKQbVq2z2no-VUOfn8tMibUcPp7kr8iQcZ0$>)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
   at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
 [!/:3.6.8]

Scott

From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Sunday, November 01, 2020 11:08 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

In the log, it seems that it’s the package com.medline.osgi which is not 
resolved.

Is it one of your package ?

Regards
JB



Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!v7JOYm60VJQSfZebzVzJUcZnPyswpRGqWRrVzf64Rvn6BasJ8h03hmiJK0e1vag$>)]]
 Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&

RE: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Hi JB,

Sorry for the confusion. The trace is a bit misleading. Yes, that is one of my 
bundles.  I added the trace as an example (arbitrarily chosen) since Felix 
outputs the same trace for all bundles the fail to resolve. The bundle I’m 
referring to is a utilities library that sits at the top of the dependency tree 
so the other bundles that refer to that one also can’t resolve as a result.

In the case of the medline.util bundle which I’m referring to, the bundle:diag 
shows a long list of unresolved java.* packages.

2020-11-01T18:47:06,499 | WARN  | fileinstall-E:/BAM | fileinstall  
| 17 - org.apache.felix.fileinstall - 3.6.8 | Error while starting 
bundle: file:/E:/BAM/medline.util.jar
org.osgi.framework.BundleException: Unable to resolve medline.util [163](R 
163.0): missing requirement [medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io) Unresolved requirements: [[medline.util [163](R 
163.0)] osgi.wiring.package; (osgi.wiring.package=java.io)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
   at 
org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998) ~[?:?]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
 [!/:3.6.8]
   at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
 [!/:3.6.8]

Scott

From: Jean-Baptiste Onofre 
Sent: Sunday, November 01, 2020 11:08 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* 
packages

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

In the log, it seems that it’s the package com.medline.osgi which is not 
resolved.

Is it one of your package ?

Regards
JB


Le 2 nov. 2020 à 01:48, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!v7JOYm60VJQSfZebzVzJUcZnPyswpRGqWRrVzf64Rvn6BasJ8h03hmiJK0e1vag$>)]]
 Unresolved requirements: [[medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]
….

Scott

Karaf 4.3.0: Bundles don't resolve because of unsatisfied java.* packages

[Leschke, Scott]

Karaf 4.3.0 on Windows, JDK 14.   All java.* packages, including java.lang, 
show as Unsatisfied Requriements in bundle:diag output.  Setting
karaf.framework=equinox
yields similar results.

org.osgi.framework.BundleException: Unable to resolve medline.bam.provider.jdbc 
[181](R 181.0): missing requirement [medline.bam.provider.jdbc [181](R 181.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0))) 
[caused by: Unable to resolve medline.osgi [169](R 169.0): missing requirement 
[medline.osgi [169](R 169.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.util.service)(version>=1.0.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve medline.util [163](R 163.0): missing requirement 
[medline.util [163](R 163.0)] osgi.wiring.package; 
(osgi.wiring.package=java.io)]] Unresolved requirements: 
[[medline.bam.provider.jdbc [181](R 181.0)] osgi.wiring.package; 
(&(osgi.wiring.package=com.medline.osgi)(version>=1.0.0)(!(version>=2.0.0)))]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4368) ~[?:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2281) 
~[?:?]


Scott

Karaf 4.3.0?

[Leschke, Scott]

I'm not seeing it listed under the Karaf Releases anymore at all.  It's not 
showing as either "Released" or "Unreleased".
Seems odd.  Still seeing a 4.3.1 release showing though.  What's up with that?  
Will 4.3.1 take the place of 4.3.0?

Scott

RE: Manifest import problems

[Leschke, Scott]

Never mind. I see it’s just
config.properties/karaf.framework

Scott

From: Leschke, Scott
Sent: Saturday, October 17, 2020 11:36 AM
To: 'user@karaf.apache.org' 
Subject: RE: Manifest import problems

Hi JB,

Yes it does appear to be coming from Felix.

I have not tried Equinox but will do that.  In what .cfg file would I do ithis?

I checked and am not accidentally exporting any of the java.* packages.

Thanks,

Scott

From: Jean-Baptiste Onofre mailto:j...@nanthrax.net>>
Sent: Friday, October 16, 2020 11:18 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Manifest import problems

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

It seems to come directly from the Felix framework.

Did you try with equinox ?

Maybe you are exporting (by mistake) 
java.io<https://urldefense.com/v3/__http:/java.io__;!!PoMpmxQzTok3!ssFmKd2T8H3_wsxtA5gWHuSI88T1gulo0NZb9y_givYLX-DPH7dbuHLPsxPSPDE$>
 and java.lang packages ?

Regards
JB


Le 16 oct. 2020 à 22:23, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

I’m getting the following with Karaf 4.2.9 and the latest BndTools 5.2.0REL. 
I’m confused by what’s going on here.  Obviously importing of java.* packages 
is still required, or at least allowed.
This first stack trace is a WARN in the log while the second one is an ERROR.  
Java 11 on Windows if that matters.

org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!ssFmKd2T8H3_wsxtA5gWHuSI88T1gulo0NZb9y_givYLX-DPH7dbuHLPkTKniQk$>
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[?:?]
at 
org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) ~[?:?]
at 
org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) ~[?:?]
….

org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.(BundleImpl.java:113) ~[?:?]
at 
org.apache.felix.framework.Felix.installBundle(Felix.java:3042) ~[?:?]
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
 ~[?:?]
….

Thanks in advance,

Scott

RE: Manifest import problems

[Leschke, Scott]

Hi JB,

Yes it does appear to be coming from Felix.

I have not tried Equinox but will do that.  In what .cfg file would I do ithis?

I checked and am not accidentally exporting any of the java.* packages.

Thanks,

Scott

From: Jean-Baptiste Onofre 
Sent: Friday, October 16, 2020 11:18 PM
To: user@karaf.apache.org
Subject: Re: Manifest import problems

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Scott,

It seems to come directly from the Felix framework.

Did you try with equinox ?

Maybe you are exporting (by mistake) 
java.io<https://urldefense.com/v3/__http:/java.io__;!!PoMpmxQzTok3!ssFmKd2T8H3_wsxtA5gWHuSI88T1gulo0NZb9y_givYLX-DPH7dbuHLPsxPSPDE$>
 and java.lang packages ?

Regards
JB



Le 16 oct. 2020 à 22:23, Leschke, Scott 
mailto:slesc...@medline.com>> a écrit :

I’m getting the following with Karaf 4.2.9 and the latest BndTools 5.2.0REL. 
I’m confused by what’s going on here.  Obviously importing of java.* packages 
is still required, or at least allowed.
This first stack trace is a WARN in the log while the second one is an ERROR.  
Java 11 on Windows if that matters.

org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.io<https://urldefense.com/v3/__http:/java.io/__;!!PoMpmxQzTok3!ssFmKd2T8H3_wsxtA5gWHuSI88T1gulo0NZb9y_givYLX-DPH7dbuHLPkTKniQk$>
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[?:?]
at 
org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) ~[?:?]
at 
org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) ~[?:?]
….

org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.(BundleImpl.java:113) ~[?:?]
at 
org.apache.felix.framework.Felix.installBundle(Felix.java:3042) ~[?:?]
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
 ~[?:?]
….

Thanks in advance,

Scott

Manifest import problems

[Leschke, Scott]

I'm getting the following with Karaf 4.2.9 and the latest BndTools 5.2.0REL. 
I'm confused by what's going on here.  Obviously importing of java.* packages 
is still required, or at least allowed.
This first stack trace is a WARN in the log while the second one is an ERROR.  
Java 11 on Windows if that matters.

org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.io
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1219) ~[?:?]
at 
org.apache.felix.framework.Felix.updateBundle(Felix.java:2388) ~[?:?]
at 
org.apache.felix.framework.BundleImpl.update(BundleImpl.java:1018) ~[?:?]


org.osgi.framework.BundleException: Importing java.* packages not allowed: 
java.lang
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.normalizeImportClauses(ManifestParser.java:349)
 ~[?:?]
at 
org.apache.felix.framework.util.manifestparser.ManifestParser.(ManifestParser.java:181)
 ~[?:?]
at 
org.apache.felix.framework.BundleRevisionImpl.(BundleRevisionImpl.java:117)
 ~[?:?]
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1282) 
~[?:?]
at 
org.apache.felix.framework.BundleImpl.(BundleImpl.java:113) ~[?:?]
at 
org.apache.felix.framework.Felix.installBundle(Felix.java:3042) ~[?:?]
at 
org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:167)
 ~[?:?]


Thanks in advance,

Scott

RE: javax.mail bundle won't resolve under Java 8

[Leschke, Scott]

Thanks, that works, as I guess I’d expect it to. I’ve just never needed to do 
that before nor does my production machine have that specified.

This started out of the blue fairly recently but I can’t say exactly when 
because unlike the production machine, the test machine doesn’t run 
continuously so I don’t know exactly when things starting going weird. It was 
fairly obvious that some of the security related stuff has changed so I can 
only assume it’s somehow related to that.

From: Leschke, Scott 
Sent: Tuesday, June 02, 2020 8:07 PM
To: user@karaf.apache.org
Subject: RE: javax.mail bundle won't resolve under Java 8

I’ve never had to do that before but I’ll give it a try.  Thanks so much.

Any other suggestions / thoughts?

From: Davi Baldin Tavares mailto:davi.bal...@gmail.com>>
Sent: Tuesday, June 02, 2020 6:08 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: javax.mail bundle won't resolve under Java 8

Hí,

In my case I have to add javax.activation in config.properties to get mail 
working, just like this:

Edit etc/config.properties and add javax.activation in the 
org.osgi.framework.system.packages.extra



<>



#

# Extra packages appended after standard packages

#

org.osgi.framework.system.packages.extra = \

org.apache.karaf.branding, \

javax.activation, \

sun.misc, \

Em ter., 2 de jun. de 2020 às 16:55, Leschke, Scott 
mailto:slesc...@medline.com>> escreveu:
Question. What change in my environment could cause a bundle to fail to 
resolve?  I’ve been using bundle javax.mail-1.5.6.jar for many months with 
Karaf 4.2.8 and OpenJDK 8.  It would appear that something was changed in my VM 
(Win 2016), some security settings at a minimum, some weeks ago and now I’m 
seeing various odd behavior, one of which is that the mail bundle no longer 
resolves but appears to fail looking for javax.activation.  I’m hoping somebody 
might help me narrow the scope of what may be causing this so that I can get 
the security guys to undo whatever it is they may have done.

This is dev/test box, my production VM is running the same setup without issues 
which is why I’m fairly certain that it’s an environment change.

2020-06-02T13:47:42,753 | ERROR | FelixStartLevel  | Felix  
  | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle 
com.sun.mail.javax.mail [44] Error starting 
file:/E:/Karaf/apache-karaf-4.2.8/deploy/javax.mail-1.5.6.jar 
(org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)])
org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2119) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) 
[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [org.apache.felix.framework-5.6.12.jar:?]

Regards,

Scott




--
Davi Baldin Tavares
(Consultoria e Serviços em T.I.)
Fone: (19) 9-9757-5166
E-mail: davi.bal...@gmail.com<mailto:davi.bal...@gmail.com>

RE: javax.mail bundle won't resolve under Java 8

[Leschke, Scott]

I’ve never had to do that before but I’ll give it a try.  Thanks so much.

Any other suggestions / thoughts?

From: Davi Baldin Tavares 
Sent: Tuesday, June 02, 2020 6:08 PM
To: user@karaf.apache.org
Subject: Re: javax.mail bundle won't resolve under Java 8

Hí,

In my case I have to add javax.activation in config.properties to get mail 
working, just like this:

Edit etc/config.properties and add javax.activation in the 
org.osgi.framework.system.packages.extra



<>



#

# Extra packages appended after standard packages

#

org.osgi.framework.system.packages.extra = \

org.apache.karaf.branding, \

javax.activation, \

sun.misc, \

Em ter., 2 de jun. de 2020 às 16:55, Leschke, Scott 
mailto:slesc...@medline.com>> escreveu:
Question. What change in my environment could cause a bundle to fail to 
resolve?  I’ve been using bundle javax.mail-1.5.6.jar for many months with 
Karaf 4.2.8 and OpenJDK 8.  It would appear that something was changed in my VM 
(Win 2016), some security settings at a minimum, some weeks ago and now I’m 
seeing various odd behavior, one of which is that the mail bundle no longer 
resolves but appears to fail looking for javax.activation.  I’m hoping somebody 
might help me narrow the scope of what may be causing this so that I can get 
the security guys to undo whatever it is they may have done.

This is dev/test box, my production VM is running the same setup without issues 
which is why I’m fairly certain that it’s an environment change.

2020-06-02T13:47:42,753 | ERROR | FelixStartLevel  | Felix  
  | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle 
com.sun.mail.javax.mail [44] Error starting 
file:/E:/Karaf/apache-karaf-4.2.8/deploy/javax.mail-1.5.6.jar 
(org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)])
org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2119) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) 
[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [org.apache.felix.framework-5.6.12.jar:?]

Regards,

Scott




--
Davi Baldin Tavares
(Consultoria e Serviços em T.I.)
Fone: (19) 9-9757-5166
E-mail: davi.bal...@gmail.com<mailto:davi.bal...@gmail.com>

javax.mail bundle won't resolve under Java 8

[Leschke, Scott]

Question. What change in my environment could cause a bundle to fail to 
resolve?  I've been using bundle javax.mail-1.5.6.jar for many months with 
Karaf 4.2.8 and OpenJDK 8.  It would appear that something was changed in my VM 
(Win 2016), some security settings at a minimum, some weeks ago and now I'm 
seeing various odd behavior, one of which is that the mail bundle no longer 
resolves but appears to fail looking for javax.activation.  I'm hoping somebody 
might help me narrow the scope of what may be causing this so that I can get 
the security guys to undo whatever it is they may have done.

This is dev/test box, my production VM is running the same setup without issues 
which is why I'm fairly certain that it's an environment change.

2020-06-02T13:47:42,753 | ERROR | FelixStartLevel  | Felix  
  | 5 - org.ops4j.pax.logging.pax-logging-api - 1.11.4 | Bundle 
com.sun.mail.javax.mail [44] Error starting 
file:/E:/Karaf/apache-karaf-4.2.8/deploy/javax.mail-1.5.6.jar 
(org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)])
org.osgi.framework.BundleException: Unable to resolve com.sun.mail.javax.mail 
[44](R 44.0): missing requirement [com.sun.mail.javax.mail [44](R 44.0)] 
osgi.wiring.package; (osgi.wiring.package=javax.activation) Unresolved 
requirements: [[com.sun.mail.javax.mail [44](R 44.0)] osgi.wiring.package; 
(osgi.wiring.package=javax.activation)]
   at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4149) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at org.apache.felix.framework.Felix.startBundle(Felix.java:2119) 
~[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) 
[org.apache.felix.framework-5.6.12.jar:?]
   at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [org.apache.felix.framework-5.6.12.jar:?]

Regards,

Scott

Question regarding Karaf 4.2.8

[Leschke, Scott]

I've been running 4.2.8 for months (on Win64) without any issues but after I 
did a reinstall on my test system last week, Karaf comes up with many of the 
commands not being recognized, like the "bundle" commands, "source" and 
"logout" for example.  Since this issue didn't exist when I originally 
installed I'm wondering what might could cause this to occur now. The log 
doesn't show anything out of the ordinary.

As a sanity check, I tried dropping back to v4.2.7 and get the same behavior. 
I'm thinking that some Karaf dependencies have been updated that could be 
causing this even though the version hasn't changed but I'm also wondering if 
something in my environment could cause it.

Thoughts?

Scott

RE: Karaf 4.2.5 Jetty client

[Leschke, Scott]

I'm curious if anybody has any thoughts on my message below.  I'm I setting up 
for HTTPS correctly?

Regards,

Scott

From: Leschke, Scott 
Sent: Friday, June 21, 2019 9:16 AM
To: user@karaf.apache.org
Subject: RE: Karaf 4.2.5 Jetty client

For the realm, I'm using an arbitrary string. Is there a specific realm I 
should be using? That whole realm thing confuses me a bit, I'm unclear as to 
how it's used.

Scott

From: Francois Papon
Sent: Thursday, June 20, 2019 11:04 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.2.5 Jetty client


Hi Scott,

Are you using the Karaf realm?

I'm not sure how the Jetty client is connected to the authentication store.

regards,

François

fpa...@apache.org<mailto:fpa...@apache.org>


Le 20/06/2019 à 20:23, Leschke, Scott a écrit :
I realize this isn't strictly a Karaf question but I'm having trouble 
authenticating using the Jetty client in Karaf 4.2.5. I'm getting a 401 from a 
server (on a GET) that I'm unable to resolve even though I've verified that the 
user/pwd I have is correct using both Chrome and Postman.

The code I'm using to setup the client is as shown below. To the best of my 
knowledge this is correct yet I'm still getting a 401.
Any help on this would be greatly appreciated.

client = new HttpClient(new SslContextFactory (true));
client.start();

... elsewhere 

AuthenticationStore auths = getClient().getAuthenticationStore();
String authRealm = "Any";

if (auths.findAuthentication("Basic", uri, authRealm) != null) return;

auths.addAuthentication(new BasicAuthentication(uri, authRealm, "myUserName", 
"myPassword");

RE: Karaf 4.2.5 Jetty client

[Leschke, Scott]

For the realm, I'm using an arbitrary string.  Is there a specific realm I 
should be using?  That whole realm thing confuses me a bit, I'm unclear as to 
how it's used.

Scott

From: Francois Papon 
Sent: Thursday, June 20, 2019 11:04 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.2.5 Jetty client


Hi Scott,

Are you using the Karaf realm?

I'm not sure how the Jetty client is connected to the authentication store.

regards,

François

fpa...@apache.org<mailto:fpa...@apache.org>
Le 20/06/2019 à 20:23, Leschke, Scott a écrit :
I realize this isn't strictly a Karaf question but I'm having trouble 
authenticating using the Jetty client in Karaf 4.2.5.  I'm getting a 401 from a 
server (on a GET) that I'm unable to resolve even though I've verified that the 
user/pwd I have is correct using both Chrome and Postman.

The code I'm using to setup the client is as shown below.  To the best of my 
knowledge this is correct yet I'm still getting a 401.
Any help on this would be greatly appreciated.

client = new HttpClient(new SslContextFactory (true));
client.start();

...  elsewhere 

AuthenticationStore auths = getClient().getAuthenticationStore();
String authRealm  = "Any";

if (auths.findAuthentication("Basic", uri, authRealm) != null) return;

auths.addAuthentication(new BasicAuthentication(uri, authRealm, "myUserName", 
"myPassword");

Karaf 4.2.5 Jetty client

[Leschke, Scott]

I realize this isn't strictly a Karaf question but I'm having trouble 
authenticating using the Jetty client in Karaf 4.2.5.  I'm getting a 401 from a 
server (on a GET) that I'm unable to resolve even though I've verified that the 
user/pwd I have is correct using both Chrome and Postman.

The code I'm using to setup the client is as shown below.  To the best of my 
knowledge this is correct yet I'm still getting a 401.
Any help on this would be greatly appreciated.

client = new HttpClient(new SslContextFactory (true));
client.start();

...  elsewhere 

AuthenticationStore auths = getClient().getAuthenticationStore();
String authRealm  = "Any";

if (auths.findAuthentication("Basic", uri, authRealm) != null) return;

auths.addAuthentication(new BasicAuthentication(uri, authRealm, "myUserName", 
"myPassword");

Transaction feature in 4.3.0

[Leschke, Scott]

I'm curious if the Transaction feature will install the Transaction Control 
service when 4.3.0 drops?

RE: Missing .cfg file?

[Leschke, Scott]

Of course, I should have thought about that before I said something.  I changed 
an install script I have and led myself to believe the file disappeared (or was 
no longer needed/desired because everything in it was defaulted).

Regards,

Scott

From: Jean-Baptiste Onofré 
Sent: Wednesday, February 20, 2019 12:07 AM
To: user@karaf.apache.org
Subject: Re: Missing .cfg file?

Hi Scott
Pax web cfg file is not present by default in the standard distribution. It 
will come when installing the http feature.
Regarding the file content, I will add (commented) the SSL part in pax web.
Regards
JB
Le 19 févr. 2019, à 23:51, "Leschke, Scott" 
mailto:slesc...@medline.com>> a écrit:
It looks like there isn’t an etc/org.ops4j.pax.web.cfg in the Windows distro of 
Karaf 4.2.3.  I’m guessing this isn’t by design although I could be wrong.
If I’m not wrong, might I suggest that you consider adding the SSL related 
properties to the file as well, with appropriate defaults of course.


org.osgi.service.http.enabled=true
org.osgi.service.https.enabled=false
org.osgi.service.http.secure.enabled=false
org.osgi.service.http.port.secure=8443


#org.ops4j.pax.web.ssl.keystore=
#org.ops4j.pax.web.ssl.password=
#org.ops4j.pax.web.ssl.keypassword=

Missing .cfg file?

[Leschke, Scott]

It looks like there isn't an etc/org.ops4j.pax.web.cfg in the Windows distro of 
Karaf 4.2.3.  I'm guessing this isn't by design although I could be wrong.
If I'm not wrong, might I suggest that you consider adding the SSL related 
properties to the file as well, with appropriate defaults of course.

org.osgi.service.http.enabled=true
org.osgi.service.https.enabled=false
org.osgi.service.http.secure.enabled=false
org.osgi.service.http.port.secure=8443

#org.ops4j.pax.web.ssl.keystore=
#org.ops4j.pax.web.ssl.password=
#org.ops4j.pax.web.ssl.keypassword=

SSL with Karaf

[Leschke, Scott]

I'm trying to get HTTPS working with Karaf and I'm looking at the following 
page:  https://karaf.apache.org/manual/latest/webcontainer

I created a keystore using the following command:
keytool -genkey -alias myapp -storetype pkcs12 -keystore .keystore.p12

I'm using the following org.ops4j.pax.web.cfg file

org.osgi.service.http.port=8181
javax.servlet.context.tempdir=${karaf.data}/pax-web-jsp
org.ops4j.pax.web.config.file=${karaf.etc}/jetty.xml
org.apache.karaf.features.configKey = org.ops4j.pax.web

org.osgi.service.http.enabled=false
org.osgi.service.https.enabled=true
org.osgi.service.http.port.secure=8443
org.osgi.service.http.secure.enabled=true

org.ops4j.pax.web.ssl.keystore=${karaf.home}/../.keystore.p12
org.ops4j.pax.web.ssl.password= MYSTOREPWD
org.ops4j.pax.web.ssl.keypassword=MYSTOREPWD


It seems that no matter what I try the browser (Chrome) gives me the following. 
 I've tried various things I've found online but to no avail.
Anybody have recommendations?

This site can't provide a secure connection
mysrv1 uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hide details
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher 
suite.

RE: Apache Karaf 4.2.2 on Windows platform

[Leschke, Scott]

Hi Nicolas,

I submitted a ticket on this a number of weeks ago and I know JB is looking 
into it.

Regards,

Scott Leschke

-Original Message-
From: DUTERTRY Nicolas  
Sent: Tuesday, January 22, 2019 10:29 AM
To: user@karaf.apache.org
Subject: RE: Apache Karaf 4.2.2 on Windows platform

Hi Jean-Baptiste,

I'm on Windows 10.
I've installed a fresh Karaf 4.2.2 and I have issues with client.bat. Pressing 
"Return" or "Backspace" have not effect, so the console is not usable.

Regards,
--
Nicolas Dutertry
-Message d'origine-
De : Jean-Baptiste Onofré  Envoyé : vendredi 18 janvier 2019 
14:14 À : user@karaf.apache.org; Karaf Dev  Objet : 
Apache Karaf 4.2.2 on Windows platform

Hi guys,

I just started a series of test using Karaf 4.2.2 on Windows 10.

I freshly installed a Windows 10 machine, where I also installed Oracle JDK 8 
and a fresh Karaf 4.2.2.

I had some warning when extracting Karaf (long path in examples folder, which 
is not a big deal).

The first manual tests work good: no problem of color, tab, or whatever.

For the Windows user, can you please share with me the issues you have and on 
which Windows version ?

Thanks,
Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

FileInstall exception in latest snapshot

[Leschke, Scott]

The following exception occurs repeatedly in the latest 4.2.3-SNAPSHOT.  This 
appears to be a regression.


2019-01-02T14:17:03,171 | ERROR | fileinstall-C:/BAM | fileinstall  
| 10 - org.apache.felix.fileinstall - 3.6.4 | In main loop, we have 
serious trouble
java.nio.file.ClosedWatchServiceException: null
at 
sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80) ~[?:?]
at 
sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
at 
org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163) 
~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
 ~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
 [10:org.apache.felix.fileinstall:3.6.4]
2019-01-02T14:17:03,190 | ERROR | fileinstall-C:/BAM | fileinstall  
| 10 - org.apache.felix.fileinstall - 3.6.4 | In main loop, we have 
serious trouble
java.nio.file.ClosedWatchServiceException: null
at 
sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80) ~[?:?]
at 
sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
at 
org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163) 
~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
 ~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
 [10:org.apache.felix.fileinstall:3.6.4]

RE: Update (I spoke too soon)

[Leschke, Scott]

I spoke too soon.  I've seen the hang issue I thought was resolved.  I believe 
it's only related to running inside the console (on Windows) although I'm not 
100% sure.  I'll create a Jira first chance I get.  Here's the stack dump.

2018-12-28 11:50:30
Full thread dump OpenJDK 64-Bit Server VM (11.0.1+13 mixed mode):

Threads class SMR info:
_java_thread_list=0x018426187c90, length=104, elements={
0x01840a311000, 0x018424ca8000, 0x018424cb2000, 0x018424cf6800,
0x018424cfb800, 0x018424d00800, 0x01842560c000, 0x01842565b800,
0x01842569e000, 0x01842596e000, 0x018425bc2000, 0x018425c64800,
0x01842768, 0x018427489000, 0x018427335800, 0x0184261d0800,
0x018426159800, 0x018427508800, 0x018427e18000, 0x018427e17000,
0x018427e16800, 0x018427e1c000, 0x018427e19800, 0x018427e1d000,
0x018427e18800, 0x018427e1a800, 0x018427e1b000, 0x018427d25800,
0x018427d2c000, 0x018427d28800, 0x018427d2a000, 0x018427d27800,
0x018427d2b000, 0x018427d2c800, 0x018427d29800, 0x018427d3,
0x018427d2e800, 0x018427d30800, 0x018427d31800, 0x018427d27000,
0x018428962000, 0x018428963000, 0x018428965800, 0x018428966000,
0x018428967000, 0x018428961800, 0x01842896a800, 0x01842896d800,
0x018428969800, 0x018428968800, 0x01842896b000, 0x018428968000,
0x01842896c800, 0x01842896e800, 0x01842897, 0x01842896c000,
0x01842896f000, 0x018428b51000, 0x018428b51800, 0x018428b52800,
0x018428b53800, 0x018428b5, 0x018428b57800, 0x018428b5a800,
0x018428b58800, 0x018428b5a000, 0x018428b5c800, 0x018427d34000,
0x018428963800, 0x018425e01000, 0x018425dfe000, 0x018425e02000,
0x018425e07800, 0x018425e09000, 0x018425e03800, 0x018425e0b000,
0x018425e06000, 0x018425e0c800, 0x018427d26000, 0x018428b5b800,
0x01842821a000, 0x018428216800, 0x018428218000, 0x018428219000,
0x018428214000, 0x018428217800, 0x018428216000, 0x018428215000,
0x01842821e000, 0x018428221000, 0x01842821c800, 0x01842821d000,
0x01842821f000, 0x01842b111000, 0x01842b10b000, 0x01842b10c800,
0x01842b111800, 0x01842b10f000, 0x01842b112800, 0x01842b10d800,
0x01842b113000, 0x01842b10e800, 0x01842b115000, 0x01842b114000
}

"main" #1 prio=5 os_prio=0 cpu=1953.13ms elapsed=1207.30s 
tid=0x01840a311000 nid=0x13d8 in Object.wait()  [0x0006cacff000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.1/Native Method)
- waiting on <0xe063fa00> (a 
org.apache.felix.framework.util.ThreadGate)
at org.apache.felix.framework.util.ThreadGate.await(ThreadGate.java:79)
- waiting to re-lock in wait() <0xe063fa00> (a 
org.apache.felix.framework.util.ThreadGate)
at org.apache.felix.framework.Felix.waitForStop(Felix.java:1075)
at org.apache.karaf.main.Main.awaitShutdown(Main.java:641)
at org.apache.karaf.main.Main.main(Main.java:188)

   Locked ownable synchronizers:
- None

"Reference Handler" #2 daemon prio=10 os_prio=2 cpu=15.63ms elapsed=1207.24s 
tid=0x018424ca8000 nid=0x2e4 waiting on condition  [0x0006cb3ff000]
   java.lang.Thread.State: RUNNABLE
at 
java.lang.ref.Reference.waitForReferencePendingList(java.base@11.0.1/Native 
Method)
at 
java.lang.ref.Reference.processPendingReferences(java.base@11.0.1/Reference.java:241)
at 
java.lang.ref.Reference$ReferenceHandler.run(java.base@11.0.1/Reference.java:213)

   Locked ownable synchronizers:
- None

"Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=1207.24s 
tid=0x018424cb2000 nid=0x130c in Object.wait()  [0x0006cb4fe000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.1/Native Method)
- waiting on 
at 
java.lang.ref.ReferenceQueue.remove(java.base@11.0.1/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0xe003c408> (a 
java.lang.ref.ReferenceQueue$Lock)
at 
java.lang.ref.ReferenceQueue.remove(java.base@11.0.1/ReferenceQueue.java:176)
at 
java.lang.ref.Finalizer$FinalizerThread.run(java.base@11.0.1/Finalizer.java:170)

   Locked ownable synchronizers:
- None

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=1207.21s 
tid=0x018424cf6800 nid=0x15b0 runnable  [0x]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
- None

"Attach Listener" #5 daemon prio=5 os_prio=2 cpu=0.00ms elapsed=1207.21s 
tid=0x018424cfb800 nid=0x131c waiting on condition  [0x]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
- None

"C2 CompilerThread0" #6 daemon 

RE: Update

[Leschke, Scott]

Thanks JB.  A quick update would be appreciated. I have a fix I need to get out 
and I'd prefer to avoid using a snapshot release for it if possible.

One last thing, some time ago I mentioned that I have a deployment folder 
hierarchy and I've noticed that pseudo-bundles, for lack of a better term, get 
created that are associated with folders in the hierarchy. This is relatively 
recent behavior that I thought might disappear again with the 4.2.2 release but 
I see that it's still there.

I created a Jira for it a while ago, FELIX-5986.

https://issues.apache.org/jira/projects/FELIX/issues/FELIX-5986?filter=updatedrecently

Regards,

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, December 26, 2018 11:36 PM
To: user@karaf.apache.org
Subject: Re: Update

Thanks for the update.

Regarding this fix and other fixes I did last week, I think I will cut a
4.2.3 pretty soon.

Regards
JB

On 27/12/2018 01:17, Freeman Fang wrote:
> Hi Scott,
> 
> Thanks for the update!
> 
> Cheers
> －
> Freeman(Yue) Fang
> 
> Red Hat, Inc.
> 
> 
> 
> 
> 
>> On Dec 27, 2018, at 7:06 AM, Leschke, Scott > <mailto:slesc...@medline.com>> wrote:
>>
>> For what it’s worth, a few weeks ago I reported that I was seeing the 
>> Karaf console hang with version 4.2.1 under Windows.  I far as I can 
>> tell, this issue appears to be resolved with the 4.2.3_SNAPSHOT 
>> release that contains the recent karaf.bat change.
>>  
>> Regards,
>>  
>> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Update

[Leschke, Scott]

Just to be clear, the karaf.bat change did not fix that issue as it was 
entirely different.  Just wanted to say that the issue APPEARS to have been 
resolved by something that was done. I can't be entirely sure as the behavior 
I'm speaking of only appeared sporadically while Karaf was running in a 
console, but often enough such that I would have expected to see it yesterday 
when I was looking for it, but didn't.

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, December 26, 2018 11:36 PM
To: user@karaf.apache.org
Subject: Re: Update

Thanks for the update.

Regarding this fix and other fixes I did last week, I think I will cut a
4.2.3 pretty soon.

Regards
JB

On 27/12/2018 01:17, Freeman Fang wrote:
> Hi Scott,
> 
> Thanks for the update!
> 
> Cheers
> －
> Freeman(Yue) Fang
> 
> Red Hat, Inc.
> 
> 
> 
> 
> 
>> On Dec 27, 2018, at 7:06 AM, Leschke, Scott > <mailto:slesc...@medline.com>> wrote:
>>
>> For what it’s worth, a few weeks ago I reported that I was seeing the 
>> Karaf console hang with version 4.2.1 under Windows.  I far as I can 
>> tell, this issue appears to be resolved with the 4.2.3_SNAPSHOT 
>> release that contains the recent karaf.bat change.
>>  
>> Regards,
>>  
>> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Update

[Leschke, Scott]

I created a Jira on 4.2.2 yesterday regarding the client not accepting some 
keystrokes, like Enter, and the Backspace key not deleting the character from 
the line.

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, December 26, 2018 11:36 PM
To: user@karaf.apache.org
Subject: Re: Update

Thanks for the update.

Regarding this fix and other fixes I did last week, I think I will cut a
4.2.3 pretty soon.

Regards
JB

On 27/12/2018 01:17, Freeman Fang wrote:
> Hi Scott,
> 
> Thanks for the update!
> 
> Cheers
> －
> Freeman(Yue) Fang
> 
> Red Hat, Inc.
> 
> 
> 
> 
> 
>> On Dec 27, 2018, at 7:06 AM, Leschke, Scott > <mailto:slesc...@medline.com>> wrote:
>>
>> For what it’s worth, a few weeks ago I reported that I was seeing the 
>> Karaf console hang with version 4.2.1 under Windows.  I far as I can 
>> tell, this issue appears to be resolved with the 4.2.3_SNAPSHOT 
>> release that contains the recent karaf.bat change.
>>  
>> Regards,
>>  
>> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Update

[Leschke, Scott]

For what it's worth, a few weeks ago I reported that I was seeing the Karaf 
console hang with version 4.2.1 under Windows.  I far as I can tell, this issue 
appears to be resolved with the 4.2.3_SNAPSHOT release that contains the recent 
karaf.bat change.

Regards,

Scott

RE: Karaf 4.2.2 with jdk 11

[Leschke, Scott]

It looks to me like the jaxb jars are getting added to the classpath within 
karaf.bat and should be found.  What do I not see?

if %JAVA_VERSION% GTR 8 (
pushd "%KARAF_HOME%\lib\jdk9plus"
for %%G in (*.jar) do call:APPEND_TO_JDK9PLUS_CLASSPATH %%G
 popd

From: Leschke, Scott 
Sent: Friday, December 21, 2018 12:53 PM
To: user@karaf.apache.org
Subject: RE: Karaf 4.2.2 with jdk 11

I did not.  I have a vague recollection that somebody else may have run into 
this recently.  Where is this to be added?  Directly in karaf.bat?  That would 
be an –add-modules java.xml.bind, correct?

From: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Sent: Friday, December 21, 2018 12:25 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf 4.2.2 with jdk 11

Did you enable the jaxb module in your jdk 11 ?
Le 21 déc. 2018, à 19:11, "Leschke, Scott" 
mailto:slesc...@medline.com>> a écrit:
What’s the statement on JDK 11 support in 4.2.2.  I’ve not had any luck with 
getting 4.2.2 to run under Windows Server 2016.  I unzip the distro, and run 
karaf.bat in the console.  Karaf starts and then appears to hang, never getting 
to the prompt.  V4.2.1 runs fine under the same scenario though.


In the log, all I get is the following:


Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock C:\karaf\apache-karaf-4.2.2\lock
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.Main$KarafLockCallback 
lockAcquired
INFO: Lock acquired. Setting startlevel to 100
2018-12-21T11:57:43,012 | WARN  | FelixStartLevel  | Activator  
  | 11 - org.apache.karaf.features.core - 4.2.2 | Error starting activator
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at 
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:166) 
~[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:89) 
[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
 [?:?]
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) [?:?]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2146) [?:?]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
at java.net.URLClassLoader.findClass(URLClassLoader.java:471) 
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:588) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
at 
org.apache.felix.framework.ExtensionManager$ExtensionManagerWiring.getClassByDelegation(ExtensionManager.java:940)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
 ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
... 8 more


Scott

RE: Karaf 4.2.2 with jdk 11

[Leschke, Scott]

I did not.  I have a vague recollection that somebody else may have run into 
this recently.  Where is this to be added?  Directly in karaf.bat?  That would 
be an –add-modules java.xml.bind, correct?

From: Jean-Baptiste Onofré 
Sent: Friday, December 21, 2018 12:25 PM
To: user@karaf.apache.org
Subject: Re: Karaf 4.2.2 with jdk 11

Did you enable the jaxb module in your jdk 11 ?
Le 21 déc. 2018, à 19:11, "Leschke, Scott" 
mailto:slesc...@medline.com>> a écrit:
What’s the statement on JDK 11 support in 4.2.2.  I’ve not had any luck with 
getting 4.2.2 to run under Windows Server 2016.  I unzip the distro, and run 
karaf.bat in the console.  Karaf starts and then appears to hang, never getting 
to the prompt.  V4.2.1 runs fine under the same scenario though.


In the log, all I get is the following:


Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock C:\karaf\apache-karaf-4.2.2\lock
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.Main$KarafLockCallback 
lockAcquired
INFO: Lock acquired. Setting startlevel to 100
2018-12-21T11:57:43,012 | WARN  | FelixStartLevel  | Activator  
  | 11 - org.apache.karaf.features.core - 4.2.2 | Error starting activator
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at 
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:166) 
~[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:89) 
[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
 [?:?]
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) [?:?]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2146) [?:?]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
at java.net.URLClassLoader.findClass(URLClassLoader.java:471) 
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:588) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
at 
org.apache.felix.framework.ExtensionManager$ExtensionManagerWiring.getClassByDelegation(ExtensionManager.java:940)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
 ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
... 8 more


Scott

Karaf 4.2.2 with jdk 11

[Leschke, Scott]

What's the statement on JDK 11 support in 4.2.2.  I've not had any luck with 
getting 4.2.2 to run under Windows Server 2016.  I unzip the distro, and run 
karaf.bat in the console.  Karaf starts and then appears to hang, never getting 
to the prompt.  V4.2.1 runs fine under the same scenario though.

In the log, all I get is the following:

Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock C:\karaf\apache-karaf-4.2.2\lock
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Dec 21, 2018 11:57:41 AM org.apache.karaf.main.Main$KarafLockCallback 
lockAcquired
INFO: Lock acquired. Setting startlevel to 100
2018-12-21T11:57:43,012 | WARN  | FelixStartLevel  | Activator  
  | 11 - org.apache.karaf.features.core - 4.2.2 | Error starting activator
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
at 
org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:166) 
~[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.karaf.util.tracker.BaseActivator.start(BaseActivator.java:89) 
[11:org.apache.karaf.features.core:4.2.2]
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
 [?:?]
at 
org.apache.felix.framework.Felix.activateBundle(Felix.java:2240) [?:?]
at 
org.apache.felix.framework.Felix.startBundle(Felix.java:2146) [?:?]
at 
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?]
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
 [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
at java.net.URLClassLoader.findClass(URLClassLoader.java:471) 
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:588) ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
at 
org.apache.felix.framework.ExtensionManager$ExtensionManagerWiring.getClassByDelegation(ExtensionManager.java:940)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
 ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
... 8 more

Scott

RE: Related to the startup performance discussion

[Leschke, Scott]

Nope, no special activation.  In this case, no activation at all actually.  
I'll see what happens after 4.2.2 comes out and if the behavior still exists 
I'll get you a thread dump.

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, December 05, 2018 10:54 PM
To: user@karaf.apache.org
Subject: Re: Related to the startup performance discussion

Hi,

Can you take a thread dump at startup and send to me ?

Do you have something special in the activator/activate of your bundle ?

Without some details, it's hard to say.

Thanks,
Regards
JB

On 06/12/2018 00:08, Leschke, Scott wrote:
> FWIW, I also have something I see.  I have a bundle that sits in the 
> Waiting state for a long time. A bundle:diag tells me it's waiting on 
> a particular service but, the service it's talking about comes from a 
> bundle that is Active, and the service itself has no dependencies and 
> has */immediate = true/* set.
> 
>  
> 
> I also see this same thing but the service in question is the 
> org.osgi.service.jndi.JNDIContextManager that it doesn't resolve 
> against. Again, the bundles waiting on this eventually resolve but it 
> frequently takes a long while, like a minute or more.
> 
>  
> 
> This happens under Windows Server 2016.
> 
>  
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Related to the startup performance discussion

[Leschke, Scott]

FWIW, I also have something I see.  I have a bundle that sits in the Waiting 
state for a long time. A bundle:diag tells me it's waiting on a particular 
service but, the service it's talking about comes from a bundle that is Active, 
and the service itself has no dependencies and has immediate = true set.

I also see this same thing but the service in question is the 
org.osgi.service.jndi.JNDIContextManager that it doesn't resolve against. 
Again, the bundles waiting on this eventually resolve but it frequently takes a 
long while, like a minute or more.

This happens under Windows Server 2016.

RE: Karaf freezes up under MS-Windows

[Leschke, Scott]

When 4.2.2 comes out, I'm should be able to run Karaf as a service under jdk 
10+.  At that point, I'll be able to check if the same situation exists when 
running log:tail in the Karaf client connected to the service.  I'm thinking it 
probably won't.

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Friday, November 30, 2018 11:13 AM
To: user@karaf.apache.org
Subject: Re: Karaf freezes up under MS-Windows

Thanks for the update Scott.

I did tests in a term without problem. Let me try again.

Did I say that I hate Windows ? ;)

Regards
JB

On 30/11/2018 17:48, Leschke, Scott wrote:
> I've hesitated to say anything since I wasn't real sure how to verify but 
> I've seen related behavior with 4.2.1 on Windows Server 2016.
> 
> What I see happen is that if I run Karaf in a console, which I think is key, 
> and I do a log:tail,  at some point the display stops updating.  Things start 
> working if I hit enter or CTRL-C in the window.
> 
> I have a warning message in my main control thread that if my thread runs 
> long (which it should never do).  When I hit a key in the console, I see the 
> message indicating that it's not waking up from a timed sleep cycle.  The 
> thread has a 20 sec. polling cycle and does very little so it generally runs 
> in a 100 or 200 hundred millis maybe.
> 
> The control thread has a priority default+1 so it is the highest priority 
> thread in the app.  I have 4.2.0 that I run as a service on a couple of other 
> machines and I've never seen this issue so I'm reasonably sure that the issue 
> is related to running in a console window.
> 
> Scott
> 
> -Original Message-
> From: Jean-Baptiste Onofré 
> Sent: Thursday, November 29, 2018 11:06 PM
> To: user@karaf.apache.org
> Subject: Re: Karaf freezes up under MS-Windows
> 
> Hi Tom,
> 
> I'm not able to reproduce on the Win7 VM.
> 
> Can you provide some details: JDK version, Windows language, ... ?
> 
> Thanks,
> Regards
> JB
> 
> On 30/11/2018 05:56, tom leung wrote:
>> Based on the latest Apache Karaf v4.1.7, run it on Windows 7.
>>
>> Still freeze up at Windows side after entering the command "list - t 0"
>> but the same symptom never happen at Linux side.
>>
>> So the bug is really related to MS-Windows.
>>
>> May you file this symptom as a bug.
>>
>> Best Rgds,
>>
>> Tom Leung
>>
>>  
>>  
>>
>> On Mon, Aug 13, 2018 at 1:03 PM Jean-Baptiste Onofré > <mailto:j...@nanthrax.net>> wrote:
>>
>> OK, let me try to reproduce (I think I still have a VM with Windows 7).
>>
>> Thanks,
>> Regards
>> JB
>>
>> On 13/08/2018 06:48, tom leung wrote:
>> > No response no matter what I type including "CTRL-C and hit ENTER"
>> >
>> > I have type the following command
>> >
>> > karaf@root()>
>> > karaf@root()> bundle:list -t 0
>> > START LEVEL 100 , List Threshold: 0
>> >
>> > Same issue, still freeze up after typing "CTRL-C" and hit ENTER
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Aug 13, 2018 at 12:44 PM, Jean-Baptiste Onofré
>> mailto:j...@nanthrax.net>
>> > <mailto:j...@nanthrax.net <mailto:j...@nanthrax.net>>> wrote:
>> >
>> >     Hi Tom,
>> >
>> >     By freeze, you mean that you can type any command anymore in the
>> >     console ?
>> >
>> >     Did you try CTRL-C or typing ENTER after the command ?
>> >     Does the same happen with bundle:list -t 0 command ?
>> >
>> >     Nothing special in the karaf.log ?
>> >
>> >     Regards
>> >     JB
>> >
>> >     On 13/08/2018 06:38, tom leung wrote:
>> >     > I find the same issues happened in V4.1.6 anf v4.2.0
>> >     >
>> >     > At MS-Windows 64-bit Windows 7.0 professional version
>> >     >
>> >     >
>> >     > I install a new fresh copy of Karaf v4.1.6
>> >     >
>> >     > After it shows the following logo
>> >     >
>> >     > C:\software\apache-karaf-4.1.6\bin>karaf
>> >     >         __ __                  
>> >     >        / //_/ __ _/ __/
>> >     >       / ,<  / __ `/ ___/ __ `/ /_
>> >     >      / /| |/ /_/ / /  / /_/ / __/
>> 

RE: Karaf freezes up under MS-Windows

[Leschke, Scott]

I've hesitated to say anything since I wasn't real sure how to verify but I've 
seen related behavior with 4.2.1 on Windows Server 2016.

What I see happen is that if I run Karaf in a console, which I think is key, 
and I do a log:tail,  at some point the display stops updating.  Things start 
working if I hit enter or CTRL-C in the window.

I have a warning message in my main control thread that if my thread runs long 
(which it should never do).  When I hit a key in the console, I see the message 
indicating that it's not waking up from a timed sleep cycle.  The thread has a 
20 sec. polling cycle and does very little so it generally runs in a 100 or 200 
hundred millis maybe.

The control thread has a priority default+1 so it is the highest priority 
thread in the app.  I have 4.2.0 that I run as a service on a couple of other 
machines and I've never seen this issue so I'm reasonably sure that the issue 
is related to running in a console window.

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Thursday, November 29, 2018 11:06 PM
To: user@karaf.apache.org
Subject: Re: Karaf freezes up under MS-Windows

Hi Tom,

I'm not able to reproduce on the Win7 VM.

Can you provide some details: JDK version, Windows language, ... ?

Thanks,
Regards
JB

On 30/11/2018 05:56, tom leung wrote:
> Based on the latest Apache Karaf v4.1.7, run it on Windows 7.
> 
> Still freeze up at Windows side after entering the command "list - t 0"
> but the same symptom never happen at Linux side.
> 
> So the bug is really related to MS-Windows.
> 
> May you file this symptom as a bug.
> 
> Best Rgds,
> 
> Tom Leung
> 
>  
>  
> 
> On Mon, Aug 13, 2018 at 1:03 PM Jean-Baptiste Onofré  > wrote:
> 
> OK, let me try to reproduce (I think I still have a VM with Windows 7).
> 
> Thanks,
> Regards
> JB
> 
> On 13/08/2018 06:48, tom leung wrote:
> > No response no matter what I type including "CTRL-C and hit ENTER"
> >
> > I have type the following command
> >
> > karaf@root()>
> > karaf@root()> bundle:list -t 0
> > START LEVEL 100 , List Threshold: 0
> >
> > Same issue, still freeze up after typing "CTRL-C" and hit ENTER
> >
> >
> >
> >
> >
> > On Mon, Aug 13, 2018 at 12:44 PM, Jean-Baptiste Onofré
> mailto:j...@nanthrax.net>
> > >> wrote:
> >
> >     Hi Tom,
> >
> >     By freeze, you mean that you can type any command anymore in the
> >     console ?
> >
> >     Did you try CTRL-C or typing ENTER after the command ?
> >     Does the same happen with bundle:list -t 0 command ?
> >
> >     Nothing special in the karaf.log ?
> >
> >     Regards
> >     JB
> >
> >     On 13/08/2018 06:38, tom leung wrote:
> >     > I find the same issues happened in V4.1.6 anf v4.2.0
> >     >
> >     > At MS-Windows 64-bit Windows 7.0 professional version
> >     >
> >     >
> >     > I install a new fresh copy of Karaf v4.1.6
> >     >
> >     > After it shows the following logo
> >     >
> >     > C:\software\apache-karaf-4.1.6\bin>karaf
> >     >         __ __                  
> >     >        / //_/ __ _/ __/
> >     >       / ,<  / __ `/ ___/ __ `/ /_
> >     >      / /| |/ /_/ / /  / /_/ / __/
> >     >     /_/ |_|\__,_/_/   \__,_/_/
> >     >
> >     >   Apache Karaf (4.1.6)
> >     >
> >     > Hit '' for a list of available commands
> >     > and '[cmd] --help' for help on a specific command.
> >     > Hit '' or type 'system:shutdown' or 'logout' to shutdown
> >     Karaf.
> >     >
> >     > karaf@root()>
> >     >
> >     > karaf@root()> list
> >     > START LEVEL 100 , List Threshold: 50
> >     >
> >     >
> >     > I type the following command, Karaf seems to be freezed up
> withut any
> >     > response.
> >     >
> >     > I need to kill Karaf process manually and restart karaf
> Karaf again.
> >     >
> >     > Same issue if I type the above command again.
> >     >
> >     > The same issue also happens in Karaf v4.2.0
> >     >
> >     > Is it a bug?
> >     >
> >     > Best Rgds,
> >     >
> >     > Tom Leung
> >     >
> >     >
> >     >
> >
> >     --
> >     Jean-Baptiste Onofré
> >     jbono...@apache.org 
> >
> >     http://blog.nanthrax.net
> >     Talend - http://www.talend.com
> >
> >
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Aries

[Leschke, Scott]

So, the implication seems to be that the Subsystem spec is effectively broken 
and not worth pursuing.  It sounds as if it's simultaneously too complicated 
and yet not complicated enough. Note that I'm not saying that's the case but 
that's what I take from what's written below and it's apparent lack of uptake.

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, November 28, 2018 12:23 AM
To: user@karaf.apache.org
Subject: Re: Aries

Hi,

I think it's related to the mail I sent last week: better and dynamic usage of 
resource repository with features resolver. It's what we discussed with 
Christian.

Clearly today, Karaf features provide unique functionalities and description, 
not covered by other repository (like subsystem or resource repository), I'm 
thinking about configuration, features flags, inner features, etc.

However, it would make sense to start Karaf with a minimal features set and 
then leverage resources repositories at runtime, dynamically.

The first step I proposed is basically to add commands to manipulate the 
resources repository at runtime and add resource repository element in features 
repositories.
Today, it's already possible to use resources repositories, defining it (in XML 
or JSON) in etc/org.apache.karaf.features.cfg. This configuration is evaluated 
when the features service starts and used by the features resolver.
The propose is:
1. add resource:repo-add and other commands to add/remove resource repositories 
at runtime and then perform a new evaluation of the resolution.
2. add  element in features repo (as we have ) allowing 
to define "open" features and relay on resources repository.

So, to be clear, I don't want to change the current features service which, 
again, provide unique features, and it's the minimal layer to start a karaf 
runtime. My proposal is to extend & improve the features service to better 
leverage the resources repositories. The user then can focus only on a resource 
repository and won't be "forced" to use a features repository.

Regards
JB

On 28/11/2018 06:38, Christian Schneider wrote:
> I understand that you are seeking a more standard way than karaf 
> features to deploy parts of an application. Indeed subsystems look 
> like a good way at first. Unfortunately they add a lot of complexity 
> to a system. So almost no one uses them.
> 
> Currently there are two major ways of packaging an application:
> - karaf features (uses repository + + requirements under the covers). 
> A feature repo is described in xml. The bundles from all the required 
> features form the repository. The bundles with dependency=false form 
> the requirements.
> - repository + requirements based approach like used by bnd (without 
> features). They currently use a pom file to describe a repository + 
> requirements in a bndrun file.
> 
> So I agree it would be great to have a more standard way to package 
> applications. I discussed with JB that we could make more explicit  
> use of repositories for karaf features. The idea is to describe karaf 
> features using a backing repository + required bundles for each feature.
> We could describe the repository for the feature in a pom and refer to 
> it in the feature repo file. The features would then only contain the 
> required bundles.
> 
> This approach would provide a repository in pom form for all karaf 
> features that is then also usable by bnd for packaging. So projects 
> like aries would only need to provide one common form of feature description.
> 
> Besides this there is a standardisation effort at the OSGi alliance 
> for features. Currently the work in progress there looks more like 
> karaf 2 featues, so it is not usable for karaf but maybe in the next 
> iteraion a repository based approach is considered.
> 
> Chritian
> 
> 
> Am Di., 27. Nov. 2018 um 21:56 Uhr schrieb Leschke, Scott 
> mailto:slesc...@medline.com>>:
> 
> It wasn’t really a dev request per se, more of a curiosity question
> as to whether something along those lines was being considered as it
> would seem to make the implementations more easily consumable in a
> variety of OSGi environments.  My primary interest is in Karaf which
> is why I guess I targeted this list. Perhaps I should have thought
> that through better.
> 
> __ __
> 
> As for how something like that were structured, I don’t know
> really.  I only have passing familiarity with the Subsystem spec and
> that it sort of overlaps and extends what Karaf Features do, at
> least to my knowledge. My take is that a Karaf Feature commonly maps
> to an OSGi service spec. implementation, even if the names don’t
> match exactly
> 
> __ __
> 
> I readily admit that I could be grossly mistaken

RE: Aries

[Leschke, Scott]

It wasn’t really a dev request per se, more of a curiosity question as to 
whether something along those lines was being considered as it would seem to 
make the implementations more easily consumable in a variety of OSGi 
environments.  My primary interest is in Karaf which is why I guess I targeted 
this list. Perhaps I should have thought that through better.

As for how something like that were structured, I don’t know really.  I only 
have passing familiarity with the Subsystem spec and that it sort of overlaps 
and extends what Karaf Features do, at least to my knowledge. My take is that a 
Karaf Feature commonly maps to an OSGi service spec. implementation, even if 
the names don’t match exactly

I readily admit that I could be grossly mistaken on that.

Scott

From: David Jencks 
Sent: Tuesday, November 27, 2018 2:08 PM
To: user@karaf.apache.org
Subject: Re: Aries

I’m somewhat curious how you decided on this karaf list for a Dev request for 
Aries.
I’m more curious how a feature subsystem would help deploying an aries osgi 
service implementation. I haven’t looked for several years at how Aries sub 
projects divide up their artifact functionality, but I’d hope that all the spec 
functionality, and api, would be from a single bundle, with, possibly 
additional bundles for extensions.  If this is how a project is structured, how 
does a feature subsystem make deployment easier? If not, would it make more 
sense to adopt such a structure than to imitate it with a feature subsystem?
Thanks
David Jencks
Sent from my iPhone

On Nov 27, 2018, at 11:27 AM, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:
I was wondering if there is a possibility that the Aries project would provide 
OSGi Feature Subsystems for each of the OSGi services they’ve implemented (with 
the exception of the subsystem spec of course).  There is a Karaf Feature for 
installing the Subsystem service so it would be nice if the remaining services 
were available as Feature Subsystems (or Karaf Features I guess but the former 
seems like a more neutral solution).

Scott

Aries

[Leschke, Scott]

I was wondering if there is a possibility that the Aries project would provide 
OSGi Feature Subsystems for each of the OSGi services they've implemented (with 
the exception of the subsystem spec of course).  There is a Karaf Feature for 
installing the Subsystem service so it would be nice if the remaining services 
were available as Feature Subsystems (or Karaf Features I guess but the former 
seems like a more neutral solution).

Scott

RE: Hmm, that's new. Felix Fileinstall

[Leschke, Scott]

The hot deploy folder hierarchy being scanned is CIFS but it is not under /etc. 
 My hot deploy is a folder directly under C:/.  It's been this way for a long 
time.

Scott

-Original Message-
From: Jean-Baptiste Onofré  
Sent: Wednesday, November 21, 2018 9:25 AM
To: user@karaf.apache.org
Subject: Re: Hmm, that's new. Felix Fileinstall

Let me start a Windows VM to try to reproduce.

According to the trace, it's certainly related to environment (Windows, ...).

By the way, is etc folder on CIFS or a shared volume ?

Regards
JB

On 21/11/2018 16:17, Leschke, Scott wrote:
> I've retested this a couple of times in the last hour.  It's 
> reasonably repeatable but is relatively new behavior in 4.2.1 as far 
> as I can tell.  It looks like the following is the cause of the 
> behavior.  It appears repeatedly in the log file.
> 
>  
> 
> 2018-11-21T09:05:29,272 | ERROR | fileinstall-C:/BAM | fileinstall
>   
> | 10 - org.apache.felix.fileinstall -
> 3.6.4 | In main loop, we have serious trouble
> 
> java.nio.file.ClosedWatchServiceException: null
> 
>     at
> sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80
> )
> ~[?:?]
> 
>     at
> sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) 
> ~[?:?]
> 
>     at
> org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.ja
> va:163) ~[10:org.apache.felix.fileinstall:3.6.4]
> 
>     at
> org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScann
> er.java:63) ~[10:org.apache.felix.fileinstall:3.6.4]
> 
>     at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWa
> tcher.java:311) [10:org.apache.felix.fileinstall:3.6.4]
> 
>  
> 
> Scott
> 
>  
> 
> *From:* Leschke, Scott 
> *Sent:* Tuesday, November 20, 2018 8:05 AM
> *To:* user@karaf.apache.org
> *Subject:* RE: Hmm, that's new. Felix Fileinstall
> 
>  
> 
> I'm curious if anybody else has seen the following?  Is this new and 
> expected behavior?
> 
>  
> 
> Scott
> 
>  
> 
> *From:*Leschke, Scott [mailto:slesc...@medline.com]
> *Sent:* Friday, November 16, 2018 3:46 PM
> *To:* user@karaf.apache.org <mailto:user@karaf.apache.org>
> *Subject:* Hmm, that's new. Felix Fileinstall
> 
>  
> 
> Question.  I've been running v 4.2.1 under Java 10.0.2 for a while in 
> my test environment and everything has been working as expected.  
> Recently though, it appeared that fileinstall wasn't picking up that 
> .jar and .cfg files we being changed via hot deploy.
> 
>  
> 
> I tried various things to get it to work but finally thought I'd do a 
> fresh install of 4.2.1 to see if that might clear things up. To 
> install, I run a PowerShell script that unzips the 
> apache-karaf-4.2.1.zip file, installs the features I need and then I 
> change where Karaf's hot deploy folder is by replacing 
> etc/org.apache.felix.fileinstall-deploy.cfg with my own file, 
> org.apache.felix.fileinstall-bam.cfg.
> 
>  
> 
> My application deploy folder is a hierarchy rooted at the folder "BAM"
> (Business Activity Monitoring) that has 3 subfolders in it,
> 
> */runtime/* (for bundles (jars) the app is dependent on),
> */datasources/* (where I keep the .cfgs that contain the 
> org.ops4j.datasource-*.cfg files the app needs), and */systems/* which 
> is another folder hierarchy containing .cfg files and subfolders 
> containing files associated with a system.
> 
>  
> 
> After the install, I'm seeing some "pseudo" bundles with the names and 
> versions shown below.
> 
>  
> 
> C__BAM_runtime   0.0.0
> 
> C__BAM_datasources   0.0.0
> 
> Wrap_jardir_C__BAM_systems 0
> 
>  
> 
> I've rerun the install a few times with some varying results.  In one 
> case, the last name was in line with the others and was shown as 
> C__BAM_systems.  In another case, none of those bundles existed at all?
> Thoughts?
> 
>  
> 
> Windows Server 2016 BTW.  Sorry for the copius detail but I'm trying 
> to be clear as to what I'm seeing.
> 
>  
> 
> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Hmm, that's new. Felix Fileinstall

[Leschke, Scott]

I've retested this a couple of times in the last hour.  It's reasonably 
repeatable but is relatively new behavior in 4.2.1 as far as I can tell.  It 
looks like the following is the cause of the behavior.  It appears repeatedly 
in the log file.

2018-11-21T09:05:29,272 | ERROR | fileinstall-C:/BAM | fileinstall  
| 10 - org.apache.felix.fileinstall - 3.6.4 | In main loop, we have 
serious trouble
java.nio.file.ClosedWatchServiceException: null
at 
sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80) ~[?:?]
at 
sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
at 
org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163) 
~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
 ~[10:org.apache.felix.fileinstall:3.6.4]
at 
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
 [10:org.apache.felix.fileinstall:3.6.4]

Scott

From: Leschke, Scott 
Sent: Tuesday, November 20, 2018 8:05 AM
To: user@karaf.apache.org
Subject: RE: Hmm, that's new. Felix Fileinstall

I'm curious if anybody else has seen the following?  Is this new and expected 
behavior?

Scott

From: Leschke, Scott [mailto:slesc...@medline.com]
Sent: Friday, November 16, 2018 3:46 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Hmm, that's new. Felix Fileinstall

Question.  I've been running v 4.2.1 under Java 10.0.2 for a while in my test 
environment and everything has been working as expected.  Recently though, it 
appeared that fileinstall wasn't picking up that .jar and .cfg files we being 
changed via hot deploy.

I tried various things to get it to work but finally thought I'd do a fresh 
install of 4.2.1 to see if that might clear things up. To install, I run a 
PowerShell script that unzips the apache-karaf-4.2.1.zip file, installs the 
features I need and then I change where Karaf's hot deploy folder is by 
replacing etc/org.apache.felix.fileinstall-deploy.cfg with my own file, 
org.apache.felix.fileinstall-bam.cfg.

My application deploy folder is a hierarchy rooted at the folder "BAM" 
(Business Activity Monitoring) that has 3 subfolders in it,
runtime (for bundles (jars) the app is dependent on), datasources (where I keep 
the .cfgs that contain the org.ops4j.datasource-*.cfg files the app needs), and 
systems which is another folder hierarchy containing .cfg files and subfolders 
containing files associated with a system.

After the install, I'm seeing some "pseudo" bundles with the names and versions 
shown below.

C__BAM_runtime   0.0.0
C__BAM_datasources   0.0.0
Wrap_jardir_C__BAM_systems 0

I've rerun the install a few times with some varying results.  In one case, the 
last name was in line with the others and was shown as C__BAM_systems.  In 
another case, none of those bundles existed at all?  Thoughts?

Windows Server 2016 BTW.  Sorry for the copius detail but I'm trying to be 
clear as to what I'm seeing.

Scott

RE: Startup timing Windows vs. Mac

[Leschke, Scott]

It still begs the question as to why you saw such a difference in times between 
Windows and Mac.

From: Oleg Cohen 
Sent: Tuesday, November 20, 2018 11:34 PM
To: user@karaf.apache.org
Subject: Re: Startup timing Windows vs. Mac

Hi JB,

Thank you for the clarification. I think the bundle load time on Windows was 
affected by a large number of services in the component. I don’t know exactly 
the reason, but how the OSGi container processes the bundle on startup was much 
slower on Windows because I had a large number of services. I reworked my 
architecture to reduce the number of service components and the startup time 
went down quite a bit.

Thank you,
Oleg


On Nov 20, 2018, at 11:55 PM, Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>> wrote:

Hi Oleg,

bundle:update is roughly equivalent to bundle:stop, bundle:uninstall,
bundle:install, bundle:start. It gets the "new" bundle version from the
bundle location (that you can see with bundle:list -l).

Nothing suspicious in the bundle activator that could explain it takes
time to stop/start on windows ?

Regards
JB

On 21/11/2018 04:36, Oleg Cohen wrote:

Hi JB,

I don’t think the antivirus is an issue in my case.

I did disable Windows Defender. My test case is with a single bundle
that is installed via this command:

install reference:file://$eclipse_projects/sample.bundle.a


The location $eclipse_projects points to the local file system where
Eclipse projects for bundles reside.

From Active state I run command *update sample.bundle.a*

I see that the entire bundle start part of the update consists of two
parts. Right after the activation process starts I see a delay. No
logging occurs, even with the log level set to TRACE. Then log output
starts showing initialization of my bundle’s components/services.

The latter part runs quick on both Windows and Mac and take about 1 sec.
However, the former part that is silent and takes about 5 sec on Mac and
20 sec on Windows. So, 4 times slower on Windows.

What happens with the bundle at the start? Are files copied? I do
suspect it has something to do with the file IO.

Thank you,
Oleg



On Nov 20, 2018, at 10:57 AM, Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>
> wrote:

Yes, first, please try with the antivirus disabled.

Regards
JB

On 20/11/2018 16:26, Oleg Cohen wrote:

Hi JB,

Yes, it is Windows. It is exactly the same set of bundles and the
same Maven repository. Yes, there is Antivirus. I can try testing
with disabling it temporarily.

How can I see what is being resolved/checked/updated/downloaded? I do
notice that Karaf has these long pauses. I am sure I can run pretty
much against the local repo.

I would appreciate any pointers on how to speed up the startup!

Best regards,
Oleg


On Nov 20, 2018, at 12:12 AM, Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>
> wrote:

Hi Oleg,

So Windows is longer than Mac (not surprising ;)).

Did you check in term of bundles resolution ? Do the two systems use the
same Maven repository and network to resolve the artifacts.

I already saw such issue due to the Windows antivirus: it verified any
artifacts downloaded by Karaf and it takes time.

Do you have antivirus on the Windows system ?

Regards
JB

On 19/11/2018 21:12, Oleg Cohen wrote:

Greetings,

I have two systems: one Mac and one Windows. I have noticed that
exactly the same application with a number of bundles, both 3rd
party and my own, take significantly longer (1.5 vs 6 mins) on
Windows compared to Mac. Both systems are pretty powerful and have
similar resources. I was wondering if anybody has noticed the same.
What would be the best way to analyze the startup performance and
identify bottlenecks?

Thank you,
Oleg

--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com


--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Startup timing Windows vs. Mac

[Leschke, Scott]

I can't speak to Karaf explicitly but there have been huge issues with both 
antivirus and disk encryption overhead in the Windows environment here.  
Encryption can really slow things down. All our laptops and desktops are 
encrypted on the fly.

While most have SSDs now, I have an old desktop that I no longer use with a 
hard drive that became effectively unusable.

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Tuesday, November 20, 2018 9:57 AM
To: user@karaf.apache.org
Subject: Re: Startup timing Windows vs. Mac

Yes, first, please try with the antivirus disabled.

Regards
JB

On 20/11/2018 16:26, Oleg Cohen wrote:
> Hi JB,
> 
> Yes, it is Windows. It is exactly the same set of bundles and the same Maven 
> repository. Yes, there is Antivirus. I can try testing with disabling it 
> temporarily. 
> 
> How can I see what is being resolved/checked/updated/downloaded? I do notice 
> that Karaf has these long pauses. I am sure I can run pretty much against the 
> local repo.
> 
> I would appreciate any pointers on how to speed up the startup!
> 
> Best regards,
> Oleg
> 
>> On Nov 20, 2018, at 12:12 AM, Jean-Baptiste Onofré  wrote:
>>
>> Hi Oleg,
>>
>> So Windows is longer than Mac (not surprising ;)).
>>
>> Did you check in term of bundles resolution ? Do the two systems use the
>> same Maven repository and network to resolve the artifacts.
>>
>> I already saw such issue due to the Windows antivirus: it verified any
>> artifacts downloaded by Karaf and it takes time.
>>
>> Do you have antivirus on the Windows system ?
>>
>> Regards
>> JB
>>
>> On 19/11/2018 21:12, Oleg Cohen wrote:
>>> Greetings,
>>>
>>> I have two systems: one Mac and one Windows. I have noticed that exactly 
>>> the same application with a number of bundles, both 3rd party and my own, 
>>> take significantly longer (1.5 vs 6 mins) on Windows compared to Mac. Both 
>>> systems are pretty powerful and have similar resources. I was wondering if 
>>> anybody has noticed the same. What would be the best way to analyze the 
>>> startup performance and identify bottlenecks?
>>>
>>> Thank you,
>>> Oleg
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Hmm, that's new. Felix Fileinstall

[Leschke, Scott]

I'm curious if anybody else has seen the following?  Is this new and expected 
behavior?

Scott

From: Leschke, Scott [mailto:slesc...@medline.com]
Sent: Friday, November 16, 2018 3:46 PM
To: user@karaf.apache.org
Subject: Hmm, that's new. Felix Fileinstall

Question.  I've been running v 4.2.1 under Java 10.0.2 for a while in my test 
environment and everything has been working as expected.  Recently though, it 
appeared that fileinstall wasn't picking up that .jar and .cfg files we being 
changed via hot deploy.

I tried various things to get it to work but finally thought I'd do a fresh 
install of 4.2.1 to see if that might clear things up. To install, I run a 
PowerShell script that unzips the apache-karaf-4.2.1.zip file, installs the 
features I need and then I change where Karaf's hot deploy folder is by 
replacing etc/org.apache.felix.fileinstall-deploy.cfg with my own file, 
org.apache.felix.fileinstall-bam.cfg.

My application deploy folder is a hierarchy rooted at the folder "BAM" 
(Business Activity Monitoring) that has 3 subfolders in it,
runtime (for bundles (jars) the app is dependent on), datasources (where I keep 
the .cfgs that contain the org.ops4j.datasource-*.cfg files the app needs), and 
systems which is another folder hierarchy containing .cfg files and subfolders 
containing files associated with a system.

After the install, I'm seeing some "pseudo" bundles with the names and versions 
shown below.

C__BAM_runtime   0.0.0
C__BAM_datasources   0.0.0
Wrap_jardir_C__BAM_systems 0

I've rerun the install a few times with some varying results.  In one case, the 
last name was in line with the others and was shown as C__BAM_systems.  In 
another case, none of those bundles existed at all?  Thoughts?

Windows Server 2016 BTW.  Sorry for the copius detail but I'm trying to be 
clear as to what I'm seeing.

Scott

Hmm, that's new. Felix Fileinstall

[Leschke, Scott]

Question.  I've been running v 4.2.1 under Java 10.0.2 for a while in my test 
environment and everything has been working as expected.  Recently though, it 
appeared that fileinstall wasn't picking up that .jar and .cfg files we being 
changed via hot deploy.

I tried various things to get it to work but finally thought I'd do a fresh 
install of 4.2.1 to see if that might clear things up. To install, I run a 
PowerShell script that unzips the apache-karaf-4.2.1.zip file, installs the 
features I need and then I change where Karaf's hot deploy folder is by 
replacing etc/org.apache.felix.fileinstall-deploy.cfg with my own file, 
org.apache.felix.fileinstall-bam.cfg.

My application deploy folder is a hierarchy rooted at the folder "BAM" 
(Business Activity Monitoring) that has 3 subfolders in it,
runtime (for bundles (jars) the app is dependent on), datasources (where I keep 
the .cfgs that contain the org.ops4j.datasource-*.cfg files the app needs), and 
systems which is another folder hierarchy containing .cfg files and subfolders 
containing files associated with a system.

After the install, I'm seeing some "pseudo" bundles with the names and versions 
shown below.

C__BAM_runtime   0.0.0
C__BAM_datasources   0.0.0
Wrap_jardir_C__BAM_systems 0

I've rerun the install a few times with some varying results.  In one case, the 
last name was in line with the others and was shown as C__BAM_systems.  In 
another case, none of those bundles existed at all?  Thoughts?

Windows Server 2016 BTW.  Sorry for the copius detail but I'm trying to be 
clear as to what I'm seeing.

Scott

RE: Encrypting property values in .cfg files

[Leschke, Scott]

Hi JB,

I'd prefer the ability to use SCR and just supply a StringEncryptor service if 
I could.  I'll use blueprint, tried it actually but didn't get it to work. 
Being able to use SCR would probably be optimal though.

I installed the jasypt-encryption feature and tried it with the encrypted pwd 
wrapped by ENC() in my .cgf file.  I haven't used blueprint in sometime btw.  I 
don't recall having to explicitly install blueprint, is it no longer part of 
boot feature set?  Also, I'm unfamiliar with "property-placeholder".  What's 
the purpose that that over a  element?

Thanks, Scott

  

  

  
  


  

  


-Original Message-
From: Jean-Baptiste Onofré  
Sent: Monday, November 05, 2018 11:02 PM
To: user@karaf.apache.org
Subject: Re: Encrypting property values in .cfg files

Hi Scott,

You want to use it blueprint, SCR or directly ConfigAdmin ?

If you use the {enc:} format, it should work at least with blueprint jasypt 
namespace.

For a generic way, we have a Jira about that. Basically, it would be a 
ConfigListener to do intercepting the {enc:} prefix in property values.
I can work on this one.

Regards
JB

On 05/11/2018 23:25, Leschke, Scott wrote:
> I'm looking to encrypt passwords the are currently in plaintext in a 
> few of my .cfg files.  I've looked at how to do that and it seemed 
> reasonably straightforward although I've had some difficulty getting 
> it working.  I'm wondering if there's anything that prevents me from 
> just supplying a service myself that implements the
> */org.jasypt.encryption.StringEncryptor/* interface rather than using 
> the Karaf jasypt-encryption service.
> 
>  
> 
> I've tried it but that doesn't seem to want to work either so I'm 
> wondering if there's a reason it doesn't.
> 
>  
> 
> Scott
> 
>  
> 
>  
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: Encrypting property values in .cfg files

[Leschke, Scott]

Thanks for the response.

So just to be clear, I’m correct in thinking that it should work?

From: Johan Edstrom [mailto:seij...@gmail.com]
Sent: Monday, November 05, 2018 4:47 PM
To: user@karaf.apache.org
Subject: Re: Encrypting property values in .cfg files

I think I have that in a Jira someplace, otherwise
I have basic code for it against an older karaf
Sent from my pressure cooker.

On Nov 5, 2018, at 15:25, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:
I’m looking to encrypt passwords the are currently in plaintext in a few of my 
.cfg files.  I’ve looked at how to do that and it seemed reasonably 
straightforward although I’ve had some difficulty getting it working.  I’m 
wondering if there’s anything that prevents me from just supplying a service 
myself that implements the org.jasypt.encryption.StringEncryptor interface 
rather than using the Karaf jasypt-encryption service.

I’ve tried it but that doesn’t seem to want to work either so I’m wondering if 
there’s a reason it doesn’t.

Scott

Encrypting property values in .cfg files

[Leschke, Scott]

I'm looking to encrypt passwords the are currently in plaintext in a few of my 
.cfg files.  I've looked at how to do that and it seemed reasonably 
straightforward although I've had some difficulty getting it working.  I'm 
wondering if there's anything that prevents me from just supplying a service 
myself that implements the org.jasypt.encryption.StringEncryptor interface 
rather than using the Karaf jasypt-encryption service.

I've tried it but that doesn't seem to want to work either so I'm wondering if 
there's a reason it doesn't.

Scott

Encrypted values in .cfg files

[Leschke, Scott]

I would like to get rid of the plaintext passwords in a number of my .cfg 
files.  I'm looking at the docs to figure out how to do it and see the 
following blueprint.
I've installed the jasypt feature already but I have a few questions regarding 
this file.


1.   Is there a Jasypt Component that can be configured using a property 
file or is blueprint required?

2.   Is there a mechanism in CA to specify that a string replacement be 
done using an environment variable or JVM property (will ${ENV_VAR} work)?

3.   I'm a bit confused by the part I highlighted. What's the purpose of 
that? It's not necessary to specify the .cfg files that will have encrypted 
properties explicitely, is it?

I don't need the .cfg file to be called out there to use ENC(encrypted_value), 
do I?

4.   Does the Jasypt feature provide a mechanism by which a string can be 
entered and the encrypted for returned? I didn't see a command. If not, is 
there a web page that provides that or some other mechanism other than writing 
some java code to tell you what the encrypted form a string is using the 
specified password?

Thanks, Scott

http://www.osgi.org/xmlns/blueprint/v1.0.0;
   
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
   
xmlns:ext="http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0;
   xmlns:enc="http://karaf.apache.org/xmlns/jasypt/v1.0.0;>

  
  
  

  

  

  
  
  
  
file:etc/db.properties
  

  

  
   
  
  

  

  

  

RE: Enabling HTTPS

[Leschke, Scott]

No I have not modified etc/jetty.xml. Does that have to be updated as well?

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Saturday, October 27, 2018 9:16 AM
To: user@karaf.apache.org
Subject: Re: Enabling HTTPS

Hi,

just to be sure, you don't use and have etc/jetty.xml ?

I just tested and it works fine using different password for key and
keystore.

Regards
JB

On 27/10/2018 15:11, Leschke, Scott wrote:
> From the example shown under the Configuration heading at
> https://karaf.apache.org/manual/latest/webcontainer, it shows
> 
>  
> 
>    keytool -genkey -keyalg RSA -alias selfsigned -keystore
> keystore -storepass karaf1234 -validity 360 -keysize 2048
> 
>  
> 
>    Now, we can enable and configure the HTTPs connector with
> this keystore in etc/org.ops4j.pax.web.cfg:
> 
>  
> 
>    org.osgi.service.http.port.secure=8443
> 
>    org.osgi.service.http.secure.enabled=true
> 
>    org.ops4j.pax.web.ssl.keystore=/path/to/keystore
> 
>    org.ops4j.pax.web.ssl.password=foo
> 
>    org.ops4j.pax.web.ssl.keypassword=karaf1234
> 
>  
> 
> The documentation at:
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration
> says
> 
>  
> 
>    To enable SSL support you must set the following properties:
> 
>  
> 
>    org.osgi.service.http.secure.enabled to true
> 
>    org.ops4j.pax.web.ssl.keystore to the path to the
> keystore to be used. If not set the default path ${user.home}/.keystore
> is used.
> 
>    org.ops4j.pax.web.ssl.password to the password used for
> keystore integrity check. The value can be in plain text or obfuscated (
> starting with OBF: )     as described in step 4 of jetty
> documentation
> 
>    org.ops4j.pax.web.ssl.keypassword to the password used
> for keystore. The value can be in plain text or obfuscated ( starting
> with OBF: ) as     described in step 4 of
> jetty documentation
> 
>  
> 
> The above would seem to indicate that the opposite of what you say is
> actually true although when I tried setting ...password to the key
> password and ...keypassword to the store password I couldn't get it to
> work. I seem to recall that I tried it the other way around as well and
> that didn't work either.
> 
> Ultimately I ended up regenerating my keystore and dropping the key
> password entirely which by default makes the key password the same as
> the store password as far as I understand.  I then set both properties
> to the keystore password value which worked.
> 
>  
> 
> I don't know why having a key password that differed from the keystore
> password it didn't work but that's what I experienced.
> 
>  
> 
> Regards,
> 
>  
> 
> Scott
> 
>  
> 
> -Original Message-
> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> Sent: Friday, October 26, 2018 9:33 PM
> To: user@karaf.apache.org
> Subject: Re: Enabling HTTPS
> 
>  
> 
> It's for the server side, so yes password is the keystore password and
> 
> keypassword is the key password.
> 
>  
> 
> Regards
> 
> JB
> 
>  
> 
> On 26/10/2018 16:02, Leschke, Scott wrote:
> 
>> After doing some digging, it would appear that both of these properties
> 
>> need to be set to the keystore password.
> 
>>
> 
>> org.ops4j.pax.web.ssl.password
> 
>>
> 
>> org.ops4j.pax.web.ssl.keypassword
> 
>>
> 
>> I’m still curious about the difference between:
> 
>>
> 
>> *org.osgi.service.http.secure.enabled=true*
> 
>>
> 
>> and
> 
>>
> 
>> *org.osgi.service.https.enabled=true*
> 
>>
> 
>> Scott
> 
>>
> 
>>  
> 
>>
> 
>> *From:*Leschke, Scott [mailto:slesc...@medline.com]
> 
>> *Sent:* Thursday, October 25, 2018 11:21 AM
> 
>> *To:* user@karaf.apache.org
> 
>> *Subject:* RE: Enabling HTTPS
> 
>>
> 
>>  
> 
>>
> 
>> Actually,
> 
>>
> 
>>  
> 
>>
> 
>> I saw most of that information at: 
> 
>>
> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration
> 
>>
> 
>>  
> 
>>
> 
>> It says, Password used for keystore integrity check.
> 
>>
> 
>>  
> 
>>
> 
>> Where does that pwd come from?  The example in the Karaf doc doesn’t
> 
>> show (it’s foo).
> 
>>
> 
>>  
> 
>>
> 
>> *From:*Achim 

RE: Enabling HTTPS

[Leschke, Scott]

From the example shown under the Configuration heading at 
https://karaf.apache.org/manual/latest/webcontainer, it shows



   keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore 
-storepass karaf1234 -validity 360 -keysize 2048



   Now, we can enable and configure the HTTPs connector with this 
keystore in etc/org.ops4j.pax.web.cfg:



   org.osgi.service.http.port.secure=8443

   org.osgi.service.http.secure.enabled=true

   org.ops4j.pax.web.ssl.keystore=/path/to/keystore

   org.ops4j.pax.web.ssl.password=foo

   org.ops4j.pax.web.ssl.keypassword=karaf1234



The documentation at: 
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration says



   To enable SSL support you must set the following properties:



   org.osgi.service.http.secure.enabled to true

   org.ops4j.pax.web.ssl.keystore to the path to the keystore to be 
used. If not set the default path ${user.home}/.keystore is used.

   org.ops4j.pax.web.ssl.password to the password used for keystore 
integrity check. The value can be in plain text or obfuscated ( starting with 
OBF: ) as described in step 4 of jetty documentation

   org.ops4j.pax.web.ssl.keypassword to the password used for 
keystore. The value can be in plain text or obfuscated ( starting with OBF: ) 
as described in step 4 of jetty documentation



The above would seem to indicate that the opposite of what you say is actually 
true although when I tried setting ...password to the key password and 
...keypassword to the store password I couldn't get it to work. I seem to 
recall that I tried it the other way around as well and that didn't work either.

Ultimately I ended up regenerating my keystore and dropping the key password 
entirely which by default makes the key password the same as the store password 
as far as I understand.  I then set both properties to the keystore password 
value which worked.



I don't know why having a key password that differed from the keystore password 
it didn't work but that's what I experienced.



Regards,



Scott



-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
Sent: Friday, October 26, 2018 9:33 PM
To: user@karaf.apache.org
Subject: Re: Enabling HTTPS



It's for the server side, so yes password is the keystore password and

keypassword is the key password.



Regards

JB



On 26/10/2018 16:02, Leschke, Scott wrote:

> After doing some digging, it would appear that both of these properties

> need to be set to the keystore password.

>

> org.ops4j.pax.web.ssl.password

>

> org.ops4j.pax.web.ssl.keypassword

>

> I’m still curious about the difference between:

>

> *org.osgi.service.http.secure.enabled=true*

>

> and

>

> *org.osgi.service.https.enabled=true*

>

> Scott

>

>

>

> *From:*Leschke, Scott [mailto:slesc...@medline.com]

> *Sent:* Thursday, October 25, 2018 11:21 AM

> *To:* user@karaf.apache.org

> *Subject:* RE: Enabling HTTPS

>

>

>

> Actually,

>

>

>

> I saw most of that information at:

> https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration

>

>

>

> It says, Password used for keystore integrity check.

>

>

>

> Where does that pwd come from?  The example in the Karaf doc doesn’t

> show (it’s foo).

>

>

>

> *From:*Achim Nierbeck 

> *Sent:* Thursday, October 25, 2018 11:09 AM

> *To:* user@karaf.apache.org

> *Subject:* Re: Enabling HTTPS

>

>

>

> Hi,

>

>

>

> I'm sure you'll find some of your questions answered here:

> http://ops4j.github.io/pax/web/SNAPSHOT/User-Guide.html#ssl-configuration

>

>

>

> regards, Achim

>

>

>

> Am Do., 25. Okt. 2018 um 17:59 Uhr schrieb Leschke, Scott

> mailto:slesc...@medline.com>>:

>

> I’m attempting to get https working by following the instructions

> at: https://karaf.apache.org/manual/latest/webcontainer

>

> I’m confused by the setting for *org.ops4j.pax.web.ssl.password*

>

> What is that intended to be. How is it defined?

>

>

>

> Also, what’s the difference between these:

>

> *org.osgi.service.http.secure.enabled=true*

>

> and

>

> *org.osgi.service.https.enabled=true* ?

>

>

>

> Anyway, I’m getting the following:

>

> Caused by: java.security.UnrecoverableKeyException: failed to

> decrypt safe contents entry: javax.crypto.BadPaddingException: Given

> final block not properly padded. Such issues can arise if a bad key

> is used during decryption.

>

>

>

> My org.ops4j.pax.web.cfg (slightly obf

RE: Enabling HTTPS

[Leschke, Scott]

After doing some digging, it would appear that both of these properties need to 
be set to the keystore password.
org.ops4j.pax.web.ssl.password
org.ops4j.pax.web.ssl.keypassword
I’m still curious about the difference between:
org.osgi.service.http.secure.enabled=true
and
org.osgi.service.https.enabled=true
Scott

From: Leschke, Scott [mailto:slesc...@medline.com]
Sent: Thursday, October 25, 2018 11:21 AM
To: user@karaf.apache.org
Subject: RE: Enabling HTTPS

Actually,

I saw most of that information at:  
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration

It says, Password used for keystore integrity check.

Where does that pwd come from?  The example in the Karaf doc doesn’t show (it’s 
foo).

From: Achim Nierbeck 
Sent: Thursday, October 25, 2018 11:09 AM
To: user@karaf.apache.org
Subject: Re: Enabling HTTPS

Hi,

I'm sure you'll find some of your questions answered here:
http://ops4j.github.io/pax/web/SNAPSHOT/User-Guide.html#ssl-configuration

regards, Achim

Am Do., 25. Okt. 2018 um 17:59 Uhr schrieb Leschke, Scott 
mailto:slesc...@medline.com>>:
I’m attempting to get https working by following the instructions at: 
https://karaf.apache.org/manual/latest/webcontainer
I’m confused by the setting for org.ops4j.pax.web.ssl.password
What is that intended to be. How is it defined?

Also, what’s the difference between these:
org.osgi.service.http.secure.enabled=true
and
org.osgi.service.https.enabled=true ?

Anyway, I’m getting the following:
Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe 
contents entry: javax.crypto.BadPaddingException: Given final block not 
properly padded. Such issues can arise if a bad key is used during decryption.

My org.ops4j.pax.web.cfg (slightly obfuscated) is shown below.

Scott


org.osgi.service.http.enabled=false
org.osgi.service.http.port=8181

org.osgi.service.http.port.secure=8443
org.osgi.service.http.secure.enabled=true
org.osgi.service.https.enabled=true

org.ops4j.pax.web.config.file=${karaf.etc}/jetty.xml
org.apache.karaf.features.configKey=org.ops4j.pax.web

org.ops4j.pax.web.ssl.keystore=c:/KeyStorePath
org.ops4j.pax.web.ssl.password=??  Not sure what this is exactly
org.ops4j.pax.web.ssl.keypassword=MyKeystorePWD

javax.servlet.context.tempdir=${karaf.data}/pax-web-jsp


--

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & 
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

RE: Enabling HTTPS

[Leschke, Scott]

Actually,

I saw most of that information at:  
https://ops4j1.jira.com/wiki/spaces/paxweb/pages/12059277/SSL+Configuration

It says, Password used for keystore integrity check.

Where does that pwd come from?  The example in the Karaf doc doesn’t show (it’s 
foo).

From: Achim Nierbeck 
Sent: Thursday, October 25, 2018 11:09 AM
To: user@karaf.apache.org
Subject: Re: Enabling HTTPS

Hi,

I'm sure you'll find some of your questions answered here:
http://ops4j.github.io/pax/web/SNAPSHOT/User-Guide.html#ssl-configuration

regards, Achim

Am Do., 25. Okt. 2018 um 17:59 Uhr schrieb Leschke, Scott 
mailto:slesc...@medline.com>>:
I’m attempting to get https working by following the instructions at: 
https://karaf.apache.org/manual/latest/webcontainer
I’m confused by the setting for org.ops4j.pax.web.ssl.password
What is that intended to be. How is it defined?

Also, what’s the difference between these:
org.osgi.service.http.secure.enabled=true
and
org.osgi.service.https.enabled=true ?

Anyway, I’m getting the following:
Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe 
contents entry: javax.crypto.BadPaddingException: Given final block not 
properly padded. Such issues can arise if a bad key is used during decryption.

My org.ops4j.pax.web.cfg (slightly obfuscated) is shown below.

Scott


org.osgi.service.http.enabled=false
org.osgi.service.http.port=8181

org.osgi.service.http.port.secure=8443
org.osgi.service.http.secure.enabled=true
org.osgi.service.https.enabled=true

org.ops4j.pax.web.config.file=${karaf.etc}/jetty.xml
org.apache.karaf.features.configKey=org.ops4j.pax.web

org.ops4j.pax.web.ssl.keystore=c:/KeyStorePath
org.ops4j.pax.web.ssl.password=??  Not sure what this is exactly
org.ops4j.pax.web.ssl.keypassword=MyKeystorePWD

javax.servlet.context.tempdir=${karaf.data}/pax-web-jsp


--

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & 
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Enabling HTTPS

[Leschke, Scott]

I'm attempting to get https working by following the instructions at: 
https://karaf.apache.org/manual/latest/webcontainer
I'm confused by the setting for org.ops4j.pax.web.ssl.password
What is that intended to be. How is it defined?

Also, what's the difference between these:
org.osgi.service.http.secure.enabled=true
and
org.osgi.service.https.enabled=true ?

Anyway, I'm getting the following:
Caused by: java.security.UnrecoverableKeyException: failed to decrypt safe 
contents entry: javax.crypto.BadPaddingException: Given final block not 
properly padded. Such issues can arise if a bad key is used during decryption.

My org.ops4j.pax.web.cfg (slightly obfuscated) is shown below.

Scott


org.osgi.service.http.enabled=false
org.osgi.service.http.port=8181

org.osgi.service.http.port.secure=8443
org.osgi.service.http.secure.enabled=true
org.osgi.service.https.enabled=true

org.ops4j.pax.web.config.file=${karaf.etc}/jetty.xml
org.apache.karaf.features.configKey=org.ops4j.pax.web

org.ops4j.pax.web.ssl.keystore=c:/KeyStorePath
org.ops4j.pax.web.ssl.password=??  Not sure what this is exactly
org.ops4j.pax.web.ssl.keypassword=MyKeystorePWD

javax.servlet.context.tempdir=${karaf.data}/pax-web-jsp

RE: Http Whiteboard

[Leschke, Scott]

OK, got it.  Sorry I realize now that’s what you were trying to tell me but I 
was slow on the uptake.

Thanks

From: Tim Ward 
Sent: Tuesday, October 23, 2018 11:14 AM
To: user@karaf.apache.org
Subject: Re: Http Whiteboard

You should be able to do:

HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_1,
HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_2,
HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_3,
HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_4,
...


Sent from my iPhone

On 23 Oct 2018, at 18:06, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:
HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_LIST

RE: Http Whiteboard

[Leschke, Scott]

I’m a bit confused.  I’m doing this with OSGi R6 so the URL pattern list has to 
be the latter part of the string created by:

HTTP_WHITEBOARD_SERVLET_PATTERN + ‘=’  + PATTERN_LIST

does it not?

From: Tim Ward 
Sent: Tuesday, October 23, 2018 10:58 AM
To: user@karaf.apache.org
Subject: Re: Http Whiteboard

You can have multiple patterns just by adding the property as a 
String[]/Collection. See 
https://osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/http/whiteboard/propertytypes/HttpWhiteboardServletPattern.html#value--
 which is the component property type for that whiteboard property.

If you can’t use component property types then repeated single value entries in 
the property element get aggregated into an array.

Tim


On 23 Oct 2018, at 17:32, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

Thanks Tim,

That’s exactly what I thought but without it I get the following from Jetty.
HTTP ERROR 404
Problem accessing /myApp/. Reason:
Not Found

Perhaps that’s related to something else and the presence/absence of 
Web-ContextPath is triggering the other issue.  I’ll see what I can figure out 
in that regard.

I do have one last question though. I’m wondering what the syntax is to 
associate multiple URL patterns with a single servlet.  I assume I can use 
wildcarding and stuff like that but can I use a Java RE?  How about a URL list? 
 Comma separated, bounded by braces, brackets?

I’m thought I had a copy of the R6 compendium squirreled away so that I could 
just look it up but it may be on my machine at home and for some reason I’m not 
seeing it at osgi.org<http://osgi.org/> even though I’m sure it’s there 
somewhere.

Scott

From: Tim Ward mailto:tim.w...@paremus.com>>
Sent: Tuesday, October 23, 2018 10:09 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Http Whiteboard

I wouldn’t expect you to need anything specific in your bnd file. 
Web-ContextPath is part of a different OSGi specification (the Web Application 
Bundle spec) so there shouldn’t be any need for that at all.

Best Regards,

Tim



On 23 Oct 2018, at 17:06, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

Thanks Tim.  That was the problem. I noticed that just after I sent the email 
but hadn’t had a chance to try it yet.  I pulled that from a YouTube video Ray 
Auge did way back in 2014 and sort of blindly regurgitated what I saw.

There’s something else I noticed though.  It would seem that it’s still 
necessary to define
Web-ContextPath .bnd file as it doesn’t appear to work without that.  Is that 
right?

From: Tim Ward mailto:tim.w...@paremus.com>>
Sent: Monday, October 22, 2018 4:28 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Http Whiteboard

I’m pretty sure that your ServletContextHelper isn’t advertised as a service 
and is therefore invisible to the whiteboard. ServletContextHelper is not an 
interface so you need to be explicit.

Tim
Sent from my iPhone

On 22 Oct 2018, at 23:04, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

I’ve in the process of trying to convert a couple of servlets over to user 
HttpWhiteboard. I looked online for an example and it seemed pretty straight 
forward.
Based on my understanding, I came up with the following but it doesn’t work. 
Jetty doesn’t have a myApp context. I assume there is something missing?

Help?

Scott


@Component(
   property  = {
  HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME,
  HTTP_WHITEBOARD_CONTEXT_PATH + '=' + ContextHelper.CTX_PATH
   }
)
public class ContextHelper
   extends org.osgi.service.http.context.ServletContextHelper
{
   public static final String CTX_NAME = "myApp";
   public static final String CTX_PATH = '/' + CTX_NAME;
}


@Component(
   name  = “myApp.listings",
   property  = {
  HTTP_WHITEBOARD_CONTEXT_SELECT  + "=(" + 
HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME + ')',
  HTTP_WHITEBOARD_SERVLET_NAME+ '=' + "MyApp Listings",
  HTTP_WHITEBOARD_SERVLET_PATTERN + '=' + "/list/*"
   },
   service   = Servlet.class,
   immediate = true)
@Designate(
   ocd = AppConfig.class)
public class Listings
   implements HttpServlet
{…}

RE: Http Whiteboard

[Leschke, Scott]

Thanks Tim,

That’s exactly what I thought but without it I get the following from Jetty.
HTTP ERROR 404
Problem accessing /myApp/. Reason:
Not Found

Perhaps that’s related to something else and the presence/absence of 
Web-ContextPath is triggering the other issue.  I’ll see what I can figure out 
in that regard.

I do have one last question though. I’m wondering what the syntax is to 
associate multiple URL patterns with a single servlet.  I assume I can use 
wildcarding and stuff like that but can I use a Java RE?  How about a URL list? 
 Comma separated, bounded by braces, brackets?

I’m thought I had a copy of the R6 compendium squirreled away so that I could 
just look it up but it may be on my machine at home and for some reason I’m not 
seeing it at osgi.org even though I’m sure it’s there somewhere.

Scott

From: Tim Ward 
Sent: Tuesday, October 23, 2018 10:09 AM
To: user@karaf.apache.org
Subject: Re: Http Whiteboard

I wouldn’t expect you to need anything specific in your bnd file. 
Web-ContextPath is part of a different OSGi specification (the Web Application 
Bundle spec) so there shouldn’t be any need for that at all.

Best Regards,

Tim


On 23 Oct 2018, at 17:06, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

Thanks Tim.  That was the problem. I noticed that just after I sent the email 
but hadn’t had a chance to try it yet.  I pulled that from a YouTube video Ray 
Auge did way back in 2014 and sort of blindly regurgitated what I saw.

There’s something else I noticed though.  It would seem that it’s still 
necessary to define
Web-ContextPath .bnd file as it doesn’t appear to work without that.  Is that 
right?

From: Tim Ward mailto:tim.w...@paremus.com>>
Sent: Monday, October 22, 2018 4:28 PM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Http Whiteboard

I’m pretty sure that your ServletContextHelper isn’t advertised as a service 
and is therefore invisible to the whiteboard. ServletContextHelper is not an 
interface so you need to be explicit.

Tim
Sent from my iPhone

On 22 Oct 2018, at 23:04, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

I’ve in the process of trying to convert a couple of servlets over to user 
HttpWhiteboard. I looked online for an example and it seemed pretty straight 
forward.
Based on my understanding, I came up with the following but it doesn’t work. 
Jetty doesn’t have a myApp context. I assume there is something missing?

Help?

Scott


@Component(
   property  = {
  HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME,
  HTTP_WHITEBOARD_CONTEXT_PATH + '=' + ContextHelper.CTX_PATH
   }
)
public class ContextHelper
   extends org.osgi.service.http.context.ServletContextHelper
{
   public static final String CTX_NAME = "myApp";
   public static final String CTX_PATH = '/' + CTX_NAME;
}


@Component(
   name  = “myApp.listings",
   property  = {
  HTTP_WHITEBOARD_CONTEXT_SELECT  + "=(" + 
HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME + ')',
  HTTP_WHITEBOARD_SERVLET_NAME+ '=' + "MyApp Listings",
  HTTP_WHITEBOARD_SERVLET_PATTERN + '=' + "/list/*"
   },
   service   = Servlet.class,
   immediate = true)
@Designate(
   ocd = AppConfig.class)
public class Listings
   implements HttpServlet
{…}

RE: Http Whiteboard

[Leschke, Scott]

Thanks Tim.  That was the problem. I noticed that just after I sent the email 
but hadn’t had a chance to try it yet.  I pulled that from a YouTube video Ray 
Auge did way back in 2014 and sort of blindly regurgitated what I saw.

There’s something else I noticed though.  It would seem that it’s still 
necessary to define
Web-ContextPath .bnd file as it doesn’t appear to work without that.  Is that 
right?

From: Tim Ward 
Sent: Monday, October 22, 2018 4:28 PM
To: user@karaf.apache.org
Subject: Re: Http Whiteboard

I’m pretty sure that your ServletContextHelper isn’t advertised as a service 
and is therefore invisible to the whiteboard. ServletContextHelper is not an 
interface so you need to be explicit.

Tim
Sent from my iPhone

On 22 Oct 2018, at 23:04, Leschke, Scott 
mailto:slesc...@medline.com>> wrote:

I’ve in the process of trying to convert a couple of servlets over to user 
HttpWhiteboard. I looked online for an example and it seemed pretty straight 
forward.
Based on my understanding, I came up with the following but it doesn’t work. 
Jetty doesn’t have a myApp context. I assume there is something missing?

Help?

Scott


@Component(
   property  = {
  HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME,
  HTTP_WHITEBOARD_CONTEXT_PATH + '=' + ContextHelper.CTX_PATH
   }
)
public class ContextHelper
   extends org.osgi.service.http.context.ServletContextHelper
{
   public static final String CTX_NAME = "myApp";
   public static final String CTX_PATH = '/' + CTX_NAME;
}


@Component(
   name  = “myApp.listings",
   property  = {
  HTTP_WHITEBOARD_CONTEXT_SELECT  + "=(" + 
HTTP_WHITEBOARD_CONTEXT_NAME + '=' + ContextHelper.CTX_NAME + ')',
  HTTP_WHITEBOARD_SERVLET_NAME+ '=' + "MyApp Listings",
  HTTP_WHITEBOARD_SERVLET_PATTERN + '=' + "/list/*"
   },
   service   = Servlet.class,
   immediate = true)
@Designate(
   ocd = AppConfig.class)
public class Listings
   implements HttpServlet
{…}

RE: Logging config

[Leschke, Scott]

 understand what you mean, but it depends of the application 
and the logger in used.

You can set off level for a specific logger.

Regards
JB

On 12/10/2018 18:11, Leschke, Scott wrote:
> Is there any way to cause Karaf to suppress logging the full exception 
> stack and instead just log the exception type and message for one or 
> more bundles?
> 
>  
> 
> There are occasions that I want to fail a service activation because 
> of a configuration error but I really don't need or want a full trace 
> of the IllegalArgumentException that was thrown.
> 
>  
> 
> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Logging config

[Leschke, Scott]

Is there any way to cause Karaf to suppress logging the full exception stack 
and instead just log the exception type and message for one or more bundles?

There are occasions that I want to fail a service activation because of a 
configuration error but I really don't need or want a full trace of the 
IllegalArgumentException that was thrown.

Scott

Karaf as a service on Windows Server

[Leschke, Scott]

I installed Karaf 4.2.1 as a service with JDK 10.  When I tried to run it, I 
get the following.  I think this was fixed previously and is a regression.

STATUS | wrapper  | 2018/10/12 10:16:55 | Launching a JVM...
INFO   | jvm 1| 2018/10/12 10:16:55 | -Djava.endorsed.dirs=C:\Program is 
not supported. Endorsed standards and standalone APIs
INFO   | jvm 1| 2018/10/12 10:16:55 | in modular form will be supported via 
the concept of upgradeable modules.
INFO   | jvm 1| 2018/10/12 10:16:55 | Error: Could not create the Java 
Virtual Machine.
INFO   | jvm 1| 2018/10/12 10:16:55 | Error: A fatal exception has 
occurred. Program will exit.
ERROR  | wrapper  | 2018/10/12 10:16:55 | JVM exited while loading the 
application.

RE: java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator when running as Service on RedHat 7.5

[Leschke, Scott]

Hi Oleg,

I’m the person who originally reported the issue that JB is referring to.  In 
my case on Windows, Karaf appears to work fine as well but there is that error 
in the log that only occurs when you start Karaf using the service wrapper.

Regards,
Scott

From: Oleg Cohen [mailto:oleg.co...@assurebridge.com]
Sent: Tuesday, July 24, 2018 2:01 PM
To: user@karaf.apache.org
Subject: Re: java.lang.NoClassDefFoundError: 
org/apache/karaf/specs/locator/OsgiLocator when running as Service on RedHat 7.5

Hi JB,

I am using the wrapper. bin/karaf works fine.

Thank you!
Oleg


On Jul 24, 2018, at 2:58 PM, Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>> wrote:

Maybe it's related to:

https://issues.apache.org/jira/browse/KARAF-5840 (I already have a fix
on a local branch)

The problem only occurs when using the wrapper.

@Oleg/Miroslav: do you use wrapper to start Karaf instead of bin/karaf ?

Regards
JB

On 24/07/2018 20:54, Francois Papon wrote:

Hi,

It's weird because I downloaded the binary and after extract it, I can
see the org.apache.karaf.specs.locator-4.2.0.jar in the lib/endorsed
directory.

regards,

François Papon
fpa...@apache.org

Le 24/07/2018 à 22:31, Oleg Cohen a écrit :

Hi Miroslav,

I think I found the issue. You are right a JAR is missing.

I built org.apache.karaf.specs.locator-4.2.0.jar and added it to the
boot/lib folder and the exception is now gone.

Thank you!
Oleg



On Jul 24, 2018, at 11:45 AM, Miroslav Beranič
mailto:miroslav.bera...@mibesis.si> 
> wrote:

Hi Oleg,

I've just downloaded package from:

http://karaf.apache.org/download.html
Binary Distribution : tar.gz [PGP] [SHA512]

I've downloaded to /opt/ folder and unpacked the package.

I am using RHEL 7.5, Oracle Java 8 ( 1.8.0.172 )

Next I've started Karf with:

[root@framework apache-karaf-4.2.0]# ls -al
total 424
drwxr-xr-x. 9 root root156 jul 24 17:35 .
drwxr-xr-x. 4 root root110 jul 24 17:35 ..
drwxr-xr-x. 3 root root282 apr  5 06:29 bin
drwxr-xr-x. 3 root root 17 apr  5 06:29 data
drwxr-xr-x. 9 root root123 apr  5 06:29 demos
drwxr-xr-x. 2 root root 20 apr  5 06:29 deploy
drwxr-xr-x. 3 root root   4096 apr  5 06:29 etc
drwxr-xr-x. 5 root root 59 apr  5 06:29 lib
-rw-r--r--. 1 root root  27754 apr  5 06:29 LICENSE
-rw-r--r--. 1 root root   1829 apr  5 06:29 NOTICE
-rw-r--r--. 1 root root   4025 apr  5 06:29 README
-rw-r--r--. 1 root root 390829 apr  5 06:29 RELEASE-NOTES
drwxr-xr-x. 3 root root 31 apr  5 06:29 system
[root@framework apache-karaf-4.2.0]# JAVA_HOME=/opt/jdk ./bin/karaf debug
Listening for transport dt_socket at address: 5005
__ __  
   / //_/ __ _/ __/
  / ,<  / __ `/ ___/ __ `/ /_
 / /| |/ /_/ / /  / /_/ / __/
/_/ |_|\__,_/_/   \__,_/_/

  Apache Karaf (4.2.0)

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.

karaf@root()> feature:install
service-wrapper

karaf@root()> wrapper:install
Creating file: /opt/apache-karaf-4.2.0/bin/karaf-wrapper
Creating file: /opt/apache-karaf-4.2.0/bin/karaf-service
Creating file: /opt/apache-karaf-4.2.0/bin/karaf.service
Creating file: /opt/apache-karaf-4.2.0/etc/karaf-wrapper.conf
Creating missing directory: /opt/apache-karaf-4.2.0/lib/wrapper
Creating file: /opt/apache-karaf-4.2.0/lib/wrapper/libwrapper.so
Creating file: /opt/apache-karaf-4.2.0/lib/wrapper/karaf-wrapper.jar
Creating file: /opt/apache-karaf-4.2.0/lib/wrapper/karaf-wrapper-main.jar

Setup complete.  You may wish to tweak the JVM properties in the
wrapper configuration file:
/opt/apache-karaf-4.2.0/etc/karaf-wrapper.conf
before installing and starting the service.


RedHat/Fedora/CentOS Linux system detected (SystemV):
  To install the service:
$ ln -s /opt/apache-karaf-4.2.0/bin/karaf-service /etc/init.d/
$ chkconfig karaf-service --add

  To start the service when the machine is rebooted:
$ chkconfig karaf-service on

  To disable starting the service when the machine is rebooted:
$ chkconfig karaf-service off

  To start the service:
$ service karaf-service start

  To stop the service:
$ service karaf-service stop

  To uninstall the service :
$ chkconfig karaf-service --del
$ rm /etc/init.d/karaf-service

For systemd compliant Linux:
  To install the service (and enable at system boot):
   $ systemctl enable /opt/apache-karaf-4.2.0/bin/karaf.service

  To start the service:
   $ systemctl start karaf

  To stop the service:
   $ systemctl stop karaf

  To check the current service status:
   $ systemctl status karaf

  To see service activity journal:
   $ journalctl -u karaf

  To uninstall the service (and disable at system boot):
   $ systemctl disable karaf
karaf@root()>

karaf@root()>


I've exited Karaf shell here ( with Ctrl + D )


[root@framework apache-karaf-4.2.0]# ^C
[root@framework 

RE: Service startup error

[Leschke, Scott]

No it doesn't.  What jar would contain 
org/apache/karaf/specs/locator/OsgiLocator and be missing?

Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Monday, July 16, 2018 10:25 AM
To: user@karaf.apache.org
Subject: Re: Service startup error

Hi Scott,

it doesn't happen when you start with bin/karaf.bat ?

It sounds like a missing jar in the classpath.

Regards
JB

On 16/07/2018 17:11, Leschke, Scott wrote:
> I see this when I start Karaf as a Windows service although it didn't 
> appear to cause any problems at first blush.
> 
>  
> 
> Scott
> 
>  
> 
>  
> 
> Jul 12, 2018 11:00:27 AM org.apache.karaf.main.KarafActivatorManager
> startKarafActivators
> 
> WARNING: Error starting karaf activator 
> org.apache.karaf.specs.activator.Activator from url 
> jar:file:/C:/apache-karaf/apache-karaf-4.2.0/lib/boot/org.apache.karaf
> .specs.activator-4.2.0.jar!/META-INF/MANIFEST.MF
> 
> java.lang.NoClassDefFoundError: 
> org/apache/karaf/specs/locator/OsgiLocator
> 
>     at
> org.apache.karaf.specs.activator.Activator.register(Activator.java:124
> )
> 
>     at
> org.apache.karaf.specs.activator.Activator.start(Activator.java:71)
> 
>     at
> org.apache.karaf.main.KarafActivatorManager.startKarafActivators(Karaf
> ActivatorManager.java:62)
> 
>     at org.apache.karaf.main.Main.launch(Main.java:280)
> 
>     at
> org.apache.karaf.wrapper.internal.service.Main.start(Main.java:55)
> 
>     at
> org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2
> 788)
> 
> Caused by: java.lang.ClassNotFoundException:
> org.apache.karaf.specs.locator.OsgiLocator
> 
>     at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> 
>     at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> 
>     at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
> 
>     at 
> java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 
>     ... 6 more
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Service startup error

[Leschke, Scott]

I see this when I start Karaf as a Windows service although it didn't appear to 
cause any problems at first blush.

Scott


Jul 12, 2018 11:00:27 AM org.apache.karaf.main.KarafActivatorManager 
startKarafActivators
WARNING: Error starting karaf activator 
org.apache.karaf.specs.activator.Activator from url 
jar:file:/C:/apache-karaf/apache-karaf-4.2.0/lib/boot/org.apache.karaf.specs.activator-4.2.0.jar!/META-INF/MANIFEST.MF
java.lang.NoClassDefFoundError: org/apache/karaf/specs/locator/OsgiLocator
at 
org.apache.karaf.specs.activator.Activator.register(Activator.java:124)
at 
org.apache.karaf.specs.activator.Activator.start(Activator.java:71)
at 
org.apache.karaf.main.KarafActivatorManager.startKarafActivators(KarafActivatorManager.java:62)
at org.apache.karaf.main.Main.launch(Main.java:280)
at 
org.apache.karaf.wrapper.internal.service.Main.start(Main.java:55)
at 
org.tanukisoftware.wrapper.WrapperManager$12.run(WrapperManager.java:2788)
Caused by: java.lang.ClassNotFoundException: 
org.apache.karaf.specs.locator.OsgiLocator
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 6 more

Startup error using JRE 10 with 4.2.0

[Leschke, Scott]

I see the following during startup of Karaf 4.2.0 with JDK 10 on Windows Server 
2016.  Has anybody else seen this?  Shall I submit a JIRA?

Regards,

Scott Leschke


2018-07-09T16:00:56,439 | ERROR | paxweb-config-2-thread-1 | Activator  
  | 108 - org.ops4j.pax.web.pax-web-runtime - 7.0.0 | Unable to 
start pax web server: Weaving hook failed.
java.lang.ClassFormatError: Weaving hook failed.
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2479)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
 ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:499) ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1414)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
 ~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:499) ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.JettyServerImpl.(JettyServerImpl.java:97)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.JettyFactoryImpl.createServer(JettyFactoryImpl.java:90)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Stopped.start(ServerControllerImpl.java:443)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.start(ServerControllerImpl.java:81)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerFactoryImpl$1.start(ServerControllerFactoryImpl.java:164)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl$Unconfigured.configure(ServerControllerImpl.java:788)
 ~[?:?]
at 
org.ops4j.pax.web.service.jetty.internal.ServerControllerImpl.configure(ServerControllerImpl.java:97)
 ~[?:?]
at 
org.ops4j.pax.web.service.internal.Activator.updateController(Activator.java:347)
 ~[?:?]
at 
org.ops4j.pax.web.service.internal.Activator.lambda$scheduleUpdateFactory$2(Activator.java:291)
 ~[?:?]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) 
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) 
[?:?]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) 
[?:?]
at java.lang.Thread.run(Thread.java:844) [?:?]
Caused by: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.(ClassReader.java:160) 
~[?:?]
at org.objectweb.asm.ClassReader.(ClassReader.java:143) 
~[?:?]
at org.objectweb.asm.ClassReader.(ClassReader.java:418) 
~[?:?]
at 
org.apache.aries.spifly.dynamic.OSGiFriendlyClassWriter.getCommonSuperClass(OSGiFriendlyClassWriter.java:81)
 ~[?:?]
at 
org.objectweb.asm.ClassWriter.getMergedType(ClassWriter.java:1729) ~[?:?]
at org.objectweb.asm.Frame.merge(Frame.java:1530) ~[?:?]
at org.objectweb.asm.Frame.merge(Frame.java:1441) ~[?:?]
at 
org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1497) ~[?:?]
at 
org.objectweb.asm.commons.LocalVariablesSorter.visitMaxs(LocalVariablesSorter.java:165)
 ~[?:?]
at 
org.objectweb.asm.ClassReader.readCode(ClassReader.java:1738) ~[?:?]
at 
org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1126) ~[?:?]
at org.objectweb.asm.ClassReader.accept(ClassReader.java:698) 
~[?:?]
at org.objectweb.asm.ClassReader.accept(ClassReader.java:500) 
~[?:?]
at 
org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:61)
 ~[?:?]
at 
org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
 ~[?:?]
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
 ~[?:?]

RE: Event admin blacklisting?

[Leschke, Scott]

I'm still having some issues with this.  I have a 2 (maybe 3) event handlers in 
my app and I've recently started having blacklist issues.  I don't know what's 
causing it since the handlers themselves haven't changed and should run very 
quickly, probably under a 10 millis or so in most cases.

Anyway, per Ben Graf's response below, I updated  file 
org.apache.felix.eventadmin.impl.EventAdmin.cfg with the following line:

org.apache.felix.eventadmin.IgnoreTimeout=com.medline.*

Given the description of the property, I expected this to cover all the event 
handlers in my app but I'm still seeing at least one of the handlers get 
blacklisted.  Is the syntax wrong or are there any other recommendations 
regarding this?

Thanks in advance,
Scott

From: Benjamin Graf [mailto:benjamin.g...@gmx.net]
Sent: Wednesday, June 13, 2018 11:16 AM
To: user@karaf.apache.org
Subject: Re: Event admin blacklisting?

Hi Scott,

timeout for blacklisting is 5000ms. (see
http://felix.apache.org/documentation/subprojects/apache-felix-event-admin.html)

Regards

Benjamin


Am 13.06.2018 um 17:41 schrieb Leschke, Scott:
>  I'm having an issue where events sto

Event admin blacklisting?

[Leschke, Scott]

I'm having an issue where events stop getting delivered to a bundle the cause 
of which appears to be the following?  Everything works perfectly until this 
occurs?  What is the timeout it's complaining about?  This is 4.2.0 btw.

Scott

2018-06-06T00:30:51,260 | WARN  | Thread-1 | eventadmin 
  | 3 - org.apache.karaf.services.eventadmin - 4.2.0 | EventAdmin: 
Blacklisting ServiceReference [[org.osgi.service.event.EventHandler] | 
Bundle(medline.mail [146])] due to timeout!
2018-06-06T00:30:51,338 | WARN  | EventAdminThread #19 | eventadmin 
  | 3 - org.apache.karaf.services.eventadmin - 4.2.0 | EventAdmin: 
Blacklisting ServiceReference [[org.osgi.service.event.EventHandler] | 
Bundle(medline.mail [146])] due to timeout!

RE: execute only at first startup?

[Leschke, Scott]

You mean the logic should only execute if the service is "changed", but not in 
the case where the service is stopped and restarted?

-Original Message-
From: Max Spring [mailto:m2spr...@springdot.org] 
Sent: Thursday, June 07, 2018 7:40 PM
To: user@karaf.apache.org
Subject: execute only at first startup?

I've got a Karaf-based service.
Whenever I deploy a new revision of my service, I need to execute some code 
only at the very first startup.
I have this first-time functionality available as a Karaf command which I 
currently run manually each time right after startup after a new deployment.
I'd like to automate this.

I'm thinking of using a marker file somewhere to indicate "first startup".
I'd have a new bundle checking for this file when it starts up. When it detect 
the file, the bundle executes my business logic initialization and then deletes 
the marker file.

Or, is there something better for this scenario?

-Max

RE: karaf with Java 9/10

[Leschke, Scott]

I am.  That's what I'm using, karaf.bat.

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Monday, April 09, 2018 11:59 AM
To: user@karaf.apache.org
Subject: Re: karaf with Java 9/10

Hi,

I guess you are on Windows ?

Because the karaf.bat|karaf.sh should deal with JVM version to use endorsed or 
not.

Regards
JB

On 09/04/2018 18:51, Leschke, Scott wrote:
> */Blah..blah...lib\endorsed is not supported. Endorsed standards and 
> standalone APIs in modular form will be supported in the form of 
> upgradeable modules./*
> 
> */Error: Could not create the JVM./*
> 
> */Error: A fatal exception has occurred. Program will exit./*
> 
> Didn't see anything in the docs about this.  What to do?
> 
> Scott
> 

karaf with Java 9/10

[Leschke, Scott]

Blah..blah.lib\endorsed is not supported. Endorsed standards and standalone 
APIs in modular form will be supported in the form of upgradeable modules.
Error: Could not create the JVM.
Error: A fatal exception has occurred. Program will exit.

Didn't see anything in the docs about this.  What to do?

Scott

RE: configuration updates

[Leschke, Scott]

The initial configuration is created using a .cfg file so it has it, but when I 
edit the configuration (programmatically), I neglected to carry it over so I 
see that it's no longer there.  So don't worry about it for now.  I'll fix that 
and let you know if I still have issues, which I suspect I won't.

Thanks,
Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Friday, April 06, 2018 11:19 AM
To: user@karaf.apache.org
Subject: Re: configuration updates

By the way, just to know, do you have felix.fileinstall.file property on the 
configuration ?

Regards
JB

On 04/06/2018 05:30 PM, Leschke, Scott wrote:
> I thought changes to a service configuration were propagated to the 
> associated .cfg file.  The configuration changes have definitely taken 
> place but I'm not seeing the I'm not seeing the changes reflected in the 
> .cfg.  Was I mistaken?
> This is on 4.2.0 M2 on Windows.
> 
>  
> 
> Thanks,
> 
>  
> 
> Scott
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

configuration updates

[Leschke, Scott]

I thought changes to a service configuration were propagated to the associated 
.cfg file.  The configuration changes have definitely taken place but I'm not 
seeing the I'm not seeing the changes reflected in the .cfg.  Was I mistaken?  
This is on 4.2.0 M2 on Windows.

Thanks,

Scott

RE: Regarding Configuration Types

[Leschke, Scott]

Ø  As for why you don’t get the default - your configuration explicitly 
contains a mapping to the empty string. Defaults only apply when the key isn’t 
present, if it is present then you get the supplied value.

I can get that for String properties I guess and figured that was the answer, 
but for discrete properties, where a mapping without a value will give you an 
error even if a default is specified, it seems that getting the default may be 
more appropriate. Perhaps an annotation could be added that specified whether 
defaulting would occur in this case or not.  I suspect that in most cases, this 
would be the preferred behavior.

A similar approach might be desirable for trimming behavior but having too many 
annotations can make things ugly in a hurry.  Does anybody have a use case 
where maintaining trailing white space in this sort of scenario (I do realize 
that java.util.properties behaves this way) is desirable?  I honestly don’t 
think I’ve ever run into a case where I wanted the whitespace maintained.

Just sayin’  :-)

Regards,

Scott

From: Tim Ward [mailto:tim.w...@paremus.com]
Sent: Monday, February 26, 2018 7:13 AM
To: user@karaf.apache.org
Subject: Re: Regarding Configuration Types

Scott,

Those two issues are actually different things. The first one is to do with the 
defaulting of configuration, the second is to do with how File Install 
interprets property values with trailing spaces.

As for why you don’t get the default - your configuration explicitly contains a 
mapping to the empty string. Defaults only apply when the key isn’t present, if 
it is present then you get the supplied value.

Best Regards,

Tim


On 25 Feb 2018, at 21:14, Ryan Moquin 
<fragility...@gmail.com<mailto:fragility...@gmail.com>> wrote:

If trimming was performed by default on tproperties, wouldn't that place a 
little extra performance overhead into OSGi vs developers just making sure 
there isn't trailing whitespace if they don't want it?  It wouldn't be much, 
but it adds up...

Ryan

On Thu, Feb 22, 2018 at 12:52 PM Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:
I have a configuration type that has a fragment in it as shown below.

@ProviderType
@ObjectClassDefinition(name = "Provider Configuration")
public @interface MetricProviderConfig
{
   String schedule() default "0";
}

If the associated property in a .cfg file exists but has no value, as in:

schedule =

I get the null string “” as opposed to the default which is what I would 
expect. While this is preferable to a null, which I got at some on some earlier 
Karaf release, I would think that you’d get the default whether the property 
didn’t exist or existed with no value.

Another comment, which perhaps is more general to OSGi in this area, is that 
properties aren’t trimmed. I honestly can’t think of a use case where somebody 
would want trailing white space passed in.  Also, if the configuration type 
exposes an enumeration, an error occurs.

@ProviderType
@ObjectClassDefinition(name = "Provider Configuration")
public @interface MetricProviderConfig
{
   MyEnum enumValue() default MyEnum.ENUM_VALUE;
}

So the first property below works, but the second one doesn’t.  Is this by 
design?

enumValue = ENUM_VALUE
enumValue = ENUM_VALUE

Regards,

Scott

RE: On another topic: Creating services programatically again

[Leschke, Scott]

Well, the ConfigurationAdmin.createFactoryConfiguration method call works in 
the version of ConfigurationAdmin that gets installed into Karaf 4.2M2, ie. a 
service gets created and is activated.  If that's not what you're referring to, 
then I guess I'm misunderstanding.

I currently only have 1 instance and it's unlikely I'll ever go to a 
multi-instance setup.  If I ever do go to a such an architecture, the service 
being created would only apply to a single instance and the service would be 
specific to a team who is associated with the instance. In that case, yes I 
imagine that there would be one instance that acted as a manager for the 
others. More likely, each team would get a separate instance to use in their 
own VM thereby keeping things pretty much like they are now. 

I'd have to check to be sure, but I think configuration changes are already 
written out to .cfg files now.  Seems to me that you can make updates to a 
configuration via the Karaf console and they end up in the associated .cfg.  My 
recollection is that it was even careful to not mess up the formatting of the 
.cfg.

Thanks for the help.  I appreciate the input.

Regards,

Scott

-Original Message-
From: David Jencks [mailto:david.a.jen...@gmail.com] 
Sent: Friday, February 23, 2018 5:14 PM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

Nothing R7 is released yet, the specs aren’t final, so I doubt very much that 
karaf implements any of it.

I don’t think you’ve considered very many ramifications of what you’re 
proposing. In my experience an osgi web server has its port and interface 
configured via config admin, so you aren’t going to be able to have two 
instances with the same set of configurations.  Therefore IMO having a CA 
implementation that somehow uses a shared persistence location isn’t going to 
be useful, ignoring whether it’s spec compliant or not (I think not).

If all of your instances have the same services running on them, then you’d 
need all of them to get the stimulus to create the factory configuration, or 
they will respond differently;  with a shared fileinstall directory you get the 
behavior you have now, where one instance gets 2 copies of the service and the 
others presumably get one, or without the shared fileinstall you get one or two 
services on one instance and none on the others.

If one of your instances (or a separate process) is acting as a management 
agent for config admin, then that has to give all the instances the same 
stimulus.  I’m suggesting that since the stimulus for all the other instances 
is fileinstall noticing the new .cfg file, you can use that for the instance 
that is acting as the management agent as well.  Note that config admin is 
asynchronous, so at best the delay is shorter if you create the config in code 
rather than letting fileinstall find it.

There might possibly be a way to configure fileinstall to detect configuration 
changes and write them back out, but when I’ve thought that class of approaches 
to configuration management I’ve decided the behavior is too hard to reason 
about for it to be a plausible solution to anything except making an unusable 
system.  Other people might have different points of view.

david jencks

> On Feb 23, 2018, at 1:49 PM, Leschke, Scott <slesc...@medline.com> wrote:
> 
> The fundamental question is:
> 
> What is the best way to create service instances (from a factory component) 
> programmatically and store the associated configurations such that they 
> persist across installations/upgrades of the platform, preferably using the 
> facilities of the platform itself (ie. no DB).
> Preferably, default configuration values are defined in a single location, 
> code or file, if possible.
> 
> It would seem that at the moment at least, you probably need to lead by 
> writing the .cfg file and just deal with the FIleInstall delay even though it 
> seems to me that using ConfigurationAdmin.createFactoryConfiguration would be 
> the preferred approach.
> 
> Scott
> 
> -Original Message-
> From: Leschke, Scott [mailto:slesc...@medline.com]
> Sent: Friday, February 23, 2018 3:14 PM
> To: user@karaf.apache.org
> Subject: RE: On another topic: Creating services programatically again
> 
> I should have clarified that this is running on Karaf 4.2 M2 so I suppose 
> that's R7.  The only issue with writing the .cfg myself and relying on Felix 
> FileInstall to do its thing is that I really didn't want to have to wait for 
> FIleInstall to hit its poll interval since the UI needs to update the display 
> with the new service.
> 
> I have to wait for the service to get created either way but if I create the 
> configuration first I can look up the associated service by its configuration 
> PID.  It would be if you could have the ConfigurationAdmin service 

RE: On another topic: Creating services programatically again

[Leschke, Scott]

The fundamental question is:

What is the best way to create service instances (from a factory component) 
programmatically and store the associated configurations such that they persist 
across installations/upgrades of the platform, preferably using the facilities 
of the platform itself (ie. no DB).
Preferably, default configuration values are defined in a single location, code 
or file, if possible.

It would seem that at the moment at least, you probably need to lead by writing 
the .cfg file and just deal with the FIleInstall delay even though it seems to 
me that using ConfigurationAdmin.createFactoryConfiguration would be the 
preferred approach.

Scott

-Original Message-
From: Leschke, Scott [mailto:slesc...@medline.com] 
Sent: Friday, February 23, 2018 3:14 PM
To: user@karaf.apache.org
Subject: RE: On another topic: Creating services programatically again

I should have clarified that this is running on Karaf 4.2 M2 so I suppose 
that's R7.  The only issue with writing the .cfg myself and relying on Felix 
FileInstall to do its thing is that I really didn't want to have to wait for 
FIleInstall to hit its poll interval since the UI needs to update the display 
with the new service.

I have to wait for the service to get created either way but if I create the 
configuration first I can look up the associated service by its configuration 
PID.  It would be if you could have the ConfigurationAdmin service write a .cfg 
file at the location of your choosing but that doesn't seem to be the case.

Scott

-Original Message-
From: David Jencks [mailto:david.a.jen...@gmail.com]
Sent: Friday, February 23, 2018 2:57 PM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

I’m not sure what all of your code is doing. However, pre R7 you can’t specify 
the pid of a factory configuration. You might get the desired result by, on 
only one karaf instance, writing the .cfg file without creating a factory 
configuration yourself.

David Jencks 

Sent from my iPhone

> On Feb 23, 2018, at 11:59 AM, Leschke, Scott <slesc...@medline.com> wrote:
> 
> That should have read "a service from a factory".  To clarify, I have a 
> component that is a factory (component), I create a new instance of the 
> configuration and service using cfgAdmin.createFactoryConfiguration as shown 
> below.  I have a single Karaf instance but if I had multiple, since my 
> hierarchy is outside of the Karaf installation, I think they would all just 
> look at the same folder structure.
> 
> My experience that Karaf DOES NOT write a .cfg file when a configuration is 
> created.  If it wrote a file to the location given by 
> "felix.fileinstall.filename", this would solve my problem.
> 
>private void createConfig(String cpid, String dir, String name, 
> Map<String,Object> props)
>throws Exception
>{
>Configuration conf =
> parent.cfgAdmin.createFactoryConfiguration(cpid, "?");
> 
>dir  = (dir.endsWith("/") ? dir : dir + '/');
>name = name.replaceAll(" ", "_").toLowerCase();
>File cfg = new File(dir + cpid + '-' + name + ".cfg");
> 
>Dictionary<String,Object> confProps = toDictionary(props);
>confProps.put("felix.fileinstall.filename",
> cfg.toURI().toString());
> 
>try
>{
>conf.update(confProps);
> 
>// Get the properties for the new service object
>props = getProps(conf.getPid());
> 
>// Create .cfg file with initial property set
>ITemplate tmp = parent.templateMgr.getTemplate( 
> configTemplates.get(cpid) );
>tmp.bind("cfg", props);
> 
>try (FileLineWriter w = new FileLineWriter(cfg))
>{
>w.putLine(tmp.render());
>}
>}
>catch (Exception e)
>{
>cfg.delete();
>conf.delete();
>throw e;
>}
>}
> 
> -Original Message-
> From: David Jencks [mailto:david.a.jen...@gmail.com]
> Sent: Friday, February 23, 2018 12:23 PM
> To: user@karaf.apache.org
> Subject: Re: On another topic: Creating services programatically again
> 
> What do you mean by “create instances of service from a factory” and how 
> would doing this result in a configuration at all?
> How are you proposing to replicate the configuration or .cfg file across 
> multiple karaf instances?
> 
> I’m not sure if or when karaf writes out a .cfg for a ca configuration 
> created through the ca api, but doing both of creating a configuration and 
> writing out a .cfg file is pretty sure to result in 2 instances, at least 
> until the r7 ca ch

RE: On another topic: Creating services programatically again

[Leschke, Scott]

I should have clarified that this is running on Karaf 4.2 M2 so I suppose 
that's R7.  The only issue with writing the .cfg myself and relying on Felix 
FileInstall to do its thing is that I really didn't want to have to wait for 
FIleInstall to hit its poll interval since the UI needs to update the display 
with the new service.

I have to wait for the service to get created either way but if I create the 
configuration first I can look up the associated service by its configuration 
PID.  It would be if you could have the ConfigurationAdmin service write a .cfg 
file at the location of your choosing but that doesn't seem to be the case.

Scott

-Original Message-
From: David Jencks [mailto:david.a.jen...@gmail.com] 
Sent: Friday, February 23, 2018 2:57 PM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

I’m not sure what all of your code is doing. However, pre R7 you can’t specify 
the pid of a factory configuration. You might get the desired result by, on 
only one karaf instance, writing the .cfg file without creating a factory 
configuration yourself.

David Jencks 

Sent from my iPhone

> On Feb 23, 2018, at 11:59 AM, Leschke, Scott <slesc...@medline.com> wrote:
> 
> That should have read "a service from a factory".  To clarify, I have a 
> component that is a factory (component), I create a new instance of the 
> configuration and service using cfgAdmin.createFactoryConfiguration as shown 
> below.  I have a single Karaf instance but if I had multiple, since my 
> hierarchy is outside of the Karaf installation, I think they would all just 
> look at the same folder structure.
> 
> My experience that Karaf DOES NOT write a .cfg file when a configuration is 
> created.  If it wrote a file to the location given by 
> "felix.fileinstall.filename", this would solve my problem.
> 
>private void createConfig(String cpid, String dir, String name, 
> Map<String,Object> props)
>throws Exception
>{
>Configuration conf = 
> parent.cfgAdmin.createFactoryConfiguration(cpid, "?");
> 
>dir  = (dir.endsWith("/") ? dir : dir + '/');
>name = name.replaceAll(" ", "_").toLowerCase();
>File cfg = new File(dir + cpid + '-' + name + ".cfg");
> 
>Dictionary<String,Object> confProps = toDictionary(props);
>confProps.put("felix.fileinstall.filename", 
> cfg.toURI().toString());
> 
>try
>{
>conf.update(confProps);
> 
>// Get the properties for the new service object
>props = getProps(conf.getPid());
> 
>// Create .cfg file with initial property set
>ITemplate tmp = parent.templateMgr.getTemplate( 
> configTemplates.get(cpid) );
>tmp.bind("cfg", props);
> 
>try (FileLineWriter w = new FileLineWriter(cfg))
>{
>w.putLine(tmp.render());
>}
>}
>catch (Exception e)
>{
>cfg.delete();
>conf.delete();
>throw e;
>}
>}
> 
> -Original Message-
> From: David Jencks [mailto:david.a.jen...@gmail.com]
> Sent: Friday, February 23, 2018 12:23 PM
> To: user@karaf.apache.org
> Subject: Re: On another topic: Creating services programatically again
> 
> What do you mean by “create instances of service from a factory” and how 
> would doing this result in a configuration at all?
> How are you proposing to replicate the configuration or .cfg file across 
> multiple karaf instances?
> 
> I’m not sure if or when karaf writes out a .cfg for a ca configuration 
> created through the ca api, but doing both of creating a configuration and 
> writing out a .cfg file is pretty sure to result in 2 instances, at least 
> until the r7 ca changes let you specify the pid of a factory configuration.
> 
> David Jencks
> 
> Sent from my iPhone
> 
>> On Feb 23, 2018, at 9:20 AM, Leschke, Scott <slesc...@medline.com> wrote:
>> 
>> That's exactly what I'm currently doing but I want to create instances of 
>> service from a factory and write the resulting configuration to .cfg.  I 
>> need to do this so that I can save the configurations across Karaf installs. 
>>  My app hierarchy resides outside of the Karaf installation so this works 
>> well.  Unfortunately, the code I show below gives me two separate service 
>> instances.
>> 
>> Scott
>> 
>> -Original Message-
>> From: David Jencks [mailto:david.a.jen...@gmail.com]
>> Sent: Friday, February 23, 2018 11:03 AM
>> To: user@karaf.apache.org
>> Subject:

RE: On another topic: Creating services programatically again

[Leschke, Scott]

That's exactly what I'm currently doing but I want to create instances of 
service from a factory and write the resulting configuration to .cfg.  I need 
to do this so that I can save the configurations across Karaf installs.  My app 
hierarchy resides outside of the Karaf installation so this works well.  
Unfortunately, the code I show below gives me two separate service instances.

Scott

-Original Message-
From: David Jencks [mailto:david.a.jen...@gmail.com] 
Sent: Friday, February 23, 2018 11:03 AM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

Rather than using a relatively low level api such as ManagedServiceFactory I’d 
suggest considering a ds component with configuration required and supplying it 
with factory configurations to get multiple instances. By using a configuration 
annotation you can have the configuration injected in a typed form and you can 
supply default values for any keys not present in the factory configuration.

David Jencks 

Sent from my iPhone

> On Feb 23, 2018, at 6:32 AM, Leschke, Scott <slesc...@medline.com> wrote:
> 
> OK, that sounds like it may be a good approach.  Could you point me to the 
> Decanter code as a reference?
> 
> Thanks,
> 
> Scott
> 
> -Original Message-
> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> Sent: Thursday, February 22, 2018 9:53 PM
> To: user@karaf.apache.org
> Subject: Re: On another topic: Creating services programatically again
> 
> Hi Scott,
> 
> Service Managed Factory is the other way around: you start from the cfg file, 
> then the service is created. The content of the file can be default or 
> whatever, it doesn't matter.
> 
> Basically, you would have:
> 
> etc/org.scott.foo-one.cfg
> etc/org.scott.foo-two.cfg
> etc/org.scott.foo-three.cfg
> 
> with the corresponding service for each cfg file. If you create 
> etc/org.scott.foo-four.cfg, then, automatically,  you will have a new 
> corresponding service created.
> 
> For instance, it's what we are using in Decanter for the JMX collector: you 
> can create a new JMX collector "on the fly", just adding a new 
> etc/org.apache.karaf.decanter.collector.jmx-foobar.cfg file.
> 
> Regards
> JB
> 
>> On 02/23/2018 04:47 AM, Leschke, Scott wrote:
>> Thanks JB,
>> 
>> Initially, the .cfg would be populated almost entirely with the defaults  
>> the service receives using a configuration type so the idea is that the 
>> service creation needs to come first so that the service can be used to get 
>> the values to write the .cfg.
>> 
>> Is there a way to get those value without actually having a service instance 
>> or hard-coding them? 
>> 
>> Scott
>> 
>> -Original Message-
>> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
>> Sent: Thursday, February 22, 2018 9:38 PM
>> To: user@karaf.apache.org
>> Subject: Re: On another topic: Creating services programatically 
>> again
>> 
>> Hi Scott,
>> 
>> why don't use a managed service factory ?
>> 
>> It would automatically create a service based on a cfg. So for your user, he 
>> creates the cfg file, and then, automatically, the corresponding service is 
>> created.
>> 
>> Thoughts ?
>> 
>> Regards
>> JB
>> 
>>> On 02/22/2018 09:18 PM, Leschke, Scott wrote:
>>> As I mentioned a few weeks ago, I'm trying to create a service 
>>> instance programmatically and write the associated .cfg file for it.
>>> Based on feedback I got, I create the following method.
>>> 
>>>  
>>> 
>>> The goal is to create the service instance and then get its 
>>> configuration which at this point will mostly be the defaults that 
>>> it receives in its configuration type (hence my previous post). It 
>>> /appears/ to work, except what is really happening is that I get two 
>>> services. One is created by createFactoryConfguration call and the 
>>> other by Felix FileInstall after the .cfg file is written.
>>> 
>>>  
>>> 
>>> Actually I'm a bit surprised that placeholder .cfg file isn't 
>>> created if property /felix.fileinstall.filename/is defined, as I 
>>> think that would solve this problem, but perhaps there's another way?
>>> 
>>>  
>>> 
>>> Thoughts?
>>> 
>>> * *
>>> 
>>> * *
>>> 
>>> *private**void* createConfig(String cpid, String dir, String name, 
>>> Map<String,Object> props)
>>> 
>>>*throws* Exception
>>> 
>>> {
>>> 
>>

RE: Pax connection pools

[Leschke, Scott]

Just another data point on this.   Another reason I don't think Hikari is 
getting initialized.  Note the pool name " HikariPool-9 - is starting".  I 
always give my pools an explicit name, and the log message is using a Hikari 
default name.

2018-02-23T09:28:12,725 | INFO  | CM Configuration Updater (Update: 
pid=org.ops4j.datasource.787a9126-3325-47e5-a5a9-8c7ad43f0ed8) | 
MultiServiceTracker  | 56 - org.ops4j.pax.jdbc.config - 1.1.0 | 
Found service org.ops4j.pax.jdbc.pool.common.PooledDataSourceFactory with 
filter 
(&(objectClass=org.ops4j.pax.jdbc.pool.common.PooledDataSourceFactory)(pool=hikari)(xa=false))
2018-02-23T09:28:12,725 | INFO  | CM Configuration Updater (Update: 
pid=org.ops4j.datasource.787a9126-3325-47e5-a5a9-8c7ad43f0ed8) | 
DataSourceRegistration   | 56 - org.ops4j.pax.jdbc.config - 1.1.0 | 
Found DataSourceFactory. Creating DataSource bam/ds/sap/sidecar
2018-02-23T09:28:12,778 | INFO  | CM Configuration Updater (Update: 
pid=org.ops4j.datasource.787a9126-3325-47e5-a5a9-8c7ad43f0ed8) | 
HikariDataSource | 145 - com.zaxxer.HikariCP - 2.4.1 | 
HikariPool-9 - is starting.

Regards,

Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Monday, February 19, 2018 11:21 PM
To: user@karaf.apache.org
Subject: Re: Pax connection pools

Hi Scott,

let me take a look. It could be related to pax-jdbc-config and the related 
features declaration.

Regards
JB

On 20/02/2018 01:36, Leschke, Scott wrote:
> I've emailed about this before but some time ago I mentioned that I 
> didn't think that the PAX connection pools were initializing the 
> underlying CP implementation (Hikari in my case) properly. In 
> particular, connections are getting dropped after 30 mins (the Hikari
> default) even though connection maxLifetime is set to inifinite (0) 
> and idleTimeout is set to 8 hrs.
> 
> Christian sent me a link to the PAX Hikari initialization code which 
> certainly looked correct. This lead me to believe that the problem was 
> not with PAX but the Hikari version that is bundled with it. While I'm 
> not positive this is the case, I suspect it is.
> 
> Might it be possible for PAX to log the pool implementations 
> configuration AFTER it creates the pool?  Also, will the version of 
> Hikari be updated in the next release of Karaf?  The latest version 
> appears to be 2.7.7.  I believe the version that comes with the most 
> recent version of Karaf is still at 2.4.1.
> 
> Regards,
> 
> Scott
> 

RE: On another topic: Creating services programatically again

[Leschke, Scott]

OK, that sounds like it may be a good approach.  Could you point me to the 
Decanter code as a reference?

Thanks,

Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Thursday, February 22, 2018 9:53 PM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

Hi Scott,

Service Managed Factory is the other way around: you start from the cfg file, 
then the service is created. The content of the file can be default or 
whatever, it doesn't matter.

Basically, you would have:

etc/org.scott.foo-one.cfg
etc/org.scott.foo-two.cfg
etc/org.scott.foo-three.cfg

with the corresponding service for each cfg file. If you create 
etc/org.scott.foo-four.cfg, then, automatically,  you will have a new 
corresponding service created.

For instance, it's what we are using in Decanter for the JMX collector: you can 
create a new JMX collector "on the fly", just adding a new 
etc/org.apache.karaf.decanter.collector.jmx-foobar.cfg file.

Regards
JB

On 02/23/2018 04:47 AM, Leschke, Scott wrote:
> Thanks JB,
> 
> Initially, the .cfg would be populated almost entirely with the defaults  the 
> service receives using a configuration type so the idea is that the service 
> creation needs to come first so that the service can be used to get the 
> values to write the .cfg.
> 
> Is there a way to get those value without actually having a service instance 
> or hard-coding them? 
> 
> Scott
> 
> -Original Message-
> From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net]
> Sent: Thursday, February 22, 2018 9:38 PM
> To: user@karaf.apache.org
> Subject: Re: On another topic: Creating services programatically again
> 
> Hi Scott,
> 
> why don't use a managed service factory ?
> 
> It would automatically create a service based on a cfg. So for your user, he 
> creates the cfg file, and then, automatically, the corresponding service is 
> created.
> 
> Thoughts ?
> 
> Regards
> JB
> 
> On 02/22/2018 09:18 PM, Leschke, Scott wrote:
>> As I mentioned a few weeks ago, I'm trying to create a service 
>> instance programmatically and write the associated .cfg file for it.
>> Based on feedback I got, I create the following method.
>>
>>  
>>
>> The goal is to create the service instance and then get its 
>> configuration which at this point will mostly be the defaults that it 
>> receives in its configuration type (hence my previous post). It 
>> /appears/ to work, except what is really happening is that I get two 
>> services. One is created by createFactoryConfguration call and the 
>> other by Felix FileInstall after the .cfg file is written.
>>
>>  
>>
>> Actually I'm a bit surprised that placeholder .cfg file isn't created 
>> if property /felix.fileinstall.filename/is defined, as I think that 
>> would solve this problem, but perhaps there's another way?
>>
>>  
>>
>> Thoughts?
>>
>> * *
>>
>> * *
>>
>> *private**void* createConfig(String cpid, String dir, String name, 
>> Map<String,Object> props)
>>
>>    *throws* Exception
>>
>> {
>>
>>    Configuration conf =
>> parent.cfgAdmin.createFactoryConfiguration(cpid, "?");
>>
>>  
>>
>>    dir  = (dir.endsWith("/") ? dir : dir + '/');
>>
>>    name = name.replaceAll(" ", "_").toLowerCase();
>>
>>    File cfg = *new* File(dir + cpid + '-' + name + ".cfg");
>>
>>  
>>
>>    Dictionary<String,Object> confProps = toDictionary(props);
>>
>>    confProps.put("felix.fileinstall.filename",
>> cfg.toURI().toString());
>>
>>  
>>
>>    *try*
>>
>>    {
>>
>>   conf.update(confProps);
>>
>>  
>>
>>   // Get the properties for the new service object
>>
>>   props = getProps(conf.getPid());
>>
>>  
>>
>>   // Create .cfg file with initial property set
>>
>>   ITemplate tmp = parent.templateMgr.getTemplate(
>> configTemplates.get(cpid) );
>>
>>   tmp.bind("cfg", props);
>>
>>  
>>
>>   *try* (FileLineWriter w = *new* FileLineWriter(cfg))
>>
>>   {
>>
>>  w.putLine(tmp.render());
>>
>>   }
>>
>>    }
>>
>>    *catch* (Exception e)
>>
>>    {
>>
>>   cfg.delete();
>>
>>   conf.delete();
>>
>>   *throw* e;
>>
>>    }
>>
>> }
>>
>>  
>>
> 
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

RE: On another topic: Creating services programatically again

[Leschke, Scott]

Thanks JB,

Initially, the .cfg would be populated almost entirely with the defaults  the 
service receives using a configuration type so the idea is that the service 
creation needs to come first so that the service can be used to get the values 
to write the .cfg.

Is there a way to get those value without actually having a service instance or 
hard-coding them? 

Scott

-Original Message-
From: Jean-Baptiste Onofré [mailto:j...@nanthrax.net] 
Sent: Thursday, February 22, 2018 9:38 PM
To: user@karaf.apache.org
Subject: Re: On another topic: Creating services programatically again

Hi Scott,

why don't use a managed service factory ?

It would automatically create a service based on a cfg. So for your user, he 
creates the cfg file, and then, automatically, the corresponding service is 
created.

Thoughts ?

Regards
JB

On 02/22/2018 09:18 PM, Leschke, Scott wrote:
> As I mentioned a few weeks ago, I'm trying to create a service 
> instance programmatically and write the associated .cfg file for it.  
> Based on feedback I got, I create the following method.
> 
>  
> 
> The goal is to create the service instance and then get its 
> configuration which at this point will mostly be the defaults that it 
> receives in its configuration type (hence my previous post). It 
> /appears/ to work, except what is really happening is that I get two 
> services. One is created by createFactoryConfguration call and the 
> other by Felix FileInstall after the .cfg file is written.
> 
>  
> 
> Actually I'm a bit surprised that placeholder .cfg file isn't created 
> if property /felix.fileinstall.filename/is defined, as I think that 
> would solve this problem, but perhaps there's another way?
> 
>  
> 
> Thoughts?
> 
> * *
> 
> * *
> 
> *private**void* createConfig(String cpid, String dir, String name, 
> Map<String,Object> props)
> 
>    *throws* Exception
> 
> {
> 
>    Configuration conf = 
> parent.cfgAdmin.createFactoryConfiguration(cpid, "?");
> 
>  
> 
>    dir  = (dir.endsWith("/") ? dir : dir + '/');
> 
>    name = name.replaceAll(" ", "_").toLowerCase();
> 
>    File cfg = *new* File(dir + cpid + '-' + name + ".cfg");
> 
>  
> 
>    Dictionary<String,Object> confProps = toDictionary(props);
> 
>    confProps.put("felix.fileinstall.filename", 
> cfg.toURI().toString());
> 
>  
> 
>    *try*
> 
>    {
> 
>   conf.update(confProps);
> 
>  
> 
>   // Get the properties for the new service object
> 
>   props = getProps(conf.getPid());
> 
>  
> 
>   // Create .cfg file with initial property set
> 
>   ITemplate tmp = parent.templateMgr.getTemplate(
> configTemplates.get(cpid) );
> 
>   tmp.bind("cfg", props);
> 
>  
> 
>   *try* (FileLineWriter w = *new* FileLineWriter(cfg))
> 
>   {
> 
>  w.putLine(tmp.render());
> 
>   }
> 
>    }
> 
>    *catch* (Exception e)
> 
>    {
> 
>   cfg.delete();
> 
>   conf.delete();
> 
>   *throw* e;
> 
>    }
> 
> }
> 
>  
> 

--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

On another topic: Creating services programatically again

[Leschke, Scott]

As I mentioned a few weeks ago, I'm trying to create a service instance 
programmatically and write the associated .cfg file for it.  Based on feedback 
I got, I create the following method.

The goal is to create the service instance and then get its configuration which 
at this point will mostly be the defaults that it receives in its configuration 
type (hence my previous post). It appears to work, except what is really 
happening is that I get two services. One is created by 
createFactoryConfguration call and the other by Felix FileInstall after the 
.cfg file is written.

Actually I'm a bit surprised that placeholder .cfg file isn't created if 
property felix.fileinstall.filename is defined, as I think that would solve 
this problem, but perhaps there's another way?

Thoughts?


private void createConfig(String cpid, String dir, String name, 
Map props)
   throws Exception
{
   Configuration conf = parent.cfgAdmin.createFactoryConfiguration(cpid, 
"?");

   dir  = (dir.endsWith("/") ? dir : dir + '/');
   name = name.replaceAll(" ", "_").toLowerCase();
   File cfg = new File(dir + cpid + '-' + name + ".cfg");

   Dictionary confProps = toDictionary(props);
   confProps.put("felix.fileinstall.filename", cfg.toURI().toString());

   try
   {
  conf.update(confProps);

  // Get the properties for the new service object
  props = getProps(conf.getPid());

  // Create .cfg file with initial property set
  ITemplate tmp = parent.templateMgr.getTemplate( 
configTemplates.get(cpid) );
  tmp.bind("cfg", props);

  try (FileLineWriter w = new FileLineWriter(cfg))
  {
 w.putLine(tmp.render());
  }
   }
   catch (Exception e)
   {
  cfg.delete();
  conf.delete();
  throw e;
   }
}

Regarding Configuration Types

[Leschke, Scott]

I have a configuration type that has a fragment in it as shown below.

@ProviderType
@ObjectClassDefinition(name = "Provider Configuration")
public @interface MetricProviderConfig
{
   String schedule() default "0";
}

If the associated property in a .cfg file exists but has no value, as in:

schedule =

I get the null string "" as opposed to the default which is what I would 
expect. While this is preferable to a null, which I got at some on some earlier 
Karaf release, I would think that you'd get the default whether the property 
didn't exist or existed with no value.

Another comment, which perhaps is more general to OSGi in this area, is that 
properties aren't trimmed. I honestly can't think of a use case where somebody 
would want trailing white space passed in.  Also, if the configuration type 
exposes an enumeration, an error occurs.

@ProviderType
@ObjectClassDefinition(name = "Provider Configuration")
public @interface MetricProviderConfig
{
   MyEnum enumValue() default MyEnum.ENUM_VALUE;
}

So the first property below works, but the second one doesn't.  Is this by 
design?

enumValue = ENUM_VALUE
enumValue = ENUM_VALUE

Regards,

Scott

Pax connection pools

[Leschke, Scott]

I've emailed about this before but some time ago I mentioned that I didn't 
think that the PAX connection pools were initializing the underlying CP 
implementation (Hikari in my case) properly. In particular, connections are 
getting dropped after 30 mins (the Hikari default) even though connection 
maxLifetime is set to inifinite (0) and idleTimeout is set to 8 hrs.
Christian sent me a link to the PAX Hikari initialization code which certainly 
looked correct. This lead me to believe that the problem was not with PAX but 
the Hikari version that is bundled with it. While I'm not positive this is the 
case, I suspect it is.

Might it be possible for PAX to log the pool implementations configuration 
AFTER it creates the pool?  Also, will the version of Hikari be updated in the 
next release of Karaf?  The latest version appears to be 2.7.7.  I believe the 
version that comes with the most recent version of Karaf is still at 2.4.1.

Regards,

Scott

RE: Transaction Control

[Leschke, Scott]

As always, thx for the response. I’ll submit a Jira first chance I get.  
Unfortunately, I need to head out of town in a little while and may not get to 
it until Monday.

Scott

From: Tim Ward [mailto:tim.w...@paremus.com]
Sent: Thursday, January 18, 2018 9:03 AM
To: user@karaf.apache.org
Subject: Re: Transaction Control

Hi Scott,

Those are the two bundles that you need. At a guess Karaf is unhappy because 
the Aries bundles substitutably export the API packages that they need 
(including config admin) for ease of deployment. When installing bundles Karaf 
sometimes attempts some interesting package rewiring operations and kills its 
own console, which is (I guess) what’s happening here. It’s hard to be sure 
though…

Tim


On 16 Jan 2018, at 21:04, Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:

I’ve been trying to integrate this into my app. I just pulled down the latest 
(0.0.3) jars from Maven Central.  As far as I can tell, the two bundles I need 
are
tx-control-service-local
tx-control-provider-jdbc-local

I can drop the first one into my deploy directory and it tells me it needs the 
second.  As soon as I try to deploy the second jar, the console stops 
recognizing commands or hangs (at least that’s the appearance).  The  Following 
is what I see in the log.  Note that I’m using 4.2.0.M2.


2018-01-16T14:38:17,751 | INFO  | fileinstall-c:/bam | fileinstall  
| 9 - org.apache.felix.fileinstall - 3.6.4 | Installing bundle 
tx-control-provider-jdbc-local / 0.0.3
2018-01-16T14:38:17,813 | INFO  | FelixFrameworkWiring | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.event/4.2.0.M2
2018-01-16T14:38:17,820 | INFO  | FelixFrameworkWiring | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.features.command/4.2.0.M2
2018-01-16T14:38:17,828 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
SLF4J API support.
2018-01-16T14:38:17,828 | INFO  | activator-1-thread-2 | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.kar.core/4.2.0.M2
2018-01-16T14:38:17,828 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Jakarta Commons Logging API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Log4J API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Avalon Logger API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling JULI 
Logger API support.
2018-01-16T14:38:17,829 | INFO  | activator-1-thread-1 | HttpServiceFactoryImpl 
  | 105 - org.ops4j.pax.web.pax-web-runtime - 6.1.0 | Unbinding bundle: 
[org.apache.karaf.webconsole.features [111]]
2018-01-16T14:38:17,830 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Log4J v2 API support.
2018-01-16T14:38:17,831 | INFO  | activator-1-thread-1 | FeaturesPlugin 
  | 111 - org.apache.karaf.webconsole.features - 4.2.0.M2 | Features 
plugin deactivated
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.BundleStateMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9<mailto:org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9>
 with name 
osgi.core:type=bundleState,version=1.7,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9<mailto:org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9>
 with name 
osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.FrameworkMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9<mailto:org.apache.karaf.management.internal.E

Transaction Control

[Leschke, Scott]

I've been trying to integrate this into my app. I just pulled down the latest 
(0.0.3) jars from Maven Central.  As far as I can tell, the two bundles I need 
are
tx-control-service-local
tx-control-provider-jdbc-local

I can drop the first one into my deploy directory and it tells me it needs the 
second.  As soon as I try to deploy the second jar, the console stops 
recognizing commands or hangs (at least that's the appearance).  The  Following 
is what I see in the log.  Note that I'm using 4.2.0.M2.


2018-01-16T14:38:17,751 | INFO  | fileinstall-c:/bam | fileinstall  
| 9 - org.apache.felix.fileinstall - 3.6.4 | Installing bundle 
tx-control-provider-jdbc-local / 0.0.3
2018-01-16T14:38:17,813 | INFO  | FelixFrameworkWiring | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.event/4.2.0.M2
2018-01-16T14:38:17,820 | INFO  | FelixFrameworkWiring | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.features.command/4.2.0.M2
2018-01-16T14:38:17,828 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
SLF4J API support.
2018-01-16T14:38:17,828 | INFO  | activator-1-thread-2 | CommandExtension   
  | 33 - org.apache.karaf.shell.core - 4.2.0.M2 | Unregistering 
commands for bundle org.apache.karaf.kar.core/4.2.0.M2
2018-01-16T14:38:17,828 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Jakarta Commons Logging API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Log4J API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Avalon Logger API support.
2018-01-16T14:38:17,829 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling JULI 
Logger API support.
2018-01-16T14:38:17,829 | INFO  | activator-1-thread-1 | HttpServiceFactoryImpl 
  | 105 - org.ops4j.pax.web.pax-web-runtime - 6.1.0 | Unbinding bundle: 
[org.apache.karaf.webconsole.features [111]]
2018-01-16T14:38:17,830 | INFO  | FelixFrameworkWiring | Activator  
  | 6 - org.ops4j.pax.logging.pax-logging-api - 1.10.1 | Disabling 
Log4J v2 API support.
2018-01-16T14:38:17,831 | INFO  | activator-1-thread-1 | FeaturesPlugin 
  | 111 - org.apache.karaf.webconsole.features - 4.2.0.M2 | Features 
plugin deactivated
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.BundleStateMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9 with 
name 
osgi.core:type=bundleState,version=1.7,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9 with 
name 
osgi.compendium:service=cm,version=1.3,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.FrameworkMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9 with 
name 
osgi.core:type=framework,version=1.7,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,870 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.ServiceStateMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9 with 
name 
osgi.core:type=serviceState,version=1.7,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,871 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 1.1.7 | Unregistering 
org.osgi.jmx.framework.PackageStateMBean to MBeanServer 
org.apache.karaf.management.internal.EventAdminMBeanServerWrapper@700031b9 with 
name 
osgi.core:type=packageState,version=1.5,framework=org.apache.felix.framework,uuid=cac40ac4-12dd-4cb5-8ded-1f73370df0aa
2018-01-16T14:38:17,871 | INFO  | FelixFrameworkWiring | core   
  | 12 - org.apache.aries.jmx.core - 

RE: [osgi-dev] Create instance of factory configuration at runtime

[Leschke, Scott]

Hi Tim,

Thanks for the response. Regarding

  *   It’s important to remember that every time you call 
“createFactoryConfiguration” you’re getting a *new* configuration, not updating 
an existing one. The code snipped below will create an increasing number of 
configurations over time
Yes, I’m aware of that.  That’s what I want.  I just want / need to be able to 
create a service instance in response to a form being filled out. Writing a 
.cfg file isn’t optimal do to the polling delay but I need to be able to place 
the .cfg at a particular location so I create the Configuration object after 
which I create the associated .cfg file in the correct location.  Seems to work 
well enough, at least to the level I’ve tested it thus far.

  *   You don’t set the PID or FACTORYPID in the configuration dictionary. 
Config Admin does that for you.
I didn’t expect this to be the case but the example that I received seemed to 
indicate that it was necessary.  I think it was just intended for context but 
wasn’t sure.

My question regarding location was mostly just a curiosity type thing. Just 
thought I’d ask.

Scott

From: Tim Ward [mailto:tim.w...@paremus.com]
Sent: Monday, December 18, 2017 5:04 AM
To: user@karaf.apache.org
Subject: Re: [osgi-dev] Create instance of factory configuration at runtime

Hi Scott,

A few things:


  *   It’s important to remember that every time you call 
“createFactoryConfiguration” you’re getting a *new* configuration, not updating 
an existing one. The code snipped below will create an increasing number of 
configurations over time
  *   You don’t set the PID or FACTORYPID in the configuration dictionary. 
Config Admin does that for you.
  *   You will need to be sure that you don’t end up infinitely looping if your 
component ever attempts to update its own configuration.

In answer to your earlier question about the bundle location parameter - it is 
supposed to match against the URL from which the bundle was installed 
(literally the bundle location that you can get from the bundle). You can do 
targeting of pids against symbolicname/version, but that’s done in a different 
way. If you’re interested I can recommend reading the Config Admin spec.

Tim




On 15 Dec 2017, at 22:11, Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:

Hi again Michael,

Just to be clear, you’re saying that something like the following will achieve 
the desired affect:

@Reference
volatile ConfigurationAdmin ca;

Dictionary<String,Object> serviceProps = 
toDictionary(previouslyInitializedServiceProperties);

serviceProps.put(ConfigurationAdmin.SERVICE_FACTORYPID, “my.factory.pid”);
serviceProps.put(“org.apache.felix.fileinstall.filename”, 
“my.service.config.path”);

ca.createFactoryConfiguration(“my.factory.pid”, “?”)
.update(serviceProps);

// Manually write the .cfg at the previously specified location.
writeCfgHere(“my.service.config.path”);

Is this a correct understanding?  If so, my only comment would be that it would 
seem that respecifying the factory PID seems as it’s given in the call to 
createFactoryConfiguration.

Scott

From: Michael Wirth [mailto:mwi...@apollon.de]
Sent: Friday, December 15, 2017 2:09 PM
To: Leschke, Scott
Cc: OSGi Developer Mail List
Subject: Re: [osgi-dev] Create instance of factory configuration at runtime

Hi Scott,

I did a short successful test. See the following steps:

1. create a new configuration: Configuration config = 
ca.createFactoryConfiguration(factoryPid, „?“);
2. create and set the following properties: prop.put(„service.factoryPid“, 
factoryPid); prop.put(„felix.fileinstall.filename“, path), 
prop.put(„service.factoryPid“, factoryPid); config.update(prop);
3. create the configurationfile using variable path (same as for 
„felix.fileinstall.filename“). Managed by Fileinstall.

After a click on a button on a webpage the configuration was created and 
displayed without delay.
If the file is changed, the webpage UI gets updated and the Web Console shows 
the new value(s).
If I change a value in the Web Console the value in the webpage UI and in the 
file is changed, and so on ...

It was only a short test based on an idea, so no guarantee.

Michael

Am 15.12.2017 um 17:56 schrieb Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>>:

Hi Michael,

Thanks for the response. Yes I’m aware of that mechanism. That’s part of 
Karaf’s hot deploy scheme which I’ve used extensively to date. What I need to 
do is create new service instances from a UI and have the created services 
available immediately, i.e. without the delay, so that the UI can update 
without a refresh.

I know that if you modify a service programmatically, the corresponding .cfg, 
if the service has one, is updated.  I can’t see anyway to tell the CA service 
to persist the new service configuration to a particular location. For my app, 
I’ve overridden the org.apache.felix.fileinstall.dir-deploy.cfg file with my 

RE: [osgi-dev] Create instance of factory configuration at runtime

[Leschke, Scott]

Hi again Michael,

Just to be clear, you’re saying that something like the following will achieve 
the desired affect:

@Reference
volatile ConfigurationAdmin ca;

Dictionary<String,Object> serviceProps = 
toDictionary(previouslyInitializedServiceProperties);

serviceProps.put(ConfigurationAdmin.SERVICE_FACTORYPID, “my.factory.pid”);
serviceProps.put(“org.apache.felix.fileinstall.filename”, 
“my.service.config.path”);

ca.createFactoryConfiguration(“my.factory.pid”, “?”)
.update(serviceProps);

// Manually write the .cfg at the previously specified location.
writeCfgHere(“my.service.config.path”);

Is this a correct understanding?  If so, my only comment would be that it would 
seem that respecifying the factory PID seems as it’s given in the call to 
createFactoryConfiguration.

Scott

From: Michael Wirth [mailto:mwi...@apollon.de]
Sent: Friday, December 15, 2017 2:09 PM
To: Leschke, Scott
Cc: OSGi Developer Mail List
Subject: Re: [osgi-dev] Create instance of factory configuration at runtime

Hi Scott,

I did a short successful test. See the following steps:

1. create a new configuration: Configuration config = 
ca.createFactoryConfiguration(factoryPid, „?“);
2. create and set the following properties: prop.put(„service.factoryPid“, 
factoryPid); prop.put(„felix.fileinstall.filename“, path), 
prop.put(„service.factoryPid“, factoryPid); config.update(prop);
3. create the configurationfile using variable path (same as for 
„felix.fileinstall.filename“). Managed by Fileinstall.

After a click on a button on a webpage the configuration was created and 
displayed without delay.
If the file is changed, the webpage UI gets updated and the Web Console shows 
the new value(s).
If I change a value in the Web Console the value in the webpage UI and in the 
file is changed, and so on ...

It was only a short test based on an idea, so no guarantee.

Michael

Am 15.12.2017 um 17:56 schrieb Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>>:

Hi Michael,

Thanks for the response. Yes I’m aware of that mechanism. That’s part of 
Karaf’s hot deploy scheme which I’ve used extensively to date. What I need to 
do is create new service instances from a UI and have the created services 
available immediately, i.e. without the delay, so that the UI can update 
without a refresh.

I know that if you modify a service programmatically, the corresponding .cfg, 
if the service has one, is updated.  I can’t see anyway to tell the CA service 
to persist the new service configuration to a particular location. For my app, 
I’ve overridden the org.apache.felix.fileinstall.dir-deploy.cfg file with my 
own that causes Karaf to scan a directory hierarchy outside of the Karaf 
install hierarchy. That way I don’t have to physically move the directory 
structure whenever I update Karaf.

Anyway, what I’m curious about is whether a .cfg file can/will be associated 
with a service after it’s already been created using 
createFactoryConfiguration.update(props);  ?  If I just create one after the 
fact, where I want it to reside, I’m curious if it will get associated with the 
existing service. Of course I can test this and intend to, I just haven’t got 
to that point yet.

Of course if someone can tell me definitively whether that will work or not, I 
won’t have to bother.

Scott

From: Michael Wirth [mailto:mwi...@apollon.de]
Sent: Friday, December 15, 2017 9:00 AM
To: Leschke, Scott; OSGi Developer Mail List
Subject: Re: [osgi-dev] Create instance of factory configuration at runtime

Hi Scott,

to point 2)
about 2-3 years ago I had a similar problem. The 'solution' was to create a 
configuration file (with the properties) in the 
'felix.fileinstall.dir'-Directory. If it is a Factory the filename should be 
-.cfg
After some time (depending on configuration) FileInstall will scan the file, 
create the configuration and the service will be instantiated.

ps. I have just checked, the 'hack' still exists and is live

Michael

Am 13.12.2017 um 22:24 schrieb Leschke, Scott via osgi-dev 
<osgi-...@mail.osgi.org<mailto:osgi-...@mail.osgi.org>>:

Hey Tim,

Thanks for this. Yes that worked. I recall seeing something about this a number 
of months ago but didn’t pay much attention since it didn’t apply to me at the 
time. Not sure why I didn’t think to give that a try though.

Two additional questions for anybody who cares to answer.

1)  If “?” isn’t used, what would the location argument look like?  Is it 
like a bundle symbolic id, with wildcards perhaps? It’s unclear to me how this 
would be used even if you wanted to.
2)  Now for a Karaf question to any/all takers. When a service instance is 
created this way, is there a way to associate a .cfg file with it so that the 
service configuration will persist across Karaf upgrades?  I know that if a 
Configuration record is updated, the service’s corresponding .cfg file is 
updated, but if you create a new service, you don’t get a .cf

RE: [osgi-dev] Create instance of factory configuration at runtime

[Leschke, Scott]

Hey Tim,

Thanks for this. Yes that worked. I recall seeing something about this a number 
of months ago but didn’t pay much attention since it didn’t apply to me at the 
time. Not sure why I didn’t think to give that a try though.

Two additional questions for anybody who cares to answer.


1)  If “?” isn’t used, what would the location argument look like?  Is it 
like a bundle symbolic id, with wildcards perhaps? It’s unclear to me how this 
would be used even if you wanted to.

2)  Now for a Karaf question to any/all takers. When a service instance is 
created this way, is there a way to associate a .cfg file with it so that the 
service configuration will persist across Karaf upgrades?  I know that if a 
Configuration record is updated, the service’s corresponding .cfg file is 
updated, but if you create a new service, you don’t get a .cfg file.

Scott

From: Tim Ward [mailto:tim.w...@paremus.com]
Sent: Saturday, December 09, 2017 3:04 AM
To: Leschke, Scott; OSGi Developer Mail List
Subject: Re: [osgi-dev] Create instance of factory configuration at runtime

Hi Scott,

That does work, but Configuration Admin has an old feature called location 
binding. This feature prevents a configuration being delivered to bundles other 
than the bundle with the specified bundle location.

The one-arg version of createFactoryConfiguration that you’re using defaults 
the bundle location to the location of the bundle which got the 
ConfigurationAdmin service instance that you’re using. This is almost never the 
correct location as it usually means only the management bundle can see your 
configuration.

The location binding behaviour is so annoying that the general recommendation 
is to disable it by using the two arg versions of Config Admin methods with a 
wildcard location binding (a “?”).

My guess is that the two arg version will give you what you’re looking for.

Tim
Sent from my iPhone

On 9 Dec 2017, at 00:36, Leschke, Scott via osgi-dev 
<osgi-...@mail.osgi.org<mailto:osgi-...@mail.osgi.org>> wrote:
How does one create a new instance of a factory configuration programmatically?

I thought it was like

ConfigurationAdmin ca;
ca.createFactoryConfiguration(“my.configuration.pid”).update(newServiceProps);

but that doesn’t seem to work for me.

Thanks in advance,

Scott
___
OSGi Developer Mail List
osgi-...@mail.osgi.org<mailto:osgi-...@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev

RE: Pax JDBC DataSourceFactory connection pooling config

[Leschke, Scott]

Hey Tim,

You make a good point about obsolete vs. deprecated.  Anyway, I was just 
looking at ConfigAdmin recently, I seem to recall seeing Dictionary exposed 
there. While I agree that changing something like that would be a breaking 
change, it seems to me that users would have the choice to continue to use R6 
(or lower) versions of services if they needed to / felt so inclined.  That’s 
kind of the point of OSGi, right, that you have that option?

I’m kind of radical in my thinking in this regard, I’ll admit. Backwards 
compatibility is great, to a point.  Sooner or later, if you want to bake a 
cake, you have to break some eggs. Oh well, one man’s opinion.  Thanks for the 
response,

Scott

From: Timothy Ward [mailto:tim.w...@paremus.com]
Sent: Wednesday, November 22, 2017 11:17 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config

Hi Scott,

The Dictionary type is actually not deprecated (although it is obsolete). 
Moving the OSGi core framework away from Dictionary would be a huge breaking 
change for users (rather than implementers), and simply isn’t going to happen. 
On the other hand there is really no need to interact with the OSGi framework 
at this level. In the general case, new specifications will attempt to make use 
of the best practices when they are made. These best practices may later turn 
out to have been wrong (c.f. Dictionary) but the alliance will avoid making 
breaking changes wherever possible in specification updates.

I would honestly be surprised if you had regular (or even any) contact with the 
Dictionary type when using R7 specifications.

Regards,

Tim


On 22 Nov 2017, at 17:06, Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:

Hi Tim,

I’ve looked at this in the past a bit, unfortunately using it would require a 
more change on my part than just using the DSF with pooling. I’ll look at it 
again to see exactly what it would require as this pooling issue is a bit 
problematic.

Regarding OSGi Release 7, I have a general question for you since you’re 
involved in the spec process.  Is there any effort going toward not using 
deprecated Java APIs in service specs?  I have a real issue with continuing to 
expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not 
export) all deprecated classes but I don’t believe this has happened.

The one that comes to mind is the use of java.util.Dictionary in numerous 
places.  I’m sure there are others.  Since OSGi supports runtime versioning, it 
would seem that replacing Dictionary with Map would be reasonable, as well as 
any other deprecated APIs that are exposed.

Regards,

Scott

From: Timothy Ward [mailto:tim.w...@paremus.com]
Sent: Tuesday, November 21, 2017 4:01 AM
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Pax JDBC DataSourceFactory connection pooling config

Hi Scott,

If you’re interested in using JDBC with pooling in an OSGi environment then I 
really would recommend looking at the Transaction Control service. This is a 
new specification coming in OSGi release 7, and it provides significant 
extensions to the DataSourceFactory model, including pooling, managed 
lifecycles for your database connection usage, standard configuration 
properties, and transaction support (both local and XA).

The proposed reference implementation is available from Apache Aries, and 
implements all of the features from the specification draft. It also has a 
large number of tests for the various components, including local and XA JPA 
support (if that’s of interest).

Regards,

Tim



On 20 Nov 2017, at 21:47, Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:

How does one configure the underlying connection pool when using Pax JDBC 
DataSourceFactory?  I’ve been using this for a while and recently discovered 
it’s not behaving as I intended. I’m using Hikari as my CP, and want to 
configure the following Hikari properties:

poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime

I’ve been prefixing each of these “hikari.” (which I concluded was the proper 
way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,

hikari.poolName= Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 2880
hikari.maxLifetime = 0

I immediately get 10 connections to the datastore, even before a connection is 
actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used.  I also tried 
prefixing with “pool.” btw (which makes more sense to me), but get the same 
behavior.

Scott

RE: Pax JDBC DataSourceFactory connection pooling config

[Leschke, Scott]

Hi Tim,

I’ve looked at this in the past a bit, unfortunately using it would require a 
more change on my part than just using the DSF with pooling. I’ll look at it 
again to see exactly what it would require as this pooling issue is a bit 
problematic.

Regarding OSGi Release 7, I have a general question for you since you’re 
involved in the spec process.  Is there any effort going toward not using 
deprecated Java APIs in service specs?  I have a real issue with continuing to 
expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not 
export) all deprecated classes but I don’t believe this has happened.

The one that comes to mind is the use of java.util.Dictionary in numerous 
places.  I’m sure there are others.  Since OSGi supports runtime versioning, it 
would seem that replacing Dictionary with Map would be reasonable, as well as 
any other deprecated APIs that are exposed.

Regards,

Scott

From: Timothy Ward [mailto:tim.w...@paremus.com]
Sent: Tuesday, November 21, 2017 4:01 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config

Hi Scott,

If you’re interested in using JDBC with pooling in an OSGi environment then I 
really would recommend looking at the Transaction Control service. This is a 
new specification coming in OSGi release 7, and it provides significant 
extensions to the DataSourceFactory model, including pooling, managed 
lifecycles for your database connection usage, standard configuration 
properties, and transaction support (both local and XA).

The proposed reference implementation is available from Apache Aries, and 
implements all of the features from the specification draft. It also has a 
large number of tests for the various components, including local and XA JPA 
support (if that’s of interest).

Regards,

Tim


On 20 Nov 2017, at 21:47, Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>> wrote:

How does one configure the underlying connection pool when using Pax JDBC 
DataSourceFactory?  I’ve been using this for a while and recently discovered 
it’s not behaving as I intended. I’m using Hikari as my CP, and want to 
configure the following Hikari properties:

poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime

I’ve been prefixing each of these “hikari.” (which I concluded was the proper 
way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,

hikari.poolName= Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 2880
hikari.maxLifetime = 0

I immediately get 10 connections to the datastore, even before a connection is 
actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used.  I also tried 
prefixing with “pool.” btw (which makes more sense to me), but get the same 
behavior.

Scott

RE: Pax JDBC DataSourceFactory connection pooling config

[Leschke, Scott]

Christian,

The code reference you sent along looks correct, at least based on my 
understanding of configuring Hikari, so perhaps there is some issue with Hikari 
itself? Will the next version of Pax JDBC use the newest version of Hikari 
(which I think is 2.7.3 or something like that?).

In my log file, I get the following, which would seem to indicate that the 
Hikari configuration properties aren’t being used. I previously thought that 
just the one config was being ignored but now I realize none are being used.

HikariDataSource | 143 - com.zaxxer.HikariCP - 2.4.1 | 
HikariPool-0 - is starting

Prior to using Pax, I was using Blueprint to create my datasources, during 
which time I would see the proper pool name “Composite Enterprise Data“ in the 
log.

Scott

From: cschneider...@gmail.com [mailto:cschneider...@gmail.com] On Behalf Of 
Christian Schneider
Sent: Tuesday, November 21, 2017 6:22 AM
To: user@karaf.apache.org
Subject: Re: Pax JDBC DataSourceFactory connection pooling config

When I look into the source I see that the hikari pooling checks for the prefix 
"hikari.". Maybe you can set a breakpoint there and check what it actually does.

See: 
https://github.com/ops4j/org.ops4j.pax.jdbc/blob/master/pax-jdbc-pool-hikaricp/src/main/java/org/ops4j/pax/jdbc/pool/hikaricp/impl/HikariPooledDataSourceFactory.java

Christian

2017-11-20 22:47 GMT+01:00 Leschke, Scott 
<slesc...@medline.com<mailto:slesc...@medline.com>>:
How does one configure the underlying connection pool when using Pax JDBC 
DataSourceFactory?  I’ve been using this for a while and recently discovered 
it’s not behaving as I intended. I’m using Hikari as my CP, and want to 
configure the following Hikari properties:

poolName
maximumPoolSize
minimumIdle
idleTimeout
maxLifetime

I’ve been prefixing each of these “hikari.” (which I concluded was the proper 
way to do it some months ago), but it appears that Hikari is using defaults.
When I configure as follows,

hikari.poolName= Composite Enterprise Data
hikari.maximumPoolSize = 1
hikari.minimumIdle = 0
hikari.idleTimeout = 2880
hikari.maxLifetime = 0

I immediately get 10 connections to the datastore, even before a connection is 
actually requested to run a query (Cisco Information Server (aka, Composite)).
This would be the default behavior if none of the above get used.  I also tried 
prefixing with “pool.” btw (which makes more sense to me), but get the same 
behavior.

Scott



--
--
Christian Schneider
http://www.liquid-reality.de<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46=http%3a%2f%2fwww.liquid-reality.de>

Computer Scientist
http://www.adobe.com