[GitHub] [commons-exec] garydgregory commented on issue #5: Maven commons-parent 49

[GitBox]

garydgregory commented on issue #5: Maven commons-parent 49
URL: https://github.com/apache/commons-exec/pull/5#issuecomment-539770321
 
 
   Please rebase on master which will fix the RAT check, and then hopefully get 
green builds on master.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-exec] sullis commented on issue #3: Update commons-parent to 48

[GitBox]

sullis commented on issue #3: Update commons-parent to 48
URL: https://github.com/apache/commons-exec/pull/3#issuecomment-539747453
 
 
   commons-parent 49 
   https://github.com/apache/commons-exec/pull/5
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-exec] sullis opened a new pull request #5: Maven commons-parent 49

[GitBox]

sullis opened a new pull request #5: Maven commons-parent 49
URL: https://github.com/apache/commons-exec/pull/5
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-lang] garydgregory commented on issue #461: Lang 1491

[GitBox]

garydgregory commented on issue #461: Lang 1491
URL: https://github.com/apache/commons-lang/pull/461#issuecomment-539691644
 
 
   Hi Peter,
   
   Thank you sharing your insights with us.
   
   The best path for the PR IMO is to minimize the change set by keeping
   elements that are public unchanged.
   
   We have had other PRs in other Commons components recently with updates
   from JUnit 4 to 5, all of these were merged and did not change visibility
   down from public.
   
   Gary
   
   On Mon, Oct 7, 2019, 16:27 Peter Verhas  wrote:
   
   > I am sorry.
   >
   > I had a discussion with my son, and he read this thread and gave me
   > feedback, that I accepted. I also edited my past comments to remove the
   > parts that I see now, were offending. I did that as a gesture and not to
   > hide the traces of my bad communication. The original versions are there,
   > visible and also included as a quote in replies word by word, which is OK.
   >
   > My son told me that the original misunderstanding was that I communicated
   > the aim of the change ambiguous. Because of that ambiguity, Mr. Kinoshita
   > was asking me about the reference where JUnit requires that the tests are
   > not public. There is no such thing. JUnit allows the tests to be public.
   > They just do not demand the tests to be public anymore as we change from
   > JUnit 4 to JUnit 5. This misunderstanding is my fault. I can also see that
   > my response to this was not-professional in the details I deleted.
   >
   > Having all said I still believe that this pull request and also the next
   > one following this is valuable for the project helping to keep the code
   > clean and up to date and the PR should not be neglected.
   >
   > —
   > You are receiving this because you commented.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or mute the thread
   > 

   > .
   >
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=325312=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325312
 ]

ASF GitHub Bot logged work on LANG-1480:


Author: ASF GitHub Bot
Created on: 08/Oct/19 20:24
Start Date: 08/Oct/19 20:24
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on issue #446: LANG-1480 
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-539688116
 
 
   @verhas 
   GitHub seems to think there conflicts here. May you rebase?
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325312)
Remaining Estimate: 16h 10m  (was: 16h 20m)
Time Spent: 7h 50m  (was: 7h 40m)

> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
>   Original Estimate: 24h
>  Time Spent: 7h 50m
>  Remaining Estimate: 16h 10m
>
> In some cases, the algorithm decides incorrectly when to which package names 
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result 
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} 
> (18 characters as requested). The reason for this is that the algorithm 
> starts from the right and goes to the left abbreviating the packages and 
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages 
> that would result in a too-long string without abbreviating the package name.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] garydgregory commented on issue #449: Update documentation related to the issue LANG-696

[GitBox]

garydgregory commented on issue #449: Update documentation related to the issue 
LANG-696
URL: https://github.com/apache/commons-lang/pull/449#issuecomment-539653289
 
 
   @verhas 
   I merged this PR into git master. Thank you!


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Work logged] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-696?focusedWorklogId=325277=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325277
 ]

ASF GitHub Bot logged work on LANG-696:
---

Author: ASF GitHub Bot
Created on: 08/Oct/19 18:55
Start Date: 08/Oct/19 18:55
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on issue #449: Update 
documentation related to the issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449#issuecomment-539653289
 
 
   @verhas 
   I merged this PR into git master. Thank you!
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325277)
Time Spent: 1h  (was: 50m)

> Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
> --
>
> Key: LANG-696
> URL: https://issues.apache.org/jira/browse/LANG-696
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: Discussion
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Added two null-safe ClassUtils.getSimpleName() APIs.
> -- Forwarded message --
> From: Gary Gregory 
> Date: Mon, Apr 11, 2011 at 10:18 AM
> Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName
> To: Commons Developers List 
> Hi All:
> Should we deprecate ClassUtils getShortClassName in favor of Class 
> getSimpleName?
> The behavior of getShortClassName is undocumented for arrays in the Javadoc 
> and is different from getSimpleName.
> When I replace the guts of getShortClassName to call getSimpleName, one test 
> fails:
> junit.framework.ComparisonFailure: null 
> expected:<[ToStringStyleTest.]Person[name=John Q. ...> but 
> was:<[]Person[name=John Q. ...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at 
> org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86)
> For now, I've made a note in the Javdoc to consider using getSimpleName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-696?focusedWorklogId=325276=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325276
 ]

ASF GitHub Bot logged work on LANG-696:
---

Author: ASF GitHub Bot
Created on: 08/Oct/19 18:53
Start Date: 08/Oct/19 18:53
Worklog Time Spent: 10m 
  Work Description: garydgregory commented on pull request #449: Update 
documentation related to the issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449
 
 
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325276)
Time Spent: 50m  (was: 40m)

> Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
> --
>
> Key: LANG-696
> URL: https://issues.apache.org/jira/browse/LANG-696
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: Discussion
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Added two null-safe ClassUtils.getSimpleName() APIs.
> -- Forwarded message --
> From: Gary Gregory 
> Date: Mon, Apr 11, 2011 at 10:18 AM
> Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName
> To: Commons Developers List 
> Hi All:
> Should we deprecate ClassUtils getShortClassName in favor of Class 
> getSimpleName?
> The behavior of getShortClassName is undocumented for arrays in the Javadoc 
> and is different from getSimpleName.
> When I replace the guts of getShortClassName to call getSimpleName, one test 
> fails:
> junit.framework.ComparisonFailure: null 
> expected:<[ToStringStyleTest.]Person[name=John Q. ...> but 
> was:<[]Person[name=John Q. ...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at 
> org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86)
> For now, I've made a note in the Javdoc to consider using getSimpleName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] garydgregory merged pull request #449: Update documentation related to the issue LANG-696

[GitBox]

garydgregory merged pull request #449: Update documentation related to the 
issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (POOL-348) The commons-pool-evictor-thread should run as a Deamon

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/POOL-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed POOL-348.
---

> The commons-pool-evictor-thread should run as a Deamon
> --
>
> Key: POOL-348
> URL: https://issues.apache.org/jira/browse/POOL-348
> Project: Commons Pool
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Thomas Neerup
>Priority: Major
> Fix For: 2.6.2
>
>
> The thread "commons-pool-evictor-thread" does not run as a Deamon and keeps 
> the JVM alive when all other non Deamon threads has ended.
> Is there any reason for this behaviour? Otherwise the thread should be 
> started as a Deamon.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Work logged] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-696?focusedWorklogId=325166=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325166
 ]

ASF GitHub Bot logged work on LANG-696:
---

Author: ASF GitHub Bot
Created on: 08/Oct/19 16:34
Start Date: 08/Oct/19 16:34
Worklog Time Spent: 10m 
  Work Description: coveralls commented on issue #449: documentation 
related to the issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449#issuecomment-539597270
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26185269/badge)](https://coveralls.io/builds/26185269)
   
   Coverage increased (+0.002%) to 95.216% when pulling 
**1a645d7ffa5eb482c439673e6f7251f59a4cd0ac on verhas:LANG-696** into 
**24f66b175fdbc37c02ac234f1f3d7b2a5f13cc57 on apache:master**.
   
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325166)
Time Spent: 40m  (was: 0.5h)

> Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
> --
>
> Key: LANG-696
> URL: https://issues.apache.org/jira/browse/LANG-696
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: Discussion
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Added two null-safe ClassUtils.getSimpleName() APIs.
> -- Forwarded message --
> From: Gary Gregory 
> Date: Mon, Apr 11, 2011 at 10:18 AM
> Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName
> To: Commons Developers List 
> Hi All:
> Should we deprecate ClassUtils getShortClassName in favor of Class 
> getSimpleName?
> The behavior of getShortClassName is undocumented for arrays in the Javadoc 
> and is different from getSimpleName.
> When I replace the guts of getShortClassName to call getSimpleName, one test 
> fails:
> junit.framework.ComparisonFailure: null 
> expected:<[ToStringStyleTest.]Person[name=John Q. ...> but 
> was:<[]Person[name=John Q. ...>
> at junit.framework.Assert.assertEquals(Assert.java:81)
> at junit.framework.Assert.assertEquals(Assert.java:87)
> at 
> org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86)
> For now, I've made a note in the Javdoc to consider using getSimpleName.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] coveralls commented on issue #449: documentation related to the issue LANG-696

[GitBox]

coveralls commented on issue #449: documentation related to the issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449#issuecomment-539597270
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26185269/badge)](https://coveralls.io/builds/26185269)
   
   Coverage increased (+0.002%) to 95.216% when pulling 
**1a645d7ffa5eb482c439673e6f7251f59a4cd0ac on verhas:LANG-696** into 
**24f66b175fdbc37c02ac234f1f3d7b2a5f13cc57 on apache:master**.
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (LANG-1177) Improve indexOf performance when called multiple times

[Liel Fridman (Jira)]

[ 
https://issues.apache.org/jira/browse/LANG-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947037#comment-16947037
 ] 

Liel Fridman commented on LANG-1177:


Hi.

Can I work on this one?

Thanks!

> Improve indexOf performance when called multiple times
> --
>
> Key: LANG-1177
> URL: https://issues.apache.org/jira/browse/LANG-1177
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>
> The indexOf methods search for a single entry in an array.
> This works fine when only the first matching entry is needed, however it is 
> not so efficient when all matches are needed (because of the setup/teardown 
> overheads).
> It might be useful to introduce an indexesOf method that returns a BitSet 
> containing all the matches.
> This can then be used in the removeAllOccurrences methods.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (VFS-733) Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and DecoratedFileObject.refresh()

[Gary D. Gregory (Jira)]

[ 
https://issues.apache.org/jira/browse/VFS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947030#comment-16947030
 ] 

Gary D. Gregory commented on VFS-733:
-

[~falcod]

Oops, I forgot to enable that test indeed. Fixed!

Thank you!
Gary

> Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and 
> DecoratedFileObject.refresh()
> ---
>
> Key: VFS-733
> URL: https://issues.apache.org/jira/browse/VFS-733
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.2, 2.4, 2.3, 2.4.1
>Reporter: Falco
>Priority: Major
> Fix For: 2.5.0
>
>
> When using {{FileObject#exists}} and {{FileObject#getContent}} on a ZIP file 
> (in any order), the reference to the parent file system is set to {{null}}.
> {code}
> final FileObject zippedFile = new OnCallRefreshFileObject(fileInZip());
> assertNotNull(zippedFile.getFileSystem().getParentLayer());
> zippedFile.exists();
> zippedFile.getContent();
> assertNotNull(zippedFile.getFileSystem().getParentLayer()); // fails
> {code}
> For an executable example, refer to 
> [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/ZipParentLayerTest.java].
> I come to believe this does not work as intended. I'm also relatively 
> clueless about a potential fix or workaround. For me, this bug blocks 
> upgrading from VFS 2.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] garydgregory commented on issue #398: Add ComparableUtils

[GitBox]

garydgregory commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539584172
 
 
   It would be worth to see in this PR IMO but let's also try but let's keep it 
simple ;-)


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Work logged] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-696?focusedWorklogId=325138=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325138
 ]

ASF GitHub Bot logged work on LANG-696:
---

Author: ASF GitHub Bot
Created on: 08/Oct/19 15:46
Start Date: 08/Oct/19 15:46
Worklog Time Spent: 10m 
  Work Description: verhas commented on pull request #449: documentation 
related to the issue LANG-696
URL: https://github.com/apache/commons-lang/pull/449#discussion_r332590295
 
 

 ##
 File path: src/test/java/org/apache/commons/lang3/ClassUtilsTest.java
 ##
 @@ -513,20 +516,34 @@ public void test_getShortCanonicalName_Object() {
 
 @Test
 public void test_getShortCanonicalName_String() {
+assertEquals("", ClassUtils.getShortCanonicalName((String)null));
+assertEquals("Map.Entry", 
ClassUtils.getShortCanonicalName(java.util.Map.Entry.class.getName()));
+assertEquals("Entry", 
ClassUtils.getShortCanonicalName(java.util.Map.Entry.class.getCanonicalName()));
 assertEquals("ClassUtils", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtils"));
 assertEquals("ClassUtils[]", 
ClassUtils.getShortCanonicalName("[Lorg.apache.commons.lang3.ClassUtils;"));
 assertEquals("ClassUtils[][]", 
ClassUtils.getShortCanonicalName("[[Lorg.apache.commons.lang3.ClassUtils;"));
 assertEquals("ClassUtils[]", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtils[]"));
 assertEquals("ClassUtils[][]", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtils[][]"));
 assertEquals("int[]", ClassUtils.getShortCanonicalName("[I"));
+assertEquals("int[]", 
ClassUtils.getShortCanonicalName(int[].class.getCanonicalName()));
+assertEquals("int[]", 
ClassUtils.getShortCanonicalName(int[].class.getName()));
 assertEquals("int[][]", ClassUtils.getShortCanonicalName("[[I"));
 assertEquals("int[]", ClassUtils.getShortCanonicalName("int[]"));
 assertEquals("int[][]", ClassUtils.getShortCanonicalName("int[][]"));
 
-// Inner types
+// this is to demonstrate that the documentation and the naming of the 
methods
+// uses the class name and canonical name totally mixed up, which 
cannot be
+// fixed without backward compatibility break
+assertEquals("int[]", int[].class.getCanonicalName());
+assertEquals("[I", int[].class.getName());
+
+// Inner types... the problem is that these are not canonical names, 
classes with this name do not even have canonical name
 assertEquals("ClassUtilsTest.6", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtilsTest$6"));
 assertEquals("ClassUtilsTest.5Named", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtilsTest$5Named"));
 assertEquals("ClassUtilsTest.Inner", 
ClassUtils.getShortCanonicalName("org.apache.commons.lang3.ClassUtilsTest$Inner"));
+// demonstrating what a canonical name is... it is a bigger issue to 
clean this up
+assertEquals("org.apache.commons.lang3.ClassUtilsTest$10", new 
org.apache.commons.lang3.ClassUtilsTest(){}.getClass().getName());
 
 Review comment:
   done as requested
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325138)
Time Spent: 0.5h  (was: 20m)

> Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
> --
>
> Key: LANG-696
> URL: https://issues.apache.org/jira/browse/LANG-696
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 2.6
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: Discussion
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Added two null-safe ClassUtils.getSimpleName() APIs.
> -- Forwarded message --
> From: Gary Gregory 
> Date: Mon, Apr 11, 2011 at 10:18 AM
> Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName
> To: Commons Developers List 
> Hi All:
> Should we deprecate ClassUtils getShortClassName in favor of Class 
> getSimpleName?
> The behavior of getShortClassName is undocumented for arrays in the Javadoc 
> and is different from getSimpleName.
> When I replace the guts of getShortClassName to call getSimpleName, one test 
> fails:
> junit.framework.ComparisonFailure: null 
> 

[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=325131=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-325131
 ]

ASF GitHub Bot logged work on LANG-1480:


Author: ASF GitHub Bot
Created on: 08/Oct/19 15:33
Start Date: 08/Oct/19 15:33
Worklog Time Spent: 10m 
  Work Description: verhas commented on issue #446: LANG-1480 
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-539570658
 
 
   I changed the test class and methods to be public.
 

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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
---

Worklog Id: (was: 325131)
Remaining Estimate: 16h 20m  (was: 16.5h)
Time Spent: 7h 40m  (was: 7.5h)

> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Major
>   Original Estimate: 24h
>  Time Spent: 7h 40m
>  Remaining Estimate: 16h 20m
>
> In some cases, the algorithm decides incorrectly when to which package names 
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result 
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}} 
> (18 characters as requested). The reason for this is that the algorithm 
> starts from the right and goes to the left abbreviating the packages and 
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages 
> that would result in a too-long string without abbreviating the package name.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …

[GitBox]

verhas commented on issue #446: LANG-1480 getAbbreviatedName refactored to 
create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-539570658
 
 
   I changed the test class and methods to be public.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (VFS-733) Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and DecoratedFileObject.refresh()

[Falco (Jira)]

[ 
https://issues.apache.org/jira/browse/VFS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946978#comment-16946978
 ] 

Falco commented on VFS-733:
---

[~ggregory] Looks good to me. You may want to un-ignore 
{{org.apache.commons.vfs2.provider.zip.Jira733TestCase}}, it's passing now.

> Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and 
> DecoratedFileObject.refresh()
> ---
>
> Key: VFS-733
> URL: https://issues.apache.org/jira/browse/VFS-733
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.2, 2.4, 2.3, 2.4.1
>Reporter: Falco
>Priority: Major
> Fix For: 2.5.0
>
>
> When using {{FileObject#exists}} and {{FileObject#getContent}} on a ZIP file 
> (in any order), the reference to the parent file system is set to {{null}}.
> {code}
> final FileObject zippedFile = new OnCallRefreshFileObject(fileInZip());
> assertNotNull(zippedFile.getFileSystem().getParentLayer());
> zippedFile.exists();
> zippedFile.getContent();
> assertNotNull(zippedFile.getFileSystem().getParentLayer()); // fails
> {code}
> For an executable example, refer to 
> [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/ZipParentLayerTest.java].
> I come to believe this does not work as intended. I'm also relatively 
> clueless about a potential fix or workaround. For me, this bug blocks 
> upgrading from VFS 2.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (VFS-733) Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and DecoratedFileObject.refresh()

[Falco (Jira)]

 [ 
https://issues.apache.org/jira/browse/VFS-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Falco closed VFS-733.
-

> Parent layer of ZipFileSystem set to null through OnCallRefreshFileObject and 
> DecoratedFileObject.refresh()
> ---
>
> Key: VFS-733
> URL: https://issues.apache.org/jira/browse/VFS-733
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.2, 2.4, 2.3, 2.4.1
>Reporter: Falco
>Priority: Major
> Fix For: 2.5.0
>
>
> When using {{FileObject#exists}} and {{FileObject#getContent}} on a ZIP file 
> (in any order), the reference to the parent file system is set to {{null}}.
> {code}
> final FileObject zippedFile = new OnCallRefreshFileObject(fileInZip());
> assertNotNull(zippedFile.getFileSystem().getParentLayer());
> zippedFile.exists();
> zippedFile.getContent();
> assertNotNull(zippedFile.getFileSystem().getParentLayer()); // fails
> {code}
> For an executable example, refer to 
> [https://github.com/f4lco/vfs-repro/blob/master/src/test/java/vfs/ZipParentLayerTest.java].
> I come to believe this does not work as intended. I'm also relatively 
> clueless about a potential fix or workaround. For me, this bug blocks 
> upgrading from VFS 2.1.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (POOL-380) Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, int) in favor of KeyedObjectPool.addObjects(Collection, int).

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/POOL-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed POOL-380.

Fix Version/s: 2.8.0
   Resolution: Fixed

In git master.

> Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, int) in favor of 
> KeyedObjectPool.addObjects(Collection, int).
> --
>
> Key: POOL-380
> URL: https://issues.apache.org/jira/browse/POOL-380
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Deprecate {{PoolUtils.prefill(KeyedObjectPool, Collection, int)}} in favor of 
> {{KeyedObjectPool.addObjects(Collection, int)}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (POOL-380) Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, int) in favor of KeyedObjectPool.addObjects(Collection, int).

[Gary Gregory (Jira)]

Gary Gregory created POOL-380:
-

 Summary: Deprecate PoolUtils.prefill(KeyedObjectPool, Collection, 
int) in favor of KeyedObjectPool.addObjects(Collection, int).
 Key: POOL-380
 URL: https://issues.apache.org/jira/browse/POOL-380
 Project: Commons Pool
  Issue Type: Improvement
Reporter: Gary Gregory
Assignee: Gary Gregory


Deprecate {{PoolUtils.prefill(KeyedObjectPool, Collection, int)}} in favor of 
{{KeyedObjectPool.addObjects(Collection, int)}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (POOL-378) Deprecate PoolUtils.prefill(ObjectPool, int) in favor of ObjectPool.addObjects(int)

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/POOL-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory closed POOL-378.


> Deprecate PoolUtils.prefill(ObjectPool, int) in favor of 
> ObjectPool.addObjects(int)
> --
>
> Key: POOL-378
> URL: https://issues.apache.org/jira/browse/POOL-378
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.8.0
>
>
> Deprecate {{PoolUtils.prefill(ObjectPool, int)}} in favor of 
> {{ObjectPool.addObjects(int)}}
> Now that we've been on Java 8 for a while, we can use a default method on 
> {{ObjectPool}} to provide this functionality in a proper object-oriented 
> manner while keeping binary compatibility.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] Sam-Kruglov commented on issue #398: Add ComparableUtils

[GitBox]

Sam-Kruglov commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539544922
 
 
   No, I didn't, but now I did. 
   I see, good idea, we could definitely include `between` in there.
   I noticed, that the short names are used for returning `Predicate`. It is 
similar how in tests Hamcrest uses naming for returning `Matchers`. Do you 
think we should do that or also return `boolean`? I think we should return 
`Predicate` - can easily be used with `Stream#filter`


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (POOL-379) Deprecate PoolUtils.prefill(KeyedObjectPool, K, int) in favor of KeyedObjectPool.addObjects(K, int)

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/POOL-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory updated POOL-379:
-
Summary: Deprecate PoolUtils.prefill(KeyedObjectPool, K, int) in 
favor of KeyedObjectPool.addObjects(K, int)  (was: Depreacte 
PoolUtils.prefill(KeyedObjectPool, K, int) in favor of 
KeyedObjectPool.addObjects(K, int))

> Deprecate PoolUtils.prefill(KeyedObjectPool, K, int) in favor of 
> KeyedObjectPool.addObjects(K, int)
> -
>
> Key: POOL-379
> URL: https://issues.apache.org/jira/browse/POOL-379
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
>
> Depreacte {{PoolUtils.prefill(KeyedObjectPool, K, int)}} in favor of 
> {{KeyedObjectPool.addObjects(K, int)}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (POOL-379) Depreacte PoolUtils.prefill(KeyedObjectPool, K, int) in favor of KeyedObjectPool.addObjects(K, int)

[Gary D. Gregory (Jira)]

Gary D. Gregory created POOL-379:


 Summary: Depreacte PoolUtils.prefill(KeyedObjectPool, K, 
int) in favor of KeyedObjectPool.addObjects(K, int)
 Key: POOL-379
 URL: https://issues.apache.org/jira/browse/POOL-379
 Project: Commons Pool
  Issue Type: Improvement
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory


Depreacte {{PoolUtils.prefill(KeyedObjectPool, K, int)}} in favor of 
{{KeyedObjectPool.addObjects(K, int)}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (POOL-378) Deprecate PoolUtils.prefill(ObjectPool, int) in favor of ObjectPool.addObjects(int)

[Gary D. Gregory (Jira)]

 [ 
https://issues.apache.org/jira/browse/POOL-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary D. Gregory resolved POOL-378.
--
Fix Version/s: 2.7.1
   Resolution: Fixed

In git master.

> Deprecate PoolUtils.prefill(ObjectPool, int) in favor of 
> ObjectPool.addObjects(int)
> --
>
> Key: POOL-378
> URL: https://issues.apache.org/jira/browse/POOL-378
> Project: Commons Pool
>  Issue Type: Improvement
>Reporter: Gary D. Gregory
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.7.1
>
>
> Deprecate {{PoolUtils.prefill(ObjectPool, int)}} in favor of 
> {{ObjectPool.addObjects(int)}}
> Now that we've been on Java 8 for a while, we can use a default method on 
> {{ObjectPool}} to provide this functionality in a proper object-oriented 
> manner while keeping binary compatibility.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (POOL-378) Deprecate PoolUtils.prefill(ObjectPool, int) in favor of ObjectPool.addObjects(int)

[Gary D. Gregory (Jira)]

Gary D. Gregory created POOL-378:


 Summary: Deprecate PoolUtils.prefill(ObjectPool, int) in favor 
of ObjectPool.addObjects(int)
 Key: POOL-378
 URL: https://issues.apache.org/jira/browse/POOL-378
 Project: Commons Pool
  Issue Type: Improvement
Reporter: Gary D. Gregory
Assignee: Gary D. Gregory


Deprecate {{PoolUtils.prefill(ObjectPool, int)}} in favor of 
{{ObjectPool.addObjects(int)}}

Now that we've been on Java 8 for a while, we can use a default method on 
{{ObjectPool}} to provide this functionality in a proper object-oriented manner 
while keeping binary compatibility.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] garydgregory commented on issue #398: Add ComparableUtils

[GitBox]

garydgregory commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539517708
 
 
   @Sam-Kruglov, 
   
   Did you look at CriteriaBuilder? I am not arguing about not one style over 
the other, CriteriaBuilder offers both.
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-lang] Sam-Kruglov commented on issue #398: Add ComparableUtils

[GitBox]

Sam-Kruglov commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539504653
 
 
   I like fully written names more. We can take inspiration from AssertJ :D 
http://joel-costigliola.github.io/assertj/core/api/index.html?org/assertj/core/internal/Comparables.html
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-lang] garydgregory commented on issue #398: Add ComparableUtils

[GitBox]

garydgregory commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539491520
 
 
   This now reminds me of JPA's 
[`CriteriaBuilder`](https://docs.oracle.com/javaee/7/api/javax/persistence/criteria/CriteriaBuilder.html)
 and the work I did writing [_Java Persistence with Hibernate, Second 
Edition_](https://www.manning.com/books/java-persistence-with-hibernate-second-edition)
 where `CriteriaBuilder` includes shorthand methods like `le` for 
`lessThanOrEqualTo`, `lt` for `lessThan`, and so on. We should not implement 
`CriteriaBuilder` of course but rather get inspiration from it.
   
   Thoughts?
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (COMPRESS-495) Zip Slip in SevenZ CLI

[Stefan Bodewig (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated COMPRESS-495:

Labels: 7zip  (was: )

> Zip Slip in SevenZ CLI
> --
>
> Key: COMPRESS-495
> URL: https://issues.apache.org/jira/browse/COMPRESS-495
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Reporter: Gabor Molnar
>Priority: Major
>  Labels: 7zip
> Fix For: 1.20
>
>
> The SevenZ decompressor doesn't check that the file to be extracted is 
> escaping the current directory or not.
> Vulnerable code: 
> [https://github.com/apache/commons-compress/blob/26b78cecfc1ca0e5daf03109b2c441f960bde678/src/main/java/org/apache/commons/compress/archivers/sevenz/CLI.java#L67]
> In another place in the repository, there is a safe implementation that was 
> added as an example when the Zip Slip vulnerability was originally published: 
> https://github.com/apache/commons-compress/blob/1a14a23a05f7104e3d41a25a0f7e78ae1556285e/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L308



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] coveralls edited a comment on issue #398: Add ComparableUtils

[GitBox]

coveralls edited a comment on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455218326
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/26178825/badge)](https://coveralls.io/builds/26178825)
   
   Coverage increased (+0.02%) to 95.206% when pulling 
**c7870caec7f20965f1424ec2f05aea8a9d237569 on 
Sam-Kruglov:LANG-1431-ComparableUtils** into 
**84636da76941dc5b83a8bc3ac7baca5583eb48e9 on apache:master**.
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (COMPRESS-495) Zip Slip in SevenZ CLI

[Stefan Bodewig (Jira)]

 [ 
https://issues.apache.org/jira/browse/COMPRESS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Bodewig updated COMPRESS-495:

Fix Version/s: 1.20

> Zip Slip in SevenZ CLI
> --
>
> Key: COMPRESS-495
> URL: https://issues.apache.org/jira/browse/COMPRESS-495
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Reporter: Gabor Molnar
>Priority: Major
> Fix For: 1.20
>
>
> The SevenZ decompressor doesn't check that the file to be extracted is 
> escaping the current directory or not.
> Vulnerable code: 
> [https://github.com/apache/commons-compress/blob/26b78cecfc1ca0e5daf03109b2c441f960bde678/src/main/java/org/apache/commons/compress/archivers/sevenz/CLI.java#L67]
> In another place in the repository, there is a safe implementation that was 
> added as an example when the Zip Slip vulnerability was originally published: 
> https://github.com/apache/commons-compress/blob/1a14a23a05f7104e3d41a25a0f7e78ae1556285e/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L308



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (COMPRESS-495) Zip Slip in SevenZ CLI

[Stefan Bodewig (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946774#comment-16946774
 ] 

Stefan Bodewig commented on COMPRESS-495:
-

Thanks Gabor, you are certainly correct. We somehow forgot about that class 
when we dealt with the initial Zip Slip report.

 

Fortunately this class is very unlikely to be used by anybody, but we should - 
and will - certainly fix it.

> Zip Slip in SevenZ CLI
> --
>
> Key: COMPRESS-495
> URL: https://issues.apache.org/jira/browse/COMPRESS-495
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Reporter: Gabor Molnar
>Priority: Major
>
> The SevenZ decompressor doesn't check that the file to be extracted is 
> escaping the current directory or not.
> Vulnerable code: 
> [https://github.com/apache/commons-compress/blob/26b78cecfc1ca0e5daf03109b2c441f960bde678/src/main/java/org/apache/commons/compress/archivers/sevenz/CLI.java#L67]
> In another place in the repository, there is a safe implementation that was 
> added as an example when the Zip Slip vulnerability was originally published: 
> https://github.com/apache/commons-compress/blob/1a14a23a05f7104e3d41a25a0f7e78ae1556285e/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L308



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-lang] Sam-Kruglov commented on issue #398: Add ComparableUtils

[GitBox]

Sam-Kruglov commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-539475710
 
 
   I am back with a private constructor for the main class and a `public` 
modifier for the test!


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (COMPRESS-495) Zip Slip in SevenZ CLI

[Gabor Molnar (Jira)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946555#comment-16946555
 ] 

Gabor Molnar commented on COMPRESS-495:
---

See also this report from the Semmle static analysis tool: 
[https://lgtm.com/projects/g/apache/commons-compress?mode=list=java%2Fzipslip]

> Zip Slip in SevenZ CLI
> --
>
> Key: COMPRESS-495
> URL: https://issues.apache.org/jira/browse/COMPRESS-495
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Reporter: Gabor Molnar
>Priority: Major
>
> The SevenZ decompressor doesn't check that the file to be extracted is 
> escaping the current directory or not.
> Vulnerable code: 
> [https://github.com/apache/commons-compress/blob/26b78cecfc1ca0e5daf03109b2c441f960bde678/src/main/java/org/apache/commons/compress/archivers/sevenz/CLI.java#L67]
> In another place in the repository, there is a safe implementation that was 
> added as an example when the Zip Slip vulnerability was originally published: 
> https://github.com/apache/commons-compress/blob/1a14a23a05f7104e3d41a25a0f7e78ae1556285e/src/main/java/org/apache/commons/compress/archivers/examples/Expander.java#L308



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [commons-io] jochenw commented on issue #31: DirectoryUtils - isEqual to compare directories

[GitBox]

jochenw commented on issue #31: DirectoryUtils - isEqual to compare directories
URL: https://github.com/apache/commons-io/pull/31#issuecomment-539364025
 
 
   Besides, rather than simply returning a boolean value, I'd hope for an event 
API, like
   
   public interface DirCompareListener {
   /**
* Called, if a file has been detected in the first directory, 
which is missing in the second.
* In other words, the difference can be remedied by copying the 
file from the first
* directory to the second.
* @param pFirstDir First directory being compared (root 
directory); the directory, where
*   a file has been found, which is 
not present in the second directory.
* @param pSecondDir Second directory being compared (root 
directory); the directory, 
*   where a file is missing.
* @param pFile Path pf the additional file, relative to the 
root directory.
*/
public void fileAdded(Path pFirstDir, Path pSecondDir, String 
pFileName);
   }
   /** Method, which compares two directories by iterating over the 
files in the first directory,
 * checking, whether they are present (and identical) in the second 
directory, and vice versa.
 * Upon detection of differences, a suitable method of the listener 
is being invoked.
 */
   public void compareDirectories(Path pFirstDir, Path pSecondDir, 
DirCompareListener pListener);
   /** Method, which compares two directories by iterating over the 
files in the first directory,
 * checking, whether they are present (and identical) in the second 
directory, and vice versa.
 * Upon detection of differences, the value false is being 
returned, otherwise returns true.
 */
   public boolean compareDirectories(Path pFirstDir, Path pSecondDir) {
   final DirCompareListener listener = new DirCompareListener(){
public void fileAdded(Path pFirstDir, Path pSecondDir, 
pFileName) {
throw new IllegalPathStateException();
}
   };
   try {
 compare(pFirstDir, pSecondDir, listener);
 return true;
   } catch (IllegalPathStateException e) {
 return false;
   }
  }
  


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [commons-io] jochenw commented on issue #31: DirectoryUtils - isEqual to compare directories

[GitBox]

jochenw commented on issue #31: DirectoryUtils - isEqual to compare directories
URL: https://github.com/apache/commons-io/pull/31#issuecomment-539357820
 
 
   What is the use case? I can hardly imagine a case, where I would want to 
compare directories. If I need equality, then I'd rather create a copy in a 
temporary directory.
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services