Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of 10527@liferay.com designates
 209.85.216.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54FD7391.1010709@apache.org>
References: 
 <CAMm6HcA9pDO1TeSny6KejeLhS3jv4sW3qQ3-p_qUYYkxx9V0KQ@mail.gmail.com>
	<54FD7391.1010709@apache.org>
Date: Mon, 9 Mar 2015 10:08:30 -0400
Message-ID: 
 <CAMm6HcBJm5DXoJop931=JCgi4SS-LYiQuqtL5KrH0JjE-qc6-g@mail.gmail.com>
Subject: Re: DS property replacement?
From: Raymond Auge <raymond.auge@liferay.com>
To: felix users <users@felix.apache.org>
Content-Type: multipart/alternative; boundary=001a1133c5be9f5ff90510db9184

--001a1133c5be9f5ff90510db9184
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler <cziegeler@apache.org>
wrote:

> Am 08.03.15 um 16:24 schrieb Raymond Auge:
> > Would people be opposed to felix scr supporting property replacement
> > something like (=C3=A0 la spring PropertyPlaceholderConfigurer):
> >
> > // implied from bundle runtime details
> > @Reference(target =3D "(service.bundleid=3D${bundle.id})")
> >
> > // implied from bundle headers
> > @Reference(target =3D "(context.path=3D${Web-ContextPath})")
> >
> > etc.
> >
> > One might overload the KXml2SAXParser.getAttributeValue(i) method which
> > scans for replaceable tokens where KXml2SAXParser is passed the bundle =
in
> > it's constructor.
> >
> I think this one will be troublesome. Apart from having a proprietary
> extension where do those values come from?
>

Bundle headers, and bundle details.


> Then you have the "properties" element which you could use to point to
> a properties file in your bundle overriding the values - I guess that's
> not working for your case.
>

This can't work. You can only get information which exists before coming
into the runtime which is not the goal.


> And finally you can change the values through a configuration, so
> instead of coming up with a new way to get a value for the placeholders
> you create a configuration that set the [reference].target property to
> the appropriate value.
>

This also isn't the goal. The goal is to automate/simplify parts which you
don't want to handle via configuration. For instance you would never use
the bundle.id because that would be foolish since uninstall and reinstall
would make the configuration invalid.

However, there are many details for which it might be useful to be able to
apply filters on, but due to their dynamic nature its impractical to use
them because you must hard code the values currently. This is true for
almost all details of a bundle at runtime.

It's also true that some information you don't want to duplicate. For
instance, anything that is in the manifest you probably want to keep
centralized there, and not require a developer to duplicate it since this
causes a change management problem.

So, my thought about where the information for replacement is that it would
come from only
- bundle runtime info
- manifest

Sincerely,
- Ray


>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


--=20
*Raymond Aug=C3=A9* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance=
)

--001a1133c5be9f5ff90510db9184--