Re: [PR] [BCEL-370] CONSTANT_Dynamic is not handled in LDC [commons-bcel]
gtoison commented on PR #254: URL: https://github.com/apache/commons-bcel/pull/254#issuecomment-1882568767 When using BCEL 4.8.1RC1 in https://github.com/spotbugs/spotbugs/pull/2807 the issue seems fixed indeed. I still get an error but that's coming from SpotBugs itself, so it is another problem -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Test the Conversion class [commons-lang]
elharo opened a new pull request, #1155: URL: https://github.com/apache/commons-lang/pull/1155 The Conversion class seems to have gotten committed with no tests. This PR adds a few, though by no means full coverage. @garydgregory -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] LANG-1720: Fix Javadoc description of exceptions thrown for Conversion class [commons-lang]
elharo commented on PR #1139: URL: https://github.com/apache/commons-lang/pull/1139#issuecomment-1882292378 On further investigation, I'm not so sure. The API here is really strange. Since the indexes that can be out of bounds are passed in from client code, StringIndexOutOfBoundsException seems appropriate in at least some cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (LANG-1725) Conversion should throw IllegalArgumentException instead of IndexOutfBoundsException
[ https://issues.apache.org/jira/browse/LANG-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804555#comment-17804555 ] Elliotte Rusty Harold commented on LANG-1725: - On further investgation, I'm not so sure. The API here is really strange. Since indexes are passed in from client code StringIndexOutOfBoundsException seems appropriate in at least some cases. > Conversion should throw IllegalArgumentException instead of > IndexOutfBoundsException > > > Key: LANG-1725 > URL: https://issues.apache.org/jira/browse/LANG-1725 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Reporter: Elliotte Rusty Harold >Priority: Major > > see https://github.com/apache/commons-lang/pull/1139 > The original exception should be wrapped. > At least some of these should be NumberFormatException, a subclass of > IllegalArgumentException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] inline method [commons-lang]
elharo opened a new pull request, #1154: URL: https://github.com/apache/commons-lang/pull/1154 simplify class @garydgregory -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Support URLencoding during normalization [commons-vfs]
garydgregory commented on PR #396: URL: https://github.com/apache/commons-vfs/pull/396#issuecomment-1881969802 ``` Error: src/main/java/org/apache/commons/vfs2/provider/UriParser.java:[528,1] (whitespace) FileTabCharacter: File contains tab characters (this is the first instance). ``` Run mvn before you push to catch build errors -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Support URLencoding during normalization [commons-vfs]
raboof commented on code in PR #396:
URL: https://github.com/apache/commons-vfs/pull/396#discussion_r1445437788
##
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
##
@@ -455,6 +455,156 @@ public static boolean fixSeparators(final StringBuilder
name) {
return changed;
}
+private static class PathNormalizer {
+private final StringBuilder path;
+private int cursor = 0;
+private int lastSeparator;
+private int end;
+PathNormalizer(StringBuilder path) {
+this.path = path;
+this.end = path.length();
+}
+void run() throws FileSystemException {
+lastSeparator = cursor;
+readSeparator();
+while (cursor < end) {
+consumeSeparators();
+if (readDot()) {
+if (readDot()) {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/../'
+removePreviousElement(beforeNextSeparator);
+} else {
+// '/..other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+} else {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/./'
+path.delete(lastSeparator, beforeNextSeparator);
+cursor = lastSeparator + (cursor -
beforeNextSeparator);
+this.end = path.length();
+} else {
+// '/.other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+} else {
+readToNextSeparator();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+}
+private void consumeSeparators() {
+boolean consuming = true;
+while (consuming) {
+consuming = consumeSeparator();
+}
+}
+private void readNonSeparators() {
+boolean reading = true;
+while (reading) {
+reading = readNonSeparator();
+}
Review Comment:
hmm, it seems PMD won't let me
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (EXEC-122) PumpStreamHandler(OutputStream) constructor relies on stream being thread-safe
[
https://issues.apache.org/jira/browse/EXEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcono1234 updated EXEC-122:
-
Description:
h3. Description
The constructor
{{org.apache.commons.exec.PumpStreamHandler.PumpStreamHandler(OutputStream)}}
which uses the {{OutputStream}} for both 'out' and 'err' currently does not
perform any synchronization, so potentially two threads are writing at the same
time to {{OutputStream}}.
(This also applies to the other {{PumpStreamHandler}} constructor overloads in
case the user manually provides the same {{OutputStream}} instance both as
'out' and 'err').
This is error-prone because not all {{OutputStream}} implementations are
thread-safe, and the user might not be aware of this behavior.
So it would be good to either:
- Mention in the {{PumpStreamHandler(OutputStream)}} documentation (and
possibly for the other constructor overloads as well, if the same stream
instance is used), that the {{OutputStream}} has to be thread-safe
- Or, {{PumpStreamHandler}} (or {{StreamPumper}}) should perform
synchronization, for example if the same stream instance is used by wrapping it
in a custom synchronizing {{OutputStream}}
(though maybe that is not desired if the stream is already thread-safe, e.g.
{{Files.newOutputStream}})
h3. Example
Run this code snippet:
{code}
OutputStream out = new OutputStream() {
@Override
public void write(int b) throws IOException {
System.out.println(Thread.currentThread().getName());
}
};
PumpStreamHandler p = new PumpStreamHandler(out);
p.setProcessOutputStream(new ByteArrayInputStream(new byte[1]));
p.setProcessErrorStream(new ByteArrayInputStream(new byte[1]));
p.start();
Thread.sleep(1000);
{code}
You will see that it prints two different thread names. If you place a
breakpoint at the {{println}} you will also see that no synchronization is
performed, and the calls happen concurrently.
was:
h3. Description
The constructor
{{org.apache.commons.exec.PumpStreamHandler.PumpStreamHandler(OutputStream)}}
which uses the {{OutputStream}} for both 'out' and 'err' currently does not
perform any synchronization, so potentially two threads are writing at the same
time to {{OutputStream}}.
(This also applies to the other {{PumpStreamHandler}} constructor overloads in
case the user manually provides the same {{OutputStream}} instance both as
'out' and 'err').
This is error-prone because not all {{OutputStream}} implementations are
thread-safe, and the user might not be aware of this behavior.
So it would be good to either:
- Mention in the {{PumpStreamHandler(OutputStream)}} documentation (and
possibly for the other constructor overloads as well, if the same stream
instance is used), that the {{OutputStream}} has to be thread-safe
- Or, {{PumpStreamHandler}} (or {{StreamPumper}}) should perform
synchronization, for example if the same stream instance is used by wrapping it
in a custom synchronizing {{OutputStream}}
(though maybe that is not desired if the stream is already thread-safe, e.g.
{{Files.newOutputStream}})
h3. Example
Run this code snippet:
{code}
OutputStream out = new OutputStream() {
@Override
public void write(int b) throws IOException {
System.out.println(Thread.currentThread().getName());
}
};
PumpStreamHandler p = new PumpStreamHandler(out);
p.setProcessOutputStream(new ByteArrayInputStream(new byte[1]));
p.setProcessErrorStream(new ByteArrayInputStream(new byte[1]));
p.start();
Thread.sleep(1000);
{code}
You will see that it prints two different thread sames. If you place a
breakpoint at the {{println}} you will also see that no synchronization is
performed, and the calls happen concurrently.
> PumpStreamHandler(OutputStream) constructor relies on stream being thread-safe
> --
>
> Key: EXEC-122
> URL: https://issues.apache.org/jira/browse/EXEC-122
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Marcono1234
>Priority: Minor
>
> h3. Description
> The constructor
> {{org.apache.commons.exec.PumpStreamHandler.PumpStreamHandler(OutputStream)}}
> which uses the {{OutputStream}} for both 'out' and 'err' currently does not
> perform any synchronization, so potentially two threads are writing at the
> same time to {{OutputStream}}.
> (This also applies to the other {{PumpStreamHandler}} constructor overloads
> in case the user manually provides the same {{OutputStream}} instance both as
> 'out' and 'err').
> This is error-prone because not all {{OutputStream}} implementations are
> thread-safe, and the user might not be aware of this behavior.
> So it would be good to either:
> - Mention in the {{PumpStreamHandler(OutputStream)}} documentation (and
> possibly for the other constructor overloads as well, if
[jira] [Updated] (EXEC-122) PumpStreamHandler(OutputStream) constructor relies on stream being thread-safe
[
https://issues.apache.org/jira/browse/EXEC-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcono1234 updated EXEC-122:
-
Summary: PumpStreamHandler(OutputStream) constructor relies on stream being
thread-safe (was: PumpStreamHandler(OutputStream) relies on stream being
thread-safe)
> PumpStreamHandler(OutputStream) constructor relies on stream being thread-safe
> --
>
> Key: EXEC-122
> URL: https://issues.apache.org/jira/browse/EXEC-122
> Project: Commons Exec
> Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Marcono1234
>Priority: Minor
>
> h3. Description
> The constructor
> {{org.apache.commons.exec.PumpStreamHandler.PumpStreamHandler(OutputStream)}}
> which uses the {{OutputStream}} for both 'out' and 'err' currently does not
> perform any synchronization, so potentially two threads are writing at the
> same time to {{OutputStream}}.
> (This also applies to the other {{PumpStreamHandler}} constructor overloads
> in case the user manually provides the same {{OutputStream}} instance both as
> 'out' and 'err').
> This is error-prone because not all {{OutputStream}} implementations are
> thread-safe, and the user might not be aware of this behavior.
> So it would be good to either:
> - Mention in the {{PumpStreamHandler(OutputStream)}} documentation (and
> possibly for the other constructor overloads as well, if the same stream
> instance is used), that the {{OutputStream}} has to be thread-safe
> - Or, {{PumpStreamHandler}} (or {{StreamPumper}}) should perform
> synchronization, for example if the same stream instance is used by wrapping
> it in a custom synchronizing {{OutputStream}}
> (though maybe that is not desired if the stream is already thread-safe, e.g.
> {{Files.newOutputStream}})
> h3. Example
> Run this code snippet:
> {code}
> OutputStream out = new OutputStream() {
> @Override
> public void write(int b) throws IOException {
> System.out.println(Thread.currentThread().getName());
> }
> };
> PumpStreamHandler p = new PumpStreamHandler(out);
> p.setProcessOutputStream(new ByteArrayInputStream(new byte[1]));
> p.setProcessErrorStream(new ByteArrayInputStream(new byte[1]));
> p.start();
> Thread.sleep(1000);
> {code}
> You will see that it prints two different thread sames. If you place a
> breakpoint at the {{println}} you will also see that no synchronization is
> performed, and the calls happen concurrently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (EXEC-122) PumpStreamHandler(OutputStream) relies on stream being thread-safe
Marcono1234 created EXEC-122:
Summary: PumpStreamHandler(OutputStream) relies on stream being
thread-safe
Key: EXEC-122
URL: https://issues.apache.org/jira/browse/EXEC-122
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.4.0
Reporter: Marcono1234
h3. Description
The constructor
{{org.apache.commons.exec.PumpStreamHandler.PumpStreamHandler(OutputStream)}}
which uses the {{OutputStream}} for both 'out' and 'err' currently does not
perform any synchronization, so potentially two threads are writing at the same
time to {{OutputStream}}.
(This also applies to the other {{PumpStreamHandler}} constructor overloads in
case the user manually provides the same {{OutputStream}} instance both as
'out' and 'err').
This is error-prone because not all {{OutputStream}} implementations are
thread-safe, and the user might not be aware of this behavior.
So it would be good to either:
- Mention in the {{PumpStreamHandler(OutputStream)}} documentation (and
possibly for the other constructor overloads as well, if the same stream
instance is used), that the {{OutputStream}} has to be thread-safe
- Or, {{PumpStreamHandler}} (or {{StreamPumper}}) should perform
synchronization, for example if the same stream instance is used by wrapping it
in a custom synchronizing {{OutputStream}}
(though maybe that is not desired if the stream is already thread-safe, e.g.
{{Files.newOutputStream}})
h3. Example
Run this code snippet:
{code}
OutputStream out = new OutputStream() {
@Override
public void write(int b) throws IOException {
System.out.println(Thread.currentThread().getName());
}
};
PumpStreamHandler p = new PumpStreamHandler(out);
p.setProcessOutputStream(new ByteArrayInputStream(new byte[1]));
p.setProcessErrorStream(new ByteArrayInputStream(new byte[1]));
p.start();
Thread.sleep(1000);
{code}
You will see that it prints two different thread sames. If you place a
breakpoint at the {{println}} you will also see that no synchronization is
performed, and the calls happen concurrently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CLI-322) Allow minus for kebab-case options
[
https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Eckenfels updated CLI-322:
Description:
Currently minus (“-“) is not allowed in option names,
which makes common long options in kebab-case
(like {{--is-not-allowed}}) impossible.
This change is to allow it inside an option name.
was:Currently minus (`-`) is not allowed in option names, which makes common
long options in kebab-case (like`-\-is-not-allowed`) impossible. This change is
to allow it inside an option name.
> Allow minus for kebab-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 minus (“-“) is not allowed in option names,
> which makes common long options in kebab-case
> (like {{--is-not-allowed}}) impossible.
> This change is to allow it inside an option name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CLI-322) Allow minus for kebab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels updated CLI-322: Description: Currently minus (`-`) is not allowed in option names, which makes common long options in kebab-case (like`-\-is-not-allowed`) impossible. This change is to allow it inside an option name. (was: Currently the '-' is not allowed in the option name. This change is to allow '-' as an option name.) Summary: Allow minus for kebab-case options (was: Allow kabab-case options) > Allow minus for kebab-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 minus (`-`) is not allowed in option names, which makes common long > options in kebab-case (like`-\-is-not-allowed`) impossible. This change is to > allow it inside an option name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CLI-306) Issue parsing numeric options following an option which accepts multiple args in DefaultParser
[
https://issues.apache.org/jira/browse/CLI-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1780#comment-1780
]
Todd Ye edited comment on CLI-306 at 1/8/24 7:50 PM:
-
Would that be correct behavior in this case? There is no comma used as the
value separator:
{code:java}
--one argNumOne,argNumTwo, -2, argNumThree {code}
vs
{code:java}
--one argNumOne,argNumTwo -2 argNumThree {code}
was (Author: todd ye):
Would that be correct behavior in this case? There is no comma used as the
value seperator:
{code:java}
--one argNumOne,argNumTwo, -2, argNumThree {code}
vs
{code:java}
--one argNumOne,argNumTwo -2 argNumThree {code}
> Issue parsing numeric options following an option which accepts multiple args
> in DefaultParser
> --
>
> Key: CLI-306
> URL: https://issues.apache.org/jira/browse/CLI-306
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
>Reporter: Todd Ye
>Priority: Major
>
> commons-cli seems to be unable to detect numeric options in their short "opt"
> form following an option which takes multiple arguments.
> Will consistently throw:
> {code:java}
> Exception in thread "main" org.apache.commons.cli.MissingOptionException:
> Missing required option: 2
> {code}
> How to reproduce:
> {code:java}
> Option multipleOptional = Option.builder("1")
> .longOpt("one")
> .argName("value1,value2,...,valueN")
> .hasArgs()
> .valueSeparator(',')
> .build();
> Option singleMandatory = Option.builder("2")
> .argName("value")
> .longOpt("two")
> .hasArg()
> .required()
> .build();
> Options options = new Options();
> options.addOption(singleMandatory);
> options.addOption(multipleOptional);
> CommandLineParser parser = new DefaultParser();
> CommandLine line = parser.parse(options, args);
> for (Option o : line.getOptions()) {
> System.out.println(o.getOpt() + '\t'
> + Arrays.toString(o.getValues()));
> }
> {code}
> now pass in:
> {code:java}
> --one argNumOne,argNumTwo -2 argNumThree
> {code}
> Note that an error will not occur if "opt" is set to a char like "a/b/c" or
> if the previous option is set with hasArg() instead of hasArgs()
> Also error will not occur if the longOpt is used such as:
> {code:java}
> --one argNumOne,argNumTwo --two argNumThree
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CLI-306) Issue parsing numeric options following an option which accepts multiple args in DefaultParser
[
https://issues.apache.org/jira/browse/CLI-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1780#comment-1780
]
Todd Ye commented on CLI-306:
-
Would that be correct behavior in this case? There is no comma used as the
value seperator:
{code:java}
--one argNumOne,argNumTwo, -2, argNumThree {code}
vs
{code:java}
--one argNumOne,argNumTwo -2 argNumThree {code}
> Issue parsing numeric options following an option which accepts multiple args
> in DefaultParser
> --
>
> Key: CLI-306
> URL: https://issues.apache.org/jira/browse/CLI-306
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.4
>Reporter: Todd Ye
>Priority: Major
>
> commons-cli seems to be unable to detect numeric options in their short "opt"
> form following an option which takes multiple arguments.
> Will consistently throw:
> {code:java}
> Exception in thread "main" org.apache.commons.cli.MissingOptionException:
> Missing required option: 2
> {code}
> How to reproduce:
> {code:java}
> Option multipleOptional = Option.builder("1")
> .longOpt("one")
> .argName("value1,value2,...,valueN")
> .hasArgs()
> .valueSeparator(',')
> .build();
> Option singleMandatory = Option.builder("2")
> .argName("value")
> .longOpt("two")
> .hasArg()
> .required()
> .build();
> Options options = new Options();
> options.addOption(singleMandatory);
> options.addOption(multipleOptional);
> CommandLineParser parser = new DefaultParser();
> CommandLine line = parser.parse(options, args);
> for (Option o : line.getOptions()) {
> System.out.println(o.getOpt() + '\t'
> + Arrays.toString(o.getValues()));
> }
> {code}
> now pass in:
> {code:java}
> --one argNumOne,argNumTwo -2 argNumThree
> {code}
> Note that an error will not occur if "opt" is set to a char like "a/b/c" or
> if the previous option is set with hasArg() instead of hasArgs()
> Also error will not occur if the longOpt is used such as:
> {code:java}
> --one argNumOne,argNumTwo --two argNumThree
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] COMPRESS-653: Fix split archive updating incorrect file [commons-compress]
kvr000 commented on PR #455: URL: https://github.com/apache/commons-compress/pull/455#issuecomment-1881714547 > @kvr000 I will review this PR tomorrow. I appreciate your patience. Sure, take your time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Support URLencoding during normalization [commons-vfs]
garydgregory commented on PR #396: URL: https://github.com/apache/commons-vfs/pull/396#issuecomment-1881669160 @raboof Please see the test failure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Support URLencoding during normalization [commons-vfs]
raboof commented on PR #396: URL: https://github.com/apache/commons-vfs/pull/396#issuecomment-1881599955 Ah, rebase mistake... thx for the fix, not sure what's going on with `DefaultFileSystemManagerTest.testResolveFileNameType`, will look into that tomorrow. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Support URLencoding during normalization [commons-vfs]
garydgregory commented on PR #396: URL: https://github.com/apache/commons-vfs/pull/396#issuecomment-1881568408 @raboof Run `mvn` before you push to catch build errors. In this case, this PR breaks binary compatibility because it makes a previously public constructor private. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DBCP-594) DBCP Does not check the validity of DB connection at the time creating preparedStatement
[ https://issues.apache.org/jira/browse/DBCP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804371#comment-17804371 ] Shaktisinh Jhala commented on DBCP-594: --- yes, it was 2.11.0 > DBCP Does not check the validity of DB connection at the time creating > preparedStatement > > > Key: DBCP-594 > URL: https://issues.apache.org/jira/browse/DBCP-594 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: OS: CentOS > DB: PostgreSQL > Java: openjdk 17.0.8.1 2023-08-24 >Reporter: Shaktisinh Jhala >Priority: Major > Fix For: 2.11.0 > > Attachments: ExceptionStackTrace.txt > > > Recently we observed an issue of "This connection has been closed." while > borrowing prepared statement from the pool. > It was trying to create a new PreparedStatement using the pooled connection > object. And the Pooled connection object was already closed due to some > reason. > There are two configurations testOnCreate and testOnBorrow ensures that the > connection is validated after create and before borrow. In case of connection > is not valid, DBCP discards such connection from the pool and will not be > used in future. However, in the current scenario, if there is some connection > in the pool which is in closed state, it will throw above error every time > when it will try to create prepareStatement with it. As the actual > PgConnection object is wrapped with the DBCP object the application cannot > close the actual DB connection. So, the DBCP should take care of this error > and discard such connection from the pool in case of this error and should > not propagate the error to the application. > Attached is the exception stack trace for this issue. > > > -- 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=17804298#comment-17804298 ] Gary D. Gregory commented on CLI-322: - I agree that there are other good alternatives like JCommander and Picocli but I'm open to this component getting new features. > 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] [Comment Edited] (DBCP-594) DBCP Does not check the validity of DB connection at the time creating preparedStatement
[ https://issues.apache.org/jira/browse/DBCP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804295#comment-17804295 ] Gary D. Gregory edited comment on DBCP-594 at 1/8/24 1:56 PM: -- [~sjhala] I'll mark this issue as resolved in 2.11.0 then. Please confirm that's the version you tested. was (Author: garydgregory): [~sjhala] I'll mark this issue as resolved in 2.11.0 then. > DBCP Does not check the validity of DB connection at the time creating > preparedStatement > > > Key: DBCP-594 > URL: https://issues.apache.org/jira/browse/DBCP-594 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: OS: CentOS > DB: PostgreSQL > Java: openjdk 17.0.8.1 2023-08-24 >Reporter: Shaktisinh Jhala >Priority: Major > Fix For: 2.11.0 > > Attachments: ExceptionStackTrace.txt > > > Recently we observed an issue of "This connection has been closed." while > borrowing prepared statement from the pool. > It was trying to create a new PreparedStatement using the pooled connection > object. And the Pooled connection object was already closed due to some > reason. > There are two configurations testOnCreate and testOnBorrow ensures that the > connection is validated after create and before borrow. In case of connection > is not valid, DBCP discards such connection from the pool and will not be > used in future. However, in the current scenario, if there is some connection > in the pool which is in closed state, it will throw above error every time > when it will try to create prepareStatement with it. As the actual > PgConnection object is wrapped with the DBCP object the application cannot > close the actual DB connection. So, the DBCP should take care of this error > and discard such connection from the pool in case of this error and should > not propagate the error to the application. > Attached is the exception stack trace for this issue. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DBCP-594) DBCP Does not check the validity of DB connection at the time creating preparedStatement
[ https://issues.apache.org/jira/browse/DBCP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved DBCP-594. -- Fix Version/s: 2.11.0 Resolution: Fixed > DBCP Does not check the validity of DB connection at the time creating > preparedStatement > > > Key: DBCP-594 > URL: https://issues.apache.org/jira/browse/DBCP-594 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: OS: CentOS > DB: PostgreSQL > Java: openjdk 17.0.8.1 2023-08-24 >Reporter: Shaktisinh Jhala >Priority: Major > Fix For: 2.11.0 > > Attachments: ExceptionStackTrace.txt > > > Recently we observed an issue of "This connection has been closed." while > borrowing prepared statement from the pool. > It was trying to create a new PreparedStatement using the pooled connection > object. And the Pooled connection object was already closed due to some > reason. > There are two configurations testOnCreate and testOnBorrow ensures that the > connection is validated after create and before borrow. In case of connection > is not valid, DBCP discards such connection from the pool and will not be > used in future. However, in the current scenario, if there is some connection > in the pool which is in closed state, it will throw above error every time > when it will try to create prepareStatement with it. As the actual > PgConnection object is wrapped with the DBCP object the application cannot > close the actual DB connection. So, the DBCP should take care of this error > and discard such connection from the pool in case of this error and should > not propagate the error to the application. > Attached is the exception stack trace for this issue. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DBCP-594) DBCP Does not check the validity of DB connection at the time creating preparedStatement
[ https://issues.apache.org/jira/browse/DBCP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804295#comment-17804295 ] Gary D. Gregory commented on DBCP-594: -- [~sjhala] I'll mark this issue as resolved in 2.11.0 then. > DBCP Does not check the validity of DB connection at the time creating > preparedStatement > > > Key: DBCP-594 > URL: https://issues.apache.org/jira/browse/DBCP-594 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: OS: CentOS > DB: PostgreSQL > Java: openjdk 17.0.8.1 2023-08-24 >Reporter: Shaktisinh Jhala >Priority: Major > Attachments: ExceptionStackTrace.txt > > > Recently we observed an issue of "This connection has been closed." while > borrowing prepared statement from the pool. > It was trying to create a new PreparedStatement using the pooled connection > object. And the Pooled connection object was already closed due to some > reason. > There are two configurations testOnCreate and testOnBorrow ensures that the > connection is validated after create and before borrow. In case of connection > is not valid, DBCP discards such connection from the pool and will not be > used in future. However, in the current scenario, if there is some connection > in the pool which is in closed state, it will throw above error every time > when it will try to create prepareStatement with it. As the actual > PgConnection object is wrapped with the DBCP object the application cannot > close the actual DB connection. So, the DBCP should take care of this error > and discard such connection from the pool in case of this error and should > not propagate the error to the application. > Attached is the exception stack trace for this issue. > > > -- 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=17804293#comment-17804293 ] Gilles Sadowski commented on CLI-322: - bq. Says who? FTR, many, many years ago, I suggested changes to Commons CLI (to allow less awkward/more standard usage, I vaguely recall); it had been rejected; I don't remember the detailed reason but it could have been equated to "no new features" indeed. Since then, I turned to "picocli". > 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=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] (DBCP-594) DBCP Does not check the validity of DB connection at the time creating preparedStatement
[ https://issues.apache.org/jira/browse/DBCP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804290#comment-17804290 ] Shaktisinh Jhala commented on DBCP-594: --- Executed the use case by manually closing connection using reflection and found it working as expected with latest version of DBCP. > DBCP Does not check the validity of DB connection at the time creating > preparedStatement > > > Key: DBCP-594 > URL: https://issues.apache.org/jira/browse/DBCP-594 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 > Environment: OS: CentOS > DB: PostgreSQL > Java: openjdk 17.0.8.1 2023-08-24 >Reporter: Shaktisinh Jhala >Priority: Major > Attachments: ExceptionStackTrace.txt > > > Recently we observed an issue of "This connection has been closed." while > borrowing prepared statement from the pool. > It was trying to create a new PreparedStatement using the pooled connection > object. And the Pooled connection object was already closed due to some > reason. > There are two configurations testOnCreate and testOnBorrow ensures that the > connection is validated after create and before borrow. In case of connection > is not valid, DBCP discards such connection from the pool and will not be > used in future. However, in the current scenario, if there is some connection > in the pool which is in closed state, it will throw above error every time > when it will try to create prepareStatement with it. As the actual > PgConnection object is wrapped with the DBCP object the application cannot > close the actual DB connection. So, the DBCP should take care of this error > and discard such connection from the pool in case of this error and should > not propagate the error to the application. > Attached is the exception stack trace for this issue. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Support URLencoding during normalization [commons-vfs]
garydgregory commented on code in PR #396:
URL: https://github.com/apache/commons-vfs/pull/396#discussion_r1444666817
##
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
##
@@ -455,6 +455,156 @@ public static boolean fixSeparators(final StringBuilder
name) {
return changed;
}
+private static class PathNormalizer {
+private final StringBuilder path;
+private int cursor = 0;
+private int lastSeparator;
+private int end;
+PathNormalizer(StringBuilder path) {
+this.path = path;
+this.end = path.length();
+}
+void run() throws FileSystemException {
+lastSeparator = cursor;
+readSeparator();
+while (cursor < end) {
+consumeSeparators();
+if (readDot()) {
+if (readDot()) {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/../'
+removePreviousElement(beforeNextSeparator);
+} else {
+// '/..other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+} else {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/./'
+path.delete(lastSeparator, beforeNextSeparator);
+cursor = lastSeparator + (cursor -
beforeNextSeparator);
+this.end = path.length();
+} else {
+// '/.other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+} else {
+readToNextSeparator();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+}
+private void consumeSeparators() {
+boolean consuming = true;
+while (consuming) {
+consuming = consumeSeparator();
+}
+}
+private void readNonSeparators() {
+boolean reading = true;
+while (reading) {
+reading = readNonSeparator();
+}
Review Comment:
Simpler to say `while (readNonSeparator()); ?
##
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
##
@@ -455,6 +455,156 @@ public static boolean fixSeparators(final StringBuilder
name) {
return changed;
}
+private static class PathNormalizer {
+private final StringBuilder path;
+private int cursor = 0;
+private int lastSeparator;
+private int end;
+PathNormalizer(StringBuilder path) {
+this.path = path;
+this.end = path.length();
+}
+void run() throws FileSystemException {
+lastSeparator = cursor;
+readSeparator();
+while (cursor < end) {
+consumeSeparators();
+if (readDot()) {
+if (readDot()) {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/../'
+removePreviousElement(beforeNextSeparator);
+} else {
+// '/..other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+} else {
+int beforeNextSeparator = cursor;
+if (readSeparator() || cursor == end) {
+// '/./'
+path.delete(lastSeparator, beforeNextSeparator);
+cursor = lastSeparator + (cursor -
beforeNextSeparator);
+this.end = path.length();
+} else {
+// '/.other'
+readNonSeparators();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+} else {
+readToNextSeparator();
+lastSeparator = cursor;
+readSeparator();
+}
+}
+}
+private void consumeSeparators() {
+boolean consuming = true;
+while (consuming) {
Re: [PR] Support URLencoding during normalization [commons-vfs]
garydgregory commented on code in PR #396:
URL: https://github.com/apache/commons-vfs/pull/396#discussion_r1444662946
##
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
##
@@ -455,6 +455,156 @@ public static boolean fixSeparators(final StringBuilder
name) {
return changed;
}
+private static class PathNormalizer {
+private final StringBuilder path;
+private int cursor = 0;
Review Comment:
Don't initialize an instance variable to its default value.
##
commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java:
##
@@ -455,6 +455,156 @@ public static boolean fixSeparators(final StringBuilder
name) {
return changed;
}
+private static class PathNormalizer {
+private final StringBuilder path;
+private int cursor = 0;
+private int lastSeparator;
+private int end;
+PathNormalizer(StringBuilder path) {
Review Comment:
Use final where you can.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804278#comment-17804278 ] Gary D. Gregory commented on CLI-322: - [~michael-o] Says who? As far as I know, we don't define "maintenance mode" in Apache Commons; nothing I know of is in such a mode. We have "dormant" components and the attic does not apply to individual components, only projects. > 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=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)
Re: [PR] Added '-' as an option char and implemented extensive tests [commons-cli]
garydgregory commented on PR #217: URL: https://github.com/apache/commons-cli/pull/217#issuecomment-1880987515 @Claudenw I think you mean "kabab" -> "kebab". Always run `mvn` before you push with the latest from git master. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[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=17804268#comment-17804268 ] Gary D. Gregory commented on CLI-322: - [~claude] "kabab" -> "kebab" right? > 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] [Created] (CLI-322) Allow kabab-case options
Claude Warren created CLI-322: - Summary: 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 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] [Updated] (CLI-322) Allow kabab-case options
[ https://issues.apache.org/jira/browse/CLI-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claude Warren updated CLI-322: -- Assignee: Claude Warren > 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] [Created] (COLLECTIONS-851) Document AbstractHashedMap does not compensate for key collisions
Arnout Engelen created COLLECTIONS-851: -- Summary: Document AbstractHashedMap does not compensate for key collisions Key: COLLECTIONS-851 URL: https://issues.apache.org/jira/browse/COLLECTIONS-851 Project: Commons Collections Issue Type: Wish Components: Map Reporter: Arnout Engelen The various AbstractHashedMap implementations do not compensate for scenario's where many values map to the same hash bucket. This means these collections are not suitable for situations where untrusted users can add values for arbitrary keys, as they could cause disproportionate resource usage. This is not necessarily a problem, but it would be good to document this in the API docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] modifying data size in DigestUtilsTest to speed up MessageDigestAlgor… [commons-codec]
garydgregory commented on PR #229: URL: https://github.com/apache/commons-codec/pull/229#issuecomment-1880893364 @aherbert That sounds good. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] modifying data size in DigestUtilsTest to speed up MessageDigestAlgor… [commons-codec]
aherbert commented on PR #229: URL: https://github.com/apache/commons-codec/pull/229#issuecomment-1880884744 Note: The `DigestTestUtils` and `MessageDigestAlgorithmsTest` classes are creating a random `byte[]` and writing it to two files for every method. If this behaviour is changed from `Before/AfterEach` to `Before/AfterAll` (with use of static data) then I observe an speed-up of 20%. Since the data is non-destructively used, then a simple switch to make the `testFile` and `testRandomAccessFile` the same saves 10% by requiring 1 less file write per test fixture. Given the limited impact of optimising the test resources, the major runtime of the test is the actual digest of the megabyte of random data. The internal buffer size in `DigestUtils` is 1024. So if the test data is changed then it should be larger than this size. The suggested 32*32 (1024) is too small to require looping within `DigestUtils` when digesting a `FileChannel` or `InputStream`. I would suggest updating the tests to use a single source of random data created once. The size can be reduced to improve speed but it should not compromise testing of the digest algorithms. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Avoid NullPointerException in TiffImageParser.getBufferedImage() [commons-imaging]
garydgregory commented on PR #347: URL: https://github.com/apache/commons-imaging/pull/347#issuecomment-1880834407 @nanfangfanqie Great. I am planning a 1.0.0-M1 release within a week or so. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] modifying data size in DigestUtilsTest to speed up MessageDigestAlgor… [commons-codec]
garydgregory commented on PR #229: URL: https://github.com/apache/commons-codec/pull/229#issuecomment-1880826895 -1: The test data variable contains "randomized" data, and taking your argument further, we could make the array size 1, which would reduce even more the randomness of the data. Of course, using randomized data can be argued back and forth but that's an additional way to test. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] modifying data size in DigestUtilsTest to speed up MessageDigestAlgor… [commons-codec]
TestImprove opened a new pull request, #229: URL: https://github.com/apache/commons-codec/pull/229 The runtime of the test class `MessageDigestAlgorithmsTest` can be improved by modifying the data array size in `DigestUtilsTest`. The byte array returned by `getTestData()` comes from DigestUtilsTest and has a size of `1024 * 1024`. When this array size is reduced to `32 * 32`, for example, the runtime of the `MessageDigestAlgorithmsTest` test class drops from `7.046 s` to `1.032 s` on our local machine. We propose not to make the tests in `MessageDigestAlgorithmsTest.java` rely on the data created by `DigestUtilsTest.java`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Avoid NullPointerException in TiffImageParser.getBufferedImage() [commons-imaging]
nanfangfanqie commented on PR #347: URL: https://github.com/apache/commons-imaging/pull/347#issuecomment-1880761753 > @nanfangfanqie Please try a local build of git master or a snapshot build from https://repository.apache.org/content/repositories/snapshots/ so we can compare a new stack trace to the current code. @garydgregory Everything is well , the error never occurs !!! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
