[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[ https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614033#comment-14614033 ] Oliver Heger commented on CONFIGURATION-604: This seems to be a pretty old change since version 1.6 was released years ago. To make sure I fully understand the problem, could you please specify exactly the expected result and the actual result? (Or even better: could you transform your demo code fragment to a unit test?) combining properties which use 3+ part names discards entries as of Commons 1.6+ Key: CONFIGURATION-604 URL: https://issues.apache.org/jira/browse/CONFIGURATION-604 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: N Campbell When two property files are combined using commons config 1.5, the aggregate configuration returns an expected result of 6 entries. If Commons configuration 1.6 or higher is used, the resulting set drops to which is not expected. The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the combiner returns the expected result. There does not appear to be any release notes etc that would suggest that this isn't a defect versus an intended implementation change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JXPATH-152) Concurrent access on hashmap of JXPathIntrospector
[ https://issues.apache.org/jira/browse/JXPATH-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613991#comment-14613991 ] Michele Vivoda commented on JXPATH-152: --- 1.4 snapshot is here https://github.com/apache/commons-jxpath Concurrent access on hashmap of JXPathIntrospector -- Key: JXPATH-152 URL: https://issues.apache.org/jira/browse/JXPATH-152 Project: Commons JXPath Issue Type: Bug Affects Versions: 1.3 Environment: Java5, Windows/AIX Reporter: pleutre Assignee: Matt Benson Priority: Minor Fix For: 1.4 Original Estimate: 24h Remaining Estimate: 24h JXPathIntrospector.registerDynamicClass method can be called in static part of classes. If two classes A B try to registerDynamicClass in the same time a concurrent access exception can append on hashmap of JXPathIntrospector. Replace hashmap by concurrent hashmap or synchronized access to these hashmaps. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CONFIGURATION-604) combining properties which use 3+ part names discards entries as of Commons 1.6+
[ https://issues.apache.org/jira/browse/CONFIGURATION-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614045#comment-14614045 ] N Campbell commented on CONFIGURATION-604: -- Expected answer is 6 as returned when using 1.5 x.y=true x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y.comparison=true x.y.in=true Switch to 1.6+ and you get 4 x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y=true Stay with 1.6 and re-order the 2-part entry in A.properties so it appears before 3 part names (x.y=true) and you get 6 again x.y=true x.y.simpleCase=false x.y.between=false x.y.isDistinctFrom=false x.y.comparison=true x.y.in=true combining properties which use 3+ part names discards entries as of Commons 1.6+ Key: CONFIGURATION-604 URL: https://issues.apache.org/jira/browse/CONFIGURATION-604 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: N Campbell When two property files are combined using commons config 1.5, the aggregate configuration returns an expected result of 6 entries. If Commons configuration 1.6 or higher is used, the resulting set drops to which is not expected. The property names include 2, 3 or 4 part names X.Y, X.Y.Z etc and it appears that as of 1.6 if the names are arranged in 2 part, then 3 part etc that the combiner returns the expected result. There does not appear to be any release notes etc that would suggest that this isn't a defect versus an intended implementation change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-296) [FTP] Socket timeout setting doesn't work if connect hangs
[ https://issues.apache.org/jira/browse/VFS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14614110#comment-14614110 ] Remko Popma commented on VFS-296: - About a week ago we started to use the timeout methods available in 2.0 (data timeout and so timeout). Since then we have not seen out app hanging (fingers crossed). If it happens again we will try to get a jstack dump before restarting, good tip, thanks! [FTP] Socket timeout setting doesn't work if connect hangs -- Key: VFS-296 URL: https://issues.apache.org/jira/browse/VFS-296 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Andreas Persson Fix For: 2.1 Attachments: sotimeout.patch, sotimeout_v2.patch The fix from VFS-216 doesn't help if the ftp server doesn't reply with any messages at all (could happen if it's behind a badly configured firewall for example). What happens is that the client.connect() called from FtpClientFactory hangs, and this line is before timeout parameter is set. I suggest the change in the attached patch. The scenario can be tested with netcat -l instead of a real ftp server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
