[
http://jira.amdatu.org/jira/browse/AMDATU-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11976#comment-11976
]
Bram de Kruijff commented on AMDATU-478:
----------------------------------------
Looks good. A few notes on the apis:
1) Please adjust your code style
We use a common code style documented at [0] and provide a template for the
eclipse formatter at [1].
[0] http://www.amdatu.org/confluence/display/Amdatu/Java+Coding+Style+Guide
[1] <svn root>\etc\eclipse settings
2) Use TemplateProcessor/TemplateContext or just Template / Context?
IMHO the longer names do not really add anything and are... well longer.
3) You say: "Should all generate methods throw an IOException?"
Yes, an exception but maybe not force IOException on the API? Why not introduce
TemplateException or even use Exception?
4) Writer/Inputstream is asymetric. Either choose or do both
> 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
