[jira] [Commented] (CONFIGURATION-834) ConfirgurationPropertySource doesn't supply resolved values.
[
https://issues.apache.org/jira/browse/CONFIGURATION-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742249#comment-17742249
]
Keith Barlow commented on CONFIGURATION-834:
Created [https://github.com/apache/commons-configuration/pull/309.] Please let
me know if there's anything else needed.
> ConfirgurationPropertySource doesn't supply resolved values.
>
>
> Key: CONFIGURATION-834
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-834
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation, Type conversion
>Affects Versions: 2.8.0
>Reporter: Keith Barlow
>Priority: Minor
>
> Per
> [https://commons.apache.org/proper/commons-configuration/userguide/howto_utilities.html#Use_Configuration_in_Spring,]
> we should be able to supply a Configuration to Spring using a
> ConfigurationPropertySource to tell spring to obtain property values from
> Commons Configuration2, however it seems that the ConfigurationPropertySource
> uses getProperty() instead of getString() to supply values to Spring. This
> means that the value supplied to string is the literal element from the
> configuration file and not the value resolved by Apache Commons
> Configuration2. This ultimately leads to Spring trying to parse a syntax it
> doesn't understand.
> When defining values that are resolved from environment properties such as:
> {code:java}
> property.custom=${env:CUSTOM_PROPERTY_VALUE}{code}
> Spring will receive the literal value of '${env:CUSTOM_PROPERTY_VALUE}' and
> ultimately treat this as a default value for a property named 'env' instead
> of an environment variable reference.
> I was able to resolve this by updating ConfigurationPropertSource to use
> `source.getString(name)` instead, then Spring will receive the value Commons
> Configuration2 has resolved from the environment value and convert it
> accordingly on it's own.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-configuration] kbarlowgw opened a new pull request, #309: CONFIGURATION-834 Update ConfigurationPropertySource to return resolved values.
kbarlowgw opened a new pull request, #309: URL: https://github.com/apache/commons-configuration/pull/309 Switches method used by getProperty() to getString() which will return values resolved by Apache Commons Configuration when properties reference system or environment values instead of just the name of the property referenced. Spring will convert the type from string to the desired type for the field declaration. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742223#comment-17742223 ] Gary D. Gregory commented on LANG-1702: --- Ah, sorry about the acronym, please see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (POOL-407) Threads get stuck when idleObjects list is empty.
[
https://issues.apache.org/jira/browse/POOL-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742216#comment-17742216
]
Phil Steitz commented on POOL-407:
--
Looking more carefully at this, the sequence in the description can happen and
it is a liveness limitation of the pool. There are other scenarios that can
lead to this. Neither GKOP nor GOP currently have a way to recover from
factory "outages." My suggestion to use ensureIdle above is not a good idea
because it could lead to looping in borrowObject.
The tests added above are not really testing anything. You can see in the
console NPE stack traces that don't cause the Junit tests to fail because the
runner is not picking them up. A more complex setup would be needed to catch
them. That setup would cause the ones where the factory returns null to fail.
By design, pool create methods throw NPE when factories return null. This is
documented in the javadoc for create, but missing from that of the pool
methods.
> Threads get stuck when idleObjects list is empty.
> -
>
> Key: POOL-407
> URL: https://issues.apache.org/jira/browse/POOL-407
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.8.1
>Reporter: Sarthak Shukla
>Priority: Major
>
> While borrowing object from pool, threads are getting stuck. I initialised
> the pool size as 1. And had 3 threads created. First thread enters
> borrowObject method, since there are no idle objects to poll from, it will
> create one object and move forward.
> {code:java}
> p = (PooledObject)this.idleObjects.pollFirst();
> if (p == null) {
> p = this.create();
> if (p != null) {
> create = true;
> }
> } {code}
> The other two threads will also follow same path and check for idle
> objects(there are none), will try to create one object but the pool size is
> set to 1. Thus, the two threads will move forward and enter
> *idleObjects.takeFirst()* function. Value of blockWhenExhausted is true and
> borrowMaxWaitMillis is -1 as we don't want timeout.
> {code:java}
> if (blockWhenExhausted) {
>if (p == null) {
> if (borrowMaxWaitMillis < 0L) {
>p = (PooledObject)this.idleObjects.takeFirst();
> } else {
>p = (PooledObject)this.idleObjects.pollFirst(borrowMaxWaitMillis,
> TimeUnit.MILLISECONDS);
> }
>}
>if (p == null) {
> throw new NoSuchElementException("Timeout waiting for idle object");
>}
> }{code}
> Now, the main thread does *this.factory.activateObject(p);* and object gets
> activated. Now, when the validation is checked *validate =
> this.factory.validateObject(p);* it comes out to be false as provider might
> have been disconnected.
> So, the object is destroyed by calling *this.destroy(p);*
> {code:java}
> private void destroy(PooledObject toDestroy) throws Exception {
> toDestroy.invalidate();
> this.idleObjects.remove(toDestroy);
> this.allObjects.remove(new
> BaseGenericObjectPool.IdentityWrapper(toDestroy.getObject()));
> try {
> this.factory.destroyObject(toDestroy);
> } finally {
> this.destroyedCount.incrementAndGet();
> this.createCount.decrementAndGet();
> }
> }{code}
> The object which was created is now destroyed and removed from idleObject and
> allObjects list. Now, the other two threads are still waiting to take object
> from idle objects list but there are no object present. Hence, the two
> threads are in wait state for infinite period and the application waits
> forever until we kill the process.
> {code:java}
> public E takeFirst() throws InterruptedException {
>this.lock.lock();
>Object var2;
>try {
> Object x;
> while((x = this.unlinkFirst()) == null) {
> this.notEmpty.await();
> }
> var2 = x;
> } finally {
> this.lock.unlock();
> }
> return var2;
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742214#comment-17742214 ] Renny Barrett commented on LANG-1702: - Sorry, I'm new to this... What's a "PR", please? > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-839) SoftRefReleaseThread线程close后，不能再次自动启动
[ https://issues.apache.org/jira/browse/VFS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742200#comment-17742200 ] Gary D. Gregory commented on VFS-839: - Google translate says: When all the cached files are cleared, the SoftRefReleaseThread thread will be automatically stopped, the fileSystemCache will be cleared when the thread is stopped, the softRefReleaseThread variable will be set to null, and the original thread will be interrupted, and the thread is safe; but during the process of stopping the SoftRefReleaseThread thread, there may be new The thread fetches the file from the cache, in In the getOrCreateFilesystemCache method, when the fileSystemCache is empty, a new SoftRefReleaseThread thread will be started, but the method of interrupting the thread has not yet set the softRefReleaseThread variable to null, the thread cannot be started, and the fileSystem is used as the key in the fileSystemCache variable, which is not thread-safe ;cause the SoftRefReleaseThread thread can no longer be automatically started; The overall execution steps are shown in the figure below: > SoftRefReleaseThread线程close后，不能再次自动启动 > - > > Key: VFS-839 > URL: https://issues.apache.org/jira/browse/VFS-839 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: CentOS 7.4 > JDK 1.8 >Reporter: fanshu >Priority: Major > Attachments: image-2023-07-11-10-07-44-143.png > > > 当缓存的文件被全部清理后，会自动停止SoftRefReleaseThread线程，停止线程会清空fileSystemCache，softRefReleaseThread变量设为null，再将原来的线程中断，且线程安全；但是在停止SoftRefReleaseThread线程过程中，可能有新的线程从缓存获取文件，在 > getOrCreateFilesystemCache方法中，当fileSystemCache为空时，会去启动新的SoftRefReleaseThread线程，但中断线程的方法还未将softRefReleaseThread变量设为null，线程不能被启动，且将fileSystem作为key放到fileSystemCache变量，非线程安全；导致SoftRefReleaseThread线程再也不能自动启动； > 整体执行步骤见下图： > !image-2023-07-11-10-07-44-143.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-839) SoftRefReleaseThread线程close后，不能再次自动启动
[ https://issues.apache.org/jira/browse/VFS-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742198#comment-17742198 ] Gary D. Gregory commented on VFS-839: - Google translate says: Google translate To Hindi To English Google English to Spanish Images App English to French To Urdu DeepL Translate English to Tagalog Voice Perspectives All filters Chinese (Simplified) English 当缓存的文件被全部清理后，会自动停止SoftRefReleaseThread线程，停止线程会清空fileSystemCache，softRefReleaseThread变量设为null，再将原来的线程中断，且线程安全；但是在停止SoftRefReleaseThread线程过程中，可能有新的线程从缓存获取文件，在 getOrCreateFilesystemCache方法中，当fileSystemCache为空时，会去启动新的SoftRefReleaseThread线程，但中断线程的方法还未将softRefReleaseThread变量设为null，线程不能被启动，且将fileSystem作为key放到fileSystemCache变量，非线程安全；导致SoftRefReleaseThread线程再也不能自动启动； 整体执行步骤见下图： Dāng huǎncún de wénjiàn bèi quánbù qīnglǐ hòu, huì zìdòng tíngzhǐ SoftRefReleaseThread xiànchéng, tíngzhǐ xiànchéng huì qīngkōng fileSystemCache,softRefReleaseThread biàn liáng shè wèi null, zài jiāng yuánlái de xiànchéng zhōngduàn, qiě xiànchéng ānquán; dànshì zài tíngzhǐ SoftRefReleaseThread xiànchéng guòchéng zhōng, kěnéng yǒu xīn de xiànchéng cóng huǎncún huòqǔ wénjiàn, zài getOrCreateFilesystemCache fāngfǎ zhōng, dāng fileSystemCache wèi kòng shí, huì qù qǐdòng xīn de SoftRefReleaseThread xiànchéng, dàn zhōngduàn xiànchéng de fāngfǎ hái wèi jiāng softRefReleaseThread biàn liáng shè wèi null, xiànchéng bùnéng bèi qǐdòng, qiě jiāng fileSystem zuòwéi key fàng dào fileSystemCache biànliàng, fēi xiànchéng ānquán; dǎozhì SoftRefReleaseThread xiànchéng zài yě bùnéng zìdòng qǐdòng; zhěngtǐ zhíxíng bùzhòu jiàn xià tú: When all the cached files are cleared, the SoftRefReleaseThread thread will be automatically stopped, the fileSystemCache will be cleared when the thread is stopped, the softRefReleaseThread variable will be set to null, and the original thread will be interrupted, and the thread is safe; but during the process of stopping the SoftRefReleaseThread thread, there may be new The thread fetches the file from the cache, in In the getOrCreateFilesystemCache method, when the fileSystemCache is empty, a new SoftRefReleaseThread thread will be started, but the method of interrupting the thread has not yet set the softRefReleaseThread variable to null, the thread cannot be started, and the fileSystem is used as the key in the fileSystemCache variable, which is not thread-safe ;cause the SoftRefReleaseThread thread can no longer be automatically started; The overall execution steps are shown in the figure below: Feedback Translate App installed Google Translate Google's service, offered free of charge, instantly translates words, phrases, and web pages between English and over 100 other languages. Detect language → English About Android How can we help you? Translate by speech Translate documents & websites Google Translate App installed People also ask Is Google Translate 100% right? What does Ingles mean in English? What is the meaning of de nada? What is the most accurate Chinese translator to English? Feedback Translate.com https://www.translate.com Translate.com: Online Translator Expert language solutions for any size of business. 25K+ professional translators. 90 language pairs. 24/7 online translation service. API. People also search for Top stories DeepL Translate https://www.deepl.com › translator-... DeepL Translate: The world's most accurate translator Translate texts & full document files instantly. Accurate translations for individuals and Teams. Millions translate with DeepL every day. Yandex Translate https://translate.yandex.com › ... Dictionary and online translation Free online translation from English and other languages into Russian and back. The translator works with words, texts, web pages, and text in photos. Google https://chrome.google.com › detail Google Translate Mar 22, 2023 — View translations easily as you browse the web. By the Google Translate team. Highlight or right-click on a section of text and click on ... > SoftRefReleaseThread线程close后，不能再次自动启动 > - > > Key: VFS-839 > URL: https://issues.apache.org/jira/browse/VFS-839 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: CentOS 7.4 > JDK 1.8 >Reporter: fanshu >Priority: Major > Attachments: image-2023-07-11-10-07-44-143.png > > > 当缓存的文件被全部清理后，会自动停止SoftRefReleaseThread线程，停止线程会清空fileSystemCache，softRefReleaseThread变量设为null，再将原来的线程中断，且线程安全；但是在停止SoftRefReleaseThread线程过程中，可能有新的线程从缓存获取文件，在 > getOrCreateFilesystemCache方法中，当fileSystemCache为空时，会去启动新的SoftRefReleaseThread线程，但中断线程的方法还未将softRefReleaseThread变量设为null，线程不能被启动，且将fileSystem作为key放到fileSystemCache变量，非线程安全；导致SoftRefReleaseThread线程再也不能自动启动； > 整体执行步骤见下图： > !image-2023-07-11-10-07-44-143.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (VFS-839) SoftRefReleaseThread线程close后，不能再次自动启动
[ https://issues.apache.org/jira/browse/VFS-839 ] Gary D. Gregory deleted comment on VFS-839: - was (Author: garydgregory): Google translate says: Google translate To Hindi To English Google English to Spanish Images App English to French To Urdu DeepL Translate English to Tagalog Voice Perspectives All filters Chinese (Simplified) English 当缓存的文件被全部清理后，会自动停止SoftRefReleaseThread线程，停止线程会清空fileSystemCache，softRefReleaseThread变量设为null，再将原来的线程中断，且线程安全；但是在停止SoftRefReleaseThread线程过程中，可能有新的线程从缓存获取文件，在 getOrCreateFilesystemCache方法中，当fileSystemCache为空时，会去启动新的SoftRefReleaseThread线程，但中断线程的方法还未将softRefReleaseThread变量设为null，线程不能被启动，且将fileSystem作为key放到fileSystemCache变量，非线程安全；导致SoftRefReleaseThread线程再也不能自动启动； 整体执行步骤见下图： Dāng huǎncún de wénjiàn bèi quánbù qīnglǐ hòu, huì zìdòng tíngzhǐ SoftRefReleaseThread xiànchéng, tíngzhǐ xiànchéng huì qīngkōng fileSystemCache,softRefReleaseThread biàn liáng shè wèi null, zài jiāng yuánlái de xiànchéng zhōngduàn, qiě xiànchéng ānquán; dànshì zài tíngzhǐ SoftRefReleaseThread xiànchéng guòchéng zhōng, kěnéng yǒu xīn de xiànchéng cóng huǎncún huòqǔ wénjiàn, zài getOrCreateFilesystemCache fāngfǎ zhōng, dāng fileSystemCache wèi kòng shí, huì qù qǐdòng xīn de SoftRefReleaseThread xiànchéng, dàn zhōngduàn xiànchéng de fāngfǎ hái wèi jiāng softRefReleaseThread biàn liáng shè wèi null, xiànchéng bùnéng bèi qǐdòng, qiě jiāng fileSystem zuòwéi key fàng dào fileSystemCache biànliàng, fēi xiànchéng ānquán; dǎozhì SoftRefReleaseThread xiànchéng zài yě bùnéng zìdòng qǐdòng; zhěngtǐ zhíxíng bùzhòu jiàn xià tú: When all the cached files are cleared, the SoftRefReleaseThread thread will be automatically stopped, the fileSystemCache will be cleared when the thread is stopped, the softRefReleaseThread variable will be set to null, and the original thread will be interrupted, and the thread is safe; but during the process of stopping the SoftRefReleaseThread thread, there may be new The thread fetches the file from the cache, in In the getOrCreateFilesystemCache method, when the fileSystemCache is empty, a new SoftRefReleaseThread thread will be started, but the method of interrupting the thread has not yet set the softRefReleaseThread variable to null, the thread cannot be started, and the fileSystem is used as the key in the fileSystemCache variable, which is not thread-safe ;cause the SoftRefReleaseThread thread can no longer be automatically started; The overall execution steps are shown in the figure below: Feedback Translate App installed Google Translate Google's service, offered free of charge, instantly translates words, phrases, and web pages between English and over 100 other languages. Detect language → English About Android How can we help you? Translate by speech Translate documents & websites Google Translate App installed People also ask Is Google Translate 100% right? What does Ingles mean in English? What is the meaning of de nada? What is the most accurate Chinese translator to English? Feedback Translate.com https://www.translate.com Translate.com: Online Translator Expert language solutions for any size of business. 25K+ professional translators. 90 language pairs. 24/7 online translation service. API. People also search for Top stories DeepL Translate https://www.deepl.com › translator-... DeepL Translate: The world's most accurate translator Translate texts & full document files instantly. Accurate translations for individuals and Teams. Millions translate with DeepL every day. Yandex Translate https://translate.yandex.com › ... Dictionary and online translation Free online translation from English and other languages into Russian and back. The translator works with words, texts, web pages, and text in photos. Google https://chrome.google.com › detail Google Translate Mar 22, 2023 — View translations easily as you browse the web. By the Google Translate team. Highlight or right-click on a section of text and click on ... > SoftRefReleaseThread线程close后，不能再次自动启动 > - > > Key: VFS-839 > URL: https://issues.apache.org/jira/browse/VFS-839 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: CentOS 7.4 > JDK 1.8 >Reporter: fanshu >Priority: Major > Attachments: image-2023-07-11-10-07-44-143.png > > > 当缓存的文件被全部清理后，会自动停止SoftRefReleaseThread线程，停止线程会清空fileSystemCache，softRefReleaseThread变量设为null，再将原来的线程中断，且线程安全；但是在停止SoftRefReleaseThread线程过程中，可能有新的线程从缓存获取文件，在 > getOrCreateFilesystemCache方法中，当fileSystemCache为空时，会去启动新的SoftRefReleaseThread线程，但中断线程的方法还未将softRefReleaseThread变量设为null，线程不能被启动，且将fileSystem作为key放到fileSystemCache变量，非线程安全；导致SoftRefReleaseThread线程再也不能自动启动； > 整体执行步骤见下图： > !image-2023-07-11-10-07-44-143.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742197#comment-17742197 ] Gary D. Gregory commented on LANG-1702: --- [~renny] Thank you for the analysis. Would you want to take a swing at a PR on GitHub? > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[
https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742178#comment-17742178
]
Renny Barrett edited comment on LANG-1702 at 7/11/23 9:28 PM:
--
LANG-1524 might be {_}related{_}, but I don't think it's necessarily the same.
LANG-1524 refers to TypeUtils.classToString, whereas this ticket refers to
TypeUtils.unrollVariables.
It could well turn out that LANG-1524 and this ticket both spring from the same
erroneous assumptions about how type variables work with inner classes, but
looking at the commons-lang implementation code, it looks like LANG-1524 could
be fixed without fixing this ticket, and vice versa.
Probably best to fix LANG-1524 and this ticket at the same time (and also test
other methods on TypeUtils operating on parameterised inner classes), but
that's not to say that this ticket _duplicates_ LANG-1524.
was (Author: JIRAUSER301302):
LANG-1524 might be {_}related{_}, but I don't think it's necessarily the same.
LANG-1524 refers to TypeUtils.classToString, whereas this ticket refers to
TypeUtils.unrollVariables.
> TypeUtils.unrollVariables can cause a StackException for parameterized inner
> class
> --
>
> Key: LANG-1702
> URL: https://issues.apache.org/jira/browse/LANG-1702
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.12.0
>Reporter: Renny Barrett
>Priority: Major
> Attachments: TestTypeUtilsUnwrap.java
>
>
> If TypeUtils.unrollVariables is called for a type which is a non-static inner
> class where the inner class and its enclosing class both have type
> parameters, then there's an infinite recursion which results in a
> StackOverflow error.
>
> Simple test code that recreates the issue is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (LANG-1697) TypeUtils.getRawType() throws a NullPointerException on Wildcard GenericArrayType
[
https://issues.apache.org/jira/browse/LANG-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-1697.
---
Fix Version/s: 3.13.0
Resolution: Fixed
[~sparkaar]
The code in git master (and snapshot builds) no longer throws an NPE in this
case and returns null. See comments in the new test
{*}org.apache.commons.lang3.reflect.TypeUtilsTest.testGetRawType_LANG_1697(){*}.
This likely needs a bit more analysis such that either the method returns a
non-null value or the Javadoc documents the behavior.
> TypeUtils.getRawType() throws a NullPointerException on Wildcard
> GenericArrayType
> -
>
> Key: LANG-1697
> URL: https://issues.apache.org/jira/browse/LANG-1697
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.12.0
>Reporter: Jan Arne Sparka
>Priority: Minor
> Fix For: 3.13.0
>
> Attachments: TestClass.java
>
>
> When calling TypeUtils.getRawType(Type type, Type assigningType), with a
> GenericArrayType of a WildcardType it crashes with a NPE.
> Minimum viable example attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[
https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742178#comment-17742178
]
Renny Barrett commented on LANG-1702:
-
LANG-1524 might be {_}related{_}, but I don't think it's necessarily the same.
LANG-1524 refers to TypeUtils.classToString, whereas this ticket refers to
TypeUtils.unrollVariables.
> TypeUtils.unrollVariables can cause a StackException for parameterized inner
> class
> --
>
> Key: LANG-1702
> URL: https://issues.apache.org/jira/browse/LANG-1702
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.12.0
>Reporter: Renny Barrett
>Priority: Major
> Attachments: TestTypeUtilsUnwrap.java
>
>
> If TypeUtils.unrollVariables is called for a type which is a non-static inner
> class where the inner class and its enclosing class both have type
> parameters, then there's an infinite recursion which results in a
> StackOverflow error.
>
> Simple test code that recreates the issue is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1697) TypeUtils getRawType throws a NullPointerException on Wildcard GenericArrayType and null
[ https://issues.apache.org/jira/browse/LANG-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1697: -- Summary: TypeUtils getRawType throws a NullPointerException on Wildcard GenericArrayType and null (was: TypeUtils getRawType throws a NullPointerException on Wildcard GenericArrayType) > TypeUtils getRawType throws a NullPointerException on Wildcard > GenericArrayType and null > - > > Key: LANG-1697 > URL: https://issues.apache.org/jira/browse/LANG-1697 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Jan Arne Sparka >Priority: Minor > Attachments: TestClass.java > > > When calling TypeUtils.getRawType(Type type, Type assigningType), with a > GenericArrayType of a WildcardType it crashes with a NPE. > Minimum viable example attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1697) TypeUtils.getRawType() throws a NullPointerException on Wildcard GenericArrayType
[ https://issues.apache.org/jira/browse/LANG-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated LANG-1697: -- Summary: TypeUtils.getRawType() throws a NullPointerException on Wildcard GenericArrayType (was: TypeUtils getRawType throws a NullPointerException on Wildcard GenericArrayType and null ) > TypeUtils.getRawType() throws a NullPointerException on Wildcard > GenericArrayType > - > > Key: LANG-1697 > URL: https://issues.apache.org/jira/browse/LANG-1697 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Jan Arne Sparka >Priority: Minor > Attachments: TestClass.java > > > When calling TypeUtils.getRawType(Type type, Type assigningType), with a > GenericArrayType of a WildcardType it crashes with a NPE. > Minimum viable example attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742168#comment-17742168 ] Gary D. Gregory edited comment on LANG-1702 at 7/11/23 8:32 PM: [~renny] Isn't this the same as LANG-1524? Please add your stack trace to the ticket description. was (Author: garydgregory): [~renny] Isn't this the same as LANG-1524? > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
[ https://issues.apache.org/jira/browse/LANG-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742168#comment-17742168 ] Gary D. Gregory commented on LANG-1702: --- [~renny] Isn't this the same as LANG-1524? > TypeUtils.unrollVariables can cause a StackException for parameterized inner > class > -- > > Key: LANG-1702 > URL: https://issues.apache.org/jira/browse/LANG-1702 > Project: Commons Lang > Issue Type: Bug > Components: lang.reflect.* >Affects Versions: 3.12.0 >Reporter: Renny Barrett >Priority: Major > Attachments: TestTypeUtilsUnwrap.java > > > If TypeUtils.unrollVariables is called for a type which is a non-static inner > class where the inner class and its enclosing class both have type > parameters, then there's an infinite recursion which results in a > StackOverflow error. > > Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (LANG-1702) TypeUtils.unrollVariables can cause a StackException for parameterized inner class
Renny Barrett created LANG-1702: --- Summary: TypeUtils.unrollVariables can cause a StackException for parameterized inner class Key: LANG-1702 URL: https://issues.apache.org/jira/browse/LANG-1702 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Affects Versions: 3.12.0 Reporter: Renny Barrett Attachments: TestTypeUtilsUnwrap.java If TypeUtils.unrollVariables is called for a type which is a non-static inner class where the inner class and its enclosing class both have type parameters, then there's an infinite recursion which results in a StackOverflow error. Simple test code that recreates the issue is attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1701) Where is the difference?
[
https://issues.apache.org/jira/browse/LANG-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742043#comment-17742043
]
Gilles Sadowski commented on LANG-1701:
---
To ensure that no (de)serialization issue, due to the particular (binary)
format at hand, is involved in this weird (?) behaviour, I saved the 2 loaded
objects to XML (using
[{{XMLEncoder}}|https://docs.oracle.com/javase/8/docs/api/java/beans/XMLEncoder.html]
from the JDK): The XML outputs (from the two object being compared) show no
differences.
Do you agree that this confirms that the [Lang]'s
[{{ReflectionDiffBuilder}}|https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/builder/ReflectionDiffBuilder.html]
is buggy, or has major (undocumented) limitations?
> Where is the difference?
>
>
> Key: LANG-1701
> URL: https://issues.apache.org/jira/browse/LANG-1701
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Reporter: Gilles Sadowski
>Priority: Major
>
> This report is a follow-up of [this
> post|https://markmail.org/message/2gsqo67i6iqkscic] on the "user" ML.
> The following is a very short excerpt of the {{DiffResult}} for my use-case.
> In this particular occurrence, the number of differences was reported to be
> 3; below is 1 of those 3.
> {noformat}
> [EBElementaryImpl
> [globalRanking=0.5968429082193868,referenceTime=2284.2000453600494,period=1.171943602656199,periodError=2.4295114805950035E-5,periodSearchInfo=STRING_LENGTH_peakIdx1_freqMultFact1.0,primaryEclPhase=0.6925071490306989,primaryEclPhaseError=0.004962180747017656,primaryEclDuration=0.37648175257319794,primaryEclDurationError=0.03878385329624003,primaryEclDepth=0.5255078446758894,primaryEclDepthError=0.0218840324586,secondaryEclPhase=0.1930675728191525,secondaryEclPhaseError=0.004611168038876871,secondaryEclDuration=0.4,secondaryEclDurationError=0.0,secondaryEclDepth=0.2201620328425875,secondaryEclDepthError=0.013621938652715037,numDegFreedom=8,issueFlagsOfFit=0,reducedChi2=2.738038313809182,reducedChi2InEclipse=2.178358093408932,numObsInPrimaryEclipse=7,numObsInSecondaryEclipse=17,probGcvsEA=0.0,probGcvsEB=1.0,probGcvsEW=0.0,pojmanskiClassification=null]],
> [EBElementaryImpl
> [globalRanking=0.5968429082193868,referenceTime=2284.2000453600494,period=1.171943602656199,periodError=2.4295114805950035E-5,periodSearchInfo=STRING_LENGTH_peakIdx1_freqMultFact1.0,primaryEclPhase=0.6925071490306989,primaryEclPhaseError=0.004962180747017656,primaryEclDuration=0.37648175257319794,primaryEclDurationError=0.03878385329624003,primaryEclDepth=0.5255078446758894,primaryEclDepthError=0.0218840324586,secondaryEclPhase=0.1930675728191525,secondaryEclPhaseError=0.004611168038876871,secondaryEclDuration=0.4,secondaryEclDurationError=0.0,secondaryEclDepth=0.2201620328425875,secondaryEclDepthError=0.013621938652715037,numDegFreedom=8,issueFlagsOfFit=0,reducedChi2=2.738038313809182,reducedChi2InEclipse=2.178358093408932,numObsInPrimaryEclipse=7,numObsInSecondaryEclipse=17,probGcvsEA=0.0,probGcvsEB=1.0,probGcvsEW=0.0,pojmanskiClassification=null]]]
> {noformat}
> But I don't see any difference...
> From another instance, 3 differences (out of 11 reported):
> {noformat}
> [ag: AstroParamImpl
> [val=0.006,error=NaN,lowerConf=0.0014,upperConf=0.0151,name=ag,gof=NaN,info=null,dummy=0.0],
> AstroParamImpl
> [val=0.006,error=NaN,lowerConf=0.0014,upperConf=0.0151,name=ag,gof=NaN,info=null,dummy=0.0]]
> [abp: AstroParamImpl
> [val=0.0074,error=NaN,lowerConf=0.0018,upperConf=0.0188,name=abp,gof=NaN,info=null,dummy=0.0],
> AstroParamImpl
> [val=0.0074,error=NaN,lowerConf=0.0018,upperConf=0.0188,name=abp,gof=NaN,info=null,dummy=0.0]]
> [arp: AstroParamImpl
> [val=0.0042,error=NaN,lowerConf=0.001,upperConf=0.0106,name=arp,gof=NaN,info=null,dummy=0.0],
> AstroParamImpl
> [val=0.0042,error=NaN,lowerConf=0.001,upperConf=0.0106,name=arp,gof=NaN,info=null,dummy=0.0]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (POOL-411) NPE when deregistering key at end of borrow
[
https://issues.apache.org/jira/browse/POOL-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741955#comment-17741955
]
Gary D. Gregory commented on POOL-411:
--
[~psteitz]
{quote}Any suggestions about how to do that in a simple, maintainable way?
{quote}
A plugin subclass or lambda?
> NPE when deregistering key at end of borrow
> ---
>
> Key: POOL-411
> URL: https://issues.apache.org/jira/browse/POOL-411
> Project: Commons Pool
> Issue Type: Task
>Affects Versions: 2.11.1
>Reporter: Richard Eckart de Castilho
>Priority: Major
> Fix For: 2.12.0
>
>
> There is a potential for an NPE happening in the finally block of
> borrowObject:
> {noformat}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "org.apache.commons.pool2.impl.GenericKeyedObjectPool$ObjectDeque.getNumInterested()"
> because "objectDeque" is null
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.deregister(GenericKeyedObjectPool.java:821)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:507)
> at
> org.apache.commons.pool2.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:350)
>
> {noformat}
> From reading the code, it seems this could happen e.g. if a pool is
> concurrently cleared while a borrow is in progress.
> Not sure what a proper solution here would be. Maybe deregister should
> silently do nothing if poolMap.get(k) returns null?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[ https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741945#comment-17741945 ] Gilles Sadowski commented on MATH-1656: --- bq. With plain junit, you just have a statement like "result is 5, should be 4" [...] I hated it when I first use junit some ... 24 years ago. At the time, it was certainly an improvement over code being released with no tests... ;-) bq. [...] I deeply feel that I won't ever convince you. More on that below. Here the point is about uniformity of the code base: Current de facto consensus is that new code should be maintainable, i.e. not add to the pile that is not (prime example being the implementation of "BOBYQA"). In CM (as in all the new components that were created from code originally in CM), top priorities (_current_ consensus) are # full documentation, # full coverage, # align on "standard" usage of "JUnit 5". I cannot decide, now and by myself, to commit your "DiffTest.java" file since it is at odds with the 3 points above: # It is undocumented. # If (for some hypothetical reason) your test framework is removed, the code that was covered, won't be anymore. # It differs from the rest (even within the "optim" package). The *consensus can change* but, on such matters, it would be settled through a _discussion_ on the "dev" ML. IOW, on the framework itself, I didn't say anything other that _it might be a neat idea_. But it is (currently) not something that (IMHO) CM should maintain just for the sake of testing a relatively small part of its code. [You are welcome to ask for others' opinion on the "dev" ML.] That said, some time ago, Gary Gregory proposed to create a "Commons Testing" component; I'm readily convinced that your framework would fit within the scope of such an endeavour. So please *post your proposal to the "dev" ML* (with a "Subject: " prefix like "[All][Testing]"). Then, if the new component gets traction, the whole "Commons" team will bear the maintenance burden; and it will be much easier for CM to have it as a dependency (and gradually replace the current tests). > Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) > are missing > -- > > Key: MATH-1656 > URL: https://issues.apache.org/jira/browse/MATH-1656 > Project: Commons Math > Issue Type: Wish > Components: legacy >Affects Versions: 4.0-beta1 >Reporter: François Laferrière >Priority: Major > Labels: features > Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip, > MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10 > 12-13-38.png > > > Some classical multivariate such as > * gradient descent, > * Raphson-Newton, > * BFGS > are missing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1656) Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS) are missing
[
https://issues.apache.org/jira/browse/MATH-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741898#comment-17741898
]
François Laferrière commented on MATH-1656:
---
{quote}I understand but my point is that the "core" of a unit test is to
compare values (computed vs reference).
{quote}
I totally agree with you. And that is exactly what DiffTest does, compare
computed test results vs reference. Except that you can compare result vs
reference with you favorite diff tool, so that you, then, have context (results
that where produces before the assert fails, result expected at failure point
and even result that could have been produced after first failure). With plain
junit, you just have a statement like "result is 5, should be 4" and to
understand what is going on, you have to run under debugger. I hated it when I
first use junit some ... 24 years ago. I started then to develop this little
framework, first in bash and makefile. This original "black box" version was
language independent and was use to test any binary (I used it for java, but
also C/C++, perl, bash etc.). Eventually "ported" it to junit/java and other
environments (nunit/c#).
I can provide a (bash) toolbox to compare and manage test references.
But I deeply feel that I won't ever convince you. *So I will rollback to a
plain junit test (without I/O or gnuplot stuff) focusing on results only.*
That may take some time.
> Classical multivariate optimizers (gradient descent, Raphson-Newton, BFGS)
> are missing
> --
>
> Key: MATH-1656
> URL: https://issues.apache.org/jira/browse/MATH-1656
> Project: Commons Math
> Issue Type: Wish
> Components: legacy
>Affects Versions: 4.0-beta1
>Reporter: François Laferrière
>Priority: Major
> Labels: features
> Attachments: MATH-1656-GradientDescent-Newton-BFGS-v2.0.zip,
> MATH-1658-GradientDescent-Newton-BFGS.patch, Screenshot from 2023-07-10
> 12-13-38.png
>
>
> Some classical multivariate such as
> * gradient descent,
> * Raphson-Newton,
> * BFGS
> are missing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
