Hello Ephemeris,
regarding 2.:
- all the cfg files of format <pid>-<mysuffix>.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 <ephemeris.lap...@gmail.com>
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-xxxx.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 <cm:managed-component
class="my.tests.t29.bean.EntityConfigurationManagedService"> 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é <j...@nanthrax.net> 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
> <ephemeris.lap...@gmail.com> 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 <mattr...@gmail.com> 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
> > > > <ephemeris.lap...@gmail.com> 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.
> > >
