felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: DS property replacement?
Date Mon, 09 Mar 2015 14:48:28 GMT
Hi

What prevents you from doing this with your build tooling ? This should, apart from the bundle.id
part, be rather easy.

E.g. leveraging the resource filtering feature of Maven

Regards
Felix

> Am 09.03.2015 um 15:08 schrieb Raymond Auge <raymond.auge@liferay.com>:
> 
> 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 (à la spring PropertyPlaceholderConfigurer):
>>> 
>>> // implied from bundle runtime details
>>> @Reference(target = "(service.bundleid=${bundle.id})")
>>> 
>>> // implied from bundle headers
>>> @Reference(target = "(context.path=${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
>> 
>> 
> 
> 
> -- 
> *Raymond Augé* <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)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Mime
View raw message