[jira] [Created] (DELTASPIKE-1441) ConfigProperty support for maps
Andrew Marinchuk created DELTASPIKE-1441:
Summary: ConfigProperty support for maps
Key: DELTASPIKE-1441
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1441
Project: DeltaSpike
Issue Type: Wish
Security Level: public (Regular issues)
Reporter: Andrew Marinchuk
Let's assume that we have the following configuration:{code}my.param.a=1
my.param.b=2
my.param.c=3
...{code}
And we want to load all the {{my.param.*}} parameters into the {{Map}}.
With the current configuration api there two ways to load such config:
# add parameter {{my.param.all=a,b,c,...}} with complete list of {{my.param.*}}
parameters, add an {{@Inject}}'ed {{List}} field with
{{@ConfigProperty}} annotation to read this parameter and then fill the map
values by reading value by each of the provided keys.
# iterate through ConfigResolver.getAllProperties() by code like
[filterPropsByPrefix
function|https://issues.apache.org/jira/browse/DELTASPIKE-1212?focusedCommentId=16986128=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16986128]
and fill the Map with it
But I think that loading such config shouldn't be a user problem, library
should be capable of loading it. Of course, user can introduce the
{{@ApplicationScoped}} bean which will inherits the
{{org.apache.deltaspike.core.spi.config.BaseConfigPropertyProducer}} and
introduce the {{@Producer}} methods for {{Map}} analog for producers
introduced in
org.apache.deltaspike.core.impl.config.DefaultConfigPropertyProducer. But it
should be a library code.
Another use case which should be covered is loading Map where
Intf - interface with {{@Configuration}} annotation, i.e.:
{code}datasources.one.url=jdbc://...
datasources.one.user=myuser
datasources.one.password=pass
datasources.two.url=jdbc://
datasources.two.user=myuser2
datasources.two.password=pass2
...{code}
Currently we use code from [this
comment|https://issues.apache.org/jira/browse/DELTASPIKE-1212?focusedCommentId=16986128=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16986128]
to load such configuration, but it could be much simpler if deltaspike had
ConfigProperty support for maps with ability to use @Configuration interfaces
as values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1417) ProjectStage inheritance
[
https://issues.apache.org/jira/browse/DELTASPIKE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229169#comment-17229169
]
Andrew Marinchuk commented on DELTASPIKE-1417:
--
Hi Mark! Of course, onExpression works great (we've implemented own expresion
interpreter to check the current projectStage).
But onExpression is only applicable for annotation, not for application config.
For example, we have a single database server for all testing projectStages.
And now we have to write something like:
{code:title=app.properties}db.server.Development=localhost
db.server.UnitTest=test-server.local
db.server.SystemTest=test-server.local
db.server.IntegrationTest=test-server.local
db.server.Production=prod-server.local{code}
or something like:
{code:title=app.properties}db.server.Development=localhost
db.server.UnitTest=test-server.local
db.server.SystemTest=${db.server.UnitTest}
db.server.IntegrationTest=${db.server.UnitTest}
db.server.Production=prod-server.local{code}
Actually, we use own project stages set and several other setting parameters
with such duplication.
Of course, we can switch from getProjectStageAwarePropertyValue to
getPropertyAwarePropertyValue, but it will require to change many places of
code. In addition, parameterization by one parameter gives us only one
parameterization dimension, however you can introduce interface markers for
projectStage as many times as you want. Of course, it could lead to the
ambiguousness of config, but this situations could be detected if all the
interface markers will be marked itself with same marker interface (so, it's
possible to enum all them).
> ProjectStage inheritance
>
>
> Key: DELTASPIKE-1417
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1417
> Project: DeltaSpike
> Issue Type: Wish
> Security Level: public(Regular issues)
> Components: Core
>Reporter: Andrew Marinchuk
>Priority: Major
>
> Currently ProjectStage is single typesafe param which allow to divide single
> configuration (including bean visibility) to several configurations. But each
> configuration should be described separately. For each configuration property
> we have to choose from two options:
> * use the same value for all project stages
> * put the separate configuration line for each project stage with non-default
> value (the value could be specified single time thanks to ability to refer
> another line, but)
> Moreover, when there is a need to use projectstage in the {{@Exclude}}
> annotation, adding the new projectstage leads to potential modifications of
> all classes annotated with {{@Exclude}}.
> Default project stages are bandled with marker interface
> org.apache.deltaspike.core.api.projectstage.TestStage attached to the testing
> projectstages, but it's not used anywhere. The idea is to use marker
> interfaces to define additional "virtual" projectstages. Such interfaces have
> not used as org.apache.deltaspike.ProjectStage value, but it could be used in
> configuration or with {{@Exclude}} annotations, i.e.:
> {code}#dev stage server
> db.server.hostname.Development=dev-host.dom
> #server for all test stages
> db.server.hostname.TestStage=test-host.dom
> #server for integration tests - projectstage name has priority, so it
> overrides value for TestStage
> db.server.hostname.IntegrationTest=itg-test-host.dom{code}
> This feature is very usable for custom projectstages because enough
> additional interfaces could be provided.
> The only problem is conflicting settings. For example, if we have two marker
> interfaces attached to the same projectstage, but some config property has
> two different marker-aware values and no projectstage-aware value provided.
> This situation is definitely a configuration bug, so the only valid option is
> to throw exception on such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1417) ProjectStage inheritance
[
https://issues.apache.org/jira/browse/DELTASPIKE-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17222181#comment-17222181
]
Andrew Marinchuk commented on DELTASPIKE-1417:
--
The initial reason for this wish is our need to make the extensible subset of
projectstages with a similar configurations and bean visibility. Our current
solution is custom script interpreter specified in {{interpretedBy}} option of
{{@Exclude}} which takes the fully qualified marker interface name from
{{onExpression}} and checks whether the projectstage implements provided
interface. But this solutions does not help to get rid of configuration
dublications
> ProjectStage inheritance
>
>
> Key: DELTASPIKE-1417
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1417
> Project: DeltaSpike
> Issue Type: Wish
> Security Level: public(Regular issues)
> Components: Core
>Reporter: Andrew Marinchuk
>Priority: Major
>
> Currently ProjectStage is single typesafe param which allow to divide single
> configuration (including bean visibility) to several configurations. But each
> configuration should be described separately. For each configuration property
> we have to choose from two options:
> * use the same value for all project stages
> * put the separate configuration line for each project stage with non-default
> value (the value could be specified single time thanks to ability to refer
> another line, but)
> Moreover, when there is a need to use projectstage in the {{@Exclude}}
> annotation, adding the new projectstage leads to potential modifications of
> all classes annotated with {{@Exclude}}.
> Default project stages are bandled with marker interface
> org.apache.deltaspike.core.api.projectstage.TestStage attached to the testing
> projectstages, but it's not used anywhere. The idea is to use marker
> interfaces to define additional "virtual" projectstages. Such interfaces have
> not used as org.apache.deltaspike.ProjectStage value, but it could be used in
> configuration or with {{@Exclude}} annotations, i.e.:
> {code}#dev stage server
> db.server.hostname.Development=dev-host.dom
> #server for all test stages
> db.server.hostname.TestStage=test-host.dom
> #server for integration tests - projectstage name has priority, so it
> overrides value for TestStage
> db.server.hostname.IntegrationTest=itg-test-host.dom{code}
> This feature is very usable for custom projectstages because enough
> additional interfaces could be provided.
> The only problem is conflicting settings. For example, if we have two marker
> interfaces attached to the same projectstage, but some config property has
> two different marker-aware values and no projectstage-aware value provided.
> This situation is definitely a configuration bug, so the only valid option is
> to throw exception on such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DELTASPIKE-1417) ProjectStage inheritance
Andrew Marinchuk created DELTASPIKE-1417:
Summary: ProjectStage inheritance
Key: DELTASPIKE-1417
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1417
Project: DeltaSpike
Issue Type: Wish
Security Level: public (Regular issues)
Components: Core
Reporter: Andrew Marinchuk
Currently ProjectStage is single typesafe param which allow to divide single
configuration (including bean visibility) to several configurations. But each
configuration should be described separately. For each configuration property
we have to choose from two options:
* use the same value for all project stages
* put the separate configuration line for each project stage with non-default
value (the value could be specified single time thanks to ability to refer
another line, but)
Moreover, when there is a need to use projectstage in the {{@Exclude}}
annotation, adding the new projectstage leads to potential modifications of all
classes annotated with {{@Exclude}}.
Default project stages are bandled with marker interface
org.apache.deltaspike.core.api.projectstage.TestStage attached to the testing
projectstages, but it's not used anywhere. The idea is to use marker interfaces
to define additional "virtual" projectstages. Such interfaces have not used as
org.apache.deltaspike.ProjectStage value, but it could be used in configuration
or with {{@Exclude}} annotations, i.e.:
{code}#dev stage server
db.server.hostname.Development=dev-host.dom
#server for all test stages
db.server.hostname.TestStage=test-host.dom
#server for integration tests - projectstage name has priority, so it overrides
value for TestStage
db.server.hostname.IntegrationTest=itg-test-host.dom{code}
This feature is very usable for custom projectstages because enough additional
interfaces could be provided.
The only problem is conflicting settings. For example, if we have two marker
interfaces attached to the same projectstage, but some config property has two
different marker-aware values and no projectstage-aware value provided. This
situation is definitely a configuration bug, so the only valid option is to
throw exception on such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DELTASPIKE-1397) Detect the cycled variable references
Andrew Marinchuk created DELTASPIKE-1397:
Summary: Detect the cycled variable references
Key: DELTASPIKE-1397
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1397
Project: DeltaSpike
Issue Type: Wish
Security Level: public (Regular issues)
Components: Configuration
Affects Versions: 1.9.1
Environment: JDK 1.8
Reporter: Andrew Marinchuk
Due to mistake in config file, we encountered the java.lang.StackOverflowError.
{code:title=properties}fs.docs.path=/opt/docsFolder
fs.docs.path.IntegrationTest=/mnt/targetDocs
fs.docs.path.Staging=${fs.docs.path.IntegrationTest}
fs.docs.path.IntegrationTest=${fs.docs.path.IntegrationTest} <--- here is
invalid copy-pasted string
fs.docs.path.Production=${fs.docs.path.IntegrationTest}{code}{code:title=stack
trace}
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(TypedResolverImpl.java:556)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.getPropertyValue(TypedResolverImpl.java:590)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveStringValue(TypedResolverImpl.java:436)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(TypedResolverImpl.java:556)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.getPropertyValue(TypedResolverImpl.java:590)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveStringValue(TypedResolverImpl.java:436)
at
org.apache.deltaspike.core.impl.config.TypedResolverImpl.getValue(TypedResolverImpl.java:253)
{code}
It's very hard to find the configuration variable with a self-referencing
problem because StackOverflowError's message does not contain information about
variable with problem.
Wrapping each TypedResolver.getValue()'s call into try-catch is not the best
practice in app code, but it's possible to detect the simplest self-referencing
issues in
org.apache.deltaspike.core.impl.config.TypedResolverImpl.resolveVariables(String).
The better (but much expensive) way is to track the reference chain during
resolving variables or catching the StackOverflowError in library's code (it's
not a good practice and will not help to find the core of reference loop
because try-catch should be done at the first TypedResolver.getValue()'s call).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DELTASPIKE-1212) Introduce a ConfigResolver.resolveAllProperties method
[
https://issues.apache.org/jira/browse/DELTASPIKE-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986128#comment-16986128
]
Andrew Marinchuk commented on DELTASPIKE-1212:
--
Hi!
This is a workaround for resolving all properties with some prefix:
{code:java}private @Nonnull Map
filterPropsByPrefix(@Nonnull Map props, @Nonnull String prefix,
boolean resolveConfig) {
int prefixLength = prefix.length();
Map result = new LinkedHashMap<>();
if (resolveConfig) {
for (Entry entry : props.entrySet())
// Select only parameters with specified prefix
if (entry.getKey().startsWith(prefix)) {
String key = entry.getKey();
if (ProjectStage.valueOf(key.substring(key.lastIndexOf('.')
+ 1)) != null)
key = key.substring(0, key.lastIndexOf('.'));
result.put(key.substring(prefixLength),
ConfigResolver.getProjectStageAwarePropertyValue(key));
}
} else
for (Entry entry : props.entrySet())
if (entry.getKey().startsWith(prefix))
result.put(entry.getKey().substring(prefixLength),
entry.getValue());
return result;
}
{code}
Usage: {code:java}private static final String CONFIG_PREFIX = "myprefix.";
// ...
Map allPropsWithPrefix =
filterPropsByPrefix(ConfigResolver.getAllProperties(), CONFIG_PREFIX,
true);{code}
May be method like this could be a good alternative to resolveAllProperties?
> Introduce a ConfigResolver.resolveAllProperties method
> --
>
> Key: DELTASPIKE-1212
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1212
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Configuration
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>Priority: Major
>
> Invoking ConfigResolver.getAllProperties does not expand out any inlined
> variables. In addition, assume the following properties file and project
> stage = Development
> {code}
> some-service-url=${edge-server-url}/some-service
> edge-server-url=undefined
> edge-server-url.Development=http://development:8081
> edge-server-url.Staging=http://staging:8081
> edge-server-url.Production=http://prod:8081
> {code}
> calling {{getAllProperties}} returns the raw output of this file.
> Introducing a new {{resolveAllProperties}} method would only return back the
> active values. The expected result would be
> {code}
> some-service-url=http://development:8081/some-service
> edge-server-url=http://development:8081
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
