[jira] [Commented] (CLI-337) Parse arguments in a single string
[ https://issues.apache.org/jira/browse/CLI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878025#comment-17878025 ] Michael Osipov commented on CLI-337: I don't understand the purpose of this request. Everything is working fine in Maven and Maven processes one arg per line and passes that one to CLI. All good. > Parse arguments in a single string > -- > > Key: CLI-337 > URL: https://issues.apache.org/jira/browse/CLI-337 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.9.0 >Reporter: Hüseyin Kartal >Priority: Major > > Apache Maven uses apache-cli to parse args. But maven also supports passing > conf file which contains these args. To handle that they do the splitting of > file content to args[] and pass this to cli. > Please provide a parser for single string to args[] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CLI-337) Parse arguments in a single string
[ https://issues.apache.org/jira/browse/CLI-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated CLI-337: --- Fix Version/s: (was: 2.0) > Parse arguments in a single string > -- > > Key: CLI-337 > URL: https://issues.apache.org/jira/browse/CLI-337 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.9.0 >Reporter: Hüseyin Kartal >Priority: Major > > Apache Maven uses apache-cli to parse args. But maven also supports passing > conf file which contains these args. To handle that they do the splitting of > file content to args[] and pass this to cli. > Please provide a parser for single string to args[] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-854) SoftRefFilesCache logs password when FS is closed
[
https://issues.apache.org/jira/browse/VFS-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17850081#comment-17850081
]
Michael Osipov commented on VFS-854:
Well, it does log the URL, not the password. You should maybe provide the creds
separately. Using auth info is deprecated in recent RFCs.
> SoftRefFilesCache logs password when FS is closed
> -
>
> Key: VFS-854
> URL: https://issues.apache.org/jira/browse/VFS-854
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Andrey Turbanov
>Priority: Major
>
> We use DEBUG logging enabled for VFS to diagnose integration problems with
> external connections.
> Unfortunately it leads to logging of clear text password in logs if use basic
> auth with SFTP/HTTP4S connectors
> {noformat}
> D 240526 060013.993 [ScheduledIpfSynchronizer_Worker-1] SoftRefFilesCache -
> Close FileSystem: http4s://mylogin:mypassw...@my.company.com:8443/
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-464) struct sigaction function pointer causes build failures on LLVM 15+
[
https://issues.apache.org/jira/browse/DAEMON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DAEMON-464:
--
Fix Version/s: 1.4.0
> struct sigaction function pointer causes build failures on LLVM 15+
> ---
>
> Key: DAEMON-464
> URL: https://issues.apache.org/jira/browse/DAEMON-464
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.0
>
>
> Issue on FreeBSD and macOS:
> {noformat}
> svc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (DAEMON-464) struct sigaction function pointer causes build failures on LLVM 15+
[
https://issues.apache.org/jira/browse/DAEMON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened DAEMON-464:
---
This issue was created on purpose to document that the issue is not macOS
specific but appear everywhere with LLVM 15+.
> struct sigaction function pointer causes build failures on LLVM 15+
> ---
>
> Key: DAEMON-464
> URL: https://issues.apache.org/jira/browse/DAEMON-464
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Issue on FreeBSD and macOS:
> {noformat}
> svc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17846213#comment-17846213
]
Michael Osipov commented on DAEMON-463:
---
FYI: https://github.com/apache/commons-daemon/pull/170
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.0
>
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-464) struct sigaction function pointer causes build failures on LLVM 15+
[
https://issues.apache.org/jira/browse/DAEMON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DAEMON-464:
--
Summary: struct sigaction function pointer causes build failures on LLVM
15+ (was: struct sigaction function pointer causes build failure on LLVM 15+)
> struct sigaction function pointer causes build failures on LLVM 15+
> ---
>
> Key: DAEMON-464
> URL: https://issues.apache.org/jira/browse/DAEMON-464
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.0
>
>
> Issue on FreeBSD and macOS:
> {noformat}
> svc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DAEMON-464) struct sigaction function pointer causes build failure on LLVM 15+
Michael Osipov created DAEMON-464:
-
Summary: struct sigaction function pointer causes build failure on
LLVM 15+
Key: DAEMON-464
URL: https://issues.apache.org/jira/browse/DAEMON-464
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.3.4
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 1.4.0
Issue on FreeBSD and macOS:
{noformat}
svc-unix.c:1311:20: error: incompatible function pointer types assigning to
'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int, struct
__siginfo *, void *)') [-Wincompatible-function-pointer-types]90
act.sa_handler = controller;91 ^ ~~
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DAEMON-463:
--
Assignee: Michael Osipov
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Assignee: Michael Osipov
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DAEMON-463:
--
Fix Version/s: 1.3.5
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.3.5
>
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845282#comment-17845282
]
Michael Osipov commented on DAEMON-463:
---
Looking at the definition of {{siginfo_t}} from
https://pubs.opengroup.org/onlinepubs/009696699/basedefs/signal.h.html we
already use {{si_pid}} from the extended runtime code, so maybe it is already
safe to use it?
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845281#comment-17845281
]
Michael Osipov commented on DAEMON-463:
---
This does work:
{noformat}
$ git diff
diff --git a/src/native/unix/native/jsvc-unix.c
b/src/native/unix/native/jsvc-unix.c
index e331a0f..187e404 100644
--- a/src/native/unix/native/jsvc-unix.c
+++ b/src/native/unix/native/jsvc-unix.c
@@ -1308,7 +1308,7 @@ static int run_controller(arg_data *args, home_data
*data, uid_t uid, gid_t gid)
* These will be replaced in the child process.
*/
memset(&act, '\0', sizeof(act));
-act.sa_handler = controller;
+act.sa_sigaction = controller;
sigemptyset(&act.sa_mask);
act.sa_flags = SA_RESTART | SA_NOCLDSTOP | SA_SIGINFO;
{noformat}
but I have no clue how to test/comply with: If the SA_SIGINFO flag is set in
the sa_flags field, and the implementation supports the Realtime Signals
Extension option or the XSI Extension option, the sa_sigaction field specifies
a signal-catching function. [Option End]
from https://pubs.opengroup.org/onlinepubs/009696699/functions/sigaction.html
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845280#comment-17845280
]
Michael Osipov commented on DAEMON-463:
---
Temporary fix:
https://github.com/freebsd/freebsd-ports/blob/e8c3e827f61838b8bd8509e3d4a6d39dfbadfdd1/devel/apache-commons-daemon/Makefile#L32-L34
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845279#comment-17845279
]
Michael Osipov commented on DAEMON-463:
---
I can confirm the issue on:
{noformat}
$ make
(cd native; make all)
cc -g -O2 -DOS_FREEBSD -DDSO_DLFCN -D_THREAD_SAFE -pthread -DCPU=\"amd64\"
-Wall -Wstrict-prototypes -I/usr/local/openjdk8/include
-I/usr/local/openjdk8/include/freebsd -c jsvc-unix.c -o jsvc-unix.o
jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int, struct
__siginfo *, void *)') [-Wincompatible-function-pointer-types]
1311 | act.sa_handler = controller;
|^ ~~
1 error generated.
*** Error code 1
Stop.
make[1]: stopped in /tmp/commons-daemon/src/native/unix/native
*** Error code 1
Stop.
make: stopped in /tmp/commons-daemon/src/native/unix
osipovmi@deblndw011x:/tmp/commons-daemon/src/native/unix (master =)
$ cc --version
FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git
llvmorg-17.0.6-0-g6009708b4367)
Target: x86_64-unknown-freebsd13.3
Thread model: posix
InstalledDir: /usr/bin
{noformat}
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17845278#comment-17845278
]
Michael Osipov commented on DAEMON-463:
---
What is the LLVM version here?
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[ https://issues.apache.org/jira/browse/DAEMON-463 ]
Michael Osipov deleted comment on DAEMON-463:
---
was (Author: michael-o):
What is the LLVM version here?
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Priority: Major
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-845) DatabaseConfiguration loses list property's order
[
https://issues.apache.org/jira/browse/CONFIGURATION-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated CONFIGURATION-845:
-
Description:
{code:java}
private static final String SQL_GET_PROPERTY = "SELECT * FROM %s WHERE %s =?";
{code}
This is the query DatabaseConfiguration executes to get a property's values.
It assumes the order will be insertion order but this is not true on postgresql.
So configuration.getList(key) loses the order of the list.
was:
{code:java}
private static final String SQL_GET_PROPERTY = "SELECT * FROM %s WHERE %s =?";
{code}
This is the query DatabaseConfiguration executes to get a property's values.
It assumes the order will be insertion order but this is not true on postgresql.
So configuration.getList(key) looses the order of the list.
> DatabaseConfiguration loses list property's order
> -
>
> Key: CONFIGURATION-845
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-845
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: pieter martin
>Priority: Major
>
> {code:java}
> private static final String SQL_GET_PROPERTY = "SELECT * FROM %s WHERE %s =?";
> {code}
> This is the query DatabaseConfiguration executes to get a property's values.
> It assumes the order will be insertion order but this is not true on
> postgresql.
> So configuration.getList(key) loses the order of the list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-845) DatabaseConfiguration loses list property's order
[
https://issues.apache.org/jira/browse/CONFIGURATION-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated CONFIGURATION-845:
-
Summary: DatabaseConfiguration loses list property's order (was:
DatabaseConfiguration looses list property's order)
> DatabaseConfiguration loses list property's order
> -
>
> Key: CONFIGURATION-845
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-845
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.10.1
>Reporter: pieter martin
>Priority: Major
>
> {code:java}
> private static final String SQL_GET_PROPERTY = "SELECT * FROM %s WHERE %s =?";
> {code}
> This is the query DatabaseConfiguration executes to get a property's values.
> It assumes the order will be insertion order but this is not true on
> postgresql.
> So configuration.getList(key) looses the order of the list.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (VALIDATOR-487) EmailValidator insufficiently strict ("internationalized addresses" always pass as valid)
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VALIDATOR-487:
-
Summary: EmailValidator insufficiently strict ("internationalized
addresses" always pass as valid) (was: EmailValidator considers non-ASCII
characters valid, assuming RFC 6530 (Internationalized Email))
> EmailValidator insufficiently strict ("internationalized addresses" always
> pass as valid)
> -
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6, 1.8.0
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (VALIDATOR-487) EmailValidator considers non-ASCII characters valid, assuming RFC 6530 (Internationalized Email)
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VALIDATOR-487:
-
Affects Version/s: 1.8.0
> EmailValidator considers non-ASCII characters valid, assuming RFC 6530
> (Internationalized Email)
>
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6, 1.8.0
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (VALIDATOR-487) EmailValidator considers non-ASCII characters valid, assuming RFC 6530 (Internationalized Email)
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VALIDATOR-487:
-
Summary: EmailValidator considers non-ASCII characters valid, assuming RFC
6530 (Internationalized Email) (was: EmailValidator validates too much)
> EmailValidator considers non-ASCII characters valid, assuming RFC 6530
> (Internationalized Email)
>
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Deleted] (COMPRESS-672) Commons-compress 1.26.0 is failing to compress files/directories
[
https://issues.apache.org/jira/browse/COMPRESS-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov deleted COMPRESS-672:
> Commons-compress 1.26.0 is failing to compress files/directories
>
>
> Key: COMPRESS-672
> URL: https://issues.apache.org/jira/browse/COMPRESS-672
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Santhosh Kumar K
>Priority: Major
>
> We are using commons-compress to compress files and with latest 1.26.0 we are
> getting the following exception where in it was working fine with 1.24.0
> {*}API being used:{*}ArchiveOutputStream jos = new ArchiveStreamFactory()
> .createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> Files.newOutputStream(WrapperFactory.getNioServiceWrapper().getPath(jarName)));
> *Stack trace:*
> [Feb 28, 2024 5:42:32 PM] [INFO] Stack Description:
> java.lang.RuntimeException: ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.getZipEncoding(ZipEncodingHelper.java:69)
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.(ZipEncodingHelper.java:37)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.(ZipArchiveOutputStream.java:331)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:516)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:498)
> at
> oracle.opatch.ZipUtilities.compressZip(ZipUtilities.java:306)
> at
> oracle.opatch.opatchactions.DeleteAction.backupForRollback(DeleteAction.java:1262)
> at
> oracle.opatch.PatchObject.backupForRollback(PatchObject.java:5492)
> at
> oracle.opatch.ApplySession.processLocal(ApplySession.java:4027)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4989)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4842)
> at
> oracle.opatch.OPatchACL.processApply(OPatchACL.java:310)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1469)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
> at
> oracle.opatch.opatchutil.NApply.process(NApply.java:353)
> at
> oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.lang.reflect.Method.invoke(Method.java:498)
> at
> oracle.opatch.UtilSession.process(UtilSession.java:355)
> at
> oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
> at
> oracle.opatch.OPatch.process(OPatch.java:873)
> at
> oracle.opatch.OPatch.main(OPatch.java:930)
> Caused by: java.lang.RuntimeException:
> ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:359)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:351)
>
[jira] [Updated] (COMMONSSITE-170) Commons-compress 1.26.0 is failing to compress files/directories
[
https://issues.apache.org/jira/browse/COMMONSSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMMONSSITE-170:
---
Summary: Commons-compress 1.26.0 is failing to compress files/directories
(was: Commons-compress 1.26.0 is failing to compress files\directories)
> Commons-compress 1.26.0 is failing to compress files/directories
> -
>
> Key: COMMONSSITE-170
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-170
> Project: Apache Commons All
> Issue Type: Bug
>Reporter: Santhosh Kumar K
>Priority: Major
>
> We are using commons-compress to compress files and with latest 1.26.0 we are
> getting the following exception where in it was working fine with 1.24.0
> {*}API being used:{*}ArchiveOutputStream jos = new ArchiveStreamFactory()
> .createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> Files.newOutputStream(WrapperFactory.getNioServiceWrapper().getPath(jarName)));
> *Stack trace:*
> [Feb 28, 2024 5:42:32 PM] [INFO] Stack Description:
> java.lang.RuntimeException: ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.getZipEncoding(ZipEncodingHelper.java:69)
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.(ZipEncodingHelper.java:37)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.(ZipArchiveOutputStream.java:331)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:516)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:498)
> at
> oracle.opatch.ZipUtilities.compressZip(ZipUtilities.java:306)
> at
> oracle.opatch.opatchactions.DeleteAction.backupForRollback(DeleteAction.java:1262)
> at
> oracle.opatch.PatchObject.backupForRollback(PatchObject.java:5492)
> at
> oracle.opatch.ApplySession.processLocal(ApplySession.java:4027)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4989)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4842)
> at
> oracle.opatch.OPatchACL.processApply(OPatchACL.java:310)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1469)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
> at
> oracle.opatch.opatchutil.NApply.process(NApply.java:353)
> at
> oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.lang.reflect.Method.invoke(Method.java:498)
> at
> oracle.opatch.UtilSession.process(UtilSession.java:355)
> at
> oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
> at
> oracle.opatch.OPatch.process(OPatch.java:873)
> at
> oracle.opatch.OPatch.main(OPatch.java:930)
> Caused by: java.lang.RuntimeException:
> ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at
> sun.misc.Launcher$AppCla
[jira] [Commented] (COMMONSSITE-170) Commons-compress 1.26.0 is failing to compress files/directories
[
https://issues.apache.org/jira/browse/COMMONSSITE-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17826959#comment-17826959
]
Michael Osipov commented on COMMONSSITE-170:
I consider this as invalid since you need to raise a bug with Oracle regarding
OPatch. It is their duty to fix their software.
> Commons-compress 1.26.0 is failing to compress files/directories
> -
>
> Key: COMMONSSITE-170
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-170
> Project: Apache Commons All
> Issue Type: Bug
>Reporter: Santhosh Kumar K
>Priority: Major
>
> We are using commons-compress to compress files and with latest 1.26.0 we are
> getting the following exception where in it was working fine with 1.24.0
> {*}API being used:{*}ArchiveOutputStream jos = new ArchiveStreamFactory()
> .createArchiveOutputStream(ArchiveStreamFactory.ZIP,
> Files.newOutputStream(WrapperFactory.getNioServiceWrapper().getPath(jarName)));
> *Stack trace:*
> [Feb 28, 2024 5:42:32 PM] [INFO] Stack Description:
> java.lang.RuntimeException: ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.getZipEncoding(ZipEncodingHelper.java:69)
> at
> org.apache.commons.compress.archivers.zip.ZipEncodingHelper.(ZipEncodingHelper.java:37)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream.(ZipArchiveOutputStream.java:331)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:516)
> at
> org.apache.commons.compress.archivers.ArchiveStreamFactory.createArchiveOutputStream(ArchiveStreamFactory.java:498)
> at
> oracle.opatch.ZipUtilities.compressZip(ZipUtilities.java:306)
> at
> oracle.opatch.opatchactions.DeleteAction.backupForRollback(DeleteAction.java:1262)
> at
> oracle.opatch.PatchObject.backupForRollback(PatchObject.java:5492)
> at
> oracle.opatch.ApplySession.processLocal(ApplySession.java:4027)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4989)
> at
> oracle.opatch.ApplySession.process(ApplySession.java:4842)
> at
> oracle.opatch.OPatchACL.processApply(OPatchACL.java:310)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:1469)
> at
> oracle.opatch.opatchutil.NApply.legacy_process(NApply.java:373)
> at
> oracle.opatch.opatchutil.NApply.process(NApply.java:353)
> at
> oracle.opatch.opatchutil.OUSession.napply(OUSession.java:1139)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.lang.reflect.Method.invoke(Method.java:498)
> at
> oracle.opatch.UtilSession.process(UtilSession.java:355)
> at
> oracle.opatch.OPatchSession.process(OPatchSession.java:2640)
> at
> oracle.opatch.OPatch.process(OPatch.java:873)
> at
> oracle.opatch.OPatch.main(OPatch.java:930)
> Caused by: java.lang.RuntimeException:
> ApplySession failed but Oracle Home has not been
> modified.org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.NoClassDefFoundError: org/apache/commons/io/Charsets
> ... 24 more
> Caused by:
> java.lang.ClassNotFoundException: org.apache.commons.io.Charsets
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at
> java.lang.ClassLoader.loadClass(ClassLoader.java:418)
>
[jira] [Commented] (COMPRESS-669) Allow usage of non-Pack200 features without Commons Lang 3
[ https://issues.apache.org/jira/browse/COMPRESS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824126#comment-17824126 ] Michael Osipov commented on COMPRESS-669: - I agree with Gary > Allow usage of non-Pack200 features without Commons Lang 3 > -- > > Key: COMPRESS-669 > URL: https://issues.apache.org/jira/browse/COMPRESS-669 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.26.0 >Reporter: Basil Crow >Priority: Major > > Commons Compress 1.26.0 has sprouted a dependency on Commons Lang 3, which is > problematic for the Jenkins project, which wishes to use Commons Compress in > Jenkins core without exposing Commons Lang 3 to all Jenkins plugins. > The Commons Lang 3 dependency is only used in Pack200 features, which we > don't care about, so in [https://github.com/jenkinsci/jenkins/pull/8997] we > have excluded the dependency. But this is merely a short-term solution, > because this places the burden on consumers to monitor future updates to > ensure that Commons Compress doesn't start relying on Commons Lang 3 for > features other than Pack200. > Some ideas for long-term solutions: > * Find a way to do without the runtime dependency on Commons Lang 3 and turn > the dependency back into a test-scoped dependency. > * Make the Commons Lang 3 dependency optional as in > [https://github.com/apache/commons-compress/pull/489] which was rejected > without any reasoning other than "We are moving away from using Maven > optional dependencies." > * [https://github.com/apache/commons-compress/pull/490] proposes to > modularize Commons Compress, which would solve this problem more generally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-669) Allow usage of non-Pack200 features without Commons Lang 3
[ https://issues.apache.org/jira/browse/COMPRESS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823355#comment-17823355 ] Michael Osipov commented on COMPRESS-669: - Nope, but as said if the code isn't too complex it could be inlined and problem solved. I'd be willing to review a PR > Allow usage of non-Pack200 features without Commons Lang 3 > -- > > Key: COMPRESS-669 > URL: https://issues.apache.org/jira/browse/COMPRESS-669 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.26.0 >Reporter: Basil Crow >Priority: Major > > Commons Compress 1.26.0 has sprouted a dependency on Commons Lang 3, which is > problematic for the Jenkins project, which wishes to use Commons Compress in > Jenkins core without exposing Commons Lang 3 to all Jenkins plugins. > The Commons Lang 3 dependency is only used in Pack200 features, which we > don't care about, so in [https://github.com/jenkinsci/jenkins/pull/8997] we > have excluded the dependency. But this is merely a short-term solution, > because this places the burden on consumers to monitor future updates to > ensure that Commons Compress doesn't start relying on Commons Lang 3 for > features other than Pack200. > Some ideas for long-term solutions: > * Find a way to do without the runtime dependency on Commons Lang 3 and turn > the dependency back into a test-scoped dependency. > * Make the Commons Lang 3 dependency optional as in > [https://github.com/apache/commons-compress/pull/489] which was rejected > without any reasoning other than "We are moving away from using Maven > optional dependencies." > * [https://github.com/apache/commons-compress/pull/490] proposes to > modularize Commons Compress, which would solve this problem more generally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-669) Allow usage of non-Pack200 features without Commons Lang 3
[ https://issues.apache.org/jira/browse/COMPRESS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823347#comment-17823347 ] Michael Osipov commented on COMPRESS-669: - Have you tried to change that spot? > Allow usage of non-Pack200 features without Commons Lang 3 > -- > > Key: COMPRESS-669 > URL: https://issues.apache.org/jira/browse/COMPRESS-669 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.26.0 >Reporter: Basil Crow >Priority: Major > > Commons Compress 1.26.0 has sprouted a dependency on Commons Lang 3, which is > problematic for the Jenkins project, which wishes to use Commons Compress in > Jenkins core without exposing Commons Lang 3 to all Jenkins plugins. > The Commons Lang 3 dependency is only used in Pack200 features, which we > don't care about, so in [https://github.com/jenkinsci/jenkins/pull/8997] we > have excluded the dependency. But this is merely a short-term solution, > because this places the burden on consumers to monitor future updates to > ensure that Commons Compress doesn't start relying on Commons Lang 3 for > features other than Pack200. > Some ideas for long-term solutions: > * Find a way to do without the runtime dependency on Commons Lang 3 and turn > the dependency back into a test-scoped dependency. > * Make the Commons Lang 3 dependency optional as in > [https://github.com/apache/commons-compress/pull/489] which was rejected > without any reasoning other than "We are moving away from using Maven > optional dependencies." > * [https://github.com/apache/commons-compress/pull/490] proposes to > modularize Commons Compress, which would solve this problem more generally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-669) Allow usage of non-Pack200 features without Commons Lang 3
[ https://issues.apache.org/jira/browse/COMPRESS-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17823310#comment-17823310 ] Michael Osipov commented on COMPRESS-669: - Are we talking about: https://github.com/apache/commons-compress/blob/10a5787cc0aa89f4036e5f1af1aa3c04f673f466/src/main/java/org/apache/commons/compress/harmony/unpack200/Pack200UnpackerAdapter.java#L123? I guess if it is only this one the code could be imported and Commons Lang 3 moved to a test scope dependency. > Allow usage of non-Pack200 features without Commons Lang 3 > -- > > Key: COMPRESS-669 > URL: https://issues.apache.org/jira/browse/COMPRESS-669 > Project: Commons Compress > Issue Type: Bug >Affects Versions: 1.26.0 >Reporter: Basil Crow >Priority: Major > > Commons Compress 1.26.0 has sprouted a dependency on Commons Lang 3, which is > problematic for the Jenkins project, which wishes to use Commons Compress in > Jenkins core without exposing Commons Lang 3 to all Jenkins plugins. > The Commons Lang 3 dependency is only used in Pack200 features, which we > don't care about, so in [https://github.com/jenkinsci/jenkins/pull/8997] we > have excluded the dependency. But this is merely a short-term solution, > because this places the burden on consumers to monitor future updates to > ensure that Commons Compress doesn't start relying on Commons Lang 3 for > features other than Pack200. > Some ideas for long-term solutions: > * Find a way to do without the runtime dependency on Commons Lang 3 and turn > the dependency back into a test-scoped dependency. > * Make the Commons Lang 3 dependency optional as in > [https://github.com/apache/commons-compress/pull/489] which was rejected > without any reasoning other than "We are moving away from using Maven > optional dependencies." > * [https://github.com/apache/commons-compress/pull/490] proposes to > modularize Commons Compress, which would solve this problem more generally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (COMPRESS-663) How Are Vulnerabilities Fixed?
[ https://issues.apache.org/jira/browse/COMPRESS-663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed COMPRESS-663. --- Resolution: Invalid This isn't a forum. Direct it to the dev mailing list. > How Are Vulnerabilities Fixed? > -- > > Key: COMPRESS-663 > URL: https://issues.apache.org/jira/browse/COMPRESS-663 > Project: Commons Compress > Issue Type: Wish >Reporter: Radar wen >Priority: Major > > CVE-2024-25710 and CVE-2024-26308 > Can you tell me how the two vulnerabilities are fixed? Or, which submission > record is corresponding to? Which code block is affected? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COMPRESS-660) OSGi Manifest requires optional dependency commons-codec
[ https://issues.apache.org/jira/browse/COMPRESS-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated COMPRESS-660: Summary: OSGi Manifest requires optional dependency commons-codec (was: OSGi Manifest requires optional maven dependency commons-codes) > OSGi Manifest requires optional dependency commons-codec > > > Key: COMPRESS-660 > URL: https://issues.apache.org/jira/browse/COMPRESS-660 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.26.0 >Reporter: Christoph Loy >Priority: Major > > Since version 1.26, commons-compress *optionally* [requires > commons-codec|https://github.com/apache/commons-compress/blob/09a271dfd73e3ce01815f3f65057f92b5b7009bb/pom.xml#L134]. > In the OSGi-Manifest, the Import-Package declaration for > org.apache.commons.codec does not have the resolution:=optional attribute. > > In our case, we have commons-compress as maven dependency. Since > commons-codec is an optional dependency, it is not downloaded automatically. > But when we start our application, we get an OSGi error that commons-codec > cannot be resolved. > > > To fix this issue, the Import-Package delcaration to all > apache.commons.compress packages has to be marked with resolution:=optional > in META-INF/MANIFEST.MF. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (LANG-1728) Deprecate EventListenerSupport
[ https://issues.apache.org/jira/browse/LANG-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1728: - Summary: Deprecate EventListenerSupport (was: Deprecate EvewntListenerSupport) > Deprecate EventListenerSupport > -- > > Key: LANG-1728 > URL: https://issues.apache.org/jira/browse/LANG-1728 > Project: Commons Lang > Issue Type: Improvement > Components: lang.event.* >Reporter: Elliotte Rusty Harold >Priority: Major > > As far as I can tell, despite the name it has nothing to do with event > listeners. It simply allows one to sequentially invoke the same method on > each member of a list of objects of the same type. There are other ways to do > that, including lambdas and executors. > This was added circa Java 5/2010 and doesn't fill any particular holes in > 2024. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804291#comment-17804291 ] Michael Osipov commented on CLI-322: I have read this somewhere on the mailing list, but don't ask for ref. Cannot remember. > Allow kabab-case options > > > Key: CLI-322 > URL: https://issues.apache.org/jira/browse/CLI-322 > Project: Commons CLI > Issue Type: New Feature > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently the '-' is not allowed in the option name. This change is to allow > '-' as an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804275#comment-17804275 ] Michael Osipov commented on CLI-322: Isn't Commons CLI is maintenance mode, means no new features will be added? > Allow kabab-case options > > > Key: CLI-322 > URL: https://issues.apache.org/jira/browse/CLI-322 > Project: Commons CLI > Issue Type: New Feature > Components: Parser >Affects Versions: 1.6.0 >Reporter: Claude Warren >Assignee: Claude Warren >Priority: Minor > Fix For: 1.7.0 > > > Currently the '-' is not allowed in the option name. This change is to allow > '-' as an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-852) webdav4s is not working with multiple TLS Record Layer segments
[ https://issues.apache.org/jira/browse/VFS-852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798319#comment-17798319 ] Michael Osipov commented on VFS-852: This sounds like a HTTP client error, no? > webdav4s is not working with multiple TLS Record Layer segments > --- > > Key: VFS-852 > URL: https://issues.apache.org/jira/browse/VFS-852 > Project: Commons VFS > Issue Type: Bug >Reporter: Sodrul Bhuiyan >Priority: Major > > We're trying to use webdav over SSL using webdav4s provider. We're running > into connection closed error because the connection had been released from > the finally block as part of > org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#executeRequest > method. The issue becomes visible from > org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#getProperties(org.apache.commons.vfs2.provider.GenericURLFileName, > int, org.apache.jackrabbit.webdav.property.DavPropertyNameSet, boolean) > method which we're using. I would imagine it'd also be an issue from > org.apache.commons.vfs2.provider.webdav4.Webdav4FileObject#doListChildrenResolved > method. As both of these methods try to get the body of the response after > the connection had been released from executeRequest method. > The design assumption was that the entire data (http response) was consumed > before closing. However while debugging the issue we have found that TLS > transmission containing the application data had been broken up into multiple > TLS Record Layer Segments (Fragments as designed). While filling up the > buffer from SSL Socket it stopped after the 1st TLS record layer, which only > contained the http headers as it hit the end of that stream (fragment). > Non-ssl transaction doesn't have fragmentation so buffer fills up entire > response at once thus doesn't cause the connection closed error. > I'd imagine the fix would be to implement an overloading executeRequest > method for keeping the connection open and close it after retrieving the body > of the response from getProperties and doListChildrenResolved method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IO-822) I hope to add a file size tool class for converting units such as TB, GB, MB, etc, such as java.util.concurrent.TimeUnit.java
[ https://issues.apache.org/jira/browse/IO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed IO-822. - Resolution: Duplicate > I hope to add a file size tool class for converting units such as TB, GB, MB, > etc, such as java.util.concurrent.TimeUnit.java > -- > > Key: IO-822 > URL: https://issues.apache.org/jira/browse/IO-822 > Project: Commons IO > Issue Type: Wish > Components: Utilities > Environment: java8+ >Reporter: hellozrh >Priority: Minor > Labels: features > Original Estimate: 48h > Remaining Estimate: 48h > > a tool for file size converting, TB, GB, MB, KB convert to each other, > including Byte conversion to a size that is convenient for human reading。 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-822) I hope to add a file size tool class for converting units such as TB, GB, MB, etc, such as java.util.concurrent.TimeUnit.java
[ https://issues.apache.org/jira/browse/IO-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789126#comment-17789126 ] Michael Osipov commented on IO-822: --- This belongs at most to Commons Lang, not IO. This has nothing to do with IO. > I hope to add a file size tool class for converting units such as TB, GB, MB, > etc, such as java.util.concurrent.TimeUnit.java > -- > > Key: IO-822 > URL: https://issues.apache.org/jira/browse/IO-822 > Project: Commons IO > Issue Type: Wish > Components: Utilities > Environment: java8+ >Reporter: hellozrh >Priority: Minor > Labels: features > Original Estimate: 48h > Remaining Estimate: 48h > > a tool for file size converting, TB, GB, MB, KB convert to each other, > including Byte conversion to a size that is convenient for human reading。 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FILEUPLOAD-354) Apache commons fileupload1.5 Support java17
[ https://issues.apache.org/jira/browse/FILEUPLOAD-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed FILEUPLOAD-354. - Resolution: Information Provided * Try it out * Ask on the users mailing list > Apache commons fileupload1.5 Support java17 > --- > > Key: FILEUPLOAD-354 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-354 > Project: Commons FileUpload > Issue Type: Wish >Affects Versions: 1.5 >Reporter: Radar wen >Priority: Minor > > hi，I want to know if apache commons fileupload 1.5 supports java17？thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1714) Deprecation of StringUtils.defaultString(...,...) is not useful
[ https://issues.apache.org/jira/browse/LANG-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772607#comment-17772607 ] Michael Osipov commented on LANG-1714: -- [~ggregory], maybe this is really just a documentation issue... > Deprecation of StringUtils.defaultString(...,...) is not useful > --- > > Key: LANG-1714 > URL: https://issues.apache.org/jira/browse/LANG-1714 > Project: Commons Lang > Issue Type: Bug >Reporter: Michael Keppler >Priority: Major > > Upgrading lang3 from 3.12.0 to 3.13.0 produces a huge amount of deprecations > on a project of mine, all caused by the deprecation of the 2 argument version > of StringUtils.defaultString(). > That deprecation causes more harm than good. It's perfectly fine to tell > users via implNote that there is Objects.toString(), which they can also use > for reaching their goal, if they want. But it should not be enforced by means > of a deprecation. > In my experience someone using the StringUtils class does so because there > are _semantically rich_ method names, not because the implementation behind > the method names is done a specific or clever way. Basically you can "think > in String semantics", without having to remember other classes and how their > combination would produce the wanted String. That's why the changed > implementation (from a conditional operator towards the Objects method) > should remain an implementation detail behind that semantically rich method > name, instead of now forcing developers to think of the Objects class when > they need to deal with a String. > If, on the other hand, we would deprecate all methods that can also be done > by some other means, the consistency of the StringUtils API would severely > decrease. By now a developer has to remember to call either > StringUtils.defaultString or Objects.toString if he wants a default string. > In the future that would be the case for many more methods. Essentially he > has to remember what has been implementation details behind StringUtils in > the past. > Basically it boils down to: Does Commons Lang provide a set of consistent > methods on certain domains, or just a set of missing methods? The first is > much more useful to its userbase, probably. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1714) Deprecation of StringUtils.defaultString(...,...) is not useful
[ https://issues.apache.org/jira/browse/LANG-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772500#comment-17772500 ] Michael Osipov commented on LANG-1714: -- I support your request. > Deprecation of StringUtils.defaultString(...,...) is not useful > --- > > Key: LANG-1714 > URL: https://issues.apache.org/jira/browse/LANG-1714 > Project: Commons Lang > Issue Type: Bug >Reporter: Michael Keppler >Priority: Major > > Upgrading lang3 from 3.12.0 to 3.13.0 produces a huge amount of deprecations > on a project of mine, all caused by the deprecation of the 2 argument version > of StringUtils.defaultString(). > That deprecation causes more harm than good. It's perfectly fine to tell > users via implNote that there is Objects.toString(), which they can also use > for reaching their goal, if they want. But it should not be enforced by means > of a deprecation. > In my experience someone using the StringUtils class does so because there > are _semantically rich_ method names, not because the implementation behind > the method names is done a specific or clever way. Basically you can "think > in String semantics", without having to remember other classes and how their > combination would produce the wanted String. That's why the changed > implementation (from a conditional operator towards the Objects method) > should remain an implementation detail behind that semantically rich method > name, instead of now forcing developers to think of the Objects class when > they need to deal with a String. > If, on the other hand, we would deprecate all methods that can also be done > by some other means, the consistency of the StringUtils API would severely > decrease. By now a developer has to remember to call either > StringUtils.defaultString or Objects.toString if he wants a default string. > In the future that would be the case for many more methods. Essentially he > has to remember what has been implementation details behind StringUtils in > the past. > Basically it boils down to: Does Commons Lang provide a set of consistent > methods on certain domains, or just a set of missing methods? The first is > much more useful to its userbase, probably. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BEANUTILS-563) Building from source release fails with a Maven error
[ https://issues.apache.org/jira/browse/BEANUTILS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764548#comment-17764548 ] Michael Osipov commented on BEANUTILS-563: -- I use it as well, kudos to your work! > Building from source release fails with a Maven error > - > > Key: BEANUTILS-563 > URL: https://issues.apache.org/jira/browse/BEANUTILS-563 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.9.4 >Reporter: Craig McClanahan >Priority: Major > > I downloaded the Commons Beanutils 1.9.4 release from > [https://dlcdn.apache.org//commons/beanutils/source/commons-beanutils-1.9.4-src.tar.gz] > And attempted to build it following the instructions at > [https://commons.apache.org/proper/commons-beanutils/building.html] > But encountered the following errors from Maven: > [*ERROR*] COMPILATION ERROR : > [*INFO*] - > [*ERROR*] Source option 6 is no longer supported. Use 7 or later. > [*ERROR*] Target option 6 is no longer supported. Use 7 or later. > [*INFO*] 2 errors > [*INFO*] - > > My Environment: > * Computer: MacBook Pro > * OS: Ventura 13.5.2 > * Java: 14.0.1 > * Maven: 3.6.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (BEANUTILS-563) Building from source release fails with a Maven error
[ https://issues.apache.org/jira/browse/BEANUTILS-563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17764508#comment-17764508 ] Michael Osipov commented on BEANUTILS-563: -- Obvious, isn't it? Use Java 8 LTS. > Building from source release fails with a Maven error > - > > Key: BEANUTILS-563 > URL: https://issues.apache.org/jira/browse/BEANUTILS-563 > Project: Commons BeanUtils > Issue Type: Bug > Components: Bean / Property Utils >Affects Versions: 1.9.4 >Reporter: Craig McClanahan >Priority: Major > > I downloaded the Commons Beanutils 1.9.4 release from > [https://dlcdn.apache.org//commons/beanutils/source/commons-beanutils-1.9.4-src.tar.gz] > And attempted to build it following the instructions at > [https://commons.apache.org/proper/commons-beanutils/building.html] > But encountered the following errors from Maven: > [*ERROR*] COMPILATION ERROR : > [*INFO*] - > [*ERROR*] Source option 6 is no longer supported. Use 7 or later. > [*ERROR*] Target option 6 is no longer supported. Use 7 or later. > [*INFO*] 2 errors > [*INFO*] - > > My Environment: > * Computer: MacBook Pro > * OS: Ventura 13.5.2 > * Java: 14.0.1 > * Maven: 3.6.3 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[ https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762350#comment-17762350 ] Michael Osipov commented on VALIDATOR-490: -- Looking at k8s documentation and these two issues (https://github.com/kubernetes/kubernetes/issues/82381, https://github.com/kubernetes/kubernetes/issues/115300) I consider their DNS setup and ill-designed and a total abuse of mDNS names which exists for 10 years now. I am inclined, just like [~ggregory], to close this one out. > [DomainValidator] Add local to LOCAL_TLDs > -- > > Key: VALIDATOR-490 > URL: https://issues.apache.org/jira/browse/VALIDATOR-490 > Project: Commons Validator > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Jon Krehling >Priority: Minor > > I am looking to have .local added to the list of LOCAL_TLDs > [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml] > It seems odd to have .localhost and not .local and by default every service > in kubernetes will end with .local > https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762191#comment-17762191
]
Michael Osipov edited comment on VALIDATOR-490 at 9/6/23 7:26 AM:
--
The kube dns pod should provide it so from the containers/application
perspective it does not resolve with mDNS. Since its containerized and the
container is agnostic to the actual server its running on I suppose it doesn't
have to mean local in the same way localhost does.
{noformat}
nslookup testapp
Server: 172.20.0.10
Address:172.20.0.10#53
Name: testapp.default.svc.cluster.local
Address: 172.20.152.235 {noformat}
was (Author: JIRAUSER302131):
The kube dns pod should provide it so from the containers/application
perspective it does not resolve with mDNS. Since its containerized and the
container is agnostic to the actual server its running on I suppose it doesn't
have to mean local in the same way localhost does.
{code:java}
nslookup testapp
Server: 172.20.0.10
Address:172.20.0.10#53
Name: testapp.default.svc.cluster.local
Address: 172.20.152.235 {code}
> [DomainValidator] Add local to LOCAL_TLDs
> --
>
> Key: VALIDATOR-490
> URL: https://issues.apache.org/jira/browse/VALIDATOR-490
> Project: Commons Validator
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Jon Krehling
>Priority: Minor
>
> I am looking to have .local added to the list of LOCAL_TLDs
> [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml]
> It seems odd to have .localhost and not .local and by default every service
> in kubernetes will end with .local
> https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[ https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762193#comment-17762193 ] Michael Osipov commented on VALIDATOR-490: -- Well, that is clearly an abuse of the .local domain especially it does not support hierarchies. > [DomainValidator] Add local to LOCAL_TLDs > -- > > Key: VALIDATOR-490 > URL: https://issues.apache.org/jira/browse/VALIDATOR-490 > Project: Commons Validator > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Jon Krehling >Priority: Minor > > I am looking to have .local added to the list of LOCAL_TLDs > [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml] > It seems odd to have .localhost and not .local and by default every service > in kubernetes will end with .local > https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[ https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762178#comment-17762178 ] Michael Osipov edited comment on VALIDATOR-490 at 9/5/23 5:50 PM: -- [~ggregory], I would not blindly add it to the list w/o understanding it. Special use does not mean local use. was (Author: michael-o): [~ggregory], I would not blindly add it to the list w/o understanding it. > [DomainValidator] Add local to LOCAL_TLDs > -- > > Key: VALIDATOR-490 > URL: https://issues.apache.org/jira/browse/VALIDATOR-490 > Project: Commons Validator > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Jon Krehling >Priority: Minor > > I am looking to have .local added to the list of LOCAL_TLDs > [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml] > It seems odd to have .localhost and not .local and by default every service > in kubernetes will end with .local > https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[ https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762178#comment-17762178 ] Michael Osipov commented on VALIDATOR-490: -- [~ggregory], I would not blindly add it to the list w/o understanding it. > [DomainValidator] Add local to LOCAL_TLDs > -- > > Key: VALIDATOR-490 > URL: https://issues.apache.org/jira/browse/VALIDATOR-490 > Project: Commons Validator > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Jon Krehling >Priority: Minor > > I am looking to have .local added to the list of LOCAL_TLDs > [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml] > It seems odd to have .localhost and not .local and by default every service > in kubernetes will end with .local > https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-490) [DomainValidator] Add local to LOCAL_TLDs
[
https://issues.apache.org/jira/browse/VALIDATOR-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762177#comment-17762177
]
Michael Osipov commented on VALIDATOR-490:
--
{{.local}} is special: https://en.wikipedia.org/wiki/.local
Does it use mDNS for resolution? That's the whole purpose of it.
> [DomainValidator] Add local to LOCAL_TLDs
> --
>
> Key: VALIDATOR-490
> URL: https://issues.apache.org/jira/browse/VALIDATOR-490
> Project: Commons Validator
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Jon Krehling
>Priority: Minor
>
> I am looking to have .local added to the list of LOCAL_TLDs
> [https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml]
> It seems odd to have .localhost and not .local and by default every service
> in kubernetes will end with .local
> https://github.com/apache/commons-validator/blob/master/src/main/java/org/apache/commons/validator/routines/DomainValidator.java#L2002
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (BEANUTILS-562) remove dependency on commons-logging
[
https://issues.apache.org/jira/browse/BEANUTILS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761200#comment-17761200
]
Michael Osipov commented on BEANUTILS-562:
--
Then plug in yet another shim? Log4j turned to be way too complex as we have
seen in the past.
> remove dependency on commons-logging
>
>
> Key: BEANUTILS-562
> URL: https://issues.apache.org/jira/browse/BEANUTILS-562
> Project: Commons BeanUtils
> Issue Type: Improvement
>Reporter: Samael Bate
>Priority: Major
>
> beanutils currently depends on commons-logging 1.2 which was released 9 years
> ago and seems to be pretty much redundant.
> {code:java}
>
> commons-logging
> commons-logging
> 1.2
> {code}
> It would make sense for beanutils, and other Apache libraries, to instead
> just make use of slf4j-api
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TEXT-230) Javadoc of org.apache.commons.text.lookup.DefaultStringLookup.XML is incorrect
[
https://issues.apache.org/jira/browse/TEXT-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754653#comment-17754653
]
Michael Osipov commented on TEXT-230:
-
It seems that other spots have copy and paste errors as well.
> Javadoc of org.apache.commons.text.lookup.DefaultStringLookup.XML is incorrect
> --
>
> Key: TEXT-230
> URL: https://issues.apache.org/jira/browse/TEXT-230
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Michael Osipov
>Priority: Major
>
> The Javadoc says:
> {code:java}
> /**
> * The lookup for URL decoding using the key {@code "xml"}.
> * @see StringLookupFactory#KEY_XML
> * @see StringLookupFactory#xmlStringLookup()
> */
> XML(StringLookupFactory.KEY_XML,
> StringLookupFactory.INSTANCE.xmlStringLookup());
> {code}
> which is obviously a copy and paste error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TEXT-229) Add XmlEncoderStringLookup/XmlDecoderStringLookup
[
https://issues.apache.org/jira/browse/TEXT-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated TEXT-229:
Assignee: Michael Osipov
> Add XmlEncoderStringLookup/XmlDecoderStringLookup
> -
>
> Key: TEXT-229
> URL: https://issues.apache.org/jira/browse/TEXT-229
> Project: Commons Text
> Issue Type: New Feature
>Affects Versions: 1.10.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> While we have URL encoder and decoder it'd be helpful to have builtin
> {{XmlEncoderStringLookup}} and {{XmlDecoderStringLookup}}.
> A quick hack works for me:
> {code:java}
> public static void main(String[] args) {
> Map lookups = new HashMap<>();
> lookups.put("xmlEncoder", XmlEncoderStringLookup.INSTANCE);
> Map vars = new HashMap<>();
> vars.put("foo", "bar");
> vars.put("baz", "");
> StringLookupFactory factory = StringLookupFactory.INSTANCE;
> StringLookup interpolatorStringLookup =
> factory.interpolatorStringLookup(lookups, factory.mapStringLookup(vars),
> false);
> StringSubstitutor sub = new
> StringSubstitutor(interpolatorStringLookup);
> sub.setEnableSubstitutionInVariables(true);
> System.out.println(sub.replace("${foo}, ${xmlEncoder: bar='sdfsf' />} ${xmlEncoder:${baz}}"));
> }
> {code}
> {noformat}
> bar,
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TEXT-229) Add XmlEncoderStringLookup/XmlDecoderStringLookup
[
https://issues.apache.org/jira/browse/TEXT-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated TEXT-229:
Fix Version/s: 1.11.0
> Add XmlEncoderStringLookup/XmlDecoderStringLookup
> -
>
> Key: TEXT-229
> URL: https://issues.apache.org/jira/browse/TEXT-229
> Project: Commons Text
> Issue Type: New Feature
>Affects Versions: 1.10.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.11.0
>
>
> While we have URL encoder and decoder it'd be helpful to have builtin
> {{XmlEncoderStringLookup}} and {{XmlDecoderStringLookup}}.
> A quick hack works for me:
> {code:java}
> public static void main(String[] args) {
> Map lookups = new HashMap<>();
> lookups.put("xmlEncoder", XmlEncoderStringLookup.INSTANCE);
> Map vars = new HashMap<>();
> vars.put("foo", "bar");
> vars.put("baz", "");
> StringLookupFactory factory = StringLookupFactory.INSTANCE;
> StringLookup interpolatorStringLookup =
> factory.interpolatorStringLookup(lookups, factory.mapStringLookup(vars),
> false);
> StringSubstitutor sub = new
> StringSubstitutor(interpolatorStringLookup);
> sub.setEnableSubstitutionInVariables(true);
> System.out.println(sub.replace("${foo}, ${xmlEncoder: bar='sdfsf' />} ${xmlEncoder:${baz}}"));
> }
> {code}
> {noformat}
> bar,
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TEXT-230) Javadoc of org.apache.commons.text.lookup.DefaultStringLookup.XML is incorrect
Michael Osipov created TEXT-230:
---
Summary: Javadoc of
org.apache.commons.text.lookup.DefaultStringLookup.XML is incorrect
Key: TEXT-230
URL: https://issues.apache.org/jira/browse/TEXT-230
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.10.0
Reporter: Michael Osipov
The Javadoc says:
{code:java}
/**
* The lookup for URL decoding using the key {@code "xml"}.
* @see StringLookupFactory#KEY_XML
* @see StringLookupFactory#xmlStringLookup()
*/
XML(StringLookupFactory.KEY_XML,
StringLookupFactory.INSTANCE.xmlStringLookup());
{code}
which is obviously a copy and paste error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TEXT-229) Add XmlEncoderStringLookup/XmlDecoderStringLookup
Michael Osipov created TEXT-229:
---
Summary: Add XmlEncoderStringLookup/XmlDecoderStringLookup
Key: TEXT-229
URL: https://issues.apache.org/jira/browse/TEXT-229
Project: Commons Text
Issue Type: New Feature
Affects Versions: 1.10.0
Reporter: Michael Osipov
While we have URL encoder and decoder it'd be helpful to have builtin
{{XmlEncoderStringLookup}} and {{XmlDecoderStringLookup}}.
A quick hack works for me:
{code:java}
public static void main(String[] args) {
Map lookups = new HashMap<>();
lookups.put("xmlEncoder", XmlEncoderStringLookup.INSTANCE);
Map vars = new HashMap<>();
vars.put("foo", "bar");
vars.put("baz", "");
StringLookupFactory factory = StringLookupFactory.INSTANCE;
StringLookup interpolatorStringLookup =
factory.interpolatorStringLookup(lookups, factory.mapStringLookup(vars), false);
StringSubstitutor sub = new
StringSubstitutor(interpolatorStringLookup);
sub.setEnableSubstitutionInVariables(true);
System.out.println(sub.replace("${foo}, ${xmlEncoder:} ${xmlEncoder:${baz}}"));
}
{code}
{noformat}
bar,
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-647) ArrayIndexOutOfBoundsException when reading Zip with data descriptor entries
[
https://issues.apache.org/jira/browse/COMPRESS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMPRESS-647:
Description:
The attached fuzzed zip file fails to open with the following test when the
{{allowStoredEntriesWithDataDescriptor}} value is {{true}}.
{code:java}
@ParameterizedTest
@ValueSource(booleans = {true, false})
public void zipInputStream(final boolean allowStoredEntriesWithDataDescriptor) {
try (ZipArchiveInputStream zIn = new
ZipArchiveInputStream(Files.newInputStream(Paths.get("crash-commons-compress-ZipArchiveInputStream-dataDescriptor")),
"UTF-8", false, allowStoredEntriesWithDataDescriptor)) {
ZipArchiveEntry zae = zIn.getNextZipEntry();
while (zae != null) {
zae = zIn.getNextZipEntry();
}
} catch (IOException e) {
// Ignore expected exception
}
} {code}
The exception is
{code:java}
java.lang.ArrayIndexOutOfBoundsException: arraycopy: source index -6 out of
bounds for byte[512] at java.base/java.lang.System.arraycopy(Native Method)
at
java.base/java.io.PushbackInputStream.unread(PushbackInputStream.java:232)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.pushback(ZipArchiveInputStream.java:979)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArchiveInputStream.java:471)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInputStream.java:1282)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStream.java:1211)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:1013)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skip(ZipArchiveInputStream.java:1343)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.closeEntry(ZipArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:735)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStreamTest.zipInputStream(ZipArchiveInputStreamTest.java:765)
{code}
I also tried to open the file with the ZipFile class and the crash does not
occure there. Seems to only affect the stream implementation with that specific
option.
was:
The attached fuzzed zip file fails to open with the following test when the
{{allowStoredEntriesWithDataDescriptor} }value is {{true}}.
{code:java}
@ParameterizedTest
@ValueSource(booleans = {true, false})
public void zipInputStream(final boolean allowStoredEntriesWithDataDescriptor) {
try (ZipArchiveInputStream zIn = new
ZipArchiveInputStream(Files.newInputStream(Paths.get("crash-commons-compress-ZipArchiveInputStream-dataDescriptor")),
"UTF-8", false, allowStoredEntriesWithDataDescriptor)) {
ZipArchiveEntry zae = zIn.getNextZipEntry();
while (zae != null) {
zae = zIn.getNextZipEntry();
}
} catch (IOException e) {
// Ignore expected exception
}
} {code}
The exception is
{code:java}
java.lang.ArrayIndexOutOfBoundsException: arraycopy: source index -6 out of
bounds for byte[512] at java.base/java.lang.System.arraycopy(Native Method)
at
java.base/java.io.PushbackInputStream.unread(PushbackInputStream.java:232)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.pushback(ZipArchiveInputStream.java:979)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArchiveInputStream.java:471)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInputStream.java:1282)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStream.java:1211)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:1013)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skip(ZipArchiveInputStream.java:1343)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.closeEntry(ZipArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:735)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStreamTest.zipInputStream(ZipArchiveInputStreamTest.java:765)
{code}
I also tried to open the file with the ZipFile class and the crash does not
occure there. Seems to only affect the stream implementation with that specific
option.
> ArrayIndexOutOfBoundsException when reading Zip with data descriptor entries
>
>
> Key: COMPRESS-647
> URL: https://issues.apache.org/jira/browse/COMPRESS-647
> Project: Commons Compress
>
[jira] [Updated] (COMPRESS-647) ArrayIndexOutOfBoundsException when reading Zip with data descriptor entries
[
https://issues.apache.org/jira/browse/COMPRESS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMPRESS-647:
Description:
The attached fuzzed zip file fails to open with the following test when the
{{allowStoredEntriesWithDataDescriptor} }value is {{true}}.
{code:java}
@ParameterizedTest
@ValueSource(booleans = {true, false})
public void zipInputStream(final boolean allowStoredEntriesWithDataDescriptor) {
try (ZipArchiveInputStream zIn = new
ZipArchiveInputStream(Files.newInputStream(Paths.get("crash-commons-compress-ZipArchiveInputStream-dataDescriptor")),
"UTF-8", false, allowStoredEntriesWithDataDescriptor)) {
ZipArchiveEntry zae = zIn.getNextZipEntry();
while (zae != null) {
zae = zIn.getNextZipEntry();
}
} catch (IOException e) {
// Ignore expected exception
}
} {code}
The exception is
{code:java}
java.lang.ArrayIndexOutOfBoundsException: arraycopy: source index -6 out of
bounds for byte[512] at java.base/java.lang.System.arraycopy(Native Method)
at
java.base/java.io.PushbackInputStream.unread(PushbackInputStream.java:232)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.pushback(ZipArchiveInputStream.java:979)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArchiveInputStream.java:471)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInputStream.java:1282)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStream.java:1211)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:1013)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skip(ZipArchiveInputStream.java:1343)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.closeEntry(ZipArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:735)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStreamTest.zipInputStream(ZipArchiveInputStreamTest.java:765)
{code}
I also tried to open the file with the ZipFile class and the crash does not
occure there. Seems to only affect the stream implementation with that specific
option.
was:
The attached fuzzed zip file fails to open with the following test when the
{{allowStoredEntriesWithDataDescriptor }}value is {{{}true{}}}.
{code:java}
@ParameterizedTest
@ValueSource(booleans = {true, false})
public void zipInputStream(final boolean allowStoredEntriesWithDataDescriptor) {
try (ZipArchiveInputStream zIn = new
ZipArchiveInputStream(Files.newInputStream(Paths.get("crash-commons-compress-ZipArchiveInputStream-dataDescriptor")),
"UTF-8", false, allowStoredEntriesWithDataDescriptor)) {
ZipArchiveEntry zae = zIn.getNextZipEntry();
while (zae != null) {
zae = zIn.getNextZipEntry();
}
} catch (IOException e) {
// Ignore expected exception
}
} {code}
The exception is
{code:java}
java.lang.ArrayIndexOutOfBoundsException: arraycopy: source index -6 out of
bounds for byte[512] at java.base/java.lang.System.arraycopy(Native Method)
at
java.base/java.io.PushbackInputStream.unread(PushbackInputStream.java:232)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.pushback(ZipArchiveInputStream.java:979)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.bufferContainsSignature(ZipArchiveInputStream.java:471)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStoredEntry(ZipArchiveInputStream.java:1282)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readStored(ZipArchiveInputStream.java:1211)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:1013)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.skip(ZipArchiveInputStream.java:1343)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.closeEntry(ZipArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.getNextZipEntry(ZipArchiveInputStream.java:735)
at
org.apache.commons.compress.archivers.zip.ZipArchiveInputStreamTest.zipInputStream(ZipArchiveInputStreamTest.java:765)
{code}
I also tried to open the file with the ZipFile class and the crash does not
occure there. Seems to only affect the stream implementation with that specific
option.
> ArrayIndexOutOfBoundsException when reading Zip with data descriptor entries
>
>
> Key: COMPRESS-647
> URL: https://issues.apache.org/jira/browse/COMPRESS-647
> Project: Commons Compress
>
[jira] [Commented] (IMAGING-356) TIFF reading extremely slow in version 1.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/IMAGING-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739127#comment-17739127 ] Michael Osipov commented on IMAGING-356: You should bisect to the offending change. > TIFF reading extremely slow in version 1.0-SNAPSHOT > --- > > Key: IMAGING-356 > URL: https://issues.apache.org/jira/browse/IMAGING-356 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0 >Reporter: Gary Lucas >Priority: Major > > I am using the latest code from github (1.0-SNAPSHOT downloaded from github > of June 2023) to read a 300 megabyte TIFF file. Version 1.0-alpha3 required > 673 milliseconds to read that file. The new code requires upward of 15 > minutes. Clearly something got broken since the last release. > The TIFF file is a 1x1 pixel 4 byte image format organized in strips. > The bottleneck appears to occur in the TiffReader getTiffRawImageData method > which reads raw data from the file in preparation of creating a BufferedImage > object. > I suspect that there may be a general slowness of file access. In debugging, > even reading the initial metadata (22 TIFF tags) took a couple of seconds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-721) FTPClient::retrieveFileStream returns empty stream for binary files when running on remote Linux
[
https://issues.apache.org/jira/browse/NET-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731614#comment-17731614
]
Michael Osipov commented on NET-721:
This is exactly what I have expected. Even after 20+ years of SSH...
> FTPClient::retrieveFileStream returns empty stream for binary files when
> running on remote Linux
>
>
> Key: NET-721
> URL: https://issues.apache.org/jira/browse/NET-721
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Dmytro Sylaiev
>Priority: Major
>
> I have next code works differently running on my local Windows machine and on
> linux docker container when args[0] is the binary file:
>
>
> {noformat}
> public class Main {
> public static void main(String[] args) throws IOException {
> String fileName = args[0];
>
> System.out.println("Print " + fileName + ":");
> printFile(fileName);
> }
> private static void printFile(String fileName) throws IOException {
> FTPClient client = new FTPClient();
> try {
> client.connect(host, port);
> client.login(user, pass);
> client.enterLocalPassiveMode();
> client.setFileType(FTP.BINARY_FILE_TYPE);
> try (InputStream is = client.retrieveFileStream(fileName)) {
> client.completePendingCommand();
> while (is.available() > 0) {
> int i = is.read();
> System.out.print((char) i);
> }
> System.out.println();
> }
> } finally {
> if (client.isConnected()) {
> client.disconnect();
> }
> }
> }
> }{noformat}
>
>
> When running it locally I have file content printed, but also I tried with
> jetty:11.0.15-jdk11 container, I executed same jar there and got empty stream
> in result:
>
>
> {noformat}
> docker cp ~\codecTest\. :/codecTest
> docker exec -it /bin/bash
> root@999c8e3413cc:/codecTest/target# java -jar codecTest-1.0-SNAPSHOT.jar
> output.zip
> Print output.zip:
> root@999c8e3413cc:/codecTest/target#{noformat}
> When I put some debug log.info line I have found that is.available() is 0
> when executing on linux, despite I have called
> client.setFileType(FTP.BINARY_FILE_TYPE); and client.completePendingCommand();
>
>
> When execute same code in the remote debug and give the jvm some time to
> fetch the stream, it works correctly. Also no problem when retieveStream for
> ASCII files (even big one)
>
> FileZilla log is also OK:
>
> {noformat}
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> Connected on port 9021,
> sending welcome message...
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220-FileZilla Server
> 0.9.60 beta
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220-written by Tim Kosse
> (tim.ko...@filezilla-project.org)
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220 Please visit
> https://filezilla-project.org/
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> USER
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 331 Password required for
> lserver
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> PASS
> (66)11.06.2023 15:58:08 - lserver (ip)> 230 Logged on
> (66)11.06.2023 15:58:08 - lserver (ip> TYPE I
> (66)11.06.2023 15:58:08 - lserver (ip)> 200 Type set to I
> (66)11.06.2023 15:58:08 - lserver (ip)> PASV
> (66)11.06.2023 15:58:08 - lserver (ip)> 227 Entering Passive Mode
> (95,67,26,232,60,72)
> (66)11.06.2023 15:58:08 - lserver (ip)> RETR output.zip
> (66)11.06.2023 15:58:08 - lserver (ip)> 150 Opening data channel for file
> download from server of "/output.zip"
> (66)11.06.2023 15:58:08 - lserver (ip)> 226 Successfully transferred
> "/output.zip"
> (66)11.06.2023 15:58:08 - lserver (ip)> disconnected{noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CODEC-307) 1.16 release plan
[ https://issues.apache.org/jira/browse/CODEC-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed CODEC-307. Resolution: Not A Problem Use the mailing list for this. > 1.16 release plan > - > > Key: CODEC-307 > URL: https://issues.apache.org/jira/browse/CODEC-307 > Project: Commons Codec > Issue Type: Improvement >Reporter: Radar wen >Priority: Major > > The last LTS version (commons-codec-1.15) of the codec has been released in > 2020. Is there any plan to release the new LTS version (1.16)? If so, when > will it be released? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-721) FTPClient::retrieveFileStream returns empty stream for binary files when running on remote Linux
[
https://issues.apache.org/jira/browse/NET-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731387#comment-17731387
]
Michael Osipov commented on NET-721:
I don't understand why still use FTP whereas there is SSH and HTTPS/WebDAV...
> FTPClient::retrieveFileStream returns empty stream for binary files when
> running on remote Linux
>
>
> Key: NET-721
> URL: https://issues.apache.org/jira/browse/NET-721
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Dmytro Sylaiev
>Priority: Major
>
> I have next code works differently running on my local Windows machine and on
> linux docker container when args[0] is the binary file:
>
>
> {noformat}
> public class Main {
> public static void main(String[] args) throws IOException {
> String fileName = args[0];
>
> System.out.println("Print " + fileName + ":");
> printFile(fileName);
> }
> private static void printFile(String fileName) throws IOException {
> FTPClient client = new FTPClient();
> try {
> client.connect(host, port);
> client.login(user, pass);
> client.enterLocalPassiveMode();
> client.setFileType(FTP.BINARY_FILE_TYPE);
> try (InputStream is = client.retrieveFileStream(fileName)) {
> client.completePendingCommand();
> while (is.available() > 0) {
> int i = is.read();
> System.out.print((char) i);
> }
> System.out.println();
> }
> } finally {
> if (client.isConnected()) {
> client.disconnect();
> }
> }
> }
> }{noformat}
>
>
> When running it locally I have file content printed, but also I tried with
> jetty:11.0.15-jdk11 container, I executed same jar there and got empty stream
> in result:
>
>
> {noformat}
> docker cp ~\codecTest\. :/codecTest
> docker exec -it /bin/bash
> root@999c8e3413cc:/codecTest/target# java -jar codecTest-1.0-SNAPSHOT.jar
> output.zip
> Print output.zip:
> root@999c8e3413cc:/codecTest/target#{noformat}
> When I put some debug log.info line I have found that is.available() is 0
> when executing on linux, despite I have called
> client.setFileType(FTP.BINARY_FILE_TYPE); and client.completePendingCommand();
>
>
> When execute same code in the remote debug and give the jvm some time to
> fetch the stream, it works correctly. Also no problem when retieveStream for
> ASCII files (even big one)
>
> FileZilla log is also OK:
>
> {noformat}
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> Connected on port 9021,
> sending welcome message...
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220-FileZilla Server
> 0.9.60 beta
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220-written by Tim Kosse
> (tim.ko...@filezilla-project.org)
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 220 Please visit
> https://filezilla-project.org/
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> USER
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> 331 Password required for
> lserver
> (66)11.06.2023 15:58:08 - (not logged in) (ip)> PASS
> (66)11.06.2023 15:58:08 - lserver (ip)> 230 Logged on
> (66)11.06.2023 15:58:08 - lserver (ip> TYPE I
> (66)11.06.2023 15:58:08 - lserver (ip)> 200 Type set to I
> (66)11.06.2023 15:58:08 - lserver (ip)> PASV
> (66)11.06.2023 15:58:08 - lserver (ip)> 227 Entering Passive Mode
> (95,67,26,232,60,72)
> (66)11.06.2023 15:58:08 - lserver (ip)> RETR output.zip
> (66)11.06.2023 15:58:08 - lserver (ip)> 150 Opening data channel for file
> download from server of "/output.zip"
> (66)11.06.2023 15:58:08 - lserver (ip)> 226 Successfully transferred
> "/output.zip"
> (66)11.06.2023 15:58:08 - lserver (ip)> disconnected{noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IO-798) DeferredFileOutputStream throws exception when system temp dir is a symlink
[
https://issues.apache.org/jira/browse/IO-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated IO-798:
--
Summary: DeferredFileOutputStream throws exception when system temp dir is
a symlink (was: DeferredFileOutputStream throws exception when system temp
folder is a symlink)
> DeferredFileOutputStream throws exception when system temp dir is a symlink
> ---
>
> Key: IO-798
> URL: https://issues.apache.org/jira/browse/IO-798
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 2.12.0
>Reporter: Shai Shapira
>Priority: Minor
>
> We have some code that creates an org.apache.commons.fileupload.FileItem and
> writes to its OutputStream. This worked well until commons-io version 12 came
> out, then started to throw a FileAlreadyExistsException. After some
> investigation, this is what seems to be happening:
> Our FileItem (created by a DiskFileItemFactory) uses a
> DeferredFileOutputStream as its output stream. DeferredFileOutputStream uses
> the system temp folder to save the file if it gets too big. When saving the
> file, it wants to create any parent folders if they don't already exist.
> The problem is, the logic for creating the parent folders seems to have been
> rewritten for version 2.12.0, and now calls:
> PathUtils.createParentDirectories({color:#9876aa}outputPath{color}){color:#cc7832};
> _{color:#172b4d}(DeferredFileOutputStream.java, line 333){color}_{color}
> {color:#172b4d}This method, by default, uses a parameter telling it not to
> follow links. On our servers, the temp folder is, unfortunately, a link. So
> the method looks at the folder in the file path, and sees the link. Since it
> does not follow links, it just sees that something other than a directory
> exists in this path, and throws an Exception.
> {color}
> The code looks something like this:
> FileItemFactory fileFact = {color:#cc7832}new
> {color}DiskFileItemFactory(){color:#cc7832};
> {color}FileItem file = fileFact.createItem(fieldName{color:#cc7832},
> {color}contentType{color:#cc7832}, {color}{color:#cc7832}false,
> {color}fileName){color:#cc7832};
> {color}{color:#cc7832}try {color}(OutputStream out = file.getOutputStream()) {
> {color:#cc7832}{color:#172b4d} {_}out{_}{color:#172b4d}>{color}
> {color}}
>
> And the stack trace:
> java.nio.file.FileAlreadyExistsException: /usr/local/apache-tomcat-base/temp
> at
>
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:94)
> at
>
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
>
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
>
> java.base/sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:389)
> at
> java.base/java.nio.file.Files.createDirectory(Files.java:690) at
> java.base/java.nio.file.Files.createAndCheckIsDirectory(Files.java:797) at
> java.base/java.nio.file.Files.createDirectories(Files.java:743) at
>
> org.apache.commons.io.file.PathUtils.createParentDirectories(PathUtils.java:383)
> at
>
> org.apache.commons.io.file.PathUtils.createParentDirectories(PathUtils.java:367)
> at
>
> org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:333)
> at
>
> org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:105)
> at
>
> org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:231)
> at
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-838) Port from Jsch to Apache Mina
[ https://issues.apache.org/jira/browse/VFS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726839#comment-17726839 ] Michael Osipov commented on VFS-838: I prefer first 3, then 4. > Port from Jsch to Apache Mina > - > > Key: VFS-838 > URL: https://issues.apache.org/jira/browse/VFS-838 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > Port from Jsch to Apache Mina > JSch seems unmaintained. > https://mina.apache.org/downloads-sshd.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VFS-838) Port from Jsch to Apache Mina
[ https://issues.apache.org/jira/browse/VFS-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726184#comment-17726184 ] Michael Osipov commented on VFS-838: Strongly support this. I have expressed the same for the Wagon SSH Provider, but lack the time to do so. I will remove JSch based provider in the next major version. > Port from Jsch to Apache Mina > - > > Key: VFS-838 > URL: https://issues.apache.org/jira/browse/VFS-838 > Project: Commons VFS > Issue Type: Bug >Reporter: Gary D. Gregory >Priority: Major > > Port from Jsch to Apache Mina > JSch seems unmaintained. > https://mina.apache.org/downloads-sshd.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-831) Unresolved (non-existend) environment variables should return null
[
https://issues.apache.org/jira/browse/CONFIGURATION-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17725754#comment-17725754
]
Michael Osipov commented on CONFIGURATION-831:
--
Consistent with what?
> Unresolved (non-existend) environment variables should return null
> --
>
> Key: CONFIGURATION-831
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-831
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Interpolation
>Affects Versions: 2.9.0
>Reporter: Wojtek
>Priority: Minor
>
> Currently Interpolation of environment variables
> (https://commons.apache.org/proper/commons-configuration/userguide/howto_basicfeatures.html#Variable_Interpolation)
> return un-interpolated string if the environment variable doesn't exists at
> all.
> It would be very convenient and (I feel) more consistent if, in that case,
> 'null' would be returned.
>
> Alternatively, option to specify default if the variable doesn't exist would
> also work.
> I.e. something along the lines:
> ```
> ${env:JAVA_HOME:}
> ```
>
> From my experiments, even if we try to register custom interpolator it's not
> possible to explicitly return `null` from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (COMPRESS-643) ZipArchiveInputStream.getCompressedCount is not calculated properly
[
https://issues.apache.org/jira/browse/COMPRESS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated COMPRESS-643:
Description:
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [81] uncompressed size: [16], calculated ratio:
[5.06] {code}
The calculated ratio is wrong the last.xml due to the compressed size and
uncompressed size is wrong.
This issue is reproducible in case of iterating over the zip entries and read
the content only for the last entry.
was:
{code:java}
{code}
h2. Context
During iterating over the zip entries by using ZipArchiveInputStream the
provided
getCompressedCount and getUncompressedCount methods do not return the correct
values when the stream content is not fully read.
h2. Demo
The zip file used in the code snippets attached to the jira.
*Good behaviour*
Executing the follow code working as expected:
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading all the content
stream.readAllBytes();
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Procced output:
{code:java}
[first.xml] compressed size: [475830] uncompressed size: [16239665], calculated
ratio: [0.03]
[last.xml] compressed size: [2221] uncompressed size: [45481], calculated
ratio: [0.05] {code}
*Bad behaviour*
The next code snippet doesn't read the second entry fully only 16 bytes, and in
this case the calculated values are wrong.
{code:java}
final ZipArchiveInputStream stream = new ZipArchiveInputStream(new
FileInputStream("test.zip"));
while (true)
{
final ZipArchiveEntry nextZipEntry = stream.getNextZipEntry();
if (null == nextZipEntry)
{
break;
}
//reading only the last entry
if ("first.xml".equals(nextZipEntry.getName()))
{
stream.readAllBytes();
}
else
{
stream.readNBytes(16);
}
System.out.println(String.format("[%s] compressed size: [%d] uncompressed
size: [%d], calculated ratio: [%.2f]",
nextZipEntry.getName(),
stream.getCompressedCount(),
stream.getUncompressedCount(),
(double) stream.getCompressedCount() /
stream.getUncompressedCount()));
} {code}
Output:
{code:java}
[first.xml] compres
[jira] [Updated] (LANG-1695) NumberUtils.isParseable does not recognise values such as "2."
[
https://issues.apache.org/jira/browse/LANG-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated LANG-1695:
-
Fix Version/s: (was: 3.12.0)
> NumberUtils.isParseable does not recognise values such as "2."
> --
>
> Key: LANG-1695
> URL: https://issues.apache.org/jira/browse/LANG-1695
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Guillaume Nodet
>Priority: Minor
>
> This is a bit of an edge case, but {{Float.parseFloat("2.")}} returns the
> value {{2.0f}} as expected, while {{NumberUtils.isParseable("2.")}} returns
> false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (LANG-1695) NumberUtils.isParseable does not recognise values such as "2."
[
https://issues.apache.org/jira/browse/LANG-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated LANG-1695:
-
Affects Version/s: 3.12.0
> NumberUtils.isParseable does not recognise values such as "2."
> --
>
> Key: LANG-1695
> URL: https://issues.apache.org/jira/browse/LANG-1695
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.12.0
>Reporter: Guillaume Nodet
>Priority: Minor
> Fix For: 3.12.0
>
>
> This is a bit of an edge case, but {{Float.parseFloat("2.")}} returns the
> value {{2.0f}} as expected, while {{NumberUtils.isParseable("2.")}} returns
> false.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (NET-719) FTPS timing issues behind WAF (F5) firewall
[ https://issues.apache.org/jira/browse/NET-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700827#comment-17700827 ] Michael Osipov edited comment on NET-719 at 3/15/23 7:27 PM: - But still, it is called WAF, not just FW. Either the product is misnamed or I do miss something here. FTP != web. was (Author: michael-o): But stll, it is called WAF, not just FW. Either the product is misnamed or I do miss something here. FTP != web. > FTPS timing issues behind WAF (F5) firewall > --- > > Key: NET-719 > URL: https://issues.apache.org/jira/browse/NET-719 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.9.0 >Reporter: Stefan Kuhr >Priority: Major > Attachments: FTPSClient_RETR_Timing_diagram_current_impl-1.png, > FTPSClient_RETR_Timing_diagram_problem.png, > FTPSClient_RETR_Timing_diagram_solution.png > > > A working data exchange setup stopped working, after the server (vsftpd / > RedHat) was moved behind a WAF (F5) web application firewall. The client uses > PASV mode and the operation resulted in a socket timeout on the client side, > as soon as the data channel came into play (LIST/RETR/STOR). > A FileZilla client does not exhibit this problem. By looking at the protocol > exchanges and laying them down in timing diagrams the problem seems to be, > that the WAF expects the client to fully establish the data-channel, after > the data-command is send over the control-channel. The current FTPS client on > the other hand expects the server reply directly after the command is sent. > A pull request will be provided. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-719) FTPS timing issues behind WAF (F5) firewall
[ https://issues.apache.org/jira/browse/NET-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700827#comment-17700827 ] Michael Osipov commented on NET-719: But stll, it is called WAF, not just FW. Either the product is misnamed or I do miss something here. FTP != web. > FTPS timing issues behind WAF (F5) firewall > --- > > Key: NET-719 > URL: https://issues.apache.org/jira/browse/NET-719 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.9.0 >Reporter: Stefan Kuhr >Priority: Major > Attachments: FTPSClient_RETR_Timing_diagram_current_impl-1.png, > FTPSClient_RETR_Timing_diagram_problem.png, > FTPSClient_RETR_Timing_diagram_solution.png > > > A working data exchange setup stopped working, after the server (vsftpd / > RedHat) was moved behind a WAF (F5) web application firewall. The client uses > PASV mode and the operation resulted in a socket timeout on the client side, > as soon as the data channel came into play (LIST/RETR/STOR). > A FileZilla client does not exhibit this problem. By looking at the protocol > exchanges and laying them down in timing diagrams the problem seems to be, > that the WAF expects the client to fully establish the data-channel, after > the data-command is send over the control-channel. The current FTPS client on > the other hand expects the server reply directly after the command is sent. > A pull request will be provided. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-719) FTPS timing issues behind WAF (F5) firewall
[ https://issues.apache.org/jira/browse/NET-719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700768#comment-17700768 ] Michael Osipov commented on NET-719: I don't understand this report. How does a *web* application firewall relate to FTP(S)? F5's website contains 90% marketing fizz. > FTPS timing issues behind WAF (F5) firewall > --- > > Key: NET-719 > URL: https://issues.apache.org/jira/browse/NET-719 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.9.0 >Reporter: Stefan Kuhr >Priority: Major > Attachments: FTPSClient_RETR_Timing_diagram_current_impl-1.png, > FTPSClient_RETR_Timing_diagram_problem.png, > FTPSClient_RETR_Timing_diagram_solution.png > > > A working data exchange setup stopped working, after the server (vsftpd / > RedHat) was moved behind a WAF (F5) web application firewall. The client uses > PASV mode and the operation resulted in a socket timeout on the client side, > as soon as the data channel came into play (LIST/RETR/STOR). > A FileZilla client does not exhibit this problem. By looking at the protocol > exchanges and laying them down in timing diagrams the problem seems to be, > that the WAF expects the client to fully establish the data-channel, after > the data-command is send over the control-channel. The current FTPS client on > the other hand expects the server reply directly after the command is sent. > A pull request will be provided. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NET-719) FTPS timing issues behind WAF (F5) firewall
[ https://issues.apache.org/jira/browse/NET-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated NET-719: --- Summary: FTPS timing issues behind WAF (F5) firewall (was: FTPS protocal timing problems behind WAF (F5) firewall) > FTPS timing issues behind WAF (F5) firewall > --- > > Key: NET-719 > URL: https://issues.apache.org/jira/browse/NET-719 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.9.0 >Reporter: Stefan Kuhr >Priority: Major > Attachments: FTPSClient_RETR_Timing_diagram_current_impl-1.png, > FTPSClient_RETR_Timing_diagram_problem.png, > FTPSClient_RETR_Timing_diagram_solution.png > > > A working data exchange setup stopped working, after the server (vsftpd / > RedHat) was moved behind a WAF (F5) web application firewall. The client uses > PASV mode and the operation resulted in a socket timeout on the client side, > as soon as the data channel came into play (LIST/RETR/STOR). > A FileZilla client does not exhibit this problem. By looking at the protocol > exchanges and laying them down in timing diagrams the problem seems to be, > that the WAF expects the client to fully establish the data-channel, after > the data-command is send over the control-channel. The current FTPS client on > the other hand expects the server reply directly after the command is sent. > A pull request will be provided. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-640) Make zip/jar date and time reproducible
[
https://issues.apache.org/jira/browse/COMPRESS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695674#comment-17695674
]
Michael Osipov commented on COMPRESS-640:
-
Makes sense, the low lovel library should just expose necessary bits for you.
> Make zip/jar date and time reproducible
> ---
>
> Key: COMPRESS-640
> URL: https://issues.apache.org/jira/browse/COMPRESS-640
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Reporter: Niels Basjes
>Priority: Major
>
> *Background*
> When creating zip/jar/war files there is a growing need to make the build
> reproducible.
> Simply put: Anyone can repeat the build in the future and get the exact same
> binary from the source (exact as in the hash of the zip is the same).
> See also
> * [https://reproducible-builds.org/]
> * [https://github.com/jvm-repo-rebuild/reproducible-central]
> *Problem with timezones*
> One of the kinds of problems I recently ran into to make this happen is that
> someone in a different timezone doing the build got a different binary
> because the timestamps of the files IN the zip were different even though a
> fixed timestamp (epoch) was provided.
> It turned out that the rootcause was that in a few key places in Commons
> Compress the local (system) timezone is used to convert the epoch into a
> local timestamp that is placed in the zip file.
> The code uses these for this: {{ZoneId.systemDefault()}} and
> {{{}Calendar.getInstance(){}}}.
> *Possible solution directions*
> The need here is reproducibility and I see at least two ways to get there:
> # Make the TimeZone/Calendar that is to be used configurable (which is a
> backward compatible direction).
> # Pin the TimeZone/Calendar to always use UTC instead of the system default
> (simpler but not backward compatible).
> *Workarounds*
> So far I have seen two workarounds
> The simple and relatively clean way is to set the timezone for the entire
> project (mvn build) from the start.
> Yet this is also this solution people choose ...
> [https://github.com/spring-projects/spring-boot/commit/998d59b7ac1a75b26634e4fd2843a7833e554840]
> What they do here is that they take the timestamp they want, shift it using
> the local timezone the wrong way and then the underlying code in ZipUtil will
> shift it back again which gives the desired timestamp in the zipfile.
> I fully understand this solution and why they chose this (mvn plugins can run
> in parallel in a single JVM and may not affect each other), yet I think this
> should be made possible in a much much cleaner way.
> Hence this improvement issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-640) Make zip/jar date and time reproducible
[
https://issues.apache.org/jira/browse/COMPRESS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695614#comment-17695614
]
Michael Osipov commented on COMPRESS-640:
-
Isn't this a high level problem? This is a low level library providing all bits
to solve your problem. WDYT?
> Make zip/jar date and time reproducible
> ---
>
> Key: COMPRESS-640
> URL: https://issues.apache.org/jira/browse/COMPRESS-640
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Reporter: Niels Basjes
>Priority: Major
>
> *Background*
> When creating zip/jar/war files there is a growing need to make the build
> reproducible.
> Simply put: Anyone can repeat the build in the future and get the exact same
> binary from the source (exact as in the hash of the zip is the same).
> See also
> * [https://reproducible-builds.org/]
> * [https://github.com/jvm-repo-rebuild/reproducible-central]
> *Problem with timezones*
> One of the kinds of problems I recently ran into to make this happen is that
> someone in a different timezone doing the build got a different binary
> because the timestamps of the files IN the zip were different even though a
> fixed timestamp (epoch) was provided.
> It turned out that the rootcause was that in a few key places in Commons
> Compress the local (system) timezone is used to convert the epoch into a
> local timestamp that is placed in the zip file.
> The code uses these for this: {{ZoneId.systemDefault()}} and
> {{{}Calendar.getInstance(){}}}.
> *Possible solution directions*
> The need here is reproducibility and I see at least two ways to get there:
> # Make the TimeZone/Calendar that is to be used configurable (which is a
> backward compatible direction).
> # Pin the TimeZone/Calendar to always use UTC instead of the system default
> (simpler but not backward compatible).
> *Workarounds*
> So far I have seen two workarounds
> The simple and relatively clean way is to set the timezone for the entire
> project (mvn build) from the start.
> Yet this is also this solution people choose ...
> [https://github.com/spring-projects/spring-boot/commit/998d59b7ac1a75b26634e4fd2843a7833e554840]
> What they do here is that they take the timestamp they want, shift it using
> the local timezone the wrong way and then the underlying code in ZipUtil will
> shift it back again which gives the desired timestamp in the zipfile.
> I fully understand this solution and why they chose this (mvn plugins can run
> in parallel in a single JVM and may not affect each other), yet I think this
> should be made possible in a much much cleaner way.
> Hence this improvement issue.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[ https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689136#comment-17689136 ] Michael Osipov commented on COMMONSSITE-165: I read that statement from jsdelivr. From a user's PoV is hard to collect the information especially that is uses CF or Fastly. I have raised a similar issue with LEGAL years ago. It took years: LEGAL-383. I won't dive into that. > [SKIN] Update Commons Skin Bootstrap > > > Key: COMMONSSITE-165 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-165 > Project: Apache Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: gsoc2023, part-time > > Our Commons components use Commons Skin, a skin, or theme, for Apache Maven > Site. > Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we > are missing several improvements (UIUX, accessibility, browser compatibility) > and JS/CSS bugs fixed over the years. > Work happening on Apache Maven Skins. Maybe we could adapt/use that one? > https://issues.apache.org/jira/browse/MSKINS-97 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[ https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688703#comment-17688703 ] Michael Osipov commented on COMMONSSITE-165: [~aherbert], thanks for the elaboration. Re: syntax highlighting. This is supported for many years now with Fluido skin and I have now also added improvements to this with the Doxia 2.0.0 stack. Re: MathJax. How is this related to the skin? This is a purely Javadoc related issue, no? Side note: The Javadoc files use jsdelivr CDN. I wonder whether: (1) this is GDPR compliant (2) a technical need (3) need to be documented here: https://privacy.apache.org/policies/privacy-policy-public.html > [SKIN] Update Commons Skin Bootstrap > > > Key: COMMONSSITE-165 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-165 > Project: Apache Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: gsoc2023, part-time > > Our Commons components use Commons Skin, a skin, or theme, for Apache Maven > Site. > Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we > are missing several improvements (UIUX, accessibility, browser compatibility) > and JS/CSS bugs fixed over the years. > Work happening on Apache Maven Skins. Maybe we could adapt/use that one? > https://issues.apache.org/jira/browse/MSKINS-97 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[ https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687814#comment-17687814 ] Michael Osipov commented on COMMONSSITE-165: > missing version number in the sub-header That's useless because it does not change and site is bleeding edge in most cases. > missing 'Apache Commons ...' in sub-header True, but it still duplicated the logo from above. What is the benefit in duplication? > different fonts and sizes That is true, but fixable. > I think quite a bit more testing and evaluation is needed before considering > dropping the Commons Skin. Of course, no doubt, but 90% is basically identical. Given that even the comment in the skin hasn't changed "Rendered using Apache Maven Fluido Skin 1.3.0", basically no one cared about it for years. > [SKIN] Update Commons Skin Bootstrap > > > Key: COMMONSSITE-165 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-165 > Project: Apache Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: gsoc2023, part-time > > Our Commons components use Commons Skin, a skin, or theme, for Apache Maven > Site. > Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we > are missing several improvements (UIUX, accessibility, browser compatibility) > and JS/CSS bugs fixed over the years. > Work happening on Apache Maven Skins. Maybe we could adapt/use that one? > https://issues.apache.org/jira/browse/MSKINS-97 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[
https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687630#comment-17687630
]
Michael Osipov commented on COMMONSSITE-165:
Here it is: http://home.apache.org/~michaelo/commons-site/
with:
{noformat}
D:\Entwicklung\Projekte\commons-site> svn diff
Index: content/site.xml
===
--- content/site.xml(revision 1907597)
+++ content/site.xml(working copy)
@@ -25,13 +25,13 @@
http://commons.apache.org/
-
+
-org.apache.commons
-commons-skin
-4
+org.apache.maven.skins
+maven-fluido-skin
+2.0.0-M3
@@ -193,14 +193,4 @@
img="https://maven.apache.org/images/logos/maven-feather.png"/>
-
-
-
-
- Apache Commons, Apache, the Apache feather logo, and the Apache Commons
project logos are trademarks of The Apache Software Foundation.
- All other marks mentioned may be trademarks or registered trademarks of
their respective owners.
-
-
-
-
Index: pom.xml
===
--- pom.xml (revision 1907597)
+++ pom.xml (working copy)
@@ -23,7 +23,7 @@
org.apache
apache
-19
+29
org.apache.commons
commons-site
@@ -32,33 +32,6 @@
Apache Commons
https://commons.apache.org/
-
-
-
-
-false
-
- central
- Central Repository
- https://repo.maven.apache.org/maven2
-
-
-
-
-
-
-never
-
-
-false
-
- central
- Central Repository
- https://repo.maven.apache.org/maven2
-
-
-
-
scm:svn:https://svn.apache.org/repos/asf/commons/cms-site/trunk
scm:svn:https://svn.apache.org/repos/asf/commons/cms-site/trunk
@@ -102,7 +75,7 @@
org.apache.maven.plugins
maven-site-plugin
- 3.9.1
+ 4.0.0-M5
${basedir}/content
@@ -117,7 +90,7 @@
org.apache.maven.plugins
maven-project-info-reports-plugin
-3.1.1
+4.0.0-M1-SNAPSHOT
D:\Entwicklung\Projekte\commons-site>
{noformat}
As of now, I see very little use/reason in maintaining Commons Skin. If
something *cannot* be solved with CSS, I'd be happy to discuss.
> [SKIN] Update Commons Skin Bootstrap
>
>
> Key: COMMONSSITE-165
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-165
> Project: Apache Commons All
> Issue Type: Bug
> Components: Commons Skin
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Labels: gsoc2023, part-time
>
> Our Commons components use Commons Skin, a skin, or theme, for Apache Maven
> Site.
> Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we
> are missing several improvements (UIUX, accessibility, browser compatibility)
> and JS/CSS bugs fixed over the years.
> Work happening on Apache Maven Skins. Maybe we could adapt/use that one?
> https://issues.apache.org/jira/browse/MSKINS-97
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[ https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686552#comment-17686552 ] Michael Osipov commented on COMMONSSITE-165: As for Hugo and JBake, there is an open issue created by [~hboutemy]. > [SKIN] Update Commons Skin Bootstrap > > > Key: COMMONSSITE-165 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-165 > Project: Apache Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: gsoc2023, part-time > > Our Commons components use Commons Skin, a skin, or theme, for Apache Maven > Site. > Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we > are missing several improvements (UIUX, accessibility, browser compatibility) > and JS/CSS bugs fixed over the years. > Work happening on Apache Maven Skins. Maybe we could adapt/use that one? > https://issues.apache.org/jira/browse/MSKINS-97 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMMONSSITE-165) [SKIN] Update Commons Skin Bootstrap
[ https://issues.apache.org/jira/browse/COMMONSSITE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686551#comment-17686551 ] Michael Osipov commented on COMMONSSITE-165: What is the main difference between this skin and Fluido? Maintaining a little diff makes almost no sense. I am currently working on the Doxia 2 alignment of Fluido Skin. Bootstrap upgrade can happen only gradually since the change are too abrupt. > [SKIN] Update Commons Skin Bootstrap > > > Key: COMMONSSITE-165 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-165 > Project: Apache Commons All > Issue Type: Bug > Components: Commons Skin >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: gsoc2023, part-time > > Our Commons components use Commons Skin, a skin, or theme, for Apache Maven > Site. > Our skin uses Bootstrap 2.x, but Bootstrap is already at 5.x release, and we > are missing several improvements (UIUX, accessibility, browser compatibility) > and JS/CSS bugs fixed over the years. > Work happening on Apache Maven Skins. Maybe we could adapt/use that one? > https://issues.apache.org/jira/browse/MSKINS-97 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-828) Configuration file truncated then there isn't enough disk space for writing
[ https://issues.apache.org/jira/browse/CONFIGURATION-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680492#comment-17680492 ] Michael Osipov commented on CONFIGURATION-828: -- Then let's close? > Configuration file truncated then there isn't enough disk space for writing > --- > > Key: CONFIGURATION-828 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-828 > Project: Commons Configuration > Issue Type: Bug > Components: File reloading >Affects Versions: 2.8.0 >Reporter: Alla Gofman >Priority: Major > > Please consider: > 1) Not to create output stream to file in case there is not enough disk space > for writing it's content in case of save. > 2) Enable to register some FileHandlerListener in this case to be notified on > such issue and can react by throwing some Exception. > The FileHandlerListener.saving(FileHandler handler) method not suitable, > because called after the file being already truncated. > * Meanwhile, the workaround is to extend > DefaultFileSystem.getOutputStream(File file) method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-828) Configuration file truncated then there isn't enough disk space for writing
[ https://issues.apache.org/jira/browse/CONFIGURATION-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680179#comment-17680179 ] Michael Osipov commented on CONFIGURATION-828: -- I think this is a non-issue. This library should not try to solve a general problem. > Configuration file truncated then there isn't enough disk space for writing > --- > > Key: CONFIGURATION-828 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-828 > Project: Commons Configuration > Issue Type: Bug > Components: File reloading >Affects Versions: 2.8.0 >Reporter: Alla Gofman >Priority: Major > > Please consider: > 1) Not to create output stream to file in case there is not enough disk space > for writing it's content in case of save. > 2) Enable to register some FileHandlerListener in this case to be notified on > such issue and can react by throwing some Exception. > The FileHandlerListener.saving(FileHandler handler) method not suitable, > because called after the file being already truncated. > * Meanwhile, the workaround is to extend > DefaultFileSystem.getOutputStream(File file) method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-638) The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to write the file name. If the file name contains non-ISO_8859_1 characters, some unknown chara
[
https://issues.apache.org/jira/browse/COMPRESS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679354#comment-17679354
]
Michael Osipov commented on COMPRESS-638:
-
{{%%%.txt}} works like a charm. Here is the proposal:
https://stackoverflow.com/questions/5325322/java-servlet-download-filename-special-characters/30446122#30446122
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name. If the file name contains non-ISO_8859_1 characters,
> some unknown characters are displayed after decompression.
> --
>
> Key: COMPRESS-638
> URL: https://issues.apache.org/jira/browse/COMPRESS-638
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Radar wen
>Priority: Major
> Attachments: 0110.png
>
>
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name.
> If the file name contains non-ISO_8859_1 characters, some unknown characters
> are displayed after decompression. !0110.png!
> Can change the ISO_8859_1 to UTF-8?
> if (filename != null) {
> out.write(filename.getBytes(ISO_8859_1));
> out.write(0);
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-638) The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to write the file name. If the file name contains non-ISO_8859_1 characters, some unknown chara
[
https://issues.apache.org/jira/browse/COMPRESS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679322#comment-17679322
]
Michael Osipov commented on COMPRESS-638:
-
Gary, why not pick up my proposal? Log a warning and make it percent-encoded?
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name. If the file name contains non-ISO_8859_1 characters,
> some unknown characters are displayed after decompression.
> --
>
> Key: COMPRESS-638
> URL: https://issues.apache.org/jira/browse/COMPRESS-638
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Radar wen
>Priority: Major
> Attachments: 0110.png
>
>
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name.
> If the file name contains non-ISO_8859_1 characters, some unknown characters
> are displayed after decompression. !0110.png!
> Can change the ISO_8859_1 to UTF-8?
> if (filename != null) {
> out.write(filename.getBytes(ISO_8859_1));
> out.write(0);
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IO-785) FileUtils.deleteDirectory fails to delete directory on Azure AKS
[
https://issues.apache.org/jira/browse/IO-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17676624#comment-17676624
]
Michael Osipov commented on IO-785:
---
Here it is:
deleteCounters = PathUtils.delete(file.toPath(),
PathUtils.EMPTY_LINK_OPTION_ARRAY,
1342 StandardDeleteOption.OVERRIDE_READ_ONLY);
Obviously your backend does not support read only, the other question is IO
fiddles with attributes at all.
> FileUtils.deleteDirectory fails to delete directory on Azure AKS
> -
>
> Key: IO-785
> URL: https://issues.apache.org/jira/browse/IO-785
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.9.0
> Environment: Azure Files Container Storage Interface (CSI) driver in
> Azure Kubernetes Service (AKS)
> apiVersion: storage.k8s.io/v1
> kind: StorageClass
> metadata:
> annotations:
> kubectl.kubernetes.io/last-applied-configuration: |
>
> \{"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"azure-aks-test-cluster-file-storage-class"},"mountOptions":["dir_mode=0777","file_mode=0777","uid=0","gid=0","mfsymlinks","cache=strict","actimeo=30"],"provisioner":"kubernetes.io/azure-file"}
> storageclass.kubernetes.io/is-default-class: "false"
> creationTimestamp: "2022-01-01T0-00:00:00Z"
> name: azure-aks-test-cluster-file-storage-class
> resourceVersion: "12768518"
> uid: bc6-invalid-8c
> mountOptions:
> - dir_mode=0777
> - file_mode=0777
> - uid=0
> - gid=0
> - mfsymlinks
> - cache=strict
> - actimeo=30
> provisioner: kubernetes.io/azure-file
> reclaimPolicy: Delete
> volumeBindingMode: Immediate
>Reporter: Ivica Loncar
>Priority: Major
>
> On Azure AKS file persistent volume
> (https://learn.microsoft.com/en-us/azure/aks/azure-files-csi) we've got
> following exception:
>
> org.apache.commons.io.IOExceptionList:
> work/bef4a1a575c54ac099816b6babf4bde9/job-3418
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:330)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1191)
> at
> com.xebialabs.xlrelease.remote.executor.k8s.KubeService.cleanWorkDir(KubeService.scala:107)
> at
> com.xebialabs.xlrelease.remote.executor.k8s.KubeJobExecutorService.cleanup(KubeJobExecutorService.scala:27)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor.$anonfun$handleEvent$4(JobRunnerActor.scala:219)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor.$anonfun$handleEvent$4$adapted(JobRunnerActor.scala:218)
> at scala.Option.foreach(Option.scala:437)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor.com$xebialabs$xlrelease$remote$runner$JobRunnerActor$$handleEvent(JobRunnerActor.scala:218)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor$$anonfun$receiveRecover$1.$anonfun$applyOrElse$2(JobRunnerActor.scala:45)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor$$anonfun$receiveRecover$1.$anonfun$applyOrElse$2$adapted(JobRunnerActor.scala:45)
> at scala.Option.foreach(Option.scala:437)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor$$anonfun$receiveRecover$1.applyOrElse(JobRunnerActor.scala:45)
> at
> scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:35)
> at akka.event.LoggingReceive.apply(LoggingReceive.scala:96)
> at akka.event.LoggingReceive.apply(LoggingReceive.scala:70)
> at
> akka.persistence.Eventsourced$$anon$2$$anonfun$1.applyOrElse(Eventsourced.scala:643)
> at akka.actor.Actor.aroundReceive(Actor.scala:537)
> at akka.actor.Actor.aroundReceive$(Actor.scala:535)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor.akka$persistence$Eventsourced$$super$aroundReceive(JobRunnerActor.scala:22)
> at
> akka.persistence.Eventsourced$$anon$3.stateReceive(Eventsourced.scala:771)
> at akka.persistence.Eventsourced.aroundReceive(Eventsourced.scala:245)
> at akka.persistence.Eventsourced.aroundReceive$(Eventsourced.scala:244)
> at
> com.xebialabs.xlrelease.remote.runner.JobRunnerActor.aroundReceive(JobRunnerActor.scala:22)
> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:579)
> at akka.actor.ActorCell.invoke(ActorCell.scala:547)
> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:270)
> at akka.dispatch.Mailbox.run(Mailbox.scala:231)
> at akka.dispatch.Mailbox.exec(Mailbox.scala:243)
> at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown
> Source)
> at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
> at java.base/java.util.conc
[jira] [Commented] (COMPRESS-638) The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to write the file name. If the file name contains non-ISO_8859_1 characters, some unknown chara
[
https://issues.apache.org/jira/browse/COMPRESS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17675574#comment-17675574
]
Michael Osipov commented on COMPRESS-638:
-
I would at most do this approach via a flag:
https://stackoverflow.com/a/30446122/696632
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name. If the file name contains non-ISO_8859_1 characters,
> some unknown characters are displayed after decompression.
> --
>
> Key: COMPRESS-638
> URL: https://issues.apache.org/jira/browse/COMPRESS-638
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Radar wen
>Priority: Major
> Attachments: 0110.png
>
>
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name.
> If the file name contains non-ISO_8859_1 characters, some unknown characters
> are displayed after decompression. !0110.png!
> Can change the ISO_8859_1 to UTF-8?
> if (filename != null) {
> out.write(filename.getBytes(ISO_8859_1));
> out.write(0);
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-638) The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to write the file name. If the file name contains non-ISO_8859_1 characters, some unknown chara
[
https://issues.apache.org/jira/browse/COMPRESS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17675572#comment-17675572
]
Michael Osipov commented on COMPRESS-638:
-
[~ggregory], I would not support a deviation from the RFC because that will
creep into many other spheres. [~Radar], ugly but you could use percent-encoded
UTF-8 values.
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name. If the file name contains non-ISO_8859_1 characters,
> some unknown characters are displayed after decompression.
> --
>
> Key: COMPRESS-638
> URL: https://issues.apache.org/jira/browse/COMPRESS-638
> Project: Commons Compress
> Issue Type: Bug
>Reporter: Radar wen
>Priority: Major
> Attachments: 0110.png
>
>
> The GzipCompressorOutputStream#writeHeader method uses the ISO_8859_1 to
> write the file name.
> If the file name contains non-ISO_8859_1 characters, some unknown characters
> are displayed after decompression. !0110.png!
> Can change the ISO_8859_1 to UTF-8?
> if (filename != null) {
> out.write(filename.getBytes(ISO_8859_1));
> out.write(0);
> }
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641249#comment-17641249 ] Michael Osipov commented on COMPRESS-635: - Don't get me started :-D > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641112#comment-17641112 ] Michael Osipov commented on COMPRESS-635: - Hell no, just use a facade SLF4J. Don't impose convoluted Log4J2. > switch system.err/system.out printlns to be log4j logging > - > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (VALIDATOR-487) EmailValidator validates too much
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640667#comment-17640667
]
Michael Osipov commented on VALIDATOR-487:
--
I'd say that one needs for the latest ASCII-only RFC and the IDN email RFC. The
rest is sugar.
> EmailValidator validates too much
> -
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (VALIDATOR-487) EmailValidator validates too much
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated VALIDATOR-487:
-
Description:
Coming from https://github.com/everit-org/json-schema which uses
{{EMailValidator}} to validate JSON schema type:
{noformat}
{
"type": "string",
"format": "email"
}
{noformat}
The problem is that the following email is returned as valid although according
to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
(https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
it must only contain ASCII printable chars:
{{др.живаго@example.com}}.
I'd expect that one could validate standard addresses and IDN ones.
was:
Coming from https://github.com/everit-org/json-schema which uses
{{EMailValidator}} to validate JSON schema type:
{noformat}
{
"type": "string",
"format": "email"
}
The problem is that the following email is returned as valid although according
to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
(https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
it must only contain ASCII printable chars:
{{др.живаго@example.com}}.
I'd expect that one could validate standard addresses and IDN ones.
> EmailValidator validates too much
> -
>
> Key: VALIDATOR-487
> URL: https://issues.apache.org/jira/browse/VALIDATOR-487
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Michael Osipov
>Priority: Major
>
> Coming from https://github.com/everit-org/json-schema which uses
> {{EMailValidator}} to validate JSON schema type:
> {noformat}
> {
> "type": "string",
> "format": "email"
> }
> {noformat}
> The problem is that the following email is returned as valid although
> according to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
> (https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
> it must only contain ASCII printable chars:
> {{др.живаго@example.com}}.
> I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (VALIDATOR-487) EmailValidator validates too much
Michael Osipov created VALIDATOR-487:
Summary: EmailValidator validates too much
Key: VALIDATOR-487
URL: https://issues.apache.org/jira/browse/VALIDATOR-487
Project: Commons Validator
Issue Type: Bug
Affects Versions: 1.6
Reporter: Michael Osipov
Coming from https://github.com/everit-org/json-schema which uses
{{EMailValidator}} to validate JSON schema type:
{noformat}
{
"type": "string",
"format": "email"
}
The problem is that the following email is returned as valid although according
to rfc5321#section-4.1.2 local-part/dot-string/atom/atext
(https://mailarchive.ietf.org/arch/msg/ietf-smtp/QlSTxHlY6cP6_Xwl6CpDvL5PQLo/)
it must only contain ASCII printable chars:
{{др.живаго@example.com}}.
I'd expect that one could validate standard addresses and IDN ones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (VFS-827) CIFS support in Commons VFS
[ https://issues.apache.org/jira/browse/VFS-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634896#comment-17634896 ] Michael Osipov commented on VFS-827: Though, not worked on VFS, don't expect this to happen. SMB is s very complex protocol and requires a lot of backend resources even to validate against Windows Server. > CIFS support in Commons VFS > --- > > Key: VFS-827 > URL: https://issues.apache.org/jira/browse/VFS-827 > Project: Commons VFS > Issue Type: Improvement >Reporter: Sreedhar J >Priority: Major > > I see CIFS file system support is in sandbox state, Any idea, when is > CIFS support would be released? > Also, does CIFS file system has support for SMB 2.0, 2.1 and SMB 3.0 ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-716) sendCommand("LIST") ends up with "425 Can't open data connection."
[
https://issues.apache.org/jira/browse/NET-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631599#comment-17631599
]
Michael Osipov commented on NET-716:
What do you expect us now do to?
> sendCommand("LIST") ends up with "425 Can't open data connection."
> --
>
> Key: NET-716
> URL: https://issues.apache.org/jira/browse/NET-716
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.8.0
>Reporter: Andreas Wagner
>Priority: Major
>
> Hello!
> I'm using org.apache.commons.net.ftp.FTPSClient to connect to FTP server
> running on a mainframe. Method "listFiles" works correct and the actual list
> of my datasets is returned to my java client program. But when using method
> call 'sendCommand("LIST")' error "425 Can't open data connection." is
> returned.
> With kind regards,
> Andreas Wagner
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CODEC-306) Is there a corresponding C++ version library?
[ https://issues.apache.org/jira/browse/CODEC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed CODEC-306. Resolution: Invalid Base64 is not encryption: https://bfy.tw/TjWd > Is there a corresponding C++ version library? > - > > Key: CODEC-306 > URL: https://issues.apache.org/jira/browse/CODEC-306 > Project: Commons Codec > Issue Type: Wish >Reporter: yingli >Priority: Major > > Hello， > We need implement a so file that can be encrypted and decrypted with same as > java commons codec, Is there a corresponding C++ version library? > > thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CODEC-306) Is there a corresponding C++ version library?
[ https://issues.apache.org/jira/browse/CODEC-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630275#comment-17630275 ] Michael Osipov commented on CODEC-306: -- This library isn't for encryption/decryption. > Is there a corresponding C++ version library? > - > > Key: CODEC-306 > URL: https://issues.apache.org/jira/browse/CODEC-306 > Project: Commons Codec > Issue Type: Wish >Reporter: yingli >Priority: Major > > Hello， > We need implement a so file that can be encrypted and decrypted with same as > java commons codec, Is there a corresponding C++ version library? > > thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CONFIGURATION-823) Update Apache Commons Text from 1.9 to 1.10.0
[ https://issues.apache.org/jira/browse/CONFIGURATION-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated CONFIGURATION-823: - Summary: Update Apache Commons Text from 1.9 to 1.10.0 (was: Update Apache Commons Text from 1.9 to 1.10.0.) > Update Apache Commons Text from 1.9 to 1.10.0 > - > > Key: CONFIGURATION-823 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-823 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: MOREAU >Priority: Critical > > There is a GHSL-2022-018 / CVE-2022-42889 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (NET-714) FTP Worldwide is “Built for Business”. https://www.ftpworldwide.com/Our Enterprise, Devoted and Managed File Transfer (MFT) plans provide the consistency and security requir
[ https://issues.apache.org/jira/browse/NET-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted NET-714: --- > FTP Worldwide is “Built for Business”. https://www.ftpworldwide.com/Our > Enterprise, Devoted and Managed File Transfer (MFT) plans provide the > consistency and security required in today’s competitive and highly regulated > business environment. > > > Key: NET-714 > URL: https://issues.apache.org/jira/browse/NET-714 > Project: Commons Net > Issue Type: Bug >Reporter: FTP Worldwide >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TEXT-219) StringTokenizer#getTokenList does not support #remove
[
https://issues.apache.org/jira/browse/TEXT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618909#comment-17618909
]
Michael Osipov commented on TEXT-219:
-
[~aherbert], did you check maybe other spots are affected as well?
> StringTokenizer#getTokenList does not support #remove
> -
>
> Key: TEXT-219
> URL: https://issues.apache.org/jira/browse/TEXT-219
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Jaap Sperling
>Priority: Major
>
> Upgraded to 1.10 from 1.9 and the {{StringTokenizer#getTokenList}} method now
> returns an {{Arrays$ArrayList}} instead of a regular {{{}ArrayList{}}}.
> This causes calls to #add and #remove to throw
> UnsupportedOperationExceptions, even if the documentation states this returns
> modifiable lists
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TEXT-219) StringTokenizer#getTokenList does not support #remove
[
https://issues.apache.org/jira/browse/TEXT-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618866#comment-17618866
]
Michael Osipov commented on TEXT-219:
-
Here is the regression:
https://github.com/apache/commons-text/commit/2d1ab7ea72298949900df47f65b4f71d56411f0b#diff-ad0c791a40d9df9bd54b9b5c744eb4b386cec52bea1992f3e4476f6e220f1bcdR459
> StringTokenizer#getTokenList does not support #remove
> -
>
> Key: TEXT-219
> URL: https://issues.apache.org/jira/browse/TEXT-219
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.10.0
>Reporter: Jaap Sperling
>Priority: Major
>
> Upgraded to 1.10 from 1.9 and the {{StringTokenizer#getTokenList}} method now
> returns an {{Arrays$ArrayList}} instead of a regular {{{}ArrayList{}}}.
> This causes calls to #add and #remove to throw
> UnsupportedOperationExceptions, even if the documentation states this returns
> modifiable lists
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DBCP-587) DBCP and Transparent Application Continuity
[ https://issues.apache.org/jira/browse/DBCP-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618168#comment-17618168 ] Michael Osipov commented on DBCP-587: - I don't see a bug here. This is better suited for StackOverflow or the users mailing list. > DBCP and Transparent Application Continuity > --- > > Key: DBCP-587 > URL: https://issues.apache.org/jira/browse/DBCP-587 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Kirk Hill >Priority: Major > > Oracle databases have a high-availability setup that uses an item called > Transparent Application Continuity. It requires using the following driver > class name for "oracle.jdbc.replay.OracleDataSourceImpl" When I attempt to > use this driver I get the following error message. > SQLException occurred : Cannot create JDBC driver of class > 'oracle.jdbc.replay.OracleDataSourceImpl' > Having this as a way to create connection pools would greatly enhance your > product. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (LAUNCHER-13) Laetoto
[ https://issues.apache.org/jira/browse/LAUNCHER-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted LAUNCHER-13: --- > Laetoto > --- > > Key: LAUNCHER-13 > URL: https://issues.apache.org/jira/browse/LAUNCHER-13 > Project: Commons Launcher > Issue Type: Bug >Reporter: lae online >Priority: Major > > Link togel toto merupakan tempat daftar togel online terpercaya pasaran judi > togel terlengkap [laetoto.live|https://laetoto.live/] bet togel online 100 > perak jackpot paus 4d 10 juta rupiah menang berapapun dibayar -- This message was sent by Atlassian Jira (v8.20.10#820010)
