AW: Install a feature multiple times with different configurations
Hello Ephemeris,
regarding 2.:
- all the cfg files of format -.cfg will be loaded by the same
cm; I don't remember the location, but could be directly in the karaf docs.
- pax-jms-config, pax-jdbc-config handle also multiple cfg files (and decanter
as said before)
BR
-Ursprüngliche Nachricht-
Von: Ephemeris Lappis
Gesendet: Donnerstag, 1. Dezember 2022 15:05
An: user@karaf.apache.org
Betreff: Re: Install a feature multiple times with different configurations
Hello.
Well, I've found some examples, and adapting them I have more or less something
that should work. See my attached blueprint.
Nevertheless, I have some questions about managed service factories.
1) I've tried to use a single CFG file, setting the same persistent ID to
define two services (my custom one and the XA datasource), but nothing works in
this case, no error message in the log, and no service is created. Some posts
seem to confirm that the same ID may be used. Is it wrong ?
2) The pattern for the persistent ID seems to be very strict. It works with
"my.test.t29.entity" and files like "my.test.t29.entity-.cfg", but I can't
put "-" or "_" in it... Is there a link to a documentation about these
conventions ?
3) The only way to initially set the values of the seems to let the
container manage them. I've tried with "component-managed", but I found no way
to have a correct initial state (only works after changing the file and the
update method is called). This requires setting properties in the file that
exactly match the attributes/setters of the class. Is it the best/only way to
do it ?
4) In the datasource case, I've tried to set the OSGi service properties in the
blueprint, but it seems that the only way to set such properties is putting
them all in the CFG file, with the exact keys. This way all the properties of
the file are set as service properties, including the keys that are only needed
for the component attributes (such as the password that is then exposed in the
shell or console). Another way to "compose" service properties using selected
values ?
5) The "managed-properties" or "cm-properties" ignore system properties unlike
usual properties placeholders. For example in "applicationName=Karaf
${my.ds.name} - ${env:HOSTNAME}", the inner property "${my.ds.name}" is
replaced as expected, but the "${env:HOSTNAME}" is not. Another way to get it ?
Thanks in advance for your help.
Regards.
Le mer. 30 nov. 2022 à 17:13, Jean-Baptiste Onofré a écrit :
>
> You can have managed service factory: one instance per configuration.
>
> It's the way it works in Decanter: you can create multiple
> elasticsearch collector "attached" to a configuration.
>
> Regards
> JB
>
> On Wed, Nov 30, 2022 at 4:29 PM Ephemeris Lappis
> wrote:
> >
> > Hello.
> >
> > Not sure this could work. If all my blueprints and beans/services
> > objects are defined in the "core feature" bundles, only one instance
> > of them is created, no ?
> > How could I multiply blueprint containers as many times as I have a
> > configuration for business entities ?
> >
> > I've already designed my works with a common "core feature" that
> > pulls the common features (blueprint, transaction, etc.) and
> > bundles (beans, database drivers, and so on), and plan to use it
> > from other features. But I found no way to share blueprints...
> >
> > Thanks for your help.
> >
> > Regards.
> >
> > Le mer. 30 nov. 2022 à 16:00, Matt Pavlovich a écrit :
> > >
> > > Yes, you would create 1 feature for the jars to provide the functionality
> > > and then a feature per-configuration. The ‘configuration features’ would
> > > only contain cfg files (instead of jars) to activate the services with
> > > different configurations.
> > >
> > > -Matt
> > >
> > > > On Nov 30, 2022, at 6:15 AM, Ephemeris Lappis
> > > > wrote:
> > > >
> > > > Hello.
> > > >
> > > > I'm almost sure that my question will seem stupid and perhaps
> > > > leads to ironic answers...
> > > >
> > > > I'd like to build a feature to define some "templated" services
> > > > (JDBC data sources for example, or custom services), that should
> > > > be exactly based on the same definition, but must be
> > > > instantiated multiple times with distinct configurations. The
> > > > goal in our global ESB platform is to provide generic Camel
> > > > routes that will run for an undefined number of business
> > > > entities. Each entity could be deployed as a feature with its
> > > > own configuration. Some of the global services use the whiteboard
> > > > pattern to collect implementations for any number of businesses.
> > > >
> > > > The trivial way could be copying a full project to build as many
> > > > features as needed, but this is not a very good way to avoid
> > > > duplicated code and maintain them...
> > > >
> > > > Any ideas on how to do that ?
> > > >
> > > > Thanks a lot.
> > > >
> > > > Regards.
> > >
Re: Prometheus Metrics Exporting
Hi, You can make your own bundle by doing the same as we do in Decanter by adding your own metrics: https://github.com/apache/karaf-decanter/blob/main/appender/prometheus/src/main/java/org/apache/karaf/decanter/appender/prometheus/PrometheusServlet.java If you just want to export JMX MBean you can use the jmx exporter from Prometheus: https://github.com/prometheus/jmx_exporter And adding this to the JAVA_OPTS env: -javaagent:./jmx_prometheus_javaagent-0.17.2.jar=4:config.yaml Regards, Francois On 02/12/2022 03:28, Mark Derricutt wrote: Hey all, Anyone got any pointers for exporting metrics from Karaf to Prometheus? I have jolokia enabled but would rather not write a custom mapping from that to prometheus. I’m currently experimenting with a bundle wrapping Micrometer but fighting imports/exports at the moment. I do see some years ago https://github.com/bobpaulin/karaf-prometheus and a thread about it [1], but not sure if that went anywhere/or is maintained - not sure if Bob Paulin is still around here? Decanter is a full-on solution, but I really only need a prometheus export to feed into our existing stack. Any solutions? ( Using Karaf 4.4.2 ). Mark [1] https://lists.apache.org/thread/o5oyxkgyrytcg1hxro74fwysoo0jqyyx -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree -- -- François
Prometheus Metrics Exporting
Hey all, Anyone got any pointers for exporting metrics from Karaf to Prometheus? I have jolokia enabled but would rather not write a custom mapping from that to prometheus. I’m currently experimenting with a bundle wrapping Micrometer but fighting imports/exports at the moment. I do see some years ago https://github.com/bobpaulin/karaf-prometheus and a thread about it [1], but not sure if that went anywhere/or is maintained - not sure if Bob Paulin is still around here? Decanter is a full-on solution, but I really only need a prometheus export to feed into our existing stack. Any solutions? ( Using Karaf 4.4.2 ). Mark [1] https://lists.apache.org/thread/o5oyxkgyrytcg1hxro74fwysoo0jqyyx -- "Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
import java.lang.runtime: WARNING - unable to find matching export - How to solve
Dear all, I am starting with Apache Karaf/OSGI, and I have created my first bundles. Now I have the following unresolved dependency: import java.lang.runtime: WARNING - unable to find matching export My question is: how do I debug this, e.g. find where this dependency is required. I do not use it explicitly in my code. Thanks for your help. -- Jaap
Re: Install a feature multiple times with different configurations
Hello.
Well, I've found some examples, and adapting them I have more or less
something that should work. See my attached blueprint.
Nevertheless, I have some questions about managed service factories.
1) I've tried to use a single CFG file, setting the same persistent ID
to define two services (my custom one and the XA datasource), but
nothing works in this case, no error message in the log, and no
service is created. Some posts seem to confirm that the same ID may be
used. Is it wrong ?
2) The pattern for the persistent ID seems to be very strict. It works
with "my.test.t29.entity" and files like
"my.test.t29.entity-.cfg", but I can't put "-" or "_" in it... Is
there a link to a documentation about these conventions ?
3) The only way to initially set the values of the
seems to
let the container manage them. I've tried with "component-managed",
but I found no way to have a correct initial state (only works after
changing the file and the update method is called). This requires
setting properties in the file that exactly match the
attributes/setters of the class. Is it the best/only way to do it ?
4) In the datasource case, I've tried to set the OSGi service
properties in the blueprint, but it seems that the only way to set
such properties is putting them all in the CFG file, with the exact
keys. This way all the properties of the file are set as service
properties, including the keys that are only needed for the component
attributes (such as the password that is then exposed in the shell or
console). Another way to "compose" service properties using selected
values ?
5) The "managed-properties" or "cm-properties" ignore system
properties unlike usual properties placeholders. For example in
"applicationName=Karaf ${my.ds.name} - ${env:HOSTNAME}", the inner
property "${my.ds.name}" is replaced as expected, but the
"${env:HOSTNAME}" is not. Another way to get it ?
Thanks in advance for your help.
Regards.
Le mer. 30 nov. 2022 à 17:13, Jean-Baptiste Onofré a écrit :
>
> You can have managed service factory: one instance per configuration.
>
> It's the way it works in Decanter: you can create multiple
> elasticsearch collector "attached" to a configuration.
>
> Regards
> JB
>
> On Wed, Nov 30, 2022 at 4:29 PM Ephemeris Lappis
> wrote:
> >
> > Hello.
> >
> > Not sure this could work. If all my blueprints and beans/services
> > objects are defined in the "core feature" bundles, only one instance
> > of them is created, no ?
> > How could I multiply blueprint containers as many times as I have a
> > configuration for business entities ?
> >
> > I've already designed my works with a common "core feature" that pulls
> > the common features (blueprint, transaction, etc.) and bundles
> > (beans, database drivers, and so on), and plan to use it from other
> > features. But I found no way to share blueprints...
> >
> > Thanks for your help.
> >
> > Regards.
> >
> > Le mer. 30 nov. 2022 à 16:00, Matt Pavlovich a écrit :
> > >
> > > Yes, you would create 1 feature for the jars to provide the functionality
> > > and then a feature per-configuration. The ‘configuration features’ would
> > > only contain cfg files (instead of jars) to activate the services with
> > > different configurations.
> > >
> > > -Matt
> > >
> > > > On Nov 30, 2022, at 6:15 AM, Ephemeris Lappis
> > > > wrote:
> > > >
> > > > Hello.
> > > >
> > > > I'm almost sure that my question will seem stupid and perhaps leads to
> > > > ironic answers...
> > > >
> > > > I'd like to build a feature to define some "templated" services (JDBC
> > > > data sources for example, or custom services), that should be exactly
> > > > based on the same definition, but must be instantiated multiple times
> > > > with distinct configurations. The goal in our global ESB platform is
> > > > to provide generic Camel routes that will run for an undefined number
> > > > of business entities. Each entity could be deployed as a feature with
> > > > its own configuration. Some of the global services use the whiteboard
> > > > pattern to collect implementations for any number of businesses.
> > > >
> > > > The trivial way could be copying a full project to build as many
> > > > features as needed, but this is not a very good way to avoid
> > > > duplicated code and maintain them...
> > > >
> > > > Any ideas on how to do that ?
> > > >
> > > > Thanks a lot.
> > > >
> > > > Regards.
> > >
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
http://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;>
