ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert M. Mather" <robert.mather....@gmail.com>
Subject Re: Some clarifications about ACE template config engine
Date Mon, 23 Mar 2015 19:03:43 GMT
Thanks so much, that's precisely the info I needed.

On Mar 23, 2015 6:33 AM, "Jan Willem Janssen" <janwillem.janssen@luminis.eu>
wrote:
>
> Hi Robert,
>
> > On 21 Mar 2015, at 05:25, Robert M. Mather <robert.mather.rmm@gmail.com>
wrote:
> >
> > Using the template engine
> > <
https://ace.apache.org/docs/user-guide.html#using-the-template-engine-for-targets
>,
> > would a metatype.xml inside a bundle (ie in the OSGI-INF/metatype
> > directory, per the spec) be processed and the variables substituted, or
> > does the metatype need to be deployed as a separate artifact.
>
> By default, the ACE templating system only works on metatype resources
deployed
> as separate files. The idea behind this is that you generally want to
have a
> “standard” set of bundles which can be configured individually per target.
>
> > Just for my understanding, where does the interpolation actually take
> > place? I've been assuming it's a process at the client/target…
>
> The processing is done at the server side right before the deployment
package
> is transferred to the client. This way, each client can get its own
“unique”
> deployment set including the proper configuration files.
>
> > If the same "tag" key gets set at multiple stages (ie artifact, feature,
> > dist, and/or target), is the a "last one wins" rule or something when
the
> > interpolation takes place?
>
> IIRC, the last ones wins indeed, but I’d need to test that out myself...
>
> >
> > And finally, is this example metatype.xml the right idea for adding the
> > ${context.blah} variables (in the content field)?
> >
> > <?xml version="1.0" encoding="UTF-8"?><metatype:MetaData
> > xmlns:metatype="http://www.osgi.org/xmlns/metatype/v1.1.0">
> >    <OCD id="ocd" name="ocd">
> >        <AD id="server" type="String" />
> >    </OCD>
> >
> >    <Designate pid="org.amdatu.conf" bundle="org.amdatu.sample.bundle">
> >        <Object ocdref="ocd">
> >            <Attribute adref="server" name="serverurl"
> > content="${context.serverUrl}" />
> >        </Object>
> >    </Designate></metatype:MetaData>
>
> Almost: the bundle-attribute needs to be prefixed with “osgi-dp:” to make
> it clear that the configuration PID (org.amdatu.conf) is for a bundle
> that is part of a deployment package. The AutoConf resource processor used
> by ACE does not allow configurations to be provisioned to bundles that are
> *not* part of a deployment package.
> Apart from that the example metatype is correct, including the template
> variable.
>
> > I'm using declarative services with bnd(tools), which is generating
> > metatype from my @OCD annotated interfaces, so I'm trying to find the
> > best/most automated way to prepare those for Apache ACE with template
> > variables.
> >
> > Any thoughts on the right way to do that would be much appreciated, I'm
> > hoping I'm not the first person to want to do something like this!
>
> Its been a while since I played with the metatype support of Bnd, but
> I believe it will embed the metatype resource files inside the bundles,
> which (as I written above) are not considered by the ACE template
> processor. If you want to keep using Bnd for generating metatype
> resources (which I can understand, given its great support) you could
> separate the actual configuration (read: Designate) from its definition
> (read: OCD): the metatype spec does allow that. This would mean that you
> provide the designates in separate files (which the ACE template
> processor can act upon) while the OCDs are created from your Bnd build.

Perfect, this is what I was hoping for. I'm assuming everything will get
pulled together based on the PID, so the filename for the metatype
designates won't matter. I guess I'll find out pretty quick if that's not
the case.

>
> Hope this helps,
>
> --
> Met vriendelijke groeten | Kind regards
>
> Jan Willem Janssen | Software Architect
> +31 631 765 814
>
> My world is revolving around INAETICS and Amdatu
>
> Luminis Technologies B.V.
> Churchillplein 1
> 7314 BZ   Apeldoorn
> +31 88 586 46 00
>
> http://www.luminis-technologies.com
> http://www.luminis.eu
>
> KvK (CoC) 09 16 28 93
> BTW (VAT) NL8169.78.566.B.01
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message