[ 
http://jira.amdatu.org/jira/browse/AMDATU-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11975#comment-11975
 ] 

Matthijs Hendriks commented on AMDATU-478:
------------------------------------------

It is. The caching implementation I have written does almost exactly the same 
as the caching version. Therefore it is quite easy to rewrite the caching 
implementation on top of the simple one. It would take me approximately ten 
minutes or so to do so. After having reviewed/improved the 
interfaces/implementations with Bram I'll attach my code here. :)
                
> 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 interfaces.zip, 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

Reply via email to