RE: Karaf + external artemis broker

2024-05-14 Thread Siano, Stephan via user 
Hi Michael,

I think the artemis commands come from the artemis bundles. There is some 
documentation here:
https://activemq.apache.org/components/artemis/documentation/1.3.0/karaf.html

Maybe this helps.

Best regards
Stephan

From: michael e 
Sent: Tuesday, 14 May 2024 10:38
To: user@karaf.apache.org
Subject: Karaf + external artemis broker

Hello i'm trying to connect to external broker (with anonymous user = false), 
and i got this error

karaf@root()> jms:queues jms/artemis
Error executing command: AMQ229031: Unable to validate user from 
/127.0.0.1:38374. Username: karaf; SSL certificate subject DN: unavailable

The jms/artemis exist from org.ops4j.connectionfactory-jms-artemis.cfg. Why the 
username is Karaf ? And how i need to configure Karaf to be able to use jms 
commands ?

Regards,
Michael.

RE: Karaf log4j conflict

2024-03-13 Thread Siano, Stephan via user 
Hi,

Maybe I add some technical explanation which might clear things up a little.

Pax-Logging essentially consists of two parts, a frontend that implements 
different logging APIs (slf4j, OSGi logging service, log4j2, apache commons 
logging…) and a backend, which is doing the actual logging and which is 
configured with the karaf logging configuration. There are two backends,  one 
using log4j2 (the default) and one using logback, which means that one of these 
log frameworks is actually there in the backend, but the classes are usually 
hidden (and the code that is accessing them will depend on the backend).

There are actually three different kinds of code that may interact with loggers:

  1.  Code that is using one of the logging APIs to write logs.
  2.  Code that is extending the logger e.g. by a custom extender to write 
specific log formats that are not supported out of the box
  3.  Code that does both and may also configure loggers but also extends 
loggers and writes logs

Code of the first type is simple, It should work out of the box.

Code of the second type should go into a fragment of the pax-logging backend. 
The fragment is an extension of the actual backend bundle. It has full access 
to all backend classes (e.g. log4j2) classes in the fragment are also 
accessible from the backend (this is important if you have your own extender 
and want to configure it in the log configuration of the Karaf container).

Code of the 3rd type is problematic, and you might have to refactor it. The 
fragment that is exporting the internal backend classes as Grzegorz mentioned 
might help you in some cases, but this means that your classes can access the 
log4j classes, but log4j cannot access your classes (which means that if your 
code contains an appender, the appender would theoretically work, but log4j 
cannot instantiate it.

If I were you, I would remove the log4j specific code of the second and third 
type for now (of course you should keep the code that is writing logs in the 
first place). This means that the logs you are writing may not have the format 
or the log levels you are intending but this should not impact the general 
functionality.
Once the code is running you can consider log configuration and custom 
appenders and add them to a fragment (and the container log configuration).

Best regards
Stephan

From: Grzegorz Grzybek 
Sent: Thursday, 14 March 2024 07:07
To: user@karaf.apache.org
Subject: Re: Karaf log4j conflict

Hello

So, for this fragment, do I simply need to make a fragment containing the extra 
log4j information, or do I need to extract the code that is using those log4j 
pieces and put that into a fragment. That seems to be a much taller order. 
Compared to bolting the necessary log4j.core classes onto the pax bundle so 
that those classes are then available to everyone from the pax bundles 
classloader.

First - here's a sample bundle fragment (attached to pax-logging-log4j2) that 
adds custom appender: 
https://github.com/ops4j/org.ops4j.pax.logging/tree/main/pax-logging-samples/fragment-log4j2

For technical details you have two options (writing without actually checking, 
but I did it many times):

  *   you create a bundle fragment (with 
org.ops4j.pax.logging.pax-logging-log4j2) that 
simply uses all private package from Log4j2, which are included (but not 
exported) from pax-logging-log4j2. You can implement anything you want, 
including appenders, layouts, ...
  *   you create a bundle fragment (again, with 
org.ops4j.pax.logging.pax-logging-log4j2) which 
DOESN'T include any code, but in it's MANIFEST.MF you export the packages you 
need (like "org.apache.logging.log4j.core") and then your 
"caterwaul-connect-core" should be resolved against pax-logging-log4j2 with the 
attached fragment (because effectively, now pax-logging-log4j2 exports what you 
need). AND YOU DON'T install any Log4j2 bundles at all (just pax-logging-log4j2)
The 2nd approach look (maybe) more clever and I used it to make Jetty 9 bundles 
work with servlet-api 4 bundle (because a fragment added additional exports 
faking that servlet api 4 exports version 3 of the packages).

I hope this helps.

regards
Grzegorz Grzybek

śr., 13 mar 2024 o 19:00 Will Hartung 
mailto:willhart...@gmail.com>> napisał(a):


On Wed, Mar 13, 2024 at 10:35 AM Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>> wrote:
Hi Will

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

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

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

I'm trying to port an existing code base, originally organized as some Maven 
modules. I'm treating the individual jars independently,  and making them 
bundles individually. One of the bundles has a Log4j appender class of its own, 
this is in contrast to the examp

RE: OSGi managed service factory / Events on changes ?

2023-11-30 Thread Siano, Stephan via user 
Hi

On the first glance a ServiceTracker might achieve what you want.

Best regards
Stephan

-Original Message-
From: Ephemeris Lappis 
Sent: Thursday, 30 November 2023 09:19
To: user@karaf.apache.org
Subject: OSGi managed service factory / Events on changes ?

Hello.

To manage some kind of dynamic configuration, I've used a managed service 
factory. It works as expected, and I can add, update or remove instances 
deploying or undeploying files in the etc folder.

The simple blueprint is like that :


http://www.osgi.org/xmlns/blueprint/v1.0.0";
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0
https://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0
http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd";>








In another bundle, I'd like to know when an instance has been updated or 
removed (new ones don't really matter). What's the best way to do it, if 
possible ? Are there some kind of events and listeners to spy managed services ?

Thanks for your help.

Regards.

RE: Karaf version java Compatibility

2023-11-19 Thread Siano, Stephan via user 
Hi,

I can confirm that Karaf 4.4.4 works with Java 8 (without a rebuild).

Best regards
Stephan

From: Jean-Baptiste Onofré 
Sent: Friday, 17 November 2023 14:29
To: user@karaf.apache.org
Subject: Re: Karaf version java Compatibility

Hi,

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

Regards
JB

On Wed, Nov 15, 2023 at 4:30 PM 
yunji@toshibagcs.com 
mailto:yunji@toshibagcs.com>> wrote:
Hi,
Thank you for the response!
I have another question: Is it possible to use Karaf 4.3.x or 4.4.x with Java 8?
I am curious if there is a version that supports both Java 8 and 17.

Appreciate your assistance.
Regards,
Yunji Lee

From: Jean-Baptiste Onofré mailto:j...@nanthrax.net>>
Sent: Wednesday, November 15, 2023 4:40 AM
To: user@karaf.apache.org 
mailto:user@karaf.apache.org>>
Subject: Re: Karaf version java Compatibility


CAUTION:  This email originated from outside our organization. Do not click 
links or open attachments unless you validate the sender.


Hi Yunji

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

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

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

Regards
JB

On Mon, Nov 13, 2023 at 7:32 PM 
yunji@toshibagcs.com 
mailto:yunji@toshibagcs.com>> wrote:
To whom it may concern,

Hello, my name is Yunji Lee.

Currently, I am utilizing version 4.2 of Karaf for our operations.
And I am reaching out to inquire about the compatibility of Karaf version 4.2 
with Java 17.

[cid:image001.png@01DA1B7C.3A948EC0]
Thanks in advance for your assistance.

Best regards,



Yunji Lee

TOSHIBA Global Commerce Solutions

Systems Management

Software Engineer I

commerce.toshiba.com

Find us on: Twitter | 
Facebook | 
YouTube



[cid:image002.jpg@01DA1B7C.3A948EC0]

Amado Nervo #2200,Torre BIO piso 5,

CP 45050, Ciudad del Sol,

Zapopan, Jalisco 

Mexico

RE: karaf newbie question.

2023-07-05 Thread Siano, Stephan via user 
Hi,

The error is actually coming from the blueprint extender. Your bundle b 
contains a file named OSGI-INF/blueprint/blueprint.xml

This file contains some service reference (to a service implementing 
xyz.JaxRsEventAdapter) and these are not resolved. You should look into the 
blueprint.xml if this service reference is necessary and if yes, you need a 
service implementation that is implementing this interface and exposing it as 
an OSGi service. The blueprint extender parses the blueprint.xml and will wait 
for five minutes for the service reference to become resolved. Then it throws 
this timeout exception.

Best regards
Stephan

From: Onder SEZGIN 
Sent: Thursday, 6 July 2023 07:02
To: user@karaf.apache.org
Subject: Re: karaf newbie question.

Hi,

there you go,

please note that the class in subject is in  abc.core.jaxrsadapter package.

both manifests,

a-common (251)

Bnd-LastModified = 1688597094984
Build-Jdk = 1.8.0_372
Built-By = abc
Created-By = Apache Maven Bundle Plugin
Manifest-Version = 1.0
Tool = Bnd-3.5.0.201709291849

Bundle-ManifestVersion = 2
Bundle-Name = a-common
Bundle-SymbolicName = a-common
Bundle-Version = 1.11.2

Require-Capability =
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))

Export-Package =
abc.core.jaxrsadapter;uses:=org.apache.cxf.message;version=1.11.2,
abc.tfc.common.audit;uses:="javax.ws.rs.ext,abc.core.jaxrsadapter,org.apache.cxf.interceptor,org.apache.cxf.message,org.apache.cxf.phase";version=1.11.2,
abc.tfc.common.cxf;uses:=org.apache.cxf.feature;version=1.11.2
Import-Package =
javax.ws.rs.ext;version="[2.1,3)",
org.apache.cxf.feature;version="[3.3,4)",
org.apache.cxf.interceptor;version="[3.3,4)",
org.apache.cxf.message;version="[3.3,4)",
org.apache.cxf.phase;version="[3.3,4)",
org.slf4j;version="[1.7,2)",
javax.ws.rs;version="[2.1,3)",
javax.ws.rs.core;version="[2.1,3)"
Private-Package =
abc.core.jaxrsadapter,
abc.tfc.common.audit,
abc.tfc.common.cxf



b-bundle (252)
-
Bnd-LastModified = 1688597081657
Build-Jdk = 1.8.0_372
Built-By = abc
Created-By = Apache Maven Bundle Plugin
Include-Resource = 
OSGI-INF/blueprint/blueprint.xml=src/main/resources/OSGI-INF/blueprint/blueprint.xml
Manifest-Version = 1.0
Tool = Bnd-3.5.0.201709291849

Bundle-Blueprint = OSGI-INF/blueprint/blueprint.xml
Bundle-ManifestVersion = 2
Bundle-Name = b-bundle
Bundle-SymbolicName = b-bundle
Bundle-Version = 1.11.2

Require-Capability =
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8))

Export-Package =
abc.tfc.exception;version=1.11.2,
abc.tfc;uses:="javax.ws.rs,javax.ws.rs.core";version=1.11.2,
abc.tfc.processors;uses:=org.apache.camel;version=1.11.2,
abc.tfc.routes;uses:="abc.tfc.processors,org.apache.camel,org.apache.camel.builder,org.slf4j";version=1.11.2
Import-Package =
org.apache.activemq,
org.apache.activemq.camel.component;version="[5.9,6)",
org.apache.activemq.pool,
org.osgi.service.blueprint;version="[1.0.0,2.0.0)",
com.fasterxml.jackson.jaxrs.json;version="[2.12,3)",
org.apache.camel;version="[2.23,3)",
org.apache.camel.builder;version="[2.23,3)",
org.apache.camel.model;version="[2.23,3)",
abc.core.jaxrsadapter;resolution:=optional,
abc.tfc.common.audit;resolution:=optional,
abc.tfc.common.cxf;resolution:=optional,
javax.ws.rs;version="[2.1,3)",
javax.ws.rs.core;version="[2.1,3)",
org.apache.cxf.message;version="[3.3,4)",
org.slf4j;version="[1.7,2)",
javax.jms;version="[1.1,2)",
org.osgi.service.cm;version="[1.4,2)",
org.apache.camel.blueprint;version="[2.12.0,3)",
org.apache.camel.component.cxf.common.message;version="[2.23,3)",
org.apache.camel.model.dataformat;version="[2.23,3)",
javax.ws.rs.ext;version="[2.1,3)",
org.apache.cxf.feature;version="[3.3,4)",
org.apache.cxf.interceptor;version="[3.3,4)",
org.apache.cxf.phase;version="[3.3,4)"
Private-Package =
abc.core.jaxrsadapter,
abc.tfc.common.audit,
abc.tfc.common.cxf

On Thu, Jul 6, 2023 at 5:35 AM Jean-Baptiste Onofré 
mailto:j...@nanthrax.net>> wrote:
Hi,

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

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

Regards
JB

On Thu, Jul 6, 2023 at 6:20 AM Onder SEZGIN 
mailto:ondersez...@gmail.com>> wrote:
>
> OK i am not very to karaf, i hadjust not gone beyond experimenting except 
> recent times.
> i have 3 repositories.
>
> one of them if called a-common bundle.
>
> it basically imports packages of dependency and since i dont specify anything 
> extra, it exports its packages as expected.
>
> this bundle is imported by another bundle called b-bundle let's say.
>
> for some reason, the package is getting exported twice
>
> there is no explicit