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é <[email protected]> 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
> <[email protected]> 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 <[email protected]> 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
> > > > <[email protected]> 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.
> > >
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
xmlns="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";>
<cm:managed-service-factory
factory-pid="my.test.t29.entity"
interface="my.tests.t29.EntityConfiguration">
<cm:managed-component class="my.tests.t29.bean.EntityConfigurationManagedService">
<cm:managed-properties
persistent-id=""
update-strategy="container-managed" />
</cm:managed-component>
</cm:managed-service-factory>
<cm:managed-service-factory
factory-pid="my.test.t29.xads"
interface="javax.sql.XADataSource">
<service-properties>
<cm:cm-properties
persistent-id=""
update="true" />
</service-properties>
<cm:managed-component class="org.postgresql.xa.PGXADataSource">
<cm:managed-properties
persistent-id=""
update-strategy="container-managed" />
</cm:managed-component>
</cm:managed-service-factory>
</blueprint>
