[
http://jira.amdatu.org/jira/browse/AMDATU-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bram de Kruijff updated AMDATU-478:
-----------------------------------
Description:
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
was:
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].
[0]
http://www.amdatu.org/confluence/display/Amdatu/Template+config?focusedCommentId=4751916&#comment-4751916
> 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
>
> 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
