[
http://jira.amdatu.org/jira/browse/AMDATU-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11971#comment-11971
]
Marcel Offermans commented on AMDATU-478:
-----------------------------------------
I created the TemplateContext interface to allow template engines to provide an
implementation that they can optimize. For example, let's assume the engine
does caching to speed up the generation of templates, and let's assume it tries
to detect if you changed anything in your context since a previous call to the
engine. With a custom implementation, that's easy to do. With a Map, it is
still possible, but probably more work / slower. I agree that neither of the
two provided implementations take advantage of that right now.
To answer your second question, the simple implementation is probably a bit too
simple now. It makes sense to have it look for ${variable} or something similar.
> Replace Config Template mechanism with processors
> -------------------------------------------------
>
> Key: AMDATU-478
> URL: http://jira.amdatu.org/jira/browse/AMDATU-478
> Project: Amdatu
> Issue Type: Improvement
> Components: Amdatu Core
> Affects Versions: 0.3.0
> Reporter: Bram de Kruijff
> Assignee: Matthijs Hendriks
> Attachments: template.zip
>
>
> As described at the wiki [0] the current Template Config mechanism is
> problematic. As mentioned there:
> 1) ConfigurationAdmin was carefully designed to be able to notify a component
> whenever its configuration changed. Using template config you can no longer
> do that because it reads the configuration only when you generate the
> configuration file.
> 2) Currently you're allowed to read data from multiple PIDs, not just your
> own. This creates a coupling between your component and many others that is
> completely undesirable. The same goes for reading system properties.
> 3) A more technical one, but when transforming a template into a
> configuration file, operations on ConfigurationAdmin are not "atomic" in the
> sense that you re-read the configuration for every single line that contains
> a variable. There is no way of knowing if any of the configurations you read
> change while doing this.
> Basically, besides doing simple interpolation it tries to add some
> intelligence that it can't, and probably shouldn't, handle (caching,
> representation) and effectively it is only used in one or two places for
> interpolation only.
> As there are several open issues on it and multi-tenant configuration spaces
> will affect it as well, it would be a good time to replace it with a simple
> template processor mechanism as proposed by Marcel at [0]. AFAIK the current
> actual use cases can be simply covered by a simple "${}" interpolation
> processor.
> [0]
> http://www.amdatu.org/confluence/display/Amdatu/Template+config?focusedCommentId=4751916&#comment-4751916
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers
