[jira] [Closed] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found
[
https://issues.apache.org/jira/browse/DELTASPIKE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb closed DELTASPIKE-1272.
--
> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.8.1
>
> Attachments: deltaspike.patch
>
>
> When calling
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this
> issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1370) Deltaspike documentation states the latest release is 1.8.2
[
https://issues.apache.org/jira/browse/DELTASPIKE-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778962#comment-16778962
]
Alexander Falb commented on DELTASPIKE-1370:
I had a quick look at
[https://github.com/apache/deltaspike/blob/master/site/src/main/asciidoc/download.adoc|https://github.com/apache/deltaspike/blob/master/site/src/main/asciidoc/download.adoc,]
and using \{latestStable} looks right to me, but I'm neither familiar with the
site-buildprocess nor with ascii doc.
Maybe we should also change the [source
page|https://deltaspike.apache.org/source.html] to point to the new repo
instead of git-wip-us.apache.org/...
> Deltaspike documentation states the latest release is 1.8.2
> ---
>
> Key: DELTASPIKE-1370
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1370
> Project: DeltaSpike
> Issue Type: Task
> Components: Documentation
>Reporter: Alexander Falb
>Priority: Trivial
>
> Our [Download|https://deltaspike.apache.org/download.html] page says the
> latest version of DeltaSpike is 1.8.2, but it should be 1.9.0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DELTASPIKE-1370) Deltaspike documentation states the latest release is 1.8.2
Alexander Falb created DELTASPIKE-1370: -- Summary: Deltaspike documentation states the latest release is 1.8.2 Key: DELTASPIKE-1370 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1370 Project: DeltaSpike Issue Type: Task Components: Documentation Reporter: Alexander Falb Our [Download|https://deltaspike.apache.org/download.html] page says the latest version of DeltaSpike is 1.8.2, but it should be 1.9.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (DELTASPIKE-900) ResourceLocalTransactionStrategy not working with multiple EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb resolved DELTASPIKE-900.
---
Resolution: Fixed
Assignee: Alexander Falb (was: Mark Struberg)
Fix Version/s: 1.9.0
> ResourceLocalTransactionStrategy not working with multiple EntityManagers
> -
>
> Key: DELTASPIKE-900
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-900
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Johannes Testori
>Assignee: Alexander Falb
>Priority: Major
> Fix For: 1.9.0
>
>
> We are using CDI-ApplicationScoped services in a batch program with
> CdiControl. We started using multiple qualified EntityManagers in a single
> service annotated with @Transactional and encountered the problem that
> database changes are not committed. After some debugging we found the problem
> in the "execute"-method in ResourceLocalTransactionStrategy.
> for (Class emQualifier : emQualifiers)
> {
> EntityManager entityManager =
> resolveEntityManagerForQualifier(emQualifier);
> EntityManagerEntry entityManagerEntry =
> createEntityManagerEntry(entityManager, emQualifier);
> transactionBeanStorage.storeUsedEntityManager(entityManagerEntry);
> EntityTransaction transaction = getTransaction(entityManagerEntry);
> if (!transaction.isActive())
> {
> beforeBegin(invocationContext, entityManagerEntry, transaction);
> transaction.begin();
> }
> else if (isOutermostInterceptor)
> {
> outermostTransactionAlreadyExisted = true;
> }
> //don't move it before EntityTransaction#begin() and invoke it in any case
> beforeProceed(invocationContext, entityManagerEntry, transaction);
> }
> A transaction is created for the first EntityManager. But since the same
> transaction is assigned to the other EntityManagers,
> "outermostTransactionAlreadyExisted" is set to true. This is the cause for
> the transaction not being committed afterwards:
> if (isOutermostInterceptor)
> {
> if (!outermostTransactionAlreadyExisted)
> {
> // We only commit transactions we opened ourselfs.
> // If the transaction got opened outside of our interceptor chain
> // we must not handle it.
> // This e.g. happens if a Stateless EJB invokes a Transactional CDI
> bean
> // which uses the BeanManagedUserTransactionStrategy.
> We've seen this problem in version 1.2.1 and 1.3.0. (didn't try other
> versions).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-900) ResourceLocalTransactionStrategy not working with multiple EntityManagers
[
https://issues.apache.org/jira/browse/DELTASPIKE-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588849#comment-16588849
]
Alexander Falb commented on DELTASPIKE-900:
---
To summarize the problem: When using a Bean with more than one EntityManger, a
Transactional method and {{BeanManagedUserTransactionStrategy}} the transaction
is not committet.
I had a chat with [~jtestori] and did a bit of debugging and found out that
{code:java}
if (!transaction.isActive())
{
beforeBegin(invocationContext, entityManagerEntry,
transaction);
transaction.begin();
}
else if (isOutermostInterceptor)
{
outermostTransactionAlreadyExisted = true;
}
{code}
starts a transaction for the first EntityManager. Afterwards the
{{BeanManagedUserTransaction#beforeProceed}} joins this Transaction. Now the
code above runs again for the 2nd EntityManager. But because the transactions
are joined, the new transaction is already active (else path) and because this
interceptor is the outermost {{outermostTransactionAlreadyExisted = true;}} is
executed.
Because of this, neither the exception handling (catch) does a transaction
rollback nor the finally a transaction commit.
Based on [~jtestori]'s idea of tracking if the current interceptor opened the
transaction or not I created a fix for this issue:
[https://github.com/elexx/deltaspike/tree/DELTASPIKE-900]
Deltaspike still builds without test failures, however I'm not sure any tests
actually touch {{BeanManagedUserTransactionStrategy}}.
> ResourceLocalTransactionStrategy not working with multiple EntityManagers
> -
>
> Key: DELTASPIKE-900
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-900
> Project: DeltaSpike
> Issue Type: Bug
> Components: JPA-Module
>Affects Versions: 1.2.1, 1.3.0
>Reporter: Johannes Testori
>Assignee: Mark Struberg
>Priority: Major
>
> We are using CDI-ApplicationScoped services in a batch program with
> CdiControl. We started using multiple qualified EntityManagers in a single
> service annotated with @Transactional and encountered the problem that
> database changes are not committed. After some debugging we found the problem
> in the "execute"-method in ResourceLocalTransactionStrategy.
> for (Class emQualifier : emQualifiers)
> {
> EntityManager entityManager =
> resolveEntityManagerForQualifier(emQualifier);
> EntityManagerEntry entityManagerEntry =
> createEntityManagerEntry(entityManager, emQualifier);
> transactionBeanStorage.storeUsedEntityManager(entityManagerEntry);
> EntityTransaction transaction = getTransaction(entityManagerEntry);
> if (!transaction.isActive())
> {
> beforeBegin(invocationContext, entityManagerEntry, transaction);
> transaction.begin();
> }
> else if (isOutermostInterceptor)
> {
> outermostTransactionAlreadyExisted = true;
> }
> //don't move it before EntityTransaction#begin() and invoke it in any case
> beforeProceed(invocationContext, entityManagerEntry, transaction);
> }
> A transaction is created for the first EntityManager. But since the same
> transaction is assigned to the other EntityManagers,
> "outermostTransactionAlreadyExisted" is set to true. This is the cause for
> the transaction not being committed afterwards:
> if (isOutermostInterceptor)
> {
> if (!outermostTransactionAlreadyExisted)
> {
> // We only commit transactions we opened ourselfs.
> // If the transaction got opened outside of our interceptor chain
> // we must not handle it.
> // This e.g. happens if a Stateless EJB invokes a Transactional CDI
> bean
> // which uses the BeanManagedUserTransactionStrategy.
> We've seen this problem in version 1.2.1 and 1.3.0. (didn't try other
> versions).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions
[
https://issues.apache.org/jira/browse/DELTASPIKE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545210#comment-16545210
]
Alexander Falb commented on DELTASPIKE-1353:
Pushed the changes, please have a look.
> null values as arguments in messagebundles lead to exceptions
> -
>
> Key: DELTASPIKE-1353
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Alexander Falb
>Priority: Major
> Attachments:
> org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt,
> org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
>
>
> When using a Deltaspike Messagebundle and feeding {{null}} as argument to
> some non-String argument, the MessageInterpolators throw Exceptions.
> Depending if I use the MessageFormatter or the String.format based
> Interpolater the Exceptions differ, but origin from the same misassumption,
> that {{null}} can be replaced with {{"'null'"}}
> (MessageBundleInvocationHandler:179)
> I created 2 unittests to showcase this behaviour, see attached surefire logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions
[
https://issues.apache.org/jira/browse/DELTASPIKE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb updated DELTASPIKE-1353:
---
Description:
When using a Deltaspike Messagebundle and feeding {{null}} as argument to some
non-String argument, the MessageInterpolators throw Exceptions. Depending if I
use the MessageFormatter or the String.format based Interpolater the Exceptions
differ, but origin from the same misassumption, that {{null}} can be replaced
with {{"'null'"}} (MessageBundleInvocationHandler:179)
I created 2 unittests to showcase this behaviour, see attached surefire logs.
was:
When using a Deltaspike Messagebundle and feeding {{null}} as argument to some
non-String argument, the MessageInterpolators throw Exceptions. Depending if I
use the MessageFormatter or the String.format based Interpolater the Exceptions
differ, but origin from the same missassumption, that {{null}} can be replaced
with {{"'null'"}} (MessageBundleInvocationHandler:179)
I created 2 unittests to showcase this behaviour, see attached surefire logs.
> null values as arguments in messagebundles lead to exceptions
> -
>
> Key: DELTASPIKE-1353
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Alexander Falb
>Priority: Major
> Attachments:
> org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt,
> org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
>
>
> When using a Deltaspike Messagebundle and feeding {{null}} as argument to
> some non-String argument, the MessageInterpolators throw Exceptions.
> Depending if I use the MessageFormatter or the String.format based
> Interpolater the Exceptions differ, but origin from the same misassumption,
> that {{null}} can be replaced with {{"'null'"}}
> (MessageBundleInvocationHandler:179)
> I created 2 unittests to showcase this behaviour, see attached surefire logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions
[
https://issues.apache.org/jira/browse/DELTASPIKE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545091#comment-16545091
]
Alexander Falb commented on DELTASPIKE-1353:
I'm currently working improving the unittests and preparing a fix for this
issue:
https://github.com/elexx/deltaspike/tree/feature/DELTASPIKE-1353_nullArgsMessagebundles
> null values as arguments in messagebundles lead to exceptions
> -
>
> Key: DELTASPIKE-1353
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Alexander Falb
>Priority: Major
> Attachments:
> org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt,
> org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
>
>
> When using a Deltaspike Messagebundle and feeding {{null}} as argument to
> some non-String argument, the MessageInterpolators throw Exceptions.
> Depending if I use the MessageFormatter or the String.format based
> Interpolater the Exceptions differ, but origin from the same missassumption,
> that {{null}} can be replaced with {{"'null'"}}
> (MessageBundleInvocationHandler:179)
> I created 2 unittests to showcase this behaviour, see attached surefire logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions
[
https://issues.apache.org/jira/browse/DELTASPIKE-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16545091#comment-16545091
]
Alexander Falb edited comment on DELTASPIKE-1353 at 7/16/18 11:31 AM:
--
I'm currently working on improving the unittests and preparing a fix for this
issue:
https://github.com/elexx/deltaspike/tree/feature/DELTASPIKE-1353_nullArgsMessagebundles
was (Author: elexx):
I'm currently working improving the unittests and preparing a fix for this
issue:
https://github.com/elexx/deltaspike/tree/feature/DELTASPIKE-1353_nullArgsMessagebundles
> null values as arguments in messagebundles lead to exceptions
> -
>
> Key: DELTASPIKE-1353
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
> Project: DeltaSpike
> Issue Type: Bug
>Affects Versions: 1.8.2
>Reporter: Alexander Falb
>Priority: Major
> Attachments:
> org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt,
> org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
>
>
> When using a Deltaspike Messagebundle and feeding {{null}} as argument to
> some non-String argument, the MessageInterpolators throw Exceptions.
> Depending if I use the MessageFormatter or the String.format based
> Interpolater the Exceptions differ, but origin from the same missassumption,
> that {{null}} can be replaced with {{"'null'"}}
> (MessageBundleInvocationHandler:179)
> I created 2 unittests to showcase this behaviour, see attached surefire logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DELTASPIKE-1353) null values as arguments in messagebundles lead to exceptions
Alexander Falb created DELTASPIKE-1353:
--
Summary: null values as arguments in messagebundles lead to
exceptions
Key: DELTASPIKE-1353
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1353
Project: DeltaSpike
Issue Type: Bug
Affects Versions: 1.8.2
Reporter: Alexander Falb
Attachments:
org.apache.deltaspike.test.core.api.message.MessageFormattedMessageTest.txt,
org.apache.deltaspike.test.core.api.message.SimpleMessageTest.txt
When using a Deltaspike Messagebundle and feeding {{null}} as argument to some
non-String argument, the MessageInterpolators throw Exceptions. Depending if I
use the MessageFormatter or the String.format based Interpolater the Exceptions
differ, but origin from the same missassumption, that {{null}} can be replaced
with {{"'null'"}} (MessageBundleInvocationHandler:179)
I created 2 unittests to showcase this behaviour, see attached surefire logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (DELTASPIKE-1327) EnvironmentPropertyConfigSource is not scannable?
Alexander Falb created DELTASPIKE-1327: -- Summary: EnvironmentPropertyConfigSource is not scannable? Key: DELTASPIKE-1327 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1327 Project: DeltaSpike Issue Type: Bug Components: Configuration Affects Versions: 1.8.1 Reporter: Alexander Falb I noticed EnvironmentPropertyConfigSource overrides isScannable() and returns false. Is this intentional? Just based on the code I don't see any reason why EnvPropConfigSource is not scannable, while MapConfigSource is scannable (EnvPropConfigSource extends MapConfigSource). Sidenote: I'm not sure this issue is a really "Bug" but I also couln't decide on a more fitting Issue Type. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found
[
https://issues.apache.org/jira/browse/DELTASPIKE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16391238#comment-16391238
]
Alexander Falb commented on DELTASPIKE-1272:
Just checked my not yet closed tickets: 1.8.1 is already released, can this
issue be closed?
Regards, Alex
> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.8.1
>
> Attachments: deltaspike.patch
>
>
> When calling
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this
> issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DELTASPIKE-1287) asList() getValue() fails with a NPE if no configured value exists
[ https://issues.apache.org/jira/browse/DELTASPIKE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Falb updated DELTASPIKE-1287: --- Attachment: 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch Attached 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch as proposal to fix this issue. > asList() getValue() fails with a NPE if no configured value exists > -- > > Key: DELTASPIKE-1287 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1287 > Project: DeltaSpike > Issue Type: Bug > Components: Configuration >Affects Versions: 1.8.0 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.8.1 > > Attachments: 0001-DELTASPIKE-1272-1287-make-defaultValues-work.patch > > > We currently blow up with a NullPointerException if a List gets resolved and > no value was actually configured. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1287) asList() getValue() fails with a NPE if no configured value exists
[
https://issues.apache.org/jira/browse/DELTASPIKE-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198616#comment-16198616
]
Alexander Falb commented on DELTASPIKE-1287:
This fix does NOT work with default values. Please have a look at the patch
attached to [https://issues.apache.org/jira/browse/DELTASPIKE-1272]. A testcase
like
{code}
@Test
public void testConfiguredListValues_WithDefault()
{
List intValues =
ConfigResolver.resolve("notexisting").as(Integer.class).asList().withDefault(Arrays.asList(99,
88, 77)).getValue();
Assert.assertNotNull(intValues);
Assert.assertEquals(3, intValues.size());
Assert.assertTrue(intValues.contains(99));
Assert.assertTrue(intValues.contains(88));
Assert.assertTrue(intValues.contains(77));
}
{code}
will still fail.
> asList() getValue() fails with a NPE if no configured value exists
> --
>
> Key: DELTASPIKE-1287
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1287
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
> Fix For: 1.8.1
>
>
> We currently blow up with a NullPointerException if a List gets resolved and
> no value was actually configured.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083964#comment-16083964
]
Alexander Falb commented on DELTASPIKE-1277:
Yes we could, but then again, we would not be able to log any changes, if we
don't load the last value from the cache. On the other hand, maybe logging
should be done in the not-yet-existing CacheManager (during a put of a new
value into the manager) rather than in the PropertyBuilder? But removing
{{logChanges()}} would change the API of PropertyBuilder.
What do you mean with, we could get corrupted data if we read the same key
twice? I can only think of getting wrong log output. ie when having 2
PropertyBuilder with the same key, both with caching disabled and logging
enabled. If we call getValue on the 1st, changing the value and calling
getValue on the 2nd, the second one would log a change even if it never ever
resolved the value before.
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16083879#comment-16083879
]
Alexander Falb commented on DELTASPIKE-1277:
Thanks for the feedback!
* Yes we need to write to some sort of cache, even if caching is disabled. If
not we could not log changes. Ofc we could use the internal cache for this (the
{{T lastValue}} i removed) but I dont see the pro for this. But the cached
value is only returned if {{cacheTimeMs > 0}} otherwise it gets reloaded.
* No particular reason. I just didn't want to clutter the commit with a
refactoring. But I totally agree, the 1200+ lines of ConfigResolver is way to
much, it really needs a refactoring.
I like the ConfigCacheManager idea! Although Deltaspike currently compiles
against Java 6 (afair), so we would need to update that first.
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb updated DELTASPIKE-1277:
---
Attachment: central_caching.patch
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082350#comment-16082350
]
Alexander Falb edited comment on DELTASPIKE-1277 at 7/11/17 3:09 PM:
-
(Uploaded central_caching.patch)
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
was (Author: elexx):
This is a first try of how a central cache could work. It is far from perfect,
because of the dynamic nature of cache-keys containing projectstage and/or
parameters. There are at least a dozen of unit tests missing covering all sorts
of loading a projectstaged/parameterized keys, caching it, changing the other
value, reloading it and so on, but I think this could be a start at least.
What do you think?
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: central_caching.patch, forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16080324#comment-16080324
]
Alexander Falb commented on DELTASPIKE-1277:
Hi Romain,
I'm not sure about which storage by application you are talking about. The
{{Map configSources}}?
Having a service (Bean or just some static methods) to retrieve all
PropertyBuilders created by the application would be the goal. Ofc an iterator
of them would provide even more options than a simple {{getByKey}}, like the
proposed {{refreshValue("key")}}. But I'm still not sure where to collect all
the created PropertyBuilders.
Alex
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[
https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066638#comment-16066638
]
Alexander Falb commented on DELTASPIKE-1277:
The problem I am trying to solve is mostly regarded to unit tests. When testing
a service that uses _Resolvers_ with caching enabled it's not possible to load
a new value if one is already cached.
Another idea to forcefully reload cached values would be some sort of global
eviction. I had some {{ConfigResolverUtils.refreshValue("key")}} in mind. From
a usage point of view I would prefer this to the solution provided by the
patch, because there would be no need the get hold of the actual resolver. But
on the other hand all resolvers then have to register to some global
registration point. That also sounded not that "fun" to implement, so I finally
decided to propose a minimally invasive and simple solution, to get some early
feedback. But if you are interested I could work on the other idea too.
> Force refresh of cached config values
> -
>
> Key: DELTASPIKE-1277
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Configuration
>Reporter: Alexander Falb
> Attachments: forcerefresh.patch
>
>
> When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
> there is no way of bypassing the cache and forcefully reloading the value
> from underlying datasources.
> The attached patch is a proposal of creating such an mechanism. It introduces
> a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this
> method by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1277) Force refresh of cached config values
Alexander Falb created DELTASPIKE-1277:
--
Summary: Force refresh of cached config values
Key: DELTASPIKE-1277
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277
Project: DeltaSpike
Issue Type: Improvement
Components: Configuration
Reporter: Alexander Falb
Attachments: forcerefresh.patch
When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled,
there is no way of bypassing the cache and forcefully reloading the value from
underlying datasources.
The attached patch is a proposal of creating such an mechanism. It introduces a
{{void forceRefresh()}} method to the {{TypedResolver}}, implements this method
by resetting the {{reloadAfter}} field and adds a unit test.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1276) Multiple license headers
Alexander Falb created DELTASPIKE-1276: -- Summary: Multiple license headers Key: DELTASPIKE-1276 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1276 Project: DeltaSpike Issue Type: Bug Reporter: Alexander Falb Priority: Trivial Some files, like _org.apache.deltaspike.cdise.api.CdiContainer_ in [deltaspike-cdictrl-weld|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-weld/src/main/resources/META-INF/services/org.apache.deltaspike.cdise.api.CdiContainer] and [deltaspike-cdictrl-owb|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-owb/src/main/resources/META-INF/services/org.apache.deltaspike.cdise.api.CdiContainer] and [deltaspike-cdictrl-openejb|https://github.com/apache/deltaspike/blob/master/deltaspike/cdictrl/impl-openejb/src/main/resources/META-INF/services/org.apache.deltaspike.cdise.api.CdiContainer] or [org.apache.deltaspike.scheduler.spi.Scheduler|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/resources/META-INF/services/org.apache.deltaspike.scheduler.spi.Scheduler] have multiple license headers. Most, if not all of them, got introduced in [https://github.com/apache/deltaspike/commit/7df7557] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found
[
https://issues.apache.org/jira/browse/DELTASPIKE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb updated DELTASPIKE-1272:
---
Affects Version/s: 1.8.0
> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
> Attachments: deltaspike.patch
>
>
> When calling
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this
> issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found
[
https://issues.apache.org/jira/browse/DELTASPIKE-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Falb updated DELTASPIKE-1272:
---
Component/s: Configuration
> ConfigResolver asList breaks if no value is found
> -
>
> Key: DELTASPIKE-1272
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
> Project: DeltaSpike
> Issue Type: Bug
> Components: Configuration
>Affects Versions: 1.8.0
>Reporter: Alexander Falb
> Attachments: deltaspike.patch
>
>
> When calling
> {code:java}
> ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
> {code}
> a NullPointerException is thrown:
> {code}
> java.lang.NullPointerException
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
> {code}
> I created and attached a patch (including a few unit tests) to fix this
> issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (DELTASPIKE-1272) ConfigResolver asList breaks if no value is found
Alexander Falb created DELTASPIKE-1272:
--
Summary: ConfigResolver asList breaks if no value is found
Key: DELTASPIKE-1272
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1272
Project: DeltaSpike
Issue Type: Bug
Reporter: Alexander Falb
Attachments: deltaspike.patch
When calling
{code:java}
ConfigResolver.resolve("notexisting").as(Integer.class).asList().getValue();
{code}
a NullPointerException is thrown:
{code}
java.lang.NullPointerException
at
org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.splitAndConvertListValue(ConfigResolver.java:1020)
at
org.apache.deltaspike.core.api.config.ConfigResolver$PropertyBuilder.getValue(ConfigResolver.java:988)
{code}
I created and attached a patch (including a few unit tests) to fix this issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
