RE: Karaf, Camel, and Spring

[Maurice Betzel]

This should not be needed, as Francois sayed Camel uses a version span of up to 
version 6.
Servicemix seems to go up to 5.3.26_1 in Maven Central. So if 27 is a must you 
could create it yourself with the servicemix parent and add a pullrequest 
against servicemix.

-Original Message-
From: Ephemeris Lappis 
Sent: Friday, April 28, 2023 12:57 PM
To: user@karaf.apache.org
Cc: us...@camel.apache.org
Subject: Re: Karaf, Camel, and Spring

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


Hello again.

Indeed, we could try to make our own feature repository to pull Spring 5.3.27, 
but I'm not very sure this is as easy as it seems : in fact I think that 
features in the current Karaf repository, with version "5.3.23.1", are all 
built with "service mix wrapped" bundles. I don't know if we can easily create 
a 5.3.27 replacing repository.

Do you confirm ?

Thanks.

Regards

Le ven. 28 avr. 2023 à 10:14, Maurice Betzel  a 
écrit :
>
> Hi,
>
> If there is no such feature XML like in maven central, you will have to 
> create one yourself with the upped versions.
> If your runtime has internet access, you can just drop that xml in deploy for 
> provisioning.
> As for the version numbering, the third digit(s), counted from left to right, 
> represent bugfixes and must be binary compatible to the previous versions.
>
> -Original Message-
> From: Ephemeris Lappis 
> Sent: Friday, April 28, 2023 9:59 AM
> To: user@karaf.apache.org
> Cc: us...@camel.apache.org
> Subject: Re: Karaf, Camel, and Spring
>
>  CAUTION: This email originated from outside of Gaston Schul. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hello.
>
> If I'm not wrong, most of Spring dependencies in Karaf come with this feature 
> repository :
>
> feature:provided mvn:org.apache.karaf.features/spring/4.4.3/xml/features
> Name   │ Version
> ───┼─
> spring │ 5.3.23.1
> spring-aspects │ 5.3.23.1
> spring-instrument  │ 5.3.23.1
> spring-jdbc│ 5.3.23.1
> spring-jms │ 5.3.23.1
> spring-messaging   │ 5.3.23.1
> spring-test│ 5.3.23.1
> spring-orm │ 5.3.23.1
> spring-oxm │ 5.3.23.1
> spring-tx  │ 5.3.23.1
> spring-web │ 5.3.23.1
> spring-websocket   │ 5.3.23.1
> spring-security│ 5.6.3.1
> spring-security│ 5.7.3.1
> aries-blueprint-spring │ 0.0.0
>
> I don't know if another version of this repository exists that I could
> add in one of our features files before Spring (spring or
> camel-spring) dependencies are resolved.
>
> I don't know if changing the Karaf version of Spring to match the Camel 
> version may have an impact on other features that do not relate to Camel...
>
> Your point of view is welcome :) !
>
> Thanks again.
>
> Regards.
>
> Le ven. 28 avr. 2023 à 09:04, Maurice Betzel  a 
> écrit :
> >
> > Hi,
> >
> > You should be able to add the feature repo and install with version.
> > Something like this from the Karaf docs:
> >
> > karaf@root()> feature:repo-add
> > mvn:org.ops4j.pax.jdbc/pax-jdbc-features/1.3.0/xml/features
> >
> > -Original Message-
> > From: Ephemeris Lappis 
> > Sent: Thursday, April 27, 2023 7:37 PM
> > To: user@karaf.apache.org; us...@camel.apache.org
> > Subject: Karaf, Camel, and Spring
> >
> >  CAUTION: This email originated from outside of Gaston Schul. Do not click 
> > links or open attachments unless you recognize the sender and know the 
> > content is safe.
> >
> >
> > Hello.
> >
> > We're upgrading Camel to 3.20.4. This version of Camel seems to depend on 
> > Spring 5.3.27.
> >
> > As the application should run on Karaf 4.4.3 that provides spring 
> > components with version 5.3.23.
> >
> > Should we either force our project dependencies to use Spring 5.3.23, or 
> > try to upgrade the Karaf repository to use Spring 5.3.27 ?
> >
> > Thanks for your help.
> >
> > Regards.
> > Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
> > Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch 
> > Staatsblad dd. 24 juni 2005 onder nr. 0090237. De tekst van deze 
> > voorwaarden wordt op uw verzoek gratis toegezonden.
> > All our transactions are subject to the General Conditions of the Belgian 
> > Forwarders Association which have 

RE: Karaf, Camel, and Spring

[Maurice Betzel]

Hi,

If there is no such feature XML like in maven central, you will have to create 
one yourself with the upped versions.
If your runtime has internet access, you can just drop that xml in deploy for 
provisioning.
As for the version numbering, the third digit(s), counted from left to right, 
represent bugfixes and must be binary compatible to the previous versions.

-Original Message-
From: Ephemeris Lappis 
Sent: Friday, April 28, 2023 9:59 AM
To: user@karaf.apache.org
Cc: us...@camel.apache.org
Subject: Re: Karaf, Camel, and Spring

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


Hello.

If I'm not wrong, most of Spring dependencies in Karaf come with this feature 
repository :

feature:provided mvn:org.apache.karaf.features/spring/4.4.3/xml/features
Name   │ Version
───┼─
spring │ 5.3.23.1
spring-aspects │ 5.3.23.1
spring-instrument  │ 5.3.23.1
spring-jdbc│ 5.3.23.1
spring-jms │ 5.3.23.1
spring-messaging   │ 5.3.23.1
spring-test│ 5.3.23.1
spring-orm │ 5.3.23.1
spring-oxm │ 5.3.23.1
spring-tx  │ 5.3.23.1
spring-web │ 5.3.23.1
spring-websocket   │ 5.3.23.1
spring-security│ 5.6.3.1
spring-security│ 5.7.3.1
aries-blueprint-spring │ 0.0.0

I don't know if another version of this repository exists that I could add in 
one of our features files before Spring (spring or
camel-spring) dependencies are resolved.

I don't know if changing the Karaf version of Spring to match the Camel version 
may have an impact on other features that do not relate to Camel...

Your point of view is welcome :) !

Thanks again.

Regards.

Le ven. 28 avr. 2023 à 09:04, Maurice Betzel  a 
écrit :
>
> Hi,
>
> You should be able to add the feature repo and install with version.
> Something like this from the Karaf docs:
>
> karaf@root()> feature:repo-add
> mvn:org.ops4j.pax.jdbc/pax-jdbc-features/1.3.0/xml/features
>
> -Original Message-
> From: Ephemeris Lappis 
> Sent: Thursday, April 27, 2023 7:37 PM
> To: user@karaf.apache.org; us...@camel.apache.org
> Subject: Karaf, Camel, and Spring
>
>  CAUTION: This email originated from outside of Gaston Schul. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hello.
>
> We're upgrading Camel to 3.20.4. This version of Camel seems to depend on 
> Spring 5.3.27.
>
> As the application should run on Karaf 4.4.3 that provides spring components 
> with version 5.3.23.
>
> Should we either force our project dependencies to use Spring 5.3.23, or try 
> to upgrade the Karaf repository to use Spring 5.3.27 ?
>
> Thanks for your help.
>
> Regards.
> Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
> Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch 
> Staatsblad dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden 
> wordt op uw verzoek gratis toegezonden.
> All our transactions are subject to the General Conditions of the Belgian 
> Forwarders Association which have been published under nr. 0090237 in the 
> "Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
> free of charge upon request.
> Toutes nos opérations se font sur base des Conditions Générales des 
> Expéditeurs de Belgique. Le texte en a été publié dans l' Annexe au Moniteur 
> Belge du 24 juin 2005 sous le n° 0090237. Ce texte sera vous envoyé 
> gratuitment sur demande.
> Email confidentiality notice:
> This email and any files transmitted with it are confidential and intended 
> only for the use of the recipient. If you have received this email in error 
> please notify its sender.
>
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf, Camel, and Spring

[Maurice Betzel]

Hi,

You should be able to add the feature repo and install with version.
Something like this from the Karaf docs:

karaf@root()> feature:repo-add 
mvn:org.ops4j.pax.jdbc/pax-jdbc-features/1.3.0/xml/features

-Original Message-
From: Ephemeris Lappis 
Sent: Thursday, April 27, 2023 7:37 PM
To: user@karaf.apache.org; us...@camel.apache.org
Subject: Karaf, Camel, and Spring

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


Hello.

We're upgrading Camel to 3.20.4. This version of Camel seems to depend on 
Spring 5.3.27.

As the application should run on Karaf 4.4.3 that provides spring components 
with version 5.3.23.

Should we either force our project dependencies to use Spring 5.3.23, or try to 
upgrade the Karaf repository to use Spring 5.3.27 ?

Thanks for your help.

Regards.
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf 4.4.3 / Unstable transaction features/services installation

[Maurice Betzel]

icemix.bundles.dom4j/2.1.3_1

mvn:org.hibernate.common/hibernate-commons-annotations/5.1.2.Final

mvn:org.hibernate/hibernate-core/${hibernate.orm.version}

mvn:org.hibernate/hibernate-osgi/${hibernate.orm.version}


osgi.service;objectClass=javax.persistence.spi.PersistenceProvider;effective:=active;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider




-Oorspronkelijk bericht-
Van: Ephemeris Lappis 
Verzonden: woensdag 12 april 2023 09:33
Aan: user@karaf.apache.org
Onderwerp: Re: Karaf 4.4.3 / Unstable transaction features/services installation

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


Hello Maurice.

I attach a description of our features stack, starting with low level resource 
management, then framework and common features, and finally an application 
feature example.

The transaction feature is pulled by a common "foo-base", and used in some of 
our application bundles that need both JMS and JDBC commits.
The blueprint code is something like that :










Any comment is welcome ;) !

Thanks.

Regards.

Le mar. 11 avr. 2023 à 20:03, Maurice Betzel  a 
écrit :
>
> Hi, I do remember having a similar issue years back and I feel your pain but 
> I cannot remember what I did to cure the issue.
> What do your custom features look like so I can compare them.
>
> -Oorspronkelijk bericht-
> Van: Ephemeris Lappis 
> Verzonden: dinsdag 11 april 2023 13:06
> Aan: user@karaf.apache.org
> Onderwerp: Karaf 4.4.3 / Unstable transaction features/services
> installation
>
>  CAUTION: This email originated from outside of Gaston Schul. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hello.
>
> I've already posted some similar questions some weeks ago about some issues 
> we had with our features deployment, but I didn't get any explanation or 
> solution. I will try again before creating a ticket for an issue that perhaps 
> is not a bug...
>
> Our "low level" karaf features install commons services like :
> - pax-jms (with ActiveMQ client and a configuration file)
> - pax-jdbc (with PostgreSQL driver and a configuration file)
> - transaction
>
> Then we install common Camel features and our applications features.
>
> If I'm not wrong, the feature transaction has the following dependencies :
> -> feature transaction-manager-geronimo
> -> feature pax-transx-tm-geronimo
> -> starts bundle
> mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3
>
> This bundle exposes the service "PlatformTransactionmanager" that we need to 
> create transaction policies in some of our application's bundles.
>
> When we install all the features on a clean Karaf, all the services
> are started, and the dependency on the PlatformTransactionManager
> (PTM) is resolved as expected.
>
> in list of services we have :
>
> pax-transx-tm-geronimo (126) provides:
> --
> [org.osgi.service.cm.ManagedService]
> [javax.transaction.TransactionManager,
> javax.transaction.TransactionSynchronizationRegistry,
> javax.transaction.UserTransaction,
> org.apache.geronimo.transaction.manager.RecoverableTransactionManager,
> org.springframework.transaction.PlatformTransactionManager]
> [org.ops4j.pax.transx.tm.TransactionManager]
>
> But if we stop the Karaf, and start it again, the PTM doesn't start, and the 
> dependent bundles fail. The services list doesn't include the PTM anymore :
>
> pax-transx-tm-geronimo (126) provides:
>
> --
>
>   [org.osgi.service.cm.ManagedService]
>
> [javax.transaction.TransactionManager,
> javax.transaction.TransactionSynchronizationRegistry,
> javax.transaction.UserTransaction,
> org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
> [org.ops4j.pax.transx.tm.TransactionManager]
>
> I discovered that using "feature:refresh" does something that restarts the 
> missing service. Then stopping and starting Karaf seems to have no impact.
>
> I don't understand why the Karaf feature installation works the first time, 
> but doesn't let the system in a stable state, and what the refresh does to 
> get it working again, since no change has been applied...
>
> Thanks in advance for any ideas.
>
> Regards.
> Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
> Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch 
> Staatsblad dd. 24 juni 2005 onder nr. 00

RE: Karaf 4.4.3 / Unstable transaction features/services installation

[Maurice Betzel]

Hi, I do remember having a similar issue years back and I feel your pain but I 
cannot remember what I did to cure the issue.
What do your custom features look like so I can compare them.

-Oorspronkelijk bericht-
Van: Ephemeris Lappis 
Verzonden: dinsdag 11 april 2023 13:06
Aan: user@karaf.apache.org
Onderwerp: Karaf 4.4.3 / Unstable transaction features/services installation

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


Hello.

I've already posted some similar questions some weeks ago about some issues we 
had with our features deployment, but I didn't get any explanation or solution. 
I will try again before creating a ticket for an issue that perhaps is not a 
bug...

Our "low level" karaf features install commons services like :
- pax-jms (with ActiveMQ client and a configuration file)
- pax-jdbc (with PostgreSQL driver and a configuration file)
- transaction

Then we install common Camel features and our applications features.

If I'm not wrong, the feature transaction has the following dependencies :
-> feature transaction-manager-geronimo
-> feature pax-transx-tm-geronimo
-> starts bundle
mvn:org.ops4j.pax.transx/pax-transx-tm-geronimo/0.5.3

This bundle exposes the service "PlatformTransactionmanager" that we need to 
create transaction policies in some of our application's bundles.

When we install all the features on a clean Karaf, all the services are 
started, and the dependency on the PlatformTransactionManager
(PTM) is resolved as expected.

in list of services we have :

pax-transx-tm-geronimo (126) provides:
--
[org.osgi.service.cm.ManagedService]
[javax.transaction.TransactionManager,
javax.transaction.TransactionSynchronizationRegistry,
javax.transaction.UserTransaction,
org.apache.geronimo.transaction.manager.RecoverableTransactionManager,
org.springframework.transaction.PlatformTransactionManager]
[org.ops4j.pax.transx.tm.TransactionManager]

But if we stop the Karaf, and start it again, the PTM doesn't start, and the 
dependent bundles fail. The services list doesn't include the PTM anymore :

pax-transx-tm-geronimo (126) provides:

--

  [org.osgi.service.cm.ManagedService]

[javax.transaction.TransactionManager,
javax.transaction.TransactionSynchronizationRegistry,
javax.transaction.UserTransaction,
org.apache.geronimo.transaction.manager.RecoverableTransactionManager]
[org.ops4j.pax.transx.tm.TransactionManager]

I discovered that using "feature:refresh" does something that restarts the 
missing service. Then stopping and starting Karaf seems to have no impact.

I don't understand why the Karaf feature installation works the first time, but 
doesn't let the system in a stable state, and what the refresh does to get it 
working again, since no change has been applied...

Thanks in advance for any ideas.

Regards.
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

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

[Maurice Betzel]

The problem of hanging on boot after a folder rename still did not disappear. 
Leaving out pax-web install on boot only made the issue appear less frequent.
Somewhere a thread gets deadlocked on first boot.

Van: Maurice Betzel
Verzonden: zaterdag 25 maart 2023 12:10
Aan: user@karaf.apache.org
Onderwerp: RE: Custom Karaf hangs on first boot if containing folder is renamed

Do you have the standard features in runtime scope (not compile scope) ?

Yes, and I blacklisted all Pax Web related Karaf features using only the 
Pax-Web features down the line.



eu.abeel.platform
platform-framework
${project.version}
kar
compile


eu.abeel.platform
platform-framework
${project.version}
features
xml
runtime


eu.abeel.platform
features
${abeel.platform.version}
features
xml
runtime


org.apache.karaf.features
standard
${karaf.version}
features
xml
runtime


org.apache.karaf.features
specs
${karaf.version}
features
xml
runtime


org.apache.karaf.features
spring
${karaf.version}
features
xml
runtime


org.apache.karaf.features
enterprise
${karaf.version}
features
xml
runtime


org.ops4j.pax.transx
pax-transx-features
${pax.transx.version}
features
xml
runtime


org.ops4j.pax.web
pax-web-features
${pax.web.version}
features
xml
runtime





eventadmin
platform-environment


wrap
shell
jaas
deployer
feature
management
bundle
config
diagnostic
instance
kar
package
service
system
log
scr
platform-security




ssh
war
cdi
groovy
jackson
felix-http
eclipselink
felix-http
felix-httplite
jackson-jaxrs
jms
obr
jdbc
jetty
hibernate
minimal
standard
hibernate-envers
blueprint-web
transaction-manager-atomikos
application-without-isolation
transaction-manager-narayana
spring-jms
spring-orm
spring-test
spring-jdbc
spring-security
spring-messaging
pax-transx-jms
pax-transx-jdbc
pax-transx-tm-atomikos
pax-transx-tm-narayana
pax-web-http
pax-web-http-war
pax-web-http-whiteboard
pax-web-tomcat
pax-web-http-tomcat
pax-web-tomcat-keycloak
pax-web-tomcat-keycloak18
pax-web-tomcat-websockets
pax-web-undertow
pax-web-http-undertow
pax-web-undertow-keycloak
pax-web-undertow-keycloak18
pax-web-undertow-websockets
pax-web-jetty-http2-jdk8
pax-web-jetty-keycloak18


Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

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

[Maurice Betzel]

Do you have the standard features in runtime scope (not compile scope) ?

Yes, and I blacklisted all Pax Web related Karaf features using only the 
Pax-Web features down the line.



eu.abeel.platform
platform-framework
${project.version}
kar
compile


eu.abeel.platform
platform-framework
${project.version}
features
xml
runtime


eu.abeel.platform
features
${abeel.platform.version}
features
xml
runtime


org.apache.karaf.features
standard
${karaf.version}
features
xml
runtime


org.apache.karaf.features
specs
${karaf.version}
features
xml
runtime


org.apache.karaf.features
spring
${karaf.version}
features
xml
runtime


org.apache.karaf.features
enterprise
${karaf.version}
features
xml
runtime


org.ops4j.pax.transx
pax-transx-features
${pax.transx.version}
features
xml
runtime


org.ops4j.pax.web
pax-web-features
${pax.web.version}
features
xml
runtime





eventadmin
platform-environment


wrap
shell
jaas
deployer
feature
management
bundle
config
diagnostic
instance
kar
package
service
system
log
scr
platform-security




ssh
war
cdi
groovy
jackson
felix-http
eclipselink
felix-http
felix-httplite
jackson-jaxrs
jms
obr
jdbc
jetty
hibernate
minimal
standard
hibernate-envers
blueprint-web
transaction-manager-atomikos
application-without-isolation
transaction-manager-narayana
spring-jms
spring-orm
spring-test
spring-jdbc
spring-security
spring-messaging
pax-transx-jms
pax-transx-jdbc
pax-transx-tm-atomikos
pax-transx-tm-narayana
pax-web-http
pax-web-http-war
pax-web-http-whiteboard
pax-web-tomcat
pax-web-http-tomcat
pax-web-tomcat-keycloak
pax-web-tomcat-keycloak18
pax-web-tomcat-websockets
pax-web-undertow
pax-web-http-undertow
pax-web-undertow-keycloak
pax-web-undertow-keycloak18
pax-web-undertow-websockets
pax-web-jetty-http2-jdk8
pax-web-jetty-keycloak18


Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

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

[Maurice Betzel]

d issue.

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

Thanks,
Regards
JB

On Thu, Mar 23, 2023 at 8:48 AM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
JB,

Good luck with your search. The Linux build does not display this behavior btw.

Van: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Verzonden: woensdag 22 maart 2023 09:44
Aan: user@karaf.apache.org<mailto:user@karaf.apache.org>
Onderwerp: Re: Custom Karaf hangs on first boot if containing folder is renamed

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

Hi Maurice,

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

I have to find a Windows to test it :)

Regards
JB

On Tue, Mar 21, 2023 at 12:13 PM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Hi JB,

I extracted the zip from the build, renamed the folder and deleted the data 
folder (which had nothing in it except the readme).
The result is the same, the shell displays:

platform.bat: KARAF_LOG doesn't exist: 
"C:\Users\User\Downloads\runtime5\bin\..\data\log"
platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

But no ascii art, logging as mentioned below. If I stop and restart all is 
working as it should.

Van: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Verzonden: dinsdag 21 maart 2023 11:03
Aan: user@karaf.apache.org<mailto:user@karaf.apache.org>
Onderwerp: Re: Custom Karaf hangs on first boot if containing folder is renamed

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

Did you try to remove the data folder ?

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

Regards
JB

On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

Having built several custom Karaf distributions the past 10 years, we now face 
a strange behavior not seen before.
Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded pax-web 
8.0.17 component.
If I extract the runtime ZIP after build and start it from the default 
containing folder, all works well. But if I rename the folder before first 
start, Karaf hangs on disabling logging, see below.
If I start and stop Karaf from its original folder and then rename this folder, 
all is well.
Seems that Karaf home gets cached somewhere? I cannot find it so I am hoping 
this behavior has been noticed before?

2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 | Starting bundles:
2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util/9.4.50.v20221201
2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.jmx/9.4.50.v20221201
2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.io/9.4.50.v20221201<http://org.eclipse.jetty.io/9.4.50.v20221201>
2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.http/9.4.50.v20221201
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
jakarta.servlet-api/4.0.0
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-api/8.0.17
2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-spi/8.0.17
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.server/9.4.50.v20221201
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.security/9.4.50.v20221201
2023-03-20T14:28:48,414 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util.ajax/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.servlet/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | Feature

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

[Maurice Betzel]

JB,

Good luck with your search. The Linux build does not display this behavior btw.

Van: Jean-Baptiste Onofré 
Verzonden: woensdag 22 maart 2023 09:44
Aan: user@karaf.apache.org
Onderwerp: Re: Custom Karaf hangs on first boot if containing folder is renamed

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

Hi Maurice,

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

I have to find a Windows to test it :)

Regards
JB

On Tue, Mar 21, 2023 at 12:13 PM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Hi JB,

I extracted the zip from the build, renamed the folder and deleted the data 
folder (which had nothing in it except the readme).
The result is the same, the shell displays:

platform.bat: KARAF_LOG doesn't exist: 
"C:\Users\User\Downloads\runtime5\bin\..\data\log"
platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

But no ascii art, logging as mentioned below. If I stop and restart all is 
working as it should.

Van: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Verzonden: dinsdag 21 maart 2023 11:03
Aan: user@karaf.apache.org<mailto:user@karaf.apache.org>
Onderwerp: Re: Custom Karaf hangs on first boot if containing folder is renamed

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

Did you try to remove the data folder ?

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

Regards
JB

On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

Having built several custom Karaf distributions the past 10 years, we now face 
a strange behavior not seen before.
Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded pax-web 
8.0.17 component.
If I extract the runtime ZIP after build and start it from the default 
containing folder, all works well. But if I rename the folder before first 
start, Karaf hangs on disabling logging, see below.
If I start and stop Karaf from its original folder and then rename this folder, 
all is well.
Seems that Karaf home gets cached somewhere? I cannot find it so I am hoping 
this behavior has been noticed before?

2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 | Starting bundles:
2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util/9.4.50.v20221201
2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.jmx/9.4.50.v20221201
2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.io/9.4.50.v20221201<http://org.eclipse.jetty.io/9.4.50.v20221201>
2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.http/9.4.50.v20221201
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
jakarta.servlet-api/4.0.0
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-api/8.0.17
2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-spi/8.0.17
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.server/9.4.50.v20221201
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.security/9.4.50.v20221201
2023-03-20T14:28:48,414 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util.ajax/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.servlet/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.xml/9.4.50.v20221201
2023-03-20T14:28:48,416 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org

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

[Maurice Betzel]

Hi JB,

I extracted the zip from the build, renamed the folder and deleted the data 
folder (which had nothing in it except the readme).
The result is the same, the shell displays:

platform.bat: KARAF_LOG doesn't exist: 
"C:\Users\User\Downloads\runtime5\bin\..\data\log"
platform.bat: Creating "C:\Users\user\Downloads\runtime5\bin\..\data\log"
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8

But no ascii art, logging as mentioned below. If I stop and restart all is 
working as it should.

Van: Jean-Baptiste Onofré 
Verzonden: dinsdag 21 maart 2023 11:03
Aan: user@karaf.apache.org
Onderwerp: Re: Custom Karaf hangs on first boot if containing folder is renamed

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

Did you try to remove the data folder ?

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

Regards
JB

On Mon, Mar 20, 2023 at 2:42 PM Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

Having built several custom Karaf distributions the past 10 years, we now face 
a strange behavior not seen before.
Environment is Windows 11 64bit, base Karaf version 4.4.3 with upgraded pax-web 
8.0.17 component.
If I extract the runtime ZIP after build and start it from the default 
containing folder, all works well. But if I rename the folder before first 
start, Karaf hangs on disabling logging, see below.
If I start and stop Karaf from its original folder and then rename this folder, 
all is well.
Seems that Karaf home gets cached somewhere? I cannot find it so I am hoping 
this behavior has been noticed before?

2023-03-20T14:28:48,405 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 | Starting bundles:
2023-03-20T14:28:48,407 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util/9.4.50.v20221201
2023-03-20T14:28:48,408 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.jmx/9.4.50.v20221201
2023-03-20T14:28:48,409 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.io/9.4.50.v20221201<http://org.eclipse.jetty.io/9.4.50.v20221201>
2023-03-20T14:28:48,410 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.http/9.4.50.v20221201
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
jakarta.servlet-api/4.0.0
2023-03-20T14:28:48,411 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-api/8.0.17
2023-03-20T14:28:48,412 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-spi/8.0.17
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.server/9.4.50.v20221201
2023-03-20T14:28:48,413 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.security/9.4.50.v20221201
2023-03-20T14:28:48,414 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.util.ajax/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.servlet/9.4.50.v20221201
2023-03-20T14:28:48,415 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.xml/9.4.50.v20221201
2023-03-20T14:28:48,416 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.jaas/9.4.50.v20221201
2023-03-20T14:28:48,417 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.servlets/9.4.50.v20221201
2023-03-20T14:28:48,418 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web.pax-web-jetty/8.0.17
2023-03-20T14:28:48,419 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.eclipse.jetty.continuation/9.4.50.v20221201
2023-03-20T14:28:48,420 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.web

Custom Karaf hangs on first boot if containing folder is renamed

[Maurice Betzel]

 - org.apache.karaf.features.core - 4.4.3 |   
org.apache.karaf.config.core/4.4.3
2023-03-20T14:28:50,207 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.apache.felix.coordinator/1.0.2
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | FeaturesServiceImpl 
 | 17 - org.apache.karaf.features.core - 4.4.3 |   
org.ops4j.pax.logging.pax-logging-api/2.2.0
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling SLF4J 
API support.
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling Apache 
Commons Logging API support.
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling JULI 
Logger API support.
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling Avalon 
Logger API support.
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling JBoss 
Logging API support.
2023-03-20T14:28:50,208 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling Log4J 
v1 API support.
2023-03-20T14:28:50,211 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling Log4J 
v2 API support.
2023-03-20T14:28:50,213 | INFO  | features-2-thread-1 | Activator   
 | 3 - org.ops4j.pax.logging.pax-logging-api - 2.2.0 | Disabling Java 
Util Logging API support.

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf 4.4.3 / Features wiring and upgrade

[Maurice Betzel]

Hi Ephemeris Lappis,

- why sometimes the service wiring works, and fails in other cases ?

I remember reading the advice to use DS, I forgot about the detailed reason, 
but I think it had to do with this and that DS is actively maintained:

https://www.slideshare.net/mfrancis/why-classforname-sucks-bj-hargrave
https://blog.hargrave.io/2007/07/why-do-classforname-and.html

- is there any way to force a refresh of all the referencing bundles when the 
feature and its service implementation are replaced ?

The blunt answer, we restart a cluster node after deployment changes.

This dynamism use case is not of importance in our enterprise setup, because of 
the fine-grained architecture we rarely have serious bugs or bugs that must be 
fixed under production times. We use OSGi mainly as crash-rails for designing 
modularity.

-Oorspronkelijk bericht-
Van: Ephemeris Lappis 
Verzonden: woensdag 8 maart 2023 13:02
Aan: user@karaf.apache.org
Onderwerp: Re: Karaf 4.4.3 / Features wiring and upgrade

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


Hello Maurice.

If I understand your explanation correctly, this inconsistent state only 
impacts blueprint service references. I've tried with simpler features, with 
only one service and one reference in the same design with Camel blueprints, 
and it seems that sometimes it works. See the attached archive with a full 
project. In this case, with the same Karaf, removing the service implementation 
feature makes the routes waiting for the service, and adding a new version of 
the feature, all works again as expected.

As all our applicative bundles are based on Camel blueprints, we can't consider 
rewriting it all... So two questions :
- why sometimes the service wiring works, and fails in other cases ?
- is there any way to force a refresh of all the referencing bundles when the 
feature and its service implementation are replaced ?

Thanks for your help.

Regards.

Le mer. 8 mars 2023 à 08:08, Maurice Betzel  a écrit 
:
>
> Hi Ephemeris Lappis,
>
> blueprint proxy objects not updating is a known issue I have experienced as 
> well, that is why we do more and more declarative services that handle 
> dynamism better.
> Concerning features, we only use them to generate Karaf archive files (KAR), 
> to have maximum control over what gets deployed, and it gets rid of the 
> external repository security concern (remember log4j).
> Our nodes per default do not have any external network connection. 
> Maintaining the cluster this way is no hassle up to now as semantic 
> versioning and domain driven design do their job in creating loosely coupled 
> modules that play nice with each other.
>
> -Oorspronkelijk bericht-
> Van: Ephemeris Lappis 
> Verzonden: dinsdag 7 maart 2023 19:04
> Aan: user@karaf.apache.org
> Onderwerp: Re: Karaf 4.4.3 / Features wiring and upgrade
>
>  CAUTION: This email originated from outside of Gaston Schul. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hello.
>
> I finally changed my design a bit, and separated "F1" into 2 distinct 
> features :
> - one for the API (interface declaration), say F1A
> - one for the service implementation, say F1S
>
> Now, when a modification is required, I can remove the repo and uninstall 
> F1S, and add the new repo and install the new version. As the imported 
> package in bundles of features Fx are still provided by F1A, Karaf lets me 
> execute the operation.
>
> But the service references in bundles from features Fx are not updated, and 
> exceptions "ServiceUnavailableException" are thrown when any operation of 
> these obsolete proxies is called.
>
> If I "bundle:refresh" the bundles individually, the references are renewed 
> and it works again. So how can I make Karaf force an update of all the 
> concerned bundles ?
>
> I also notice something strange when I remove an old repo. I use "repo-remove 
> -u REPO" to do it, and after that, the feature doesn't appear any more. But 
> when I do "repo-add REPO", it seems that Karaf retrieves some invalid state, 
> and the feature is installed in the same operation, and its bundle started, 
> before I run a "feature:install"...
>
> Thanks for your help.
>
> Regards.
>
> Le ven. 3 mars 2023 à 12:37, Ephemeris Lappis  a 
> écrit :
> >
> > Hello.
> >
> > I think I still need to learn a lot of things about Karaf's features...
> >
> > We have something like that, with 3 features levels :
> >
> > - F1
> >   set dependencies on some Camel and Karaf features
> >   provides 

RE: Karaf 4.4.3 / Features wiring and upgrade

[Maurice Betzel]

Hi Ephemeris Lappis,

blueprint proxy objects not updating is a known issue I have experienced as 
well, that is why we do more and more declarative services that handle dynamism 
better.
Concerning features, we only use them to generate Karaf archive files (KAR), to 
have maximum control over what gets deployed, and it gets rid of the external 
repository security concern (remember log4j).
Our nodes per default do not have any external network connection. Maintaining 
the cluster this way is no hassle up to now as semantic versioning and domain 
driven design do their job in creating loosely coupled modules that play nice 
with each other.

-Oorspronkelijk bericht-
Van: Ephemeris Lappis 
Verzonden: dinsdag 7 maart 2023 19:04
Aan: user@karaf.apache.org
Onderwerp: Re: Karaf 4.4.3 / Features wiring and upgrade

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


Hello.

I finally changed my design a bit, and separated "F1" into 2 distinct features :
- one for the API (interface declaration), say F1A
- one for the service implementation, say F1S

Now, when a modification is required, I can remove the repo and uninstall F1S, 
and add the new repo and install the new version. As the imported package in 
bundles of features Fx are still provided by F1A, Karaf lets me execute the 
operation.

But the service references in bundles from features Fx are not updated, and 
exceptions "ServiceUnavailableException" are thrown when any operation of these 
obsolete proxies is called.

If I "bundle:refresh" the bundles individually, the references are renewed and 
it works again. So how can I make Karaf force an update of all the concerned 
bundles ?

I also notice something strange when I remove an old repo. I use "repo-remove 
-u REPO" to do it, and after that, the feature doesn't appear any more. But 
when I do "repo-add REPO", it seems that Karaf retrieves some invalid state, 
and the feature is installed in the same operation, and its bundle started, 
before I run a "feature:install"...

Thanks for your help.

Regards.

Le ven. 3 mars 2023 à 12:37, Ephemeris Lappis  a 
écrit :
>
> Hello.
>
> I think I still need to learn a lot of things about Karaf's features...
>
> We have something like that, with 3 features levels :
>
> - F1
>   set dependencies on some Camel and Karaf features
>   provides bundles that expose OSGi services
>
> -F2
>   set dependencies on many common Camel features used by all the applications
>   and on F1
>
> -Fx (all our applicative features)
>   set a dependency on F2
>   provides the business Camel routes as a blueprint that use services
> from F1 (and more)
>
> Note that in the bundles in Fx features, we have had to set
> "<_removeheaders>Import-Service" because of missing
> capabilities on services that are provided by pax-jdbc or pax-jms :
> features do not install since pax-* do not expose these capabilities.
>
> When we add the repositories and install features for F1, F2 and Fx, all 
> works.
>
> Now, if I want to upgrade F1, we remove the repository with option
> "-u" to uninstall the feature, and it may be logical to see some
> impacts on dependent features F2, Fx, but nothing.
>
> Then we add the new repository in the new version and install again
> F1. Here we also expected some impact on F2 and Fx, but nothing.
>
> Both actions produce this kind of logs, with "No deployment change"  :
>
> 11:50:08.971 INFO [pipe-feature:install -u $args] The specified
> feature: 'caterpillar-support' version '0.0.1.SNAPSHOT' has been
> upgraded
> 11:50:08.976 INFO [pipe-feature:install -u $args] Adding features:
> caterpillar-support/[0.0.1.SNAPSHOT,0.0.1.SNAPSHOT]
> 11:50:10.647 INFO [features-3-thread-1] No deployment change.
> 11:50:10.653 INFO [features-3-thread-1] Done.
>
> What is wrong ? We expected all the dependent features and their
> bundles (for Fx) to be restarted when a required dependency changes.
> And in our case, all the Fx bundles are still displayed as active,
> routes running, and so on, but the references with F1's services are
> broken, and execution fails.
>
> Thanks in advance for your help.
>
> Regards.
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Emai

Karaf Wrapper with alternative JAVA_HOME

[Maurice Betzel]

Hi,

I have several custom Karaf builds requiring Java 8, but the most resent one 
requires Java 17.
To avoid switching JAVA_HOME on every machine I resorted to attaching the 
required Java version number in the environment variables e.g., JAVA_HOME_17.
Within the Karaf build the file setenv is modified to the correct JAVA_HOME 
version e.g., SET JAVA_HOME=%JAVA_HOME_17%
This works well until the service wrapper gets installed, displayed below a 
part of the Windows 11 wrapper.conf.
set.default.JAVA_HOME is set correctly, but further below %JAVA_HOME% points to 
the default JAVA_HOME in my environment settings, giving Java 8 exceptions on 
startup.
Resetting JAVA_HOME to point to the JDK 17 resolves the issues, but then 
clashes with older builds.

What are the possibilities to propagate the setenv into all wrapper references?

#
# Wrapper Properties
#
set.default.JAVA_HOME=C:\Program Files\Eclipse Adoptium\jdk-17.0.6.10-hotspot
set.default.KARAF_HOME=C:\Users\betzm\Downloads\runtime
set.default.KARAF_BASE=C:\Users\betzm\Downloads\runtime
set.default.KARAF_DATA=C:\Users\betzm\Downloads\runtime\data
set.default.KARAF_ETC=C:\Users\betzm\Downloads\runtime\etc
set.default.KARAF_LOG=C:\Users\betzm\Downloads\runtime\data\log
set.default.KARAF_VERSION=4.4.3
set.default.PATH_WITH_JAVA=%JAVA_HOME%%WRAPPER_FILE_SEPARATOR%bin%WRAPPER_PATH_SEPARATOR%%PATH%%WRAPPER_FILE_SEPARATOR%.

# Include JAVA_HOME/bin in the default PATH variable
set.PATH=%PATH_WITH_JAVA%

set.JDK_JAVA_OPTIONS=--add-reads=java.xml=java.logging 
--add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED 
--patch-module 
java.base=%KARAF_HOME%/lib/endorsed/org.apache.karaf.specs.locator-%KARAF_VERSION%.jar
 --patch-module 
java.xml=%KARAF_HOME%/lib/endorsed/org.apache.karaf.specs.java.xml-%KARAF_VERSION%.jar
 --add-opens java.base/java.security=ALL-UNNAMED --add-opens 
java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED 
--add-opens java.base/java.util=ALL-UNNAMED --add-opens 
java.naming/javax.naming.spi=ALL-UNNAMED --add-opens 
java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.protocol.file=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.protocol.ftp=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED 
--add-exports=java.base/sun.net.www.content.text=ALL-UNNAMED 
--add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED 
--add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED 
--add-exports=java.rmi/sun.rmi.registry=ALL-UNNAMED 
--add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED

# Java Application
wrapper.working.dir=%KARAF_BASE%
wrapper.java.command=%JAVA_HOME%/bin/java
wrapper.java.mainclass=org.apache.karaf.wrapper.internal.service.Main
wrapper.java.classpath.1=%KARAF_BASE%/lib/boot/*.jar
wrapper.java.classpath.2=%KARAF_BASE%/lib/jdk9plus/*.jar
wrapper.java.classpath.3=%KARAF_BASE%/lib/wrapper/*.jar
wrapper.java.library.path.1=%KARAF_BASE%/lib/wrapper/

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer - Gaston Schul Group


Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf LDAP without blueprint

[Maurice Betzel]

Update, I got it working so far.

I mixed up the ProxyLoginModule with the 
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule.
For those searching the same issue, look at how 
org.apache.karaf.jaas.modules.impl.KarafRealm is creating the 
AppConfigurationEntry collection.
The OSGi JAAS module goes into the options, not into the AppConfigurationEntry 
constructor.

From: Maurice Betzel 
Sent: donderdag 23 februari 2023 10:48
To: user@karaf.apache.org
Subject: RE: Karaf LDAP without blueprint

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

Update,

Javax is not able to involve login on the Karaf LDAP module because it cannot 
find it:

javax.security.auth.login.LoginException: No LoginModule found for 
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule

Do I have to register the Karaf JAAS modules anywhere or how can I make 
javax.security.auth.login find 
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule?


From: Maurice Betzel 
mailto:m.bet...@gaston-schul.com>>
Sent: donderdag 23 februari 2023 09:59
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: RE: Karaf LDAP without blueprint

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

Moin,

My DS JAAS bundle is active, but I cannot perform an ssh login and no 
exceptions are thrown so I guessing no Karaf LDAP JAAS module configured is 
active.

I am creating a list of type AppConfigurationEntry and add a new one with 
params:

org.apache.karaf.jaas.modules.ldap.LDAPLoginModule,
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
and the LDAP options Map from the blueprint setup.

What am I missing?

From: Matt Pavlovich mailto:mattr...@gmail.com>>
Sent: woensdag 22 februari 2023 21:03
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf LDAP without blueprint

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

Hi Paul-

Thanks for the input. Yep, I’m seeing the same thing. There needs to be a 
class-level lock that operations are synchronized on, and not rely on 
class-static cache and method synchronization.

I made a JIRA to track: https://issues.apache.org/jira/browse/KARAF-7671

-Matt Pavlovich

On Feb 21, 2023, at 12:01 PM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

Matt,
From memory (& less than stellar comments) I believe the issue is in concurrent 
access to getCache() & clear()

public static LDAPCache getCache(LDAPOptions options) {
LDAPCache cache = CACHES.get(options);
if (cache == null) {
CACHES.putIfAbsent(options, new LDAPCache(options));
cache = CACHES.get(options);
}
return cache;
}

If clear() is called by another thread between the putIfAbsent() and get() then 
null is returned.

A second issue (and this is just from memory & Karaf code review, so I may be 
mistaken) is that the LDAP cache is cleared in LDAPLoginModule.initialize(), 
but this method is called every time a user authenticates - so the cache is 
never used.

Paul


On Tue, 21 Feb 2023 at 15:27, Matt Pavlovich 
mailto:mattr...@gmail.com>> wrote:
Paul-

What issues have you found with the LDAP caching module? Please share, so I can 
open a JIRA and fix it.

Thanks!
Matt Pavlovich

On Feb 21, 2023, at 4:42 AM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

I use a DS component which instantiates an 
org.apache.karaf.jaas.config.JaasRealm and registers it via 
org.osgi.framework.BundleContext.registerService(Class, JaasRealm, 
Dictionary).

My DS component uses Config Admnin to configure the realm. I wrap the standard 
Karaf LDAP module in my own caching proxy (as I found concurrency issues with 
org.apache.karaf.jaas.modules.ldap.LDAPCache.getCache(LDAPOptions)).

I can't share the code, but I can answer any questions you have.

Paul

On Tue, 21 Feb 2023 at 08:09, Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

I am building a new custom Karaf assembly and would like to avoid installing 
aries blueprint just for creating an LDAP login module.
Does anybody have any experience with alternatives like declarative services or 
low-level activator setup willing to share the knowledge?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
F

RE: Karaf LDAP without blueprint

[Maurice Betzel]

Update,

Javax is not able to involve login on the Karaf LDAP module because it cannot 
find it:

javax.security.auth.login.LoginException: No LoginModule found for 
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule

Do I have to register the Karaf JAAS modules anywhere or how can I make 
javax.security.auth.login find 
org.apache.karaf.jaas.modules.ldap.LDAPLoginModule?


From: Maurice Betzel 
Sent: donderdag 23 februari 2023 09:59
To: user@karaf.apache.org
Subject: RE: Karaf LDAP without blueprint

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

Moin,

My DS JAAS bundle is active, but I cannot perform an ssh login and no 
exceptions are thrown so I guessing no Karaf LDAP JAAS module configured is 
active.

I am creating a list of type AppConfigurationEntry and add a new one with 
params:

org.apache.karaf.jaas.modules.ldap.LDAPLoginModule,
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
and the LDAP options Map from the blueprint setup.

What am I missing?

From: Matt Pavlovich mailto:mattr...@gmail.com>>
Sent: woensdag 22 februari 2023 21:03
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: Re: Karaf LDAP without blueprint

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

Hi Paul-

Thanks for the input. Yep, I’m seeing the same thing. There needs to be a 
class-level lock that operations are synchronized on, and not rely on 
class-static cache and method synchronization.

I made a JIRA to track: https://issues.apache.org/jira/browse/KARAF-7671

-Matt Pavlovich

On Feb 21, 2023, at 12:01 PM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

Matt,
From memory (& less than stellar comments) I believe the issue is in concurrent 
access to getCache() & clear()

public static LDAPCache getCache(LDAPOptions options) {
LDAPCache cache = CACHES.get(options);
if (cache == null) {
CACHES.putIfAbsent(options, new LDAPCache(options));
cache = CACHES.get(options);
}
return cache;
}

If clear() is called by another thread between the putIfAbsent() and get() then 
null is returned.

A second issue (and this is just from memory & Karaf code review, so I may be 
mistaken) is that the LDAP cache is cleared in LDAPLoginModule.initialize(), 
but this method is called every time a user authenticates - so the cache is 
never used.

Paul


On Tue, 21 Feb 2023 at 15:27, Matt Pavlovich 
mailto:mattr...@gmail.com>> wrote:
Paul-

What issues have you found with the LDAP caching module? Please share, so I can 
open a JIRA and fix it.

Thanks!
Matt Pavlovich

On Feb 21, 2023, at 4:42 AM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

I use a DS component which instantiates an 
org.apache.karaf.jaas.config.JaasRealm and registers it via 
org.osgi.framework.BundleContext.registerService(Class, JaasRealm, 
Dictionary).

My DS component uses Config Admnin to configure the realm. I wrap the standard 
Karaf LDAP module in my own caching proxy (as I found concurrency issues with 
org.apache.karaf.jaas.modules.ldap.LDAPCache.getCache(LDAPOptions)).

I can't share the code, but I can answer any questions you have.

Paul

On Tue, 21 Feb 2023 at 08:09, Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

I am building a new custom Karaf assembly and would like to avoid installing 
aries blueprint just for creating an LDAP login module.
Does anybody have any experience with alternatives like declarative services or 
low-level activator setup willing to share the knowledge?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.




Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van Be

RE: Karaf LDAP without blueprint

[Maurice Betzel]

Moin,

My DS JAAS bundle is active, but I cannot perform an ssh login and no 
exceptions are thrown so I guessing no Karaf LDAP JAAS module configured is 
active.

I am creating a list of type AppConfigurationEntry and add a new one with 
params:

org.apache.karaf.jaas.modules.ldap.LDAPLoginModule,
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED,
and the LDAP options Map from the blueprint setup.

What am I missing?

From: Matt Pavlovich 
Sent: woensdag 22 februari 2023 21:03
To: user@karaf.apache.org
Subject: Re: Karaf LDAP without blueprint

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

Hi Paul-

Thanks for the input. Yep, I’m seeing the same thing. There needs to be a 
class-level lock that operations are synchronized on, and not rely on 
class-static cache and method synchronization.

I made a JIRA to track: https://issues.apache.org/jira/browse/KARAF-7671

-Matt Pavlovich


On Feb 21, 2023, at 12:01 PM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

Matt,
From memory (& less than stellar comments) I believe the issue is in concurrent 
access to getCache() & clear()

public static LDAPCache getCache(LDAPOptions options) {
LDAPCache cache = CACHES.get(options);
if (cache == null) {
CACHES.putIfAbsent(options, new LDAPCache(options));
cache = CACHES.get(options);
}
return cache;
}

If clear() is called by another thread between the putIfAbsent() and get() then 
null is returned.

A second issue (and this is just from memory & Karaf code review, so I may be 
mistaken) is that the LDAP cache is cleared in LDAPLoginModule.initialize(), 
but this method is called every time a user authenticates - so the cache is 
never used.

Paul


On Tue, 21 Feb 2023 at 15:27, Matt Pavlovich 
mailto:mattr...@gmail.com>> wrote:
Paul-

What issues have you found with the LDAP caching module? Please share, so I can 
open a JIRA and fix it.

Thanks!
Matt Pavlovich


On Feb 21, 2023, at 4:42 AM, Paul McCulloch 
mailto:pkmccull...@gmail.com>> wrote:

I use a DS component which instantiates an 
org.apache.karaf.jaas.config.JaasRealm and registers it via 
org.osgi.framework.BundleContext.registerService(Class, JaasRealm, 
Dictionary).

My DS component uses Config Admnin to configure the realm. I wrap the standard 
Karaf LDAP module in my own caching proxy (as I found concurrency issues with 
org.apache.karaf.jaas.modules.ldap.LDAPCache.getCache(LDAPOptions)).

I can't share the code, but I can answer any questions you have.

Paul

On Tue, 21 Feb 2023 at 08:09, Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

I am building a new custom Karaf assembly and would like to avoid installing 
aries blueprint just for creating an LDAP login module.
Does anybody have any experience with alternatives like declarative services or 
low-level activator setup willing to share the knowledge?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.




Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files tra

RE: Karaf LDAP without blueprint

[Maurice Betzel]

Hi Paul, thanks for the input.
What I reverse engineer from blueprint and docs is that I indeed need to 
publish a JaasRealm on the service registry that wraps (?) the Karaf login 
module in some way. Props are indeed per config admin and a Designate for 
binding the config,  which I am testing just now:


import org.apache.karaf.jaas.config.JaasRealm;
import org.osgi.service.component.ComponentContext;
import org.osgi.service.component.annotations.Activate;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.ConfigurationPolicy;

import org.osgi.service.metatype.annotations.*;

import javax.security.auth.login.AppConfigurationEntry;
import java.util.Dictionary;
import java.util.Enumeration;

@Component(name = "eu.abeel.platform.security.jaas",
service = JaasRealm.class,
configurationPolicy = ConfigurationPolicy.REQUIRE,
configurationPid = "eu.abeel.platform.security.jaas.ldap",
immediate = true)
@Designate(ocd = JaasModuleConfig.class)
public class PlatformJaasRealm implements JaasRealm {


@Activate
public void activate(ComponentContext context, JaasModuleConfig 
jaasModuleConfig) {
Dictionary properties = context.getProperties();
Enumeration keys = properties.keys();
while (keys.hasMoreElements()) {
String key = keys.nextElement();
System.out.println(key + " = " + properties.get(key));
}
}


From: Paul McCulloch 
Sent: dinsdag 21 februari 2023 11:43
To: user@karaf.apache.org
Subject: Re: Karaf LDAP without blueprint

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

I use a DS component which instantiates an 
org.apache.karaf.jaas.config.JaasRealm and registers it via 
org.osgi.framework.BundleContext.registerService(Class, JaasRealm, 
Dictionary).

My DS component uses Config Admnin to configure the realm. I wrap the standard 
Karaf LDAP module in my own caching proxy (as I found concurrency issues with 
org.apache.karaf.jaas.modules.ldap.LDAPCache.getCache(LDAPOptions)).

I can't share the code, but I can answer any questions you have.

Paul

On Tue, 21 Feb 2023 at 08:09, Maurice Betzel 
mailto:m.bet...@gaston-schul.com>> wrote:
Dear community,

I am building a new custom Karaf assembly and would like to avoid installing 
aries blueprint just for creating an LDAP login module.
Does anybody have any experience with alternatives like declarative services or 
low-level activator setup willing to share the knowledge?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.



Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

Karaf LDAP without blueprint

[Maurice Betzel]

Dear community,

I am building a new custom Karaf assembly and would like to avoid installing 
aries blueprint just for creating an LDAP login module.
Does anybody have any experience with alternatives like declarative services or 
low-level activator setup willing to share the knowledge?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: osgi serviceloader missing in 4.4.3

[Maurice Betzel]

Hi,

Are you using Aries SPI Fly?

https://aries.apache.org/documentation/modules/spi-fly.html

An example of dependencies needed in the kar maven module:

https://github.com/Maurice-Betzel/twelvemonkeys-osgi


From: Paul Fraser 
Sent: dinsdag 7 februari 2023 11:20
To: user@karaf.apache.org
Subject: osgi serviceloader missing in 4.4.3

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


Hi,

4.3.6 out of the box has the Aries org.apache.aries.spifly.dynamic.bundle 
loaded and service loading works OK.

4.4.3 does not have this bundle loaded and as a consequence service loading 
(for me) does not work.

In 4.3.6 I cannot find what causes this bundle to be loaded as it is not listed 
in startup.properties and I cannot find

a feature in features.cfg that handles it.

feature:info spifly does not indicate that it handles the dynamic bundle either.

What am I missing and what needs to be added to handle service loading in 4.4.3.

Regards

Paul Fraser



Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Transactions and PAX JDBC

[Maurice Betzel]

Hi,

I use a tool for displaying the log that lets me highlight certain lines in 
different selectable colours depending on words contained in the log.
It is called baretail and it helps filtering the log soup ad hoc.

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com





-Original Message-
From: Ephemeris Lappis 
Sent: 03 December 2022 02:41
To: user@karaf.apache.org; Maurice Betzel 
Subject: Re: Transactions and PAX JDBC

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


Hello.

I'm going to try setting the log level on the TM, even if I'm afraid that in 
debug I get too much logs...

Thanks.

Regards.

Ephemeris Lappis

Le 02/12/2022 à 12:30, Maurice Betzel a écrit :
> Hi,
>
> You can turn on logging for the specific namespace like log:set DEBUG
> org.apache.aries.transaction or I choose the pax-jdbc-pool-aries because it 
> supported XA transactions, there are pools that do not IIRC.
>
> Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
> Maurice Betzel Principal Software Engineer Gaston Schul Group
>
>
> -Original Message-
> From: Ephemeris Lappis 
> Sent: 02 December 2022 12:24
> To: user@karaf.apache.org
> Subject: Transactions and PAX JDBC
>
>   CAUTION: This email originated from outside of Gaston Schul. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
>
>
> Hello.
>
> I'm testing pax-jdbc-config to configure XA data sources that should be 
> available as "wrapped and auto-enlisted" javax.sql.DataSource to be used in 
> Camel routes.
>
> The data source is configured using the pax-jdbc-config with a simple CFG 
> file setting the pool type (dbcp2) and xa flag.
>
> My tests seem to be OK, both on simple "non transacted" routes with SQL only 
> and on "transacted" routes with JMS and SQL operations. From an external 
> point of view, the transactions are correct...
>
> Is there any way to monitor the transaction manager to see what it does ?
>
> When I look at the JMX MBeans I can see some information about the
> DBCP2 pool, but nothing about underlying (postgresql) connections...
>
> What kind of statistics should I care about to control transactions ?
>
> Thanks for your help.
>
> Regards.
> Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
> Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch 
> Staatsblad dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden 
> wordt op uw verzoek gratis toegezonden.
> All our transactions are subject to the General Conditions of the Belgian 
> Forwarders Association which have been published under nr. 0090237 in the 
> "Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
> free of charge upon request.
> Toutes nos opérations se font sur base des Conditions Générales des 
> Expéditeurs de Belgique. Le texte en a été publié dans l' Annexe au Moniteur 
> Belge du 24 juin 2005 sous le n° 0090237. Ce texte sera vous envoyé 
> gratuitment sur demande.
> Email confidentiality notice:
> This email and any files transmitted with it are confidential and intended 
> only for the use of the recipient. If you have received this email in error 
> please notify its sender.
>

--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Transactions and PAX JDBC

[Maurice Betzel]

Hi,

You can turn on logging for the specific namespace like log:set DEBUG 
org.apache.aries.transaction or
I choose the pax-jdbc-pool-aries because it supported XA transactions, there 
are pools that do not IIRC.

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group


-Original Message-
From: Ephemeris Lappis 
Sent: 02 December 2022 12:24
To: user@karaf.apache.org
Subject: Transactions and PAX JDBC

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


Hello.

I'm testing pax-jdbc-config to configure XA data sources that should be 
available as "wrapped and auto-enlisted" javax.sql.DataSource to be used in 
Camel routes.

The data source is configured using the pax-jdbc-config with a simple CFG file 
setting the pool type (dbcp2) and xa flag.

My tests seem to be OK, both on simple "non transacted" routes with SQL only 
and on "transacted" routes with JMS and SQL operations. From an external point 
of view, the transactions are correct...

Is there any way to monitor the transaction manager to see what it does ?

When I look at the JMX MBeans I can see some information about the
DBCP2 pool, but nothing about underlying (postgresql) connections...

What kind of statistics should I care about to control transactions ?

Thanks for your help.

Regards.
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: [VOTE] Adopt new Apache Karaf "generic" logo

[Maurice Betzel]

+1

Like the colours, the logo design, and the font.

Do the small squares represent a Karaf instance or the modules on a runtime?
Or could be both?
If modules, the black box surrounding the small squares is the runtime?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com





-Original Message-
From: Jean-Baptiste Onofré 
Sent: 15 November 2022 09:57
To: dev ; user 
Subject: [VOTE] Adopt new Apache Karaf "generic" logo

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


Hi guys,

As discussed on the other thread, here's a vote for the new Karaf logo proposal.

As a reminder, this logo is the generic one, used on the main karaf.apache.org 
website. Each Karaf subproject (Minho, OSGi, etc) will have its own 
"sub-website", with dedicated content and eventually its own logo.

Please vote:
+1 to adopt Karaf generic logo
0 I don't care
-1 for Karaf generic logo and work on a new one

NB: I would like to move forward pretty fast on the logo just to promote the 
new website and announce Karaf Minho.

Thanks,
Regards
JB
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf Minho

[Maurice Betzel]

- Spring Cloud: usually small balls of mud interacting, no crash barriers build 
in for designing a clean modular and loosely coupled architecture
- Apache Karaf: OSGi providing the crash barriers to guide developers in making 
the right choices creating modules by separation of concerns and communicating 
over a central OSGi service registry, needs more than average knowledge of the 
Java classpath, module dependencies and SOLID in general
-Apache Karaf Minho: what I know sofar, by default a single classpath and no 
OSGi livecycle (which could limit dynamic loading of new code?), service 
propagation done by the Java 6 default service provider mechanism

See https://www.youtube.com/watch?v=mhqgPXoJXCk

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT

-Original Message-
From: Jaap Gordijn 
Sent: 10 November 2022 15:27
To: user@karaf.apache.org
Subject: RE: Karaf Minho

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


No one who can help me here?

Essentially, to build a dynamic frontend/backend plugin system we have to 
decide to go for:
- Spring Cloud (large community, but needs many processes / JVMs to build it , 
so it seems not very efficient
- Apache Karaf (efficient system as there needs only to be one JVM, but
complex)
- Minho, which seems to be able to dynamically (un)load Spring Boot modules)

Best,

-- Jaap

> -Original Message-
> From: frm 
> Sent: maandag 7 november 2022 12:05
> To: user@karaf.apache.org
> Subject: Karaf Minho
>
> Hi,
>
> I've looked at the githib repo (https://github.com/jbonofre/karaf5) at
> Minho.
> It looks very interesting to me, as I want to host multiple Spring
> Boot applications into one container.
>
> A few questions:
> - I read there is an example of two Spring Boot applications that can
> run
into
> Minho, but I can not find the example. Can you tell me where the
> example is?
> - Does Minho support dynamic loading of Spring Boot application?
>
> Best,
>
> -- Jaap Gordijn
>


Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: [DISCUSS] Adopt new Karaf logo

[Maurice Betzel]

How about something like a dry stone wall.

More detailed metaphor explanation:

https://fgiesen.wordpress.com/2015/07/22/the-modulith/

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com





-Original Message-
From: Jean-Baptiste Onofré 
Sent: 07 November 2022 13:19
To: Jean-Baptiste Onofré 
Cc: dev ; user@karaf.apache.org
Subject: Re: [DISCUSS] Adopt new Karaf logo

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


Hi guys,

Thanks all for your feedback.

Regarding your comments (it seems cloud logo doesn't convince everyone), and to 
represent more the generic aspect of karaf (as umbrella project), I created a 
new more abstract logo.

Thoughts ?

Regards
JB

On Tue, Nov 1, 2022 at 2:11 PM Jean-Baptiste Onofré  wrote:
>
> Hi guys,
>
> as discussed on a previous thread, I'm working on a new website
> proposal with the following objectives:
>
> 1. Use docusaurus instead of jekyll to build. The good thing is that
> it supports md syntax, blog, etc.
> 2. Give the same space/visibility to the subprojects (Karaf Minho,
> Karaf OSGi, Karaf Decanter, Karaf Cellar, Karaf Cave, Karaf
> Winegrower)
> 3. Add blog feature to announce and provide details about Karaf
> projects
>
> Related to that, I created a new "generic" logo for Karaf (each
> project can have its own logo).
>
> You can see the logo proposal attached.
>
> Basically the idea is:
> - boxes populating the cloud represent Karaf projects
> - we can assembly Karaf projects to create a cloud solution
>
> Thoughts ?
>
> If we agree with this logo, I would like to prepare some goodies using
> it (probably on https://www.redbubble.com/en/).
>
> Regards
> JB
Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: cxf / camel-blueprint stax2 classloading issue

[Maurice Betzel]

Seems this was an issue more often, please research the following:

https://stackoverflow.com/questions/53990175/cxfservlet-throws-java-lang-nosuchmethoderror-org-codehaus-stax2-ri-emptyiterat

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com<https://www.gaston-schul.com/>

[cid:image001.jpg@01D8F28A.C860B7E0]



[cid:image002.jpg@01D8F28A.C860B7E0]



From: Björn Konrad 
Sent: 07 November 2022 09:17
To: user@karaf.apache.org
Subject: AW: cxf / camel-blueprint stax2 classloading issue

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

This does not help (I have no unresolved bundles).

I reproduced the problem with some simple steps:

  1.  downloaded karaf 4.4.2
  2.  I added the mentioned feature repos 
(mvn:org.apache.cxf.karaf/apache-cxf/3.5.4/xml/features, 
mvn:org.apache.camel.karaf/apache-camel/3.19.0/xml/features)
  3.  feature:install cxf aries-blueprint camel-blueprint
  4.  I deployed a simple webservice bundle

blueprint.xml:




  1.  Accessing http://localhost:8181/cxf/my-service?wsdl gives me the 
mentioned error
Any help would be great!

Kind regards

Von: Maurice Betzel 
mailto:m.bet...@gaston-schul.com>>
Gesendet: Freitag, 4. November 2022 13:24
An: user@karaf.apache.org<mailto:user@karaf.apache.org> 
mailto:user@karaf.apache.org>>
Betreff: RE: cxf / camel-blueprint stax2 classloading issue


Download the correct jar from Maven central and drop it in the Karaf deploy 
folder to see if the other bundles are now resolving and / or not throwing an 
error.

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,

Maurice Betzel
Principal Software Engineer

Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03

Website: www.gaston-schul.com<https://www.gaston-schul.com/>


[cid:image001.jpg@01D8F28A.C860B7E0]





[cid:image002.jpg@01D8F28A.C860B7E0]






From: Björn Konrad mailto:bjoern.kon...@hr.de>>
Sent: 04 November 2022 13:13
To: user@karaf.apache.org<mailto:user@karaf.apache.org>
Subject: cxf / camel-blueprint stax2 classloading issue



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



I include the features



mvn:org.apache.cxf.karaf/apache-cxf/3.5.2/xml/features, \
mvn:org.apache.camel.karaf/apache-camel/3.18.0/xml/features



in karaf 4.4.1 (org.apache.karaf.features.cfg) and configured 'cxf' and 
'camel-blueprint' as featuresBoot.



Accessing the wsdl (e.g. /cxf/my-service?wsdl) gives me following error:



java.lang.NoSuchMethodError: 'org.codehaus.stax2.ri.EmptyIterator 
org.codehaus.stax2.ri.EmptyIterator.getInstance()



As it turns out, following bundles are installed:



233 │ Active  │  20 │ 4.2.1 │ 
mvn:org.codehaus.woodstox/stax2-api/4.2.1 (installed by cxf)

318 │ Active  │  10 │ 3.1.4 │ 
mvn:org.codehaus.woodstox/stax2-api/3.1.4 (installed by camel-blueprint)



So, it seems like cxf is wired to the wrong version auf stax2-api.



Any ideas how to solve this?

Der Inhalt dieser E-Mail stellt keine rechtsverbindliche Erklärung des 
Absenders dar. Zur rechtsgeschäftlichen Vertretung des hr sind neben dem 
Intendanten als seinem gesetzlichen Vertreter grundsätzlich nur zwei 
bevollmächtigte Personen gemeinsam berechtigt. Auskünfte über den Umfang der 
Vollmachten erteilt die Justiziarin des hr.

Der Inhalt dieser E-Mail (einschließlich beigefügter Dateien) ist vertraulich 
und nur für den Empfänger bestimmt; dies gilt nicht für Mails der Pressestelle 
oder für Newsletter. Wenn Sie nicht der bestimmungsgemäße Empfänger dieser 
E-Mail sind, informieren Sie bitte sofort den Absender und löschen Sie diese 
Mail von Ihrem System. Beachten Sie, dass die Verbreitung, das Kopieren sowie 
die Weitergabe der E-Mail nicht gestattet sind; dies gilt nicht für Mails der 
Pressestelle oder für Newsletter.

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Condi

RE: cxf / camel-blueprint stax2 classloading issue

[Maurice Betzel]

Download the correct jar from Maven central and drop it in the Karaf deploy 
folder to see if the other bundles are now resolving and / or not throwing an 
error.
Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com<https://www.gaston-schul.com/>

[cid:image001.jpg@01D8F050.CB78EF60]



[cid:image002.jpg@01D8F050.CB78EF60]



From: Björn Konrad 
Sent: 04 November 2022 13:13
To: user@karaf.apache.org
Subject: cxf / camel-blueprint stax2 classloading issue

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

I include the features

mvn:org.apache.cxf.karaf/apache-cxf/3.5.2/xml/features, \
mvn:org.apache.camel.karaf/apache-camel/3.18.0/xml/features

in karaf 4.4.1 (org.apache.karaf.features.cfg) and configured 'cxf' and 
'camel-blueprint' as featuresBoot.

Accessing the wsdl (e.g. /cxf/my-service?wsdl) gives me following error:

java.lang.NoSuchMethodError: 'org.codehaus.stax2.ri.EmptyIterator 
org.codehaus.stax2.ri.EmptyIterator.getInstance()

As it turns out, following bundles are installed:

233 │ Active  │  20 │ 4.2.1 │ 
mvn:org.codehaus.woodstox/stax2-api/4.2.1 (installed by cxf)
318 │ Active  │  10 │ 3.1.4 │ 
mvn:org.codehaus.woodstox/stax2-api/3.1.4 (installed by camel-blueprint)

So, it seems like cxf is wired to the wrong version auf stax2-api.

Any ideas how to solve this?

Der Inhalt dieser E-Mail stellt keine rechtsverbindliche Erklärung des 
Absenders dar. Zur rechtsgeschäftlichen Vertretung des hr sind neben dem 
Intendanten als seinem gesetzlichen Vertreter grundsätzlich nur zwei 
bevollmächtigte Personen gemeinsam berechtigt. Auskünfte über den Umfang der 
Vollmachten erteilt die Justiziarin des hr.

Der Inhalt dieser E-Mail (einschließlich beigefügter Dateien) ist vertraulich 
und nur für den Empfänger bestimmt; dies gilt nicht für Mails der Pressestelle 
oder für Newsletter. Wenn Sie nicht der bestimmungsgemäße Empfänger dieser 
E-Mail sind, informieren Sie bitte sofort den Absender und löschen Sie diese 
Mail von Ihrem System. Beachten Sie, dass die Verbreitung, das Kopieren sowie 
die Weitergabe der E-Mail nicht gestattet sind; dies gilt nicht für Mails der 
Pressestelle oder für Newsletter.

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf Cellar, un-import OSGi service on client node if remote service is stopped?

[Maurice Betzel]

Thanks Scott,

I have started hardening the DOSGi module of Karaf Cellar and the tests are 
looking very good.
The main issue was an executer thread dying a silent death and not registering 
any further remote services on the local registry.
The project you suggested will be my bathtub lecture for the upcoming days, 
maybe I can gain some more insights in handling distributed OSGI services.

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel

From: Scott Lewis 
Sent: 26 July 2022 03:11
To: user@karaf.apache.org
Subject: Re: Karaf Cellar, un-import OSGi service on client node if remote 
service is stopped?

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


Hi Maurice,
On 7/4/2022 5:16 AM, Maurice Betzel wrote:
Good afternoon,

Some DOSGi questions appeared when researching cluster wide exported service 
properties propagation.
In version 4.2.1 I am observing the following behaviour on the client node if I 
turn off a remote service:

On startup the client node will import the remote service to the local service 
registry by endpoint ID via the ImportServiceListener.
I can start using the service and receive responses.
If I now stop the remote service bundle I would expect that the client would 
un-import the service from the local OSGi service registry.
This is not the case.
The service tracker monitoring remote services does notice the removed service 
but nothing else is happening.
If the client now calls the service, it will stall for about 20 seconds and 
then return null instead of a service not found exception.

I this the default behaviour? Is it possible to un-import the remote service if 
the endpoint gets removed from the Hazelcast service map?

I'm  not familiar enough with the Cellar DOSGi impl to say why you are not 
experiencing the expected behavior (remote service is unregistered, then 
clients should unimport the remote service and unregister the proxy).

I can tell you that ECF RSA impl [1] + the Hazelcast distribution provider (see 
[2]) does have this expected behavior.  There are instructions in the README.md 
for running an example app with the Hazelcast provider on Karaf (i.e. using 
karaf features).

Scott

[1] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project

[2] https://github.com/ECF/HazelcastProvider



Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice


Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.



Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

Karaf Cellar DOSGi, concurrent modification exception

[Maurice Betzel]

Hi all,

I have found a concurrent modification exception in the ImportServiceListener 
class on line 198 : pendingListeners.remove(listenerInfo) during the iteration 
of the pendingListeners within the run.
This silently kills the SingleThreadScheduledExecutor so the exception is never 
displayed in the logs.
Is this the expected behaviour?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Pax-Web - org.ops4j.pax.web.ssl.ciphersuites.excluded

[Maurice Betzel]

No I have not. But if you are using jetty you can redirect the socket 
configuration to the Jetty settings xml.

Add to org.ops4j.pax.web.cfg:

org.ops4j.pax.web.config.file = ${karaf.etc}/settings.xml

Within the xml you can declare and setup the Jetty beans:



/etc/keystore/xyz.jks

xxx
xxx










SSLv3




SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
...






Has anyone used Pax-Web settings

org.ops4j.pax.web.ssl.ciphersuites.excluded=
org.ops4j.pax.web.ssl.ciphersuites.included=

? I've tried, for example, to exclude all ciphers with

org.ops4j.pax.web.ssl.ciphersuites.excluded=.*

but it doesn't seem to have an effect.




Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf Cellar DOSGi, throw exception if remote results is NULL

[Maurice Betzel]

Nah, CancellationException seem more appropriate:

throw new CancellationException("CELLAR DOSGI: no remote service execution 
results for " + serviceClass + " due to time out");

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Gaston Schul Group
Department ICT
Kazernestraat 10
5928 NL Venlo

Phone: +31 77 32 460 26
Mobile Phone: +31 6 10 37 58 03
Website: www.gaston-schul.com<https://www.gaston-schul.com/>

[cid:image001.jpg@01D892CA.35C0DA70]



[cid:image002.jpg@01D892CA.35C0DA70]



From: Maurice Betzel
Sent: 08 July 2022 12:16
To: user@karaf.apache.org
Subject: RE: Karaf Cellar DOSGi, throw exception if remote results is NULL

Hi JBO,

I just did a test run with this setup but throwing a 
RemoteServiceInvocationException results in a client side  
UndeclaredThrowableException, so I used the runtime exception NullPointer, as 
that is what we actually get from the poll method:

Class RemoteServiceInvocationHandler line 78:

throw new NullPointerException("CELLAR DOSGI: no remote service execution 
results for " + endpointId + " due to time out");
Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

RE: Karaf Cellar DOSGi, throw exception if remote results is NULL

[Maurice Betzel]

Hi JBO,

I just did a test run with this setup but throwing a 
RemoteServiceInvocationException results in a client side  
UndeclaredThrowableException, so I used the runtime exception NullPointer, as 
that is what we actually get from the poll method:

Class RemoteServiceInvocationHandler line 78:

throw new NullPointerException("CELLAR DOSGI: no remote service execution 
results for " + endpointId + " due to time out");
Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

Karaf Cellar DOSGi, throw exception if remote results is NULL

[Maurice Betzel]

Good morning,

In the Karaf Cellar DOSGi module the RemoteServiceInvocationHandler polls the 
remote results from a result queue in Command getResult() returning a map. If 
this poll times out after 30 secs NULL gest returned to the caller. Would it 
not be a better idea to raise a
RemoteServiceInvocationException if results is NULL so the caller can 
differentiate between a service returning NULL and a failed invocation?
Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel

Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

Karaf Cellar, un-import OSGi service on client node if remote service is stopped?

[Maurice Betzel]

Good afternoon,

Some DOSGi questions appeared when researching cluster wide exported service 
properties propagation.
In version 4.2.1 I am observing the following behaviour on the client node if I 
turn off a remote service:

On startup the client node will import the remote service to the local service 
registry by endpoint ID via the ImportServiceListener.
I can start using the service and receive responses.
If I now stop the remote service bundle I would expect that the client would 
un-import the service from the local OSGi service registry.
This is not the case.
The service tracker monitoring remote services does notice the removed service 
but nothing else is happening.
If the client now calls the service, it will stall for about 20 seconds and 
then return null instead of a service not found exception.

I this the default behaviour? Is it possible to un-import the remote service if 
the endpoint gets removed from the Hazelcast service map?

Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice


Al onze verrichtingen geschieden op basis van de Algemene voorwaarden der 
Expediteurs van België, gepubliceerd in de bijlage tot het Belgisch Staatsblad 
dd. 24 juni 2005 onder nr. 0090237. De tekst van deze voorwaarden wordt op uw 
verzoek gratis toegezonden.
All our transactions are subject to the General Conditions of the Belgian 
Forwarders Association which have been published under nr. 0090237 in the 
"Bijlage tot het Belgisch Staatsblad" dated June 24th, 2005, and is available 
free of charge upon request.
Toutes nos opérations se font sur base des Conditions Générales des Expéditeurs 
de Belgique. Le texte en a été publié dans l' Annexe au Moniteur Belge du 24 
juin 2005 sous le n° 0090237. Ce texte sera vous envoyé gratuitment sur demande.
Email confidentiality notice:
This email and any files transmitted with it are confidential and intended only 
for the use of the recipient. If you have received this email in error please 
notify its sender.

Re: CXF 3.3.6 Web-socket on Karaf 4.2.8

[Maurice Betzel]

Nope, data -> trash and already reinstalled



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: CXF 3.3.6 Web-socket on Karaf 4.2.8

[Maurice Betzel]

I wanted to put this issue on the mailing list of CXF this morning and after
booting my dev computer and trying to reproduce the error, the websocket
example is suddenly working. This is frustrating and i will try to see if i
can get it to fail again and why.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: What is the hibernate version in enterprise feature 4.2.8?

[Maurice Betzel]

Hibernate-never is using the placeholder so I guess someone forgot to add
these. Make it a  Jira

  
or create a pull request.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Camel auto downloader?

[Maurice Betzel]

Forgot this one for assembly:

https://github.com/apache/karaf/tree/master/examples/karaf-maven-example/karaf-maven-example-assembly



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Camel auto downloader?

[Maurice Betzel]

It is a lot and can be overwhelming in the beginnings, but stick to the
examples and experience will aggregate:

https://github.com/apache/karaf/tree/master/examples/karaf-camel-example



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

CXF 3.3.6 Web-socket on Karaf 4.2.8

[Maurice Betzel]

Dear community,

this  CXF web-socket example

  
is not getting a WS connection with the js client returning a 404. There
were posts regarding this issue in the past, but I found no working
solution. I would like to have just framework handling all of my JAX RS and
WS.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: KarService Problem

[Maurice Betzel]

Of the top of my head it is kar:install File://path.to.kar.file.kar 

After kar: do a tab for auto completion and display all options.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Apache POI

[Maurice Betzel]

JB is right about the servicemix bundles, I use POI in several integration
projects and something like the features below should do the job. Just drop
in the deploy folder of a karaf with maven central connection. Then you can
read it in with Workbook workbook = WorkbookFactory.create(xxx);





-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi Remote Services with gRCP

[Maurice Betzel]

Since default java serialization is on it’s way out your work will definitely
gain traction within DOSGi and for my setup this is a attractive
alternative. I the need arises I will extend it myself and create a pull
request. This could also be a good blueprint for Apache Thrift. Exchangeable
protocols is wishful thinking 🤔.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi Remote Services with gRCP

[Maurice Betzel]

Rephrasing the question, does this bring extended functionality to other
protobuf supported languages as well?



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi Remote Services with gRCP

[Maurice Betzel]

Now I remember why I mostly used Apache Thrift instead of protobuf, it has
official php support. I usually generate the model in one jar like this: 
kie-server-java/pom.xml
<https://github.com/Maurice-Betzel/org.kie.server.thrift/blob/master/kie-server-java/pom.xml>
  



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi Remote Services with gRCP

[Maurice Betzel]

Hi Scott, I mainly used protobuf and other binary protocols for communication
in heterogeneous environments.
I guess for a pure Java environment this could more easily span multiple JRE
versions in comparison with the default Java serialization mechanism. In
your setup, could I also create a stub for, let’s say, a php client?



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

Missed your the status request:

  │ Node   │ Status │ Event Handler
──┼┼┼─
  │ 10.1.7.16:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.1.7.16:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.1.7.16:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.1.7.16:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.1.7.16:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.1.7.16:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.1.7.16:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
  │ 10.2.1.23:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.2.1.23:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.2.1.23:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.2.1.23:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.2.1.23:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.2.1.23:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.2.1.23:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
  │ 10.1.7.61:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.1.7.61:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.1.7.61:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.1.7.61:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.1.7.61:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.1.7.61:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.1.7.61:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
x │ 10.2.1.18:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
x │ 10.2.1.18:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
x │ 10.2.1.18:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
x │ 10.2.1.18:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
x │ 10.2.1.18:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
x │ 10.2.1.18:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
x │ 10.2.1.18:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
  │ 10.1.7.48:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.1.7.48:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.1.7.48:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.1.7.48:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.1.7.48:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.1.7.48:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.1.7.48:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
  │ 10.1.7.59:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.1.7.59:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.1.7.59:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.1.7.59:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.1.7.59:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.1.7.59:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.1.7.59:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler
  │ 10.1.7.62:5701 │ OFF│
org.apache.karaf.cellar.bundle.BundleEventHandler
  │ 10.1.7.62:5701 │ OFF│
org.apache.karaf.cellar.config.ConfigurationEventHandler
  │ 10.1.7.62:5701 │ ON │ org.apache.karaf.cellar.kar.KarEventHandler
  │ 10.1.7.62:5701 │ ON │
org.apache.karaf.cellar.features.RepositoryEventHandler
  │ 10.1.7.62:5701 │ OFF│
org.apache.karaf.cellar.features.FeaturesEventHandler
  │ 10.1.7.62:5701 │ ON │
org.apache.karaf.cellar.dosgi.RemoteServiceCallHandler
  │ 10.1.7.62:5701 │ ON │
org.apache.karaf.cellar.event.ClusterEventHandler




-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [ANN] Apache Karaf Decanter 2.4.0 has been released

[Maurice Betzel]

Thanks JB, over the years i collected many resources on Karaf and OSGi
topics, your blog is in my top 10.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [ANN] Apache Karaf Decanter 2.4.0 has been released

[Maurice Betzel]

Damn your fast, you beat me to my own addition :)



fpapon wrote
> Hi,
> 
> I'm preparing a blog post on a fully Decanter installation,
> configuration and use cases, it will be available soon ;)
> 
> regards,
> 
> François

> fpapon@

> 
> Le 03/05/2020 à 11:29, Maurice Betzel a écrit :
>> A few years back I tried this monitoring solution but I could not get the
>> filtering right, getting so much events that the whole thing would just
>> block. Swapped to Jolokia and HAWTIO, using jmx over http, working stable
>> ever since. I will have a go at the new version, do you know any
>> documentation or blogs, besides the default, giving useful hints?
>>
>>
>>
>> -
>> if ( you want ) { you can } else { you can't }
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html





-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [ANN] Apache Karaf Decanter 2.4.0 has been released

[Maurice Betzel]

...let me make that “recent blogs or doc”, I am aware of blog nantrax:).



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [ANN] Apache Karaf Decanter 2.4.0 has been released

[Maurice Betzel]

A few years back I tried this monitoring solution but I could not get the
filtering right, getting so much events that the whole thing would just
block. Swapped to Jolokia and HAWTIO, using jmx over http, working stable
ever since. I will have a go at the new version, do you know any
documentation or blogs, besides the default, giving useful hints?



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

org.apache.karaf.cellar.node.cfg

# OSGi event handler
handler.org.apache.karaf.cellar.event.ClusterEventHandler = true

Yep!



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

I guess async uses sockets and timeouts as well. I must dive into that code
though to confirm my assumption.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

Yeah, the stack-traces where me fooling around. On production i only see the
blacklisting warning on the producer. See post Nr. 3.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

So the questions remains, when does blacklisting happen? Only on resource
starvation or has someone else discovered something else regarding this
topic?



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

Boggers its a warning and is comming from Karaf and not from Felix :(, So i
should have seen this always in the logs, strange thing about the Hazelcast
exceptions turning up on the same breakpoint as the post before.



-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

Hold your horses, i did not have org.apache.felix logging on DEBUG 

After a complete reinstall an restart i get the following if i block the
consuming side, no hazelcast exceptions anymore:

2020-05-01T14:58:48,148 | DEBUG | Camel (platform-facade-stream-service)
thread #1 - JmsConsumer[streamFacadeQueue] |
DatabaseChangeNotificationListener | 158 -
eu.abeel.platform.facade.mariadb.stream.persistence - 3.2.0 | ServiceEvent:
org.osgi.service.event.Event
[topic=eu/abeel/platform/facade/mariadb/stream/declaration]
{eu.abeel.platform.proxy.knowledgevalues.stream.exchange.service=eu.abeel.platform.facade.mariadb.api.model.DatabaseChangeNotification@393450b9}
2020-05-01T14:58:48,149 | DEBUG | EventAdminThread #15 |
DatabaseChangeNotificationHandler | 229 -
eu.abeel.platform.proxy.knowledgevalues.stream.exchange.service.outbound -
1.0.0 | Received event on topic
eu/abeel/platform/facade/mariadb/stream/declaration
2020-05-01T15:03:34,913 | WARN  | EventAdminAsyncThread #3 | eventadmin 
 
| 3 - org.apache.karaf.services.eventadmin - 4.2.6 | EventAdmin:
Blacklisting ServiceReference [[org.osgi.service.event.EventHandler] |
Bundle(eu.abeel.platform.proxy.knowledgevalues.stream.exchange.service.outbound
[229])] due to timeout!
2020-05-01T15:03:34,914 | WARN  | EventAdminThread #15 | eventadmin 
 
| 3 - org.apache.karaf.services.eventadmin - 4.2.6 | EventAdmin:
Blacklisting ServiceReference [[org.osgi.service.event.EventHandler] |
Bundle(eu.abeel.platform.proxy.knowledgevalues.stream.exchange.service.outbound
[229])] due to timeout!
2020-05-01T15:03:34,919 | DEBUG | Camel (platform-facade-stream-service)
thread #1 - JmsConsumer[streamFacadeQueue] | service 
| 186 - eu.abeel.platform.facade.stream.service - 3.2.0 | Registered XML
file : 6c248c72-64c8-49bd-a908-a5d269f9ca0a.xml
2020-05-01T15:03:34,919 | DEBUG | Camel (platform-facade-stream-service)
thread #1 - JmsConsumer[streamFacadeQueue] | service 
| 186 - eu.abeel.platform.facade.stream.service - 3.2.0 | Writing Stream XML
file :
/data/CUSTOMS/Interface/AGS/Incoming/6c248c72-64c8-49bd-a908-a5d269f9ca0a.xml





-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

The producer uses post (async) to not block the Oracle DCN listener thread
comming from the JDBC driver so it can return asap.
This does not happen very often, like once a month where timely distances
may vary (no pattern), and indeed i see blacklist logs from Felix if i
remember correctly. The only solution on the net i found was setting the
timeout to 0, e.g. no timeout at all. This i find very troublesome, blocking
event-threads for a long time or even permanent, destabilizing the whole
node? So my timeout is set at 30 seconds which should be sufficient as the
JVM params i monitored are seldom at max levels.
On the consuming side the event is handed over ASAP to a ExcecuterService to
free up the event producing thread, which is comming from Hazelcast. If this
is blocked you will see the following without blacklisting logs, but also
stopping further eventing after release of the breakpoint:



Side question: is this consumer call synchronous comming from Hazelcast into
the OSGi EventAdmin?

So this seems to come out of nowhere from the producing node as i cannot
find any exceptions not system specific limitations, speculating on network
glitches? But then i should see more exceptions right?




-
if ( you want ) { you can } else { you can't }
--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Karaf Cellar Osgi Event Admin timeout

[Maurice Betzel]

Hi community,

the Karaf cluster i am running with Karaf Cellar uses also the OSGi Event
Broadcasting support (eventadmin) and i have noticed that it sometimes stops
broadcasting without logging any errors. I can simulate the behavior if i
add a break-point on the receiving side of the event and do not release it
for a time if it gets hit.
Then i do get a lot of exceptions in the logs, but the point is that any
subsequent events do not get propagated any more, in production nor in my
test.
In order to restart eventing without a node restart i have to change the 
org.apache.felix.eventadmin.impl.EventAdmin.cfg and save it so the Felix
event-admin is reinitialized.
Because i do not see any exceptions logged in production i was wondering if
anybody else has experienced or even resolved the issue.

My current config:

org.apache.felix.eventadmin.AddTimestamp=true
org.apache.felix.eventadmin.AddSubject=true
org.apache.felix.eventadmin.Timeout=3

i think it must timeout fast enough so i do not block to many threads.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf as micro service container

[Maurice Betzel]

Hi Mike,

maybe some input from my experience is useful.
Within our Karaf cluster OSGi services are grouped by functionality like one
Karaf node for Mariadb facades, one for Oracle facades, two for integration
projects, one facade for ERP interaction etc...
The Karaf is a homebrew dynamic one covering the basics every node needs to
have in the cluster, like DOSGi (Cellar).
The nodes with the specific functionalities build on a node specific basic
multi maven module project, inheriting from the home-brew Karaf pom. This
basic project brings the BOM for the functionality for that node like Aries
JPA, Hibernate, MariaDB driver and PAX JDBC for the MariaDB node. Every
MariaDB database then gets its own multi maven module facade project
building on that basic project for the node.
This makes it easy extendable and up-gradable per project / facade /
database / node adding more and more methods to the facade as we go along.
Think Symantic versioning.
Because our backend nodes do not have WAN access every multi maven module
project gets packaged in KAR files containing al the jar files needed for
installment. The one disadvantage is that the Karaf maven plugin packaging
the KAR file cannot extract specific dependency parts of other feature XML
files like the camel-ftp feature. So this is a manual copy past action.
Karaf Cellar builds the cluster on runtime and besides cluster provisioning,
exposes specific marked services within the cluster as if they are local to
every node on the cluster (DOSGi), even the event admin can send events into
the cluster. 
Cron-Jobs are mostly used within our integration projects on the integration
nodes and that is where we use Apache Camel a lot, having all the EIP
functionality you can wish for and a powerful DSL.

Hope this inside view helps and improvements and discussions of my
architecture are always welcome.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Handling legacy libraries in OSGi/Karaf - Karat Meet-up chat questions

[Maurice Betzel]

I did have some stuff regarding this on github.

Aries Spi-Fly and bundeling non Osgi stuff:
https://github.com/Maurice-Betzel/twelvemonkeys-osgi

Even native code can be bundled: https://github.com/Maurice-Betzel/lmdb-osgi



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [UPDATE] Karaf Virtual Meetup preparation

[Maurice Betzel]

Great, now you asked I have to come up with an explanation 😋

Like Karaf with OSGi being my unicorn in software.

Wiki extract:

The unicorn is a legendary creature that has been described since
antiquity...(of software science)
A symbol of purity and grace (practice long known theories, force modular
thinking and design), which could be captured only by a virgin. In the
encyclopedias, its horn was said to have the power to render poisoned water
potable and to heal sickness...(resolve a big ball of mud, I do not have a
analogy for the virgin yet:))
The unicorn continues to hold a place in popular culture. It is often used
as a symbol of fantasy or rarity...(it’s time to change that).



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: [UPDATE] Karaf Virtual Meetup preparation

[Maurice Betzel]

Like a fluffy unicorn 

https://www.youtube.com/watch?v=BYtWcGIaV7A



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Maurice Betzel]

Reproducing the same symptoms is not always straightforward. I can remember
the loop-back setting from the days I was using it in SOAP / Blueprint
setups, but I cannot remember the practical reason from that project. Was it
only needed for local host testing... facepalm...



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Maurice Betzel]

You must set default.application.base as well. I set it to :

default.application.base=/api/rest/

and removed it from the Path annotation leaving /@Path("hero")/

CXF docs:

http://cxf.apache.org/docs/jax-rs.html



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Maurice Betzel]

>From the CXF HttpUtils:

private static final String REPLACE_LOOPBACK_PROPERTY =
"replace.loopback.address.with.localhost";

Or whether CXF uses IP 0.0.0.0 or 127.0.0.1.

It seems to be a setting in the HTTP context / context helper for the
whiteboard, having a configuration containing
replace.loopback.address.with.localhost -> false .






--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Maurice Betzel]

That seems to be the origin of my problem, i was having
org.apache.aries.jax.rs.whiteboard.default.cfg:

default.web=false
default.application.base=/

adding

replace.loopback.address.with.localhost=false 

did the trick. Now where can i find these settings and there meanings? CXF?



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

OSGi R7 HTTP static resources and JAXRS whiteboard issue

[Maurice Betzel]

Hi all,

I am experimenting with Karaf 4.3.0.RC1, Felix-http and Aries JAXRS to get
Angular up and running. The JAXRS backend bundle is a recent Christian
Schneider github example, the frontend bundle a Angular 9 hello world
packaged with bnd @HttpWhiteboardResource having the Angular static content
is in the root of the jar.
Both get bound to the default http context, having the ReST api endpoint on
/api/rest/hero and the static content accessible  on /heroes/*. 
Each bundle separate does what it’s supposed to do, if I start both I get
404 on the Angular. If I stop the Aries JAXRS whiteboard bundle I can access
the static content again. The other way around and both work producing data
in the frontend.
Any ideas? Should I use separate http contexts? Equinox examples I studied
equal my code, and the fast amount of configuration in the OSGi ref makes my
head spin.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Apache Karaf community Meetup in April and CFP

[Maurice Betzel]

JB, i left my smiley away so it was up to you if you would like to punch me
in the face or I could buy you a beer or two . Happy to add a smiley here.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Apache Karaf community Meetup in April and CFP

[Maurice Betzel]

JB, i get it, but I am still coming.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Apache Karaf community Meetup in April and CFP

[Maurice Betzel]

Simply put, at what time should i be there?



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Apache Karaf community Meetup in April and CFP

[Maurice Betzel]

Hi Achim an JB,

thank you for your the effort regarding this event.
My conception of a complete open community, as proclaimed on the Karaf
website, might be wrong.
But having a closed and a open event part which you "like to open even
further to more people outside this community" makes me wonder. Could you
elaborate a bit this so i can make myself a clearer picture what your
intentions are?

Thanks Maurice.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Vaadin Flow and Apache Karaf

[Maurice Betzel]

Hi, we at a Gaston-Schul have a Vaadin 14 and bnd / low level OSGi
application running in production for about half a year now. Basically it
builds on the Vaadin OSGi example, service discovery is low level OSGi
though. It consists just of one big bundle, modularity is in research. I
accomplished deeper OSGi integration with Vaadin 8 using only Java side
development, on Vaadin flow with polymer this seems not possible due to
having to embed all web components  in every bundle added to the front end.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Transient feature aggregation on KAR creation

[Maurice Betzel]

Windows 10
Karaf 4.2.6 / 4.3.0.RC1
Cellar 4.1.3

Dear community, i am trying to get to grips with the feature functionality
of Karaf. Until now i created my feature files for KAR packaging manually in
a seperate Maven module, and i am looking for a way to do this with the
Karaf Maven plugin.
I have studied the tooling karaf-maven-plugin test cases but i cannot seem
to get it to work, so here i am.

As a example i have a MariaDB base project that on deploy installs all
needed external bundles and my own generic API bundle that gets used by
projects building on the base project. Best explained by example, my current
*feature.xml*:


http://karaf.apache.org/xmlns/features/v1.6.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.6.0
http://karaf.apache.org/xmlns/features/v1.6.0";>


aries-blueprint
transaction
jndi

mvn:org.osgi/org.osgi.service.jdbc/1.0.0
mvn:org.ops4j.pax.jdbc/pax-jdbc/${pax.jdbc.version}
   
mvn:org.ops4j.pax.jdbc/pax-jdbc-mariadb/${pax.jdbc.version}
   
mvn:org.apache.karaf.jdbc/org.apache.karaf.jdbc.core/${karaf.version}
mvn:org.apache.aries/org.apache.aries.util/1.1.3
   
mvn:org.apache.aries.transaction/org.apache.aries.transaction.manager/${aries.transaction.manager.version}
   
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
   
mvn:org.apache.geronimo.specs/geronimo-j2ee-connector_1.6_spec/1.0
   
mvn:org.apache.geronimo.specs/geronimo-validation_1.0_spec/1.1
   
mvn:org.apache.geronimo.components/geronimo-connector/3.1.4
   
mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-common/${pax.jdbc.version}
   
mvn:org.ops4j.pax.jdbc/pax-jdbc-pool-aries/${pax.jdbc.version}
   
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.9.3_1
   
mvn:org.ops4j.pax.jdbc/pax-jdbc-config/${pax.jdbc.version}

mvn:org.osgi/org.osgi.service.jpa/1.1.0
   
mvn:javax.interceptor/javax.interceptor-api/${javax.interceptor-api.version}
   
mvn:javax.persistence/javax.persistence-api/${javax.persistence-api.version}

   
osgi.service;effective:=active;objectClass=javax.persistence.spi.PersistenceProvider

mvn:org.apache.felix/org.apache.felix.coordinator/1.0.2
mvn:org.apache.aries.jpa.javax.persistence/javax.persistence_2.1/${aries.jpa.version}
mvn:org.apache.aries.jpa/org.apache.aries.jpa.api/${aries.jpa.version}
mvn:org.apache.aries.jpa/org.apache.aries.jpa.container/${aries.jpa.version}
mvn:org.apache.aries.jpa/org.apache.aries.jpa.support/${aries.jpa.version}
mvn:org.apache.aries.jpa/org.apache.aries.jpa.blueprint/${aries.jpa.version}

mvn:org.jboss.logging/jboss-logging/3.3.2.Final
   
mvn:org.hibernate.javax.persistence/hibernate-jpa-2.1-api/1.0.0.Final
   
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.antlr/2.7.7_5
mvn:org.javassist/javassist/3.24.0-GA
mvn:net.bytebuddy/byte-buddy/1.9.5
   
mvn:org.jboss.spec.javax.transaction/jboss-transaction-api_1.2_spec/1.1.1.Final
mvn:org.jboss/jandex/2.0.5.Final
mvn:com.fasterxml/classmate/1.3.4
   
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.dom4j/2.1.1_1
   
mvn:org.hibernate.common/hibernate-commons-annotations/5.1.0.Final
   
mvn:org.hibernate/hibernate-core/${hibernate.orm.version}
   
mvn:org.hibernate/hibernate-osgi/${hibernate.orm.version}

   
osgi.service;objectClass=javax.persistence.spi.PersistenceProvider;effective:=active;javax.persistence.provider=org.hibernate.jpa.HibernatePersistenceProvider


   
mvn:org.mariadb.jdbc/mariadb-java-client/${mariadb.client.version}
   
mvn:eu.abeel.platform/dosgi/${abeel.platform.version}
   
mvn:eu.abeel.platform.facade.mariadb/api/${project.version}



*POM*


http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>

parent
eu.abeel.platform.facade.mariadb
3.1.2
../parent/pom.xml

4.0.0

platform-facade-mariadb-service
kar

Abeel :: Enterprise Platform :: Facade :: MariaDB :: KAR

Karaf archive creation




org.apache.karaf.tooling
karaf-maven-plugin






Keeping this up to date by hand gets rather time consuming, so i am trying
something like this *feature*:


http://karaf.apache.org/xmlns/features/v1.6.0";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.6.0
http://karaf.apache.org/xmlns/features/v1.6.0";>

   
mvn:org.ops4j.pax.jdbc/pax-jdbc-features/${pax.jdbc.version}/xml/features