On Mon, Mar 9, 2015 at 6:18 AM, Carsten Ziegeler <cziege...@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
> cziege...@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@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)
