[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)
[GitHub] [commons-lang] PiMaDaum commented on pull request #992: NumberUtils check if Number is null or zero
PiMaDaum commented on PR #992: URL: https://github.com/apache/commons-lang/pull/992#issuecomment-1331475163 Sorry, I have forget to comment the new method and clean unused imports. -- 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
[GitHub] [commons-lang] PiMaDaum closed pull request #992: NumberUtils check if Number is null or zero
PiMaDaum closed pull request #992: NumberUtils check if Number is null or zero URL: https://github.com/apache/commons-lang/pull/992 -- 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
[GitHub] [commons-lang] codecov-commenter commented on pull request #992: NumberUtils check if Number is null or zero
codecov-commenter commented on PR #992: URL: https://github.com/apache/commons-lang/pull/992#issuecomment-1331461814 # [Codecov](https://codecov.io/gh/apache/commons-lang/pull/992?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#992](https://codecov.io/gh/apache/commons-lang/pull/992?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (2a512ee) into [master](https://codecov.io/gh/apache/commons-lang/commit/770e72d2f78361b14f3fe27caea41e5977d3c638?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (770e72d) will **increase** coverage by `0.00%`. > The diff coverage is `100.00%`. ```diff @@Coverage Diff@@ ## master #992 +/- ## = Coverage 92.04% 92.05% - Complexity 7430 7434+4 = Files 193 193 Lines 1567415675+1 Branches 2898 2898 = + Hits 1442714429+2 Misses 674 674 + Partials573 572-1 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-lang/pull/992?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...ava/org/apache/commons/lang3/math/NumberUtils.java](https://codecov.io/gh/apache/commons-lang/pull/992/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvbGFuZzMvbWF0aC9OdW1iZXJVdGlscy5qYXZh) | `95.03% <100.00%> (+0.01%)` | :arrow_up: | | [...apache/commons/lang3/reflect/ConstructorUtils.java](https://codecov.io/gh/apache/commons-lang/pull/992/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvbGFuZzMvcmVmbGVjdC9Db25zdHJ1Y3RvclV0aWxzLmphdmE=) | `86.00% <0.00%> (+2.00%)` | :arrow_up: | :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) -- 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] [Created] (COMPRESS-635) switch system.err/system.out printlns to be log4j logging
PJ Fanning created COMPRESS-635: --- Summary: 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 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)
[GitHub] [commons-compress] garydgregory closed pull request #303: [SECURITY] Fix Zip Slip Vulnerability
garydgregory closed pull request #303: [SECURITY] Fix Zip Slip Vulnerability URL: https://github.com/apache/commons-compress/pull/303 -- 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
[GitHub] [commons-compress] garydgregory commented on pull request #303: [SECURITY] Fix Zip Slip Vulnerability
garydgregory commented on PR #303: URL: https://github.com/apache/commons-compress/pull/303#issuecomment-1331448704 Closing, tests are not a security risk. -- 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
[GitHub] [commons-bcel] nbauma109 commented on pull request #178: verifier tests on various opcodes and fixed typo testCommonsLang1->2
nbauma109 commented on PR #178: URL: https://github.com/apache/commons-bcel/pull/178#issuecomment-1331324271 Coverage report didn't show up. Check here https://github.com/nbauma109/commons-bcel/pull/24. -- 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
[GitHub] [commons-exec] arturobernalg commented on pull request #27: [EXEC-114] - Migrate to Junit 5
arturobernalg commented on PR #27: URL: https://github.com/apache/commons-exec/pull/27#issuecomment-1331293219 > @arturobernalg > Hi, > This component is now on Java 8. Hey @garydgregory I think its already done. TY -- 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
[GitHub] [commons-compress] kinow merged pull request #333: Bump slf4j-api from 2.0.4 to 2.0.5
kinow merged PR #333: URL: https://github.com/apache/commons-compress/pull/333 -- 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] [Resolved] (COMPRESS-623) make ZipFile's getRawInputStream usable when local headers are not read
[ https://issues.apache.org/jira/browse/COMPRESS-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved COMPRESS-623. -- Fix Version/s: 1.23 Resolution: Fixed > make ZipFile's getRawInputStream usable when local headers are not read > --- > > Key: COMPRESS-623 > URL: https://issues.apache.org/jira/browse/COMPRESS-623 > Project: Commons Compress > Issue Type: Improvement >Reporter: Dawid Weiss >Priority: Minor > Fix For: 1.23 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > I have a somewhat odd use case with gigabytes of ZIP files, each with > thousands of documents (on comparatively slow, network drives). We need to > restructure these ZIPs without the need to recompress files. > The above turns out to work almost perfectly with raw-data copying ZipFile > offers but empirical tests showed a major slowdown in the initial opening of > zip files, linked to multiple reads/seeks for local file headers. If an > option is passed to ignore those headers, raw streams are inaccessible. > I've taken a look at the code and the code in getRawInputStream could > basically do the same thing that getInputStream does - lazily load the > missing offset via getDataOffset(ZipEntry). In fact, getInputStream could > just call getRawInputStream directly, which avoids some code duplication. > I see speedups for opening and copying random raw streams in the order of > 3-4x and all the current tests pass. I filed a PR at github - happy to > discuss it there. > [https://github.com/apache/commons-compress/pull/306] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work logged] (COMPRESS-623) make ZipFile's getRawInputStream usable when local headers are not read
[ https://issues.apache.org/jira/browse/COMPRESS-623?focusedWorklogId=829840&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-829840 ] ASF GitHub Bot logged work on COMPRESS-623: --- Author: ASF GitHub Bot Created on: 29/Nov/22 18:12 Start Date: 29/Nov/22 18:12 Worklog Time Spent: 10m Work Description: garydgregory merged PR #306: URL: https://github.com/apache/commons-compress/pull/306 Issue Time Tracking --- Worklog Id: (was: 829840) Time Spent: 2h 20m (was: 2h 10m) > make ZipFile's getRawInputStream usable when local headers are not read > --- > > Key: COMPRESS-623 > URL: https://issues.apache.org/jira/browse/COMPRESS-623 > Project: Commons Compress > Issue Type: Improvement >Reporter: Dawid Weiss >Priority: Minor > Time Spent: 2h 20m > Remaining Estimate: 0h > > I have a somewhat odd use case with gigabytes of ZIP files, each with > thousands of documents (on comparatively slow, network drives). We need to > restructure these ZIPs without the need to recompress files. > The above turns out to work almost perfectly with raw-data copying ZipFile > offers but empirical tests showed a major slowdown in the initial opening of > zip files, linked to multiple reads/seeks for local file headers. If an > option is passed to ignore those headers, raw streams are inaccessible. > I've taken a look at the code and the code in getRawInputStream could > basically do the same thing that getInputStream does - lazily load the > missing offset via getDataOffset(ZipEntry). In fact, getInputStream could > just call getRawInputStream directly, which avoids some code duplication. > I see speedups for opening and copying random raw streams in the order of > 3-4x and all the current tests pass. I filed a PR at github - happy to > discuss it there. > [https://github.com/apache/commons-compress/pull/306] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-compress] garydgregory merged pull request #306: COMPRESS-623: make ZipFile's getRawInputStream usable when local headers are not read
garydgregory merged PR #306: URL: https://github.com/apache/commons-compress/pull/306 -- 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
[GitHub] [commons-compress] dependabot[bot] opened a new pull request, #333: Bump slf4j-api from 2.0.4 to 2.0.5
dependabot[bot] opened a new pull request, #333: URL: https://github.com/apache/commons-compress/pull/333 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 2.0.4 to 2.0.5. Commits https://github.com/qos-ch/slf4j/commit/7e62e1e6917e19e6eeb8faf97daa9e2469bc946d";>7e62e1e prepare release 2.0.5 https://github.com/qos-ch/slf4j/commit/d250ad79ebbd46f098b07c0868d1cbc8c09c8d6c";>d250ad7 in jcl-over-slf4j rename LICENSE.TXT as LICENSE, add LICENSE file to log4j-ov... https://github.com/qos-ch/slf4j/commit/3bc58f3e81cfbe5ef9011c5124c0bd13dceee3a9";>3bc58f3 add SecurityManager support https://github.com/qos-ch/slf4j/commit/207bb299c319886aededb999269c1555abb9deae";>207bb29 start work on 2.0.5-SNAPSHOT See full diff in https://github.com/qos-ch/slf4j/compare/v_2.0.4...v_2.0.5";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Resolved] (VFS-828) Dependency hadoop-hdfs-client should be optional
[ https://issues.apache.org/jira/browse/VFS-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-828. - Resolution: Fixed It already is, see git master. > Dependency hadoop-hdfs-client should be optional > > > Key: VFS-828 > URL: https://issues.apache.org/jira/browse/VFS-828 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.9.0 >Reporter: Michael Gorovoy >Priority: Minor > Fix For: 2.10.0 > > > Hadoop HDFS Client library dependency needs to be marked as optional to avoid > creating a transitive dependency if HDFS is not being used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NET-717) FTPClient: Encapsulate completePendingCommand in returned outputstream
Julien Béti created NET-717:
---
Summary: FTPClient: Encapsulate completePendingCommand in returned
outputstream
Key: NET-717
URL: https://issues.apache.org/jira/browse/NET-717
Project: Commons Net
Issue Type: Improvement
Components: FTP
Reporter: Julien Béti
Most store / retrieve methods in {{FTPClient}} class requires a call to
{{completePendingCommand}} method in order to make sure that the operation
completed successfully, and allow additional operations to go on.
This is clearly documented, but often lead to clumsy code as 99% of the time we
just need to know if the file operation executed successfully or not (and in
some case, the {{completePendingCommand}} is simply forgotten leading to, as
documented, unexpected behavior of subsequent commands.
The idea would be to return a {{FilterOutputStream}} / {{FilterInputStream}}
that would encapsulates the returned {{OutputStream}}/{{InputStream}} returned
by methods that need a subsequent call to {{completePendingCommand}}. These
filter implementations would call the {{completePendingCommand}} method on
{{close}}, throwing an {{IOException}} if it returns false.
{code:java}
package org.apache.commons.net.ftp;
import java.io.FilterOutputStream;
import java.io.IOException;
import java.io.OutputStream;
public class FTPOutputStream extends FilterOutputStream {
private final FTPClient ftpClient;
public FTPOutputStream(OutputStream out, FTPClient ftpClient) {
super(out);
this.ftpClient = ftpClient;
}
@Override
public void close() throws IOException {
super.close();
if(!ftpClient.completePendingCommand()) {
throw new IOException("FTP Client was unable to complete pending
command");
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-vfs] garydgregory merged pull request #339: Bump commons.pmd.version from 6.51.0 to 6.52.0
garydgregory merged PR #339: URL: https://github.com/apache/commons-vfs/pull/339 -- 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
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request, #340: Bump checkstyle from 9.3 to 10.5.0
dependabot[bot] opened a new pull request, #340: URL: https://github.com/apache/commons-vfs/pull/340 Bumps [checkstyle](https://github.com/checkstyle/checkstyle) from 9.3 to 10.5.0. Release notes Sourced from https://github.com/checkstyle/checkstyle/releases";>checkstyle's releases. checkstyle-10.5.0 Checkstyle 10.5.0 - https://checkstyle.org/releasenotes.html#Release_10.5.0";>https://checkstyle.org/releasenotes.html#Release_10.5.0 New: https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/11644";>#11644 - Allow 3rd party Check providers to group modules under custom parent module Bug fixes: https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/12443";>#12443 - checkstyle 10.3.3 and newer throws NullPointerException on annotated generic types from IllegalType rule https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/12345";>#12345 - False positive in NoWhiteSpaceAfter https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/12291";>#12291 - EmptyForInitializerPad: ArrayIndexOutOfBoundsException checkstyle-10.4 Checkstyle 10.4 - https://checkstyle.org/releasenotes.html#Release_10.4";>https://checkstyle.org/releasenotes.html#Release_10.4 Breaking backward compatibility: ... (truncated) Commits https://github.com/checkstyle/checkstyle/commit/dbeb9024c861ad11b194e40d8c6e08d7e6ec5122";>dbeb902 [maven-release-plugin] prepare release checkstyle-10.5.0 https://github.com/checkstyle/checkstyle/commit/9051f224167d3226c3b82f59639a020c8224df43";>9051f22 doc: releasenotes 10.5.0 https://github.com/checkstyle/checkstyle/commit/e9e79c310024480b0487fcfd0bd864a97bfc2d30";>e9e79c3 minor: moves codenarc under config https://github.com/checkstyle/checkstyle/commit/4288c3b4c35483c44b2da0e846af8038701e53ba";>4288c3b minor: moves release settings under config https://github.com/checkstyle/checkstyle/commit/2ea02957d304d3652c3aa175b70987ecac88661f";>2ea0295 minor: moves projects to test on under config https://github.com/checkstyle/checkstyle/commit/a84418770e0b57a52b556ef1ee736091196fef67";>a844187 Issue https://github-redirect.dependabot.com/checkstyle/checkstyle/issues/12441";>#12441: Resolve Pitest suppression for RightCurlyCheck https://github.com/checkstyle/checkstyle/commit/858dcaa32a00038a157390ace599d9732ca86d7b";>858dcaa minor: moves jsoref spellchecker under config https://github.com/checkstyle/checkstyle/commit/72fa0536c643e56934cb7095061150ebf17a84e6";>72fa053 minor: moves pitest suppressions under config https://github.com/checkstyle/checkstyle/commit/495594e3d4febf38c379326436b3d05fa63c0e0b";>495594e minor: moves error prone suppressions under config https://github.com/checkstyle/checkstyle/commit/b2e49dd2a0e313db887d4bf88d92f2addd3bed85";>b2e49dd minor: moves checker framework suppressions under config Additional commits viewable in https://github.com/checkstyle/checkstyle/compare/checkstyle-9.3...checkstyle-10.5.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request, #339: Bump commons.pmd.version from 6.51.0 to 6.52.0
dependabot[bot] opened a new pull request, #339: URL: https://github.com/apache/commons-vfs/pull/339 Bumps `commons.pmd.version` from 6.51.0 to 6.52.0. Updates `pmd-core` from 6.51.0 to 6.52.0 Release notes Sourced from https://github.com/pmd/pmd/releases";>pmd-core's releases. PMD 6.52.0 (26-November-2022) 26-November-2022 - 6.52.0 The PMD team is pleased to announce PMD 6.52.0. This is a minor release. Table Of Contents https://github.com/pmd/pmd/blob/HEAD/#new-and-noteworthy";>New and noteworthy https://github.com/pmd/pmd/blob/HEAD/#new-rules";>New rules https://github.com/pmd/pmd/blob/HEAD/#renamed-rules";>Renamed rules https://github.com/pmd/pmd/blob/HEAD/#modified-rules";>Modified rules https://github.com/pmd/pmd/blob/HEAD/#fixed-issues";>Fixed Issues https://github.com/pmd/pmd/blob/HEAD/#api-changes";>API Changes https://github.com/pmd/pmd/blob/HEAD/#pmd-cli";>PMD CLI https://github.com/pmd/pmd/blob/HEAD/#cpd-cli";>CPD CLI https://github.com/pmd/pmd/blob/HEAD/#linux-run.sh-parameters";>Linux run.sh parameters https://github.com/pmd/pmd/blob/HEAD/#deprecated-api";>Deprecated API https://github.com/pmd/pmd/blob/HEAD/#external-contributions";>External Contributions https://github.com/pmd/pmd/blob/HEAD/#stats";>Stats New and noteworthy New rules The new Java rule https://pmd.github.io/pmd-6.52.0/pmd_rules_java_design.html#invalidjavabean";>InvalidJavaBean identifies beans, that don't follow the https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/";>JavaBeans API specification, like beans with missing getters or setters.Renamed rules The Java rule https://pmd.github.io/pmd-6.52.0/pmd_rules_java_errorprone.html#beanmembersshouldserialize";>BeanMembersShouldSerialize has been renamed to https://pmd.github.io/pmd-6.52.0/pmd_rules_java_errorprone.html#nonserializableclass";>NonSerializableClass. It has been revamped to only check for classes that are marked with Serializable and reports each field in it, that is not serializable. The property prefix has been deprecated, since in a serializable class all fields have to be serializable regardless of the name. Modified rules The rule https://pmd.github.io/pmd-6.52.0/pmd_rules_java_codestyle.html#classnamingconventions";>ClassNamingConventions has a new property testClassPattern, which is applied to test classes. By default, test classes should end with the suffix "Test". Test classes are top-level classes, that either inherit from JUnit 3 TestCase or have at least one method annotated with the Test annotations from JUnit4/5 or TestNG. ... (truncated) Commits https://github.com/pmd/pmd/commit/e90bf0f11b5458593358f6b36f88815218b5c9f7";>e90bf0f [maven-release-plugin] prepare release pmd_releases/6.52.0 https://github.com/pmd/pmd/commit/6f64edf7141c9fefceb6e3d74101ba2ee4ba486b";>6f64edf Prepare pmd release 6.52.0 https://github.com/pmd/pmd/commit/9c42eba8b568b6da01c130b19c4a3e19fd5ba739";>9c42eba Add https://github.com/nvervelle";>@nvervelle as a contributor https://github.com/pmd/pmd/commit/335a12fe1b3aa855e791ba88ea3128f2dab4ab98";>335a12f Add https://github.com/mihalyr";>@mihalyr as a contributor https://github.com/pmd/pmd/commit/8f2ce2408e82449b58915eca176eb5fcc064a70c";>8f2ce24 Add https://github.com/ctoomey";>@ctoomey as a contributor https://github.com/pmd/pmd/commit/8b71fe6fd6b2a006cec88a28ad261f57a759c687";>8b71fe6 Merge pull request https://github-redirect.dependabot.com/pmd/pmd/issues/4231";>#4231 from adangel:issue-4175-ImmutableField-deprecate-ign... https://github.com/pmd/pmd/commit/93587f0b1fcdbc8cb3842ee536a9d69c183bda9d";>93587f0 Merge pull request https://github-redirect.dependabot.com/pmd/pmd/issues/4203";>#4203 from adangel:issue-4177-InvalidJavaBean https://github.com/pmd/pmd/commit/9be37acaeb7a4d8a42f7c70de91f38a3255c554d";>9be37ac Merge pull request https://github-redirect.dependabot.com/pmd/pmd/issues/4196";>#4196 from adangel:issue-4176-NonSerializableClass https://github.com/pmd/pmd/commit/8a5d9641763214647294e6f39364492744895dff";>8a5d964 [java] Restore BeanMembersShouldSerializeRule as deprecated class https://github.com/pmd/pmd/commit/44cc43ce2b60af1dc52731597beff674a59488a1";>44cc43c Merge pull request https://github-redirect.dependabot.com/pmd/pmd/issues/4232";>#4232 from deining:fix/typos Additional commits viewable in https://github.com/pmd/pmd/compare/pmd_releases/6.51.0...pmd_releases/6.52.0";>compare view Updates `pmd-java` from 6.51.0 to 6.52.0 Release notes Sourced from https://github.com/pmd/pmd/releases";>pmd-java's releases. PMD 6.52.0 (26-November-2022) 26-November-2022 - 6.52.0 The PMD team is pleased to announce PM
[GitHub] [commons-vfs] dependabot[bot] opened a new pull request, #338: Bump slf4j-simple from 1.7.26 to 2.0.5
dependabot[bot] opened a new pull request, #338: URL: https://github.com/apache/commons-vfs/pull/338 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.26 to 2.0.5. Commits https://github.com/qos-ch/slf4j/commit/7e62e1e6917e19e6eeb8faf97daa9e2469bc946d";>7e62e1e prepare release 2.0.5 https://github.com/qos-ch/slf4j/commit/d250ad79ebbd46f098b07c0868d1cbc8c09c8d6c";>d250ad7 in jcl-over-slf4j rename LICENSE.TXT as LICENSE, add LICENSE file to log4j-ov... https://github.com/qos-ch/slf4j/commit/3bc58f3e81cfbe5ef9011c5124c0bd13dceee3a9";>3bc58f3 add SecurityManager support https://github.com/qos-ch/slf4j/commit/207bb299c319886aededb999269c1555abb9deae";>207bb29 start work on 2.0.5-SNAPSHOT https://github.com/qos-ch/slf4j/commit/35dd7ff1e75cf83ffb6784a9537ff92c865e78b2";>35dd7ff removed unused META-INF/services entry https://github.com/qos-ch/slf4j/commit/440c2f3000fc0e2d7646f0b3d6e36e8bc2ef2485";>440c2f3 prepare release 2.0.4 https://github.com/qos-ch/slf4j/commit/43a36303e5a2338c22ec9aad5b01a401034eb553";>43a3630 use the class loader that loaded LoggerFactory (instead of the threadContextC... https://github.com/qos-ch/slf4j/commit/557bf7c0bd4e2c2cd85ef389729107461938dd15";>557bf7c [SLF4J-548] Fix ServiceLoader usage in servlet environment https://github.com/qos-ch/slf4j/commit/632410565b26e4d67fc7ef2ce4c212380b4e59d1";>6324105 enhance manifest with capabilities https://github.com/qos-ch/slf4j/commit/e540299d58bc5f53cab3236cc1b2f29281982074";>e540299 edit blurb on release championing Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.26...v_2.0.5";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [commons-bcel] nbauma109 commented on a diff in pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034761303
##
src/test/resources/StackMapExample2.java:
##
@@ -0,0 +1,8 @@
+public class StackMapExample2 {
+
Review Comment:
Commented rather than javadoc-ed as it is test input.
--
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
[GitHub] [commons-bcel] nbauma109 commented on pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on PR #177: URL: https://github.com/apache/commons-bcel/pull/177#issuecomment-1330659897 > @nbauma109 Rebase on git master to pick up `StackMapTest`. Done -- 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
[GitHub] [commons-bcel] nbauma109 commented on a diff in pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034748724
##
src/main/java/org/apache/bcel/classfile/Code.java:
##
@@ -247,6 +247,20 @@ public LineNumberTable getLineNumberTable() {
return null;
}
+/**
+ * Finds the first attribute of {@link StackMap} instance.
+ * @return StackMap of Code, if it has one, else null.
+ * @since 6.7.1
+ */
+public StackMap getStackMap() {
Review Comment:
Yes. Removed "first".
--
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
[GitHub] [commons-bcel] garydgregory commented on a diff in pull request #177: Bcelifier stackmap support verifier
garydgregory commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034747557
##
src/main/java/org/apache/bcel/classfile/Code.java:
##
@@ -247,6 +247,20 @@ public LineNumberTable getLineNumberTable() {
return null;
}
+/**
+ * Finds the first attribute of {@link StackMap} instance.
+ * @return StackMap of Code, if it has one, else null.
+ * @since 6.7.1
+ */
+public StackMap getStackMap() {
Review Comment:
Ah, ok, then it's the comment that needs updating IMO, as "first" makes it
sound like there can be more than one.
--
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
[GitHub] [commons-bcel] nbauma109 commented on a diff in pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034720605
##
src/main/java/org/apache/bcel/classfile/Code.java:
##
@@ -247,6 +247,20 @@ public LineNumberTable getLineNumberTable() {
return null;
}
+/**
+ * Finds the first attribute of {@link StackMap} instance.
+ * @return StackMap of Code, if it has one, else null.
+ * @since 6.7.1
+ */
+public StackMap getStackMap() {
Review Comment:
There may be at most one StackMapTable attribute in the attributes table of
a Code attribute.
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.7.4
--
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
[GitHub] [commons-bcel] garydgregory commented on pull request #177: Bcelifier stackmap support verifier
garydgregory commented on PR #177: URL: https://github.com/apache/commons-bcel/pull/177#issuecomment-1330604892 @nbauma109 Rebase on git master to pick up `StackMapTest`. -- 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
[GitHub] [commons-bcel] codecov-commenter commented on pull request #177: Bcelifier stackmap support verifier
codecov-commenter commented on PR #177: URL: https://github.com/apache/commons-bcel/pull/177#issuecomment-1330603035 # [Codecov](https://codecov.io/gh/apache/commons-bcel/pull/177?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report > Merging [#177](https://codecov.io/gh/apache/commons-bcel/pull/177?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (815a322) into [master](https://codecov.io/gh/apache/commons-bcel/commit/b015e90257850e810e57d1244664300f50de4a4c?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (b015e90) will **increase** coverage by `0.24%`. > The diff coverage is `100.00%`. ```diff @@ Coverage Diff @@ ## master #177 +/- ## + Coverage 61.64% 61.89% +0.24% - Complexity 3654 3684 +30 Files 363 363 Lines 1563315700 +67 Branches 1950 1958 +8 + Hits 9637 9717 +80 + Misses 5122 5102 -20 - Partials874 881 +7 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-bcel/pull/177?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...c/main/java/org/apache/bcel/classfile/Visitor.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL1Zpc2l0b3IuamF2YQ==) | `0.00% <ø> (ø)` | | | [src/main/java/org/apache/bcel/classfile/Code.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL0NvZGUuamF2YQ==) | `73.00% <100.00%> (+1.12%)` | :arrow_up: | | [...a/org/apache/bcel/classfile/DescendingVisitor.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL0Rlc2NlbmRpbmdWaXNpdG9yLmphdmE=) | `94.40% <100.00%> (+0.12%)` | :arrow_up: | | [...n/java/org/apache/bcel/classfile/EmptyVisitor.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL0VtcHR5VmlzaXRvci5qYXZh) | `95.00% <100.00%> (+0.08%)` | :arrow_up: | | [...n/java/org/apache/bcel/classfile/StackMapType.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL1N0YWNrTWFwVHlwZS5qYXZh) | `69.76% <100.00%> (+4.76%)` | :arrow_up: | | [src/main/java/org/apache/bcel/util/BCELifier.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvdXRpbC9CQ0VMaWZpZXIuamF2YQ==) | `97.28% <100.00%> (+0.85%)` | :arrow_up: | | [.../java/org/apache/bcel/classfile/StackMapEntry.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL1N0YWNrTWFwRW50cnkuamF2YQ==) | `52.48% <0.00%> (+3.86%)` | :arrow_up: | | [.../main/java/org/apache/bcel/classfile/StackMap.java](https://codecov.io/gh/apache/commons-bcel/pull/177/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL1N0YWNrTWFwLmphdmE=) | `82.05% <0.00%> (+12.82%)` | :arrow_up: | :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral&utm_source=gi
[GitHub] [commons-bcel] nbauma109 commented on a diff in pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034705119
##
src/main/java/org/apache/bcel/classfile/StackMapType.java:
##
@@ -29,9 +29,9 @@
* @see StackMap
* @see Const
*/
-public final class StackMapType implements Cloneable {
+public final class StackMapType implements Node, Cloneable {
-public static final StackMapType[] EMPTY_ARRAY = {}; // must be public
because BCELifier code generator writes calls to it
+static final StackMapType[] EMPTY_ARRAY = {}; // package visibility as
BCELifier code generator writes calls to constructor translating null to
EMPTY_ARRAY
Review Comment:
Ah sorry about this. Putting it back to public.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[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)
[GitHub] [commons-bcel] nbauma109 commented on a diff in pull request #177: Bcelifier stackmap support verifier
nbauma109 commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034702240
##
src/main/java/org/apache/bcel/classfile/StackMap.java:
##
@@ -135,7 +135,7 @@ public StackMapEntry[] getStackMap() {
public void setStackMap(final StackMapEntry[] table) {
this.table = table != null ? table : StackMapEntry.EMPTY_ARRAY;
int len = 2; // Length of 'number_of_entries' field prior to the array
of stack maps
-for (final StackMapEntry element : this.table) {
+for (final StackMapEntry element : table) {
Review Comment:
Yes. I've just re-integrated the lost NPE fix.
--
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
[GitHub] [commons-bcel] garydgregory commented on a diff in pull request #177: Bcelifier stackmap support verifier
garydgregory commented on code in PR #177:
URL: https://github.com/apache/commons-bcel/pull/177#discussion_r1034692847
##
src/test/resources/StackMapExample2.java:
##
@@ -0,0 +1,8 @@
+public class StackMapExample2 {
+
Review Comment:
Javadoc what this tests.
##
src/main/java/org/apache/bcel/classfile/StackMap.java:
##
@@ -135,7 +135,7 @@ public StackMapEntry[] getStackMap() {
public void setStackMap(final StackMapEntry[] table) {
this.table = table != null ? table : StackMapEntry.EMPTY_ARRAY;
int len = 2; // Length of 'number_of_entries' field prior to the array
of stack maps
-for (final StackMapEntry element : this.table) {
+for (final StackMapEntry element : table) {
Review Comment:
This creates an NPE.
##
src/main/java/org/apache/bcel/classfile/StackMapType.java:
##
@@ -29,9 +29,9 @@
* @see StackMap
* @see Const
*/
-public final class StackMapType implements Cloneable {
+public final class StackMapType implements Node, Cloneable {
-public static final StackMapType[] EMPTY_ARRAY = {}; // must be public
because BCELifier code generator writes calls to it
+static final StackMapType[] EMPTY_ARRAY = {}; // package visibility as
BCELifier code generator writes calls to constructor translating null to
EMPTY_ARRAY
Review Comment:
You can't make something public, not public, this will break BC, you can't
tell now because we are in the middle of a release.
##
src/main/java/org/apache/bcel/classfile/Code.java:
##
@@ -247,6 +247,20 @@ public LineNumberTable getLineNumberTable() {
return null;
}
+/**
+ * Finds the first attribute of {@link StackMap} instance.
+ * @return StackMap of Code, if it has one, else null.
+ * @since 6.7.1
+ */
+public StackMap getStackMap() {
Review Comment:
Should this be called getFirstStackMap()?
--
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
[GitHub] [commons-bcel] nbauma109 opened a new pull request, #177: Bcelifier stackmap support verifier
nbauma109 opened a new pull request, #177: URL: https://github.com/apache/commons-bcel/pull/177 * Bcelifier stackmap support * BCELifier generates the stack map table so that the generated class passes the Java verifier checks. * added some test inputs StackMapExample and StackMapExample2 compiled in JDK8 * Updated BCELifierTestCase.java: added testStackMap * StackMapType.EMPTY_ARRAY in package visibility and updated BinaryOpCreator.java accordingly Co-authored-by: nbauma109 -- 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] (VALIDATOR-487) EmailValidator validates too much
[
https://issues.apache.org/jira/browse/VALIDATOR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640652#comment-17640652
]
Gary D. Gregory commented on VALIDATOR-487:
---
Should we have different validation for different RFCs?
> 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] [Comment Edited] (JEXL-388) v3.3-SNAPSHOT doesn't find public getter as property
[
https://issues.apache.org/jira/browse/JEXL-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640643#comment-17640643
]
Henri Biestro edited comment on JEXL-388 at 11/29/22 12:06 PM:
---
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
...permissions(JexlPermissions.UNRESTRICTED) .create();
{code}
Or more globall, before creating the builder:
{code}
JexlBuilder.setDefaultPermissions(JexlPermissions.UNRESTRICTED);
{code}
Btw, any comment on [JEXL-342|https://issues.apache.org/jira/browse/JEXL-342]?
was (Author: henrib):
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
...permissions(JexlPermissions.UNRESTRICTED) .create();
{code}
Btw, any comment on [JEXL-342|https://issues.apache.org/jira/browse/JEXL-342]?
> v3.3-SNAPSHOT doesn't find public getter as property
>
>
> Key: JEXL-388
> URL: https://issues.apache.org/jira/browse/JEXL-388
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: Java 17; Windows 10
>Reporter: Garret Wilson
>Priority: Major
>
> In my [Guise Mummy|https://github.com/globalmentor/guise-mummy] static site
> generator I'm using JEXL to interpret the built-in [Mesh Expression
> Language|https://github.com/globalmentor/guise-mummy/tree/main/mesh] (MEXL).
> Everything was working fine with JEXL 3.1. In fact the entire [Guise Mummy
> web site|https://guise.io/mummy/] itself was produced using Guise Mummy with
> MEXL on top of JEXL. But when I upgrade to JEXL 3.3-SNAPSHOT, a couple of
> unit tests break. In particular, the new version doesn't seem to find a
> public getter method on a custom public class as a property.
> In the Mesh templating, we have an {{mx:each}} attribute (similar to JSP or
> Thymeleaf) which loops through and replicates some HTML element (e.g. an
> {{}} inside an {{}}) for each value in a list. It assigns each value,
> one at a time, to a variable {{it}} in the context. That is working fine. But
> on each iteration it also assigns {{iter}} in the context, with the value
> being an instance of
> [{{MeshIterator}}|https://github.com/globalmentor/guise-mummy/blob/main/mesh/src/main/java/io/guise/mesh/MeshIterator.java].
> That object has, among other things, {{getCurrent()}}:
> {code:java}
> /**
> * Returns the current item. This will be the result of the last successful
> call to {@link #next()}.
> * @throws NoSuchElementException if iteration has not yet started.
> * @return The current item.
> */
> public Object getCurrent() { ... }
> {code}
> To make a long story short, the MEXL expression should be able to use
> {{iter.current}} to get the value, but it's not finding it. I traced through
> the new code, and it's finding the {{MeshIterator}} instance just fine and
> assigning it to {{iter}}. The problem is that JEXL's {{ClassMap}} (probably
> inside {{create()}}) is not finding and caching {{getCurrent()}} mapped to
> the {{current}} property.
> It looks like {{Permissions.allow()}} for method
> {{MeshIterator.getCurrent()}}, is falling through to the end and returning
> {{explicit[0]}}, which happens to be {{false}}. It looks like this comes from
> {{wildcardAllow(Class clazz)}}, which eventually calls
> {{wildcardAllow(Set allowed, String name)}}. There's what I presume
> to be a set of allowed packages. Is that new? Do we have to explicitly
> provide a list of allowed packages for property discovery via reflection now?
> To reproduce this:
> # Clone [Guise Mummy
> 0.5.3|https://github.com/globalmentor/guise-mummy/releases/tag/v0.5.3].
> # In the overall project {{pom.xml}}, change the version of
> {{org.apache.commons:commons-jexl3}} from {{3.1}} to
> {{3.3-SNAPSHOT}}. (You'll also need to add the
> {{https://repository.apache.org/content/repositories/snapshots/}} repository
> in the POM.)
> # Run {{mvn clean verify}}.
> You'll see that {{io.guise.mesh.GuiseMeshTest.testMxEachWithIterVar()}} will
> fail because {{iter.current}} can't be found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-388) v3.3-SNAPSHOT doesn't find public getter as property
[
https://issues.apache.org/jira/browse/JEXL-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640643#comment-17640643
]
Henri Biestro edited comment on JEXL-388 at 11/29/22 12:04 PM:
---
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
...permissions(JexlPermissions.UNRESTRICTED) .create();
{code}
Btw, any comment on [JEXL-342|https://issues.apache.org/jira/browse/JEXL-342]?
was (Author: henrib):
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
.permissions(JexlPermissions.UNRESTRICTED)
.sandbox(sandbox)
.safe(false)
.strict(true)
.create();
{code}
Btw, any comment on [JEXL-342|https://issues.apache.org/jira/browse/JEXL-342]?
> v3.3-SNAPSHOT doesn't find public getter as property
>
>
> Key: JEXL-388
> URL: https://issues.apache.org/jira/browse/JEXL-388
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: Java 17; Windows 10
>Reporter: Garret Wilson
>Priority: Major
>
> In my [Guise Mummy|https://github.com/globalmentor/guise-mummy] static site
> generator I'm using JEXL to interpret the built-in [Mesh Expression
> Language|https://github.com/globalmentor/guise-mummy/tree/main/mesh] (MEXL).
> Everything was working fine with JEXL 3.1. In fact the entire [Guise Mummy
> web site|https://guise.io/mummy/] itself was produced using Guise Mummy with
> MEXL on top of JEXL. But when I upgrade to JEXL 3.3-SNAPSHOT, a couple of
> unit tests break. In particular, the new version doesn't seem to find a
> public getter method on a custom public class as a property.
> In the Mesh templating, we have an {{mx:each}} attribute (similar to JSP or
> Thymeleaf) which loops through and replicates some HTML element (e.g. an
> {{}} inside an {{}}) for each value in a list. It assigns each value,
> one at a time, to a variable {{it}} in the context. That is working fine. But
> on each iteration it also assigns {{iter}} in the context, with the value
> being an instance of
> [{{MeshIterator}}|https://github.com/globalmentor/guise-mummy/blob/main/mesh/src/main/java/io/guise/mesh/MeshIterator.java].
> That object has, among other things, {{getCurrent()}}:
> {code:java}
> /**
> * Returns the current item. This will be the result of the last successful
> call to {@link #next()}.
> * @throws NoSuchElementException if iteration has not yet started.
> * @return The current item.
> */
> public Object getCurrent() { ... }
> {code}
> To make a long story short, the MEXL expression should be able to use
> {{iter.current}} to get the value, but it's not finding it. I traced through
> the new code, and it's finding the {{MeshIterator}} instance just fine and
> assigning it to {{iter}}. The problem is that JEXL's {{ClassMap}} (probably
> inside {{create()}}) is not finding and caching {{getCurrent()}} mapped to
> the {{current}} property.
> It looks like {{Permissions.allow()}} for method
> {{MeshIterator.getCurrent()}}, is falling through to the end and returning
> {{explicit[0]}}, which happens to be {{false}}. It looks like this comes from
> {{wildcardAllow(Class clazz)}}, which eventually calls
> {{wildcardAllow(Set allowed, String name)}}. There's what I presume
> to be a set of allowed packages. Is that new? Do we have to explicitly
> provide a list of allowed packages for property discovery via reflection now?
> To reproduce this:
> # Clone [Guise Mummy
> 0.5.3|https://github.com/globalmentor/guise-mummy/releases/tag/v0.5.3].
> # In the overall project {{pom.xml}}, change the version of
> {{org.apache.commons:commons-jexl3}} from {{3.1}} to
> {{3.3-SNAPSHOT}}. (You'll also need to add the
> {{https://repository.apache.org/content/repositories/snapshots/}} repository
> in the POM.)
> # Run {{mvn clean verify}}.
> You'll see that {{io.guise.mesh.GuiseMeshTest.testMxEachWithIterVar()}} will
> fail because {{iter.current}} can't be found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-388) v3.3-SNAPSHOT doesn't find public getter as property
[
https://issues.apache.org/jira/browse/JEXL-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640643#comment-17640643
]
Henri Biestro edited comment on JEXL-388 at 11/29/22 12:03 PM:
---
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
.permissions(JexlPermissions.UNRESTRICTED)
.sandbox(sandbox)
.safe(false)
.strict(true)
.create();
{code}
Btw, any comment on [JEXL-342|https://issues.apache.org/jira/browse/JEXL-342]?
was (Author: henrib):
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
.permissions(JexlPermissions.UNRESTRICTED)
.sandbox(sandbox)
.safe(false)
.strict(true)
.create();
{code}
> v3.3-SNAPSHOT doesn't find public getter as property
>
>
> Key: JEXL-388
> URL: https://issues.apache.org/jira/browse/JEXL-388
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: Java 17; Windows 10
>Reporter: Garret Wilson
>Priority: Major
>
> In my [Guise Mummy|https://github.com/globalmentor/guise-mummy] static site
> generator I'm using JEXL to interpret the built-in [Mesh Expression
> Language|https://github.com/globalmentor/guise-mummy/tree/main/mesh] (MEXL).
> Everything was working fine with JEXL 3.1. In fact the entire [Guise Mummy
> web site|https://guise.io/mummy/] itself was produced using Guise Mummy with
> MEXL on top of JEXL. But when I upgrade to JEXL 3.3-SNAPSHOT, a couple of
> unit tests break. In particular, the new version doesn't seem to find a
> public getter method on a custom public class as a property.
> In the Mesh templating, we have an {{mx:each}} attribute (similar to JSP or
> Thymeleaf) which loops through and replicates some HTML element (e.g. an
> {{}} inside an {{}}) for each value in a list. It assigns each value,
> one at a time, to a variable {{it}} in the context. That is working fine. But
> on each iteration it also assigns {{iter}} in the context, with the value
> being an instance of
> [{{MeshIterator}}|https://github.com/globalmentor/guise-mummy/blob/main/mesh/src/main/java/io/guise/mesh/MeshIterator.java].
> That object has, among other things, {{getCurrent()}}:
> {code:java}
> /**
> * Returns the current item. This will be the result of the last successful
> call to {@link #next()}.
> * @throws NoSuchElementException if iteration has not yet started.
> * @return The current item.
> */
> public Object getCurrent() { ... }
> {code}
> To make a long story short, the MEXL expression should be able to use
> {{iter.current}} to get the value, but it's not finding it. I traced through
> the new code, and it's finding the {{MeshIterator}} instance just fine and
> assigning it to {{iter}}. The problem is that JEXL's {{ClassMap}} (probably
> inside {{create()}}) is not finding and caching {{getCurrent()}} mapped to
> the {{current}} property.
> It looks like {{Permissions.allow()}} for method
> {{MeshIterator.getCurrent()}}, is falling through to the end and returning
> {{explicit[0]}}, which happens to be {{false}}. It looks like this comes from
> {{wildcardAllow(Class clazz)}}, which eventually calls
> {{wildcardAllow(Set allowed, String name)}}. There's what I presume
> to be a set of allowed packages. Is that new? Do we have to explicitly
> provide a list of allowed packages for property discovery via reflection now?
> To reproduce this:
> # Clone [Guise Mummy
> 0.5.3|https://github.com/globalmentor/guise-mummy/releases/tag/v0.5.3].
> # In the overall project {{pom.xml}}, change the version of
> {{org.apache.commons:commons-jexl3}} from {{3.1}} to
> {{3.3-SNAPSHOT}}. (You'll also need to add the
> {{https://repository.apache.org/content/repositories/snapshots/}} repository
> in the POM.)
> # Run {{mvn clean verify}}.
> You'll see that {{io.guise.mesh.GuiseMeshTest.testMxEachWithIterVar()}} will
> fail because {{iter.current}} can't be found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JEXL-388) v3.3-SNAPSHOT doesn't find public getter as property
[
https://issues.apache.org/jira/browse/JEXL-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640643#comment-17640643
]
Henri Biestro commented on JEXL-388:
Current trunk default is to restrict what JEXL can see using permissions
(JexlPermissions).
To revert to previous (security oblivious) setting:
{code}
JexlEngine jexl = new JexlBuilder()
.permissions(JexlPermissions.UNRESTRICTED)
.sandbox(sandbox)
.safe(false)
.strict(true)
.create();
{code}
> v3.3-SNAPSHOT doesn't find public getter as property
>
>
> Key: JEXL-388
> URL: https://issues.apache.org/jira/browse/JEXL-388
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.3
> Environment: Java 17; Windows 10
>Reporter: Garret Wilson
>Priority: Major
>
> In my [Guise Mummy|https://github.com/globalmentor/guise-mummy] static site
> generator I'm using JEXL to interpret the built-in [Mesh Expression
> Language|https://github.com/globalmentor/guise-mummy/tree/main/mesh] (MEXL).
> Everything was working fine with JEXL 3.1. In fact the entire [Guise Mummy
> web site|https://guise.io/mummy/] itself was produced using Guise Mummy with
> MEXL on top of JEXL. But when I upgrade to JEXL 3.3-SNAPSHOT, a couple of
> unit tests break. In particular, the new version doesn't seem to find a
> public getter method on a custom public class as a property.
> In the Mesh templating, we have an {{mx:each}} attribute (similar to JSP or
> Thymeleaf) which loops through and replicates some HTML element (e.g. an
> {{}} inside an {{}}) for each value in a list. It assigns each value,
> one at a time, to a variable {{it}} in the context. That is working fine. But
> on each iteration it also assigns {{iter}} in the context, with the value
> being an instance of
> [{{MeshIterator}}|https://github.com/globalmentor/guise-mummy/blob/main/mesh/src/main/java/io/guise/mesh/MeshIterator.java].
> That object has, among other things, {{getCurrent()}}:
> {code:java}
> /**
> * Returns the current item. This will be the result of the last successful
> call to {@link #next()}.
> * @throws NoSuchElementException if iteration has not yet started.
> * @return The current item.
> */
> public Object getCurrent() { ... }
> {code}
> To make a long story short, the MEXL expression should be able to use
> {{iter.current}} to get the value, but it's not finding it. I traced through
> the new code, and it's finding the {{MeshIterator}} instance just fine and
> assigning it to {{iter}}. The problem is that JEXL's {{ClassMap}} (probably
> inside {{create()}}) is not finding and caching {{getCurrent()}} mapped to
> the {{current}} property.
> It looks like {{Permissions.allow()}} for method
> {{MeshIterator.getCurrent()}}, is falling through to the end and returning
> {{explicit[0]}}, which happens to be {{false}}. It looks like this comes from
> {{wildcardAllow(Class clazz)}}, which eventually calls
> {{wildcardAllow(Set allowed, String name)}}. There's what I presume
> to be a set of allowed packages. Is that new? Do we have to explicitly
> provide a list of allowed packages for property discovery via reflection now?
> To reproduce this:
> # Clone [Guise Mummy
> 0.5.3|https://github.com/globalmentor/guise-mummy/releases/tag/v0.5.3].
> # In the overall project {{pom.xml}}, change the version of
> {{org.apache.commons:commons-jexl3}} from {{3.1}} to
> {{3.3-SNAPSHOT}}. (You'll also need to add the
> {{https://repository.apache.org/content/repositories/snapshots/}} repository
> in the POM.)
> # Run {{mvn clean verify}}.
> You'll see that {{io.guise.mesh.GuiseMeshTest.testMxEachWithIterVar()}} will
> fail because {{iter.current}} can't be found.
--
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] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17640504#comment-17640504
]
Flying Wolf commented on FILEUPLOAD-309:
Maybe it's time to stop with Commons File Upload? Joakim Erdfelt (from Jetty
and Jakarta EE) said:
[https://stackoverflow.com/questions/68820707/jetty-11-and-commons-fileupload]
{quote}commons-fileupload is not required from Servlet 3.1 onwards.
In fact, using commons-fileupload in combination with the a container that
supports Servlet spec 3.1 (or newer) is actually not recommended.
There hasn't even been a release of commons-fileupload since 2018, and no
releases that support Servlet 3.1 or newer (the last release of
commons-fileupload supports Servlet 2.4 and older)
Why?
The Multipart features are built into the Servlet spec since 3.1.
Every server that supports Servlet 3.1 supports multipart file upload
now.{quote}
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
