[GitHub] [commons-build-plugin] dependabot[bot] opened a new pull request #59: Bump maven-plugin-tools-ant from 3.6.2 to 3.6.4
dependabot[bot] opened a new pull request #59: URL: https://github.com/apache/commons-build-plugin/pull/59 Bumps maven-plugin-tools-ant from 3.6.2 to 3.6.4. [](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-dbcp] garydgregory commented on pull request #159: Bump h2 from 2.0.204 to 2.0.206
garydgregory commented on pull request #159: URL: https://github.com/apache/commons-dbcp/pull/159#issuecomment-1018182397 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory merged pull request #161: Bump spotbugs-maven-plugin from 4.5.2.0 to 4.5.3.0
garydgregory merged pull request #161: URL: https://github.com/apache/commons-dbcp/pull/161 -- 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-dbcp] garydgregory merged pull request #163: Bump narayana-jta from 5.12.4.Final to 5.12.5.Final
garydgregory merged pull request #163: URL: https://github.com/apache/commons-dbcp/pull/163 -- 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-dbcp] garydgregory commented on pull request #161: Bump spotbugs-maven-plugin from 4.5.2.0 to 4.5.3.0
garydgregory commented on pull request #161: URL: https://github.com/apache/commons-dbcp/pull/161#issuecomment-1018176795 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory commented on pull request #159: Bump h2 from 2.0.204 to 2.0.206
garydgregory commented on pull request #159: URL: https://github.com/apache/commons-dbcp/pull/159#issuecomment-1018176869 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory commented on pull request #163: Bump narayana-jta from 5.12.4.Final to 5.12.5.Final
garydgregory commented on pull request #163: URL: https://github.com/apache/commons-dbcp/pull/163#issuecomment-1018176742 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] garydgregory merged pull request #162: Bump jboss-logging from 3.4.2.Final to 3.4.3.Final
garydgregory merged pull request #162: URL: https://github.com/apache/commons-dbcp/pull/162 -- 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-dbcp] dependabot[bot] opened a new pull request #163: Bump narayana-jta from 5.12.4.Final to 5.12.5.Final
dependabot[bot] opened a new pull request #163: URL: https://github.com/apache/commons-dbcp/pull/163 Bumps narayana-jta from 5.12.4.Final to 5.12.5.Final. [](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-dbcp] dependabot[bot] opened a new pull request #162: Bump jboss-logging from 3.4.2.Final to 3.4.3.Final
dependabot[bot] opened a new pull request #162: URL: https://github.com/apache/commons-dbcp/pull/162 Bumps [jboss-logging](https://github.com/jboss-logging/jboss-logging) from 3.4.2.Final to 3.4.3.Final. Release notes Sourced from https://github.com/jboss-logging/jboss-logging/releases;>jboss-logging's releases. 3.4.3.Final Release Notes Commits https://github.com/jboss-logging/jboss-logging/commit/96f73e44d677aa82e27d8b5433641e0a9dffd902;>96f73e4 Prepare for 3.4.3.Final release https://github.com/jboss-logging/jboss-logging/commit/ed233b795961b1b761f9b091e9b3cb8e46736b5a;>ed233b7 Merge pull request https://github-redirect.dependabot.com/jboss-logging/jboss-logging/issues/44;>#44 from lesiak/log4j-update https://github.com/jboss-logging/jboss-logging/commit/0033f84864cb00ba360113343d7ac6d352864149;>0033f84 [JBLOGGING-158] Upgrade log4j2 to 2.17.1 https://github.com/jboss-logging/jboss-logging/commit/679306df46d3e346837405e12acbbd2dac8647e5;>679306d Merge pull request https://github-redirect.dependabot.com/jboss-logging/jboss-logging/issues/43;>#43 from jamezp/java17 https://github.com/jboss-logging/jboss-logging/commit/fad44ee93f4bfafc7349a7c7a87579d78753f964;>fad44ee [JBLOGGING-157] Add support for building and testing with Java 17. https://github.com/jboss-logging/jboss-logging/commit/6f89a03574a43ba39f5004849914ea8c0ec20c70;>6f89a03 Merge pull request https://github-redirect.dependabot.com/jboss-logging/jboss-logging/issues/42;>#42 from jamezp/component-upgrades https://github.com/jboss-logging/jboss-logging/commit/b84783f38c5706ab71f1d1fd86036d35e1fb41ed;>b84783f [JBLOGGING-156] Upgrade JUnit to 5.8.2. https://github.com/jboss-logging/jboss-logging/commit/9a21d49215db4cabbb9bfe74c266412c247d26b0;>9a21d49 [JBLOGGING-155] Upgrade JUnit to 5.8.2. https://github.com/jboss-logging/jboss-logging/commit/666c8ec98e0a33d6b61a3d7cd6f069768526e9f7;>666c8ec [JBLOGGING-154] Upgrade jboss-logmanager to 2.1.18.Final https://github.com/jboss-logging/jboss-logging/commit/9eeb6a06c0922096617c9fce8a6cb5da59f3c685;>9eeb6a0 [JBLOGGING-153] Upgrade log4j 2 to 2.16.0. Additional commits viewable in https://github.com/jboss-logging/jboss-logging/compare/3.4.2.Final...3.4.3.Final;>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-dbcp] dependabot[bot] opened a new pull request #161: Bump spotbugs-maven-plugin from 4.5.2.0 to 4.5.3.0
dependabot[bot] opened a new pull request #161: URL: https://github.com/apache/commons-dbcp/pull/161 Bumps [spotbugs-maven-plugin](https://github.com/spotbugs/spotbugs-maven-plugin) from 4.5.2.0 to 4.5.3.0. Release notes Sourced from https://github.com/spotbugs/spotbugs-maven-plugin/releases;>spotbugs-maven-plugin's releases. Spotbugs-maven-plugin 4.5.3.0 Support spotbugs maven plugin 4.5.3.0 Make maven scoped dependencies provided scope Commits https://github.com/spotbugs/spotbugs-maven-plugin/commit/ae3658622b8590836b7994801526c39e52f2e76f;>ae36586 [maven-release-plugin] prepare release spotbugs-maven-plugin-4.5.3.0 https://github.com/spotbugs/spotbugs-maven-plugin/commit/03b7e0dae5375b33abc6f3f2cda80fa6824b4b9e;>03b7e0d Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/392;>#392 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/477b67e3277a419386c384830b831b59fd2bf188;>477b67e [pom] Bump spotbugs to 4.5.3 https://github.com/spotbugs/spotbugs-maven-plugin/commit/4c29db7bfa66552bc972eb70369d0c677e7de434;>4c29db7 Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/390;>#390 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/7ceb76b9bb290eb393eea8f52eaced6cdc8281f5;>7ceb76b [actions] Adjust name for wrapper 3.3.9 usage and wrapper goal https://github.com/spotbugs/spotbugs-maven-plugin/commit/15b5b51bb0d0c81d9cd84685354be31510fbe142;>15b5b51 [actions] Add github action to run entirely through maven 3.3.9 https://github.com/spotbugs/spotbugs-maven-plugin/commit/fd7b8cc94f0f57d4a2d605f00ed609de16d0dd3c;>fd7b8cc Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/389;>#389 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/196b77ff23e457b82a0ea624c19bf0e8ae60d662;>196b77f [mvn] Update maven wrapper https://github.com/spotbugs/spotbugs-maven-plugin/commit/15fff12958c4f97550313383852901d32ea2cecb;>15fff12 Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/388;>#388 from hazendaz/spotbugs https://github.com/spotbugs/spotbugs-maven-plugin/commit/6c0bb1e9c333c887d096747409d621d37933f943;>6c0bb1e Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/387;>#387 from spotbugs/dependabot/maven/scmPluginVersion-1.12.2 Additional commits viewable in https://github.com/spotbugs/spotbugs-maven-plugin/compare/spotbugs-maven-plugin-4.5.2.0...spotbugs-maven-plugin-4.5.3.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 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] [Work logged] (COLLECTIONS-795) provide a PairIterator to zip two iterators of different types.
[
https://issues.apache.org/jira/browse/COLLECTIONS-795?focusedWorklogId=712566=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-712566
]
ASF GitHub Bot logged work on COLLECTIONS-795:
--
Author: ASF GitHub Bot
Created on: 21/Jan/22 02:19
Start Date: 21/Jan/22 02:19
Worklog Time Spent: 10m
Work Description: anantdamle commented on pull request #238:
URL:
https://github.com/apache/commons-collections/pull/238#issuecomment-1018102419
Any updates on this 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
Issue Time Tracking
---
Worklog Id: (was: 712566)
Time Spent: 7h 10m (was: 7h)
> provide a PairIterator to zip two iterators of different types.
> ---
>
> Key: COLLECTIONS-795
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-795
> Project: Commons Collections
> Issue Type: New Feature
> Components: Iterator
>Reporter: Anant Damle
>Priority: Minor
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> ZippingIterator provides a way to simulatenously iterate over multiple
> iterators of the *same-type.*
> The proposed pair iterator allows simultaneously iterating over two iterators
> of different type, like the example below:
> {code:java}
> Iterator leftIterator = ...;
> Iterator rightIterator = ...;
> PairIterator pairIterator = PairIterator.of(leftIterator, rightIterator);
> while (pairIterator.hasNext()) {
>ImmutablePair item = pairIterator.next();
>...
> }{code}
>
> Another convenience could be to use an Iterable for easy for-each constructs.
> {code:java}
> List studentIds = ...
> List studentNames = ...
> for (PairedItem items :
> IterableUtils.pairedIterable(studentIds, studentNames) {
> Integer studentId = item.getLeft();
> String studentName = item.getRight();
> ...
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-collections] anantdamle commented on pull request #238: [COLLECTIONS-795] Add a new Iterator to allowing zipping over two iterators of different types
anantdamle commented on pull request #238: URL: https://github.com/apache/commons-collections/pull/238#issuecomment-1018102419 Any updates on this 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
[jira] [Deleted] (TEXT-214) Which Material we are using?
[ https://issues.apache.org/jira/browse/TEXT-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert deleted TEXT-214: -- > Which Material we are using? > > > Key: TEXT-214 > URL: https://issues.apache.org/jira/browse/TEXT-214 > Project: Commons Text > Issue Type: Task >Reporter: Customize Dubai >Priority: Major > > Have you had the inclination to plan your own T-shirt? This article will give > you a significant heads-up on where to begin. > In the present design world, everyone needs to be remarkable. Yet, this ends > up being especially hard with the mass dress plan creation the enormous > brands are delivering available. Fortunately, with a little (or more) > information in the planning field, you can without much of a stretch plan > your own T-shirt that is completely custom and customized by your taste. > Prior to burning through any additional time, how about we go through the > prescribed procedures and tips from the business first and afterward see what > sort of programming you want to make your fantasy T-shirt plan a reality. > Extraordinary plans start with good thoughts. Assuming you as of now have an > unmistakable thought of a [*T Shirt Printing > Dubai*|https://customizedubai.com/t-shirt-printing-dubai/] configuration > you’ll make, that is awesome. In any case, assuming you end up gazing at a > fresh start, not knowing where to begin, you ought to presumably need to > search for motivation all the more effectively. > Clearly, your initial few stops would be the most popular plan-based stages, > like Pinterest, Instagram, Bedance. Such stages are fundamentally wellsprings > of motivation and will stack your inventive brain with astounding visual > thoughts. In any case, some of the time, motivation might strike when you > wouldn’t dare hope anymore. Furthermore, it won’t really come from the screen. > When perusing for motivation, you will discover that there is really a wide > range of visual plan styles that are useful for a T-shirt: cartoony, > moderate, typography-based, photo-based, vintage, and so on Perusing many > plans will assist you with clearing up the idea and find out about the visual > style you will be seeking after for your own plan. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (TEXT-214) Which Material we are using?
[ https://issues.apache.org/jira/browse/TEXT-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Customize Dubai updated TEXT-214: - Summary: Which Material we are using? (was: Our main priority is customer satisfaction when it comes to t shirt printing dubai. We do all possible efforts to live unto the expectations of not only our Dubai Customers but across the world.) > Which Material we are using? > > > Key: TEXT-214 > URL: https://issues.apache.org/jira/browse/TEXT-214 > Project: Commons Text > Issue Type: Task >Reporter: Customize Dubai >Priority: Major > Attachments: > ed419e06a1d46f317e4bb4f26c1f0ec78b-tshirt-ODE.rsquare.w1200.jpg > > > Have you had the inclination to plan your own T-shirt? This article will give > you a significant heads-up on where to begin. > In the present design world, everyone needs to be remarkable. Yet, this ends > up being especially hard with the mass dress plan creation the enormous > brands are delivering available. Fortunately, with a little (or more) > information in the planning field, you can without much of a stretch plan > your own T-shirt that is completely custom and customized by your taste. > Prior to burning through any additional time, how about we go through the > prescribed procedures and tips from the business first and afterward see what > sort of programming you want to make your fantasy T-shirt plan a reality. > Extraordinary plans start with good thoughts. Assuming you as of now have an > unmistakable thought of a [*T Shirt Printing > Dubai*|https://customizedubai.com/t-shirt-printing-dubai/] configuration > you’ll make, that is awesome. In any case, assuming you end up gazing at a > fresh start, not knowing where to begin, you ought to presumably need to > search for motivation all the more effectively. > Clearly, your initial few stops would be the most popular plan-based stages, > like Pinterest, Instagram, Bedance. Such stages are fundamentally wellsprings > of motivation and will stack your inventive brain with astounding visual > thoughts. In any case, some of the time, motivation might strike when you > wouldn’t dare hope anymore. Furthermore, it won’t really come from the screen. > When perusing for motivation, you will discover that there is really a wide > range of visual plan styles that are useful for a T-shirt: cartoony, > moderate, typography-based, photo-based, vintage, and so on Perusing many > plans will assist you with clearing up the idea and find out about the visual > style you will be seeking after for your own plan. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (TEXT-214) Our main priority is customer satisfaction when it comes to t shirt printing dubai. We do all possible efforts to live unto the expectations of not only our Dubai Customers
Customize Dubai created TEXT-214: Summary: Our main priority is customer satisfaction when it comes to t shirt printing dubai. We do all possible efforts to live unto the expectations of not only our Dubai Customers but across the world. Key: TEXT-214 URL: https://issues.apache.org/jira/browse/TEXT-214 Project: Commons Text Issue Type: Task Reporter: Customize Dubai Attachments: ed419e06a1d46f317e4bb4f26c1f0ec78b-tshirt-ODE.rsquare.w1200.jpg Have you had the inclination to plan your own T-shirt? This article will give you a significant heads-up on where to begin. In the present design world, everyone needs to be remarkable. Yet, this ends up being especially hard with the mass dress plan creation the enormous brands are delivering available. Fortunately, with a little (or more) information in the planning field, you can without much of a stretch plan your own T-shirt that is completely custom and customized by your taste. Prior to burning through any additional time, how about we go through the prescribed procedures and tips from the business first and afterward see what sort of programming you want to make your fantasy T-shirt plan a reality. Extraordinary plans start with good thoughts. Assuming you as of now have an unmistakable thought of a [*T Shirt Printing Dubai*|https://customizedubai.com/t-shirt-printing-dubai/] configuration you’ll make, that is awesome. In any case, assuming you end up gazing at a fresh start, not knowing where to begin, you ought to presumably need to search for motivation all the more effectively. Clearly, your initial few stops would be the most popular plan-based stages, like Pinterest, Instagram, Bedance. Such stages are fundamentally wellsprings of motivation and will stack your inventive brain with astounding visual thoughts. In any case, some of the time, motivation might strike when you wouldn’t dare hope anymore. Furthermore, it won’t really come from the screen. When perusing for motivation, you will discover that there is really a wide range of visual plan styles that are useful for a T-shirt: cartoony, moderate, typography-based, photo-based, vintage, and so on Perusing many plans will assist you with clearing up the idea and find out about the visual style you will be seeking after for your own plan. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-collections] kinow commented on a change in pull request #258: Simplify bloom filters
kinow commented on a change in pull request #258:
URL:
https://github.com/apache/commons-collections/pull/258#discussion_r789154937
##
File path:
src/main/java/org/apache/commons/collections4/bloomfilter/package-info.java
##
@@ -18,101 +18,78 @@
/**
* A collection of extensible Bloom filter classes and interfaces.
*
- *
- * Background:
- *
- * A Bloom filter is conceptually a bit vector. It is used to
- * tell you where things are not. Basically, you create a Bloom filter by
creating hashes
- * and converting those to enabled bits in a vector. You can merge the Bloom
filters
- * together with logical "or" (call this filter "B"). You can then check to
see if filter
- * "A" was "or"ed into "B" by testing A B == A. if the statement is
false then "A" was
- * not merged into "B", otherwise it _might_ have. They are generally used
where hash
- * tables would be too large or as a filter front end for longer processes.
For example
+ * Background:
+ *
+ * The Bloom filter is a probabilistic data structure that indicates where
things are not.
+ * Conceptually it is a a bit vector. You create a Bloom filter by creating
hashes
+ * and converting those to enabled bits in the vector. Multiple Bloom filters
may be merged
+ * together into one Bloom filter. It is possible to test if a filter {@code
B} as merged into
+ * another filter {@code A} by verifying that {@code (A & B) == B}.
+ *
+ * Bloom filters are generally used where hash
+ * tables would be too large, or as a filter front end for longer processes.
For example
* most browsers have a Bloom filter that is built from all known bad URLs
(ones that
* serve up malware). When you enter a URL the browser builds a Bloom filter
and checks to
* see if it is "in" the bad URL filter. If not the URL is good, if it
matches, then the
* expensive lookup on a remote system is made to see if it actually is in the
list. There
* are lots of other uses, and in most cases the reason is to perform a fast
check as a
* gateway for a longer operation.
- *
- * BloomFilter
- *
- * The bloom filter code is
- * an abstract class that requires implementation of 4 methods:
- *
- * getBits() which
- * returns the set bits as a buffer encoded into an array of long.
- *
- * getHasher()
- * which returns a list of integers that are indexes of the bits that are
enabled. These
- * are returned in a Hasher construct.
- *
- * merge( BloomFilter ) to merge another
- * Bloom filter into this one.
- *
- * merge( Hasher ) to merge the values in a hasher
- * into this Bloom filter.
- *
- * There are 3 implementations of Bloom filter
- * provided:
- *
- * BitSetBloomFilter - based on the Java BitSet class.
- *
- *
- * CountingBloomFilter - uses a sparse array of integers (Map) to implement a
counting
- * Bloom filter. This filter also implements remove() methods as that is the
great
- * advantage of a counting Bloom filter.
- *
- * HasherBloomFilter - implements bloom
- * filter on a Hasher. A rather slow implementation but convenient in some
- * situations.
- *
- *
- *
- * Shape
- *
- * Describes the Bloom filter using the
- * standard number of bits, number of hash functions and number of items along
with a
- * description of the HashFunction. It is this description that has caused the
most issues
- * of late.
- *
- * Hasher
- *
- * converts byte buffers into an iterator if int based
- * on a Shape. There are 2 implementations of Hasher provided
- *
- * Dynamic - calls
- * the HashFunction for each value required in the Bloom filter.
- *
- * Static - based
- * on a pre-calculated list of Bloom filter index values. It is also limited
to generating
- * values for a specific Shape.
- *
- *
- *
- * Hash Functions
- *
- * Hash
- * functions generate individual index values for the filter from a byte
buffer. There are
- * four implementations provided.
- *
- * HashFunctionIdentity
- *
- * The
- * HashFunctionIdentity is the base interface for the HashFunction. It tracks
three (3)
- * properties:
- *
- * The Hashing algorithm
- *
- * Whether the contents of the
- * resulting hash buffer are read as signed or unsigned values.
- *
- * Whether the hash
- * function uses an iterative or cyclic method. In traditional iterative
methods this is
- * done by calling the selected hash function with a different seed for each
hash
- * required. The second method described by Adam Kirsch and Micheal
Mitzenmacher[1] has
- * become more common and is used in applications like Cassandra[2].
- *
+ *
+ * BloomFilter
+ *
+ * The Bloom filter architecture here is designed so that the
implementation of the storage of bit is abstracted.
+ * Programs that utilize the Bloom filters may use the {@code BitMapProducer}
or {@code IndexProducer} to retrieve a
+ * representation of the internal structure. Additional methods are available
in the {@code BitMap} to assist in
+ *
[jira] [Created] (IMAGING-324) Add a parameter to limit the size of data loaded by the library
Bruno P. Kinoshita created IMAGING-324: -- Summary: Add a parameter to limit the size of data loaded by the library Key: IMAGING-324 URL: https://issues.apache.org/jira/browse/IMAGING-324 Project: Commons Imaging Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha2 Reporter: Bruno P. Kinoshita Fix For: Discussion Google OSS Fuzz, and some security reports in our mailing list are always reporting issues with OutOfMemoryError's due to the library code trying to allocate large arrays/buffers. This issue is for discussion on a possible setting specifying the maximum imaze size to all methods that allocate memory. This can be challenging when we have metadata that allocates data incrementally. In some cases we can have a file of some megabytes that ends up allocation GB's of data in some for-loop. This was suggested by [~erans] (thanks!), as well as an option where we could look at the JVM available memory to mitigate OOM errors. Not sure how well this would work across different JVM implementations/versions/vendors, OS, and race-conditions, etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-math] asfgit closed pull request #202: Avoid array declarations written in C-style syntax and replace it with java.
asfgit closed pull request #202: URL: https://github.com/apache/commons-math/pull/202 -- 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-collections] garydgregory commented on pull request #258: Simplify bloom filters
garydgregory commented on pull request #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-1017712873 > @aherbert , @dota17 , @garydgregory , @kinow > > Can I get a review and possible merge for this pull? It has the changes requested and is much cleaner than what is there now. If there are more things to clean up I would like to do it as smaller pull requests. > > Thank you Fine w me, @aherbert ? -- 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-collections] Claude-at-Instaclustr commented on pull request #258: Simplify bloom filters
Claude-at-Instaclustr commented on pull request #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-1017711213 @aherbert , @dota17 , @garydgregory , @kinow Can I get a review and possible merge for this pull? It has the changes requested and is much cleaner than what is there now. If there are more things to clean up I would like to do it as smaller pull requests. Thank you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (NUMBERS-183) Improve binomial coefficient classes
[
https://issues.apache.org/jira/browse/NUMBERS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved NUMBERS-183.
--
Resolution: Implemented
Binomial coefficient classes update in commit:
d22325416794452dcf19d998374b4dd1519523bf
> Improve binomial coefficient classes
>
>
> Key: NUMBERS-183
> URL: https://issues.apache.org/jira/browse/NUMBERS-183
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
>
> The binomial coefficient classes can be improved by several small changes.
> h2. Avoid recursion
> All classes use a recursive method call to compute either C(n, k) or C(n, n -
> k) depending which is smaller. The methods can avoid recursion using m =
> min(k, n - k) and computing C(n, m).
> h2. Threshold for overflow
> The LogBinomialCoeffiecient knows that C(1030, 515) overflows a double. But
> the BinomialCoefficientDouble does not. It will compute C(10, 5) with
> a loop of 5 computations and return infinity. The class should be updated
> with some better thresholds:
> {noformat}
> C(1030, 515) ~ 2.85e308 => m >= 515 is overflow
> C(2147483647, 37) * 37 ~ 5.13e303 => m < 38cannot overflow
> {noformat}
> h2. Overflow protection
> Better overflow protection is required for large results. These all currently
> fail as they overflow to infinity in the intermediate computation:
> {code:java}
> @ParameterizedTest
> @CsvSource({
> "1040, 450, 2.3101613255412135615e307",
> "1029, 514, 1.4298206864989040819e308",
> "1786388282, 38, 7.187239013254065384599502085053593e306",
> "1914878305, 38, 100.6570419073661447979173868523364e306",
> "1179067476, 39, 30.22890249420109200962786203300876e306",
> "2147483647, 37, 1.388890512412231479281222156415993e302",
> })
> void testBinomialCoefficientLargeK(int n, int k, double nCk) {
> final double x = BinomialCoefficientDouble.value(n, k);
> Assertions.assertEquals(nCk, x, Math.ulp(nCk) * 10,
> () -> "ULP error: " + (x - nCk) / Math.ulp(nCk));
> }
> {code}
> A test for overflow in the loop can rearrange the terms to compute the
> correct result.
> h2. Use the known factorials
> The BinomialCoefficientDouble class can exploit the known factorials stored
> in the Factorial class and avoid a loop computation for small n:
> {code:java}
> if (n <= 170) {
> // Use fast table lookup:
> result = Factorial.doubleValue(n);
> // Smaller m will have a more accurate factorial and may be exact
> result /= Factorial.doubleValue(m);
> result /= Factorial.doubleValue(n - m);
> }{code}
> The result appears to be as accurate as the current implementation on a
> partial test dataset. The complete dataset of factorials will require
> approximately (sum i=1 ... 170/2) * 2 == 7310 values so could be tested to
> see if this fast method is robust.
> h2. Avoid cancellation in summations
> The LogBinomialCoefficient sum will suffer from cancellation:
> {code:java}
> // Sum for values that could overflow.
> double logSum = 0;
> // n! / (n - k)!
> for (int i = n - k + 1; i <= n; i++) {
> logSum += Math.log(i);
> }
> // Divide by k!
> for (int i = 2; i <= k; i++) {
> logSum -= Math.log(i);
> }
> return logSum;
> {code}
> The divide by k! should be summed separately and subtracted as a single sum.
> This could be performed using the LogFactorial class which can cache results
> for reuse.
> h2. Use the gamma functions
> Note: The combinatorics package depends on the gamma package. The factorial
> can be computed using the gamma function:
> {noformat}
> n! = gamma(n+1)
> {noformat}
> This is used in the LogFactorial class which delegates to LogGamma.
> The binomial coefficient can be computed using the beta function:
> {noformat}
>n!gamma(n+1) gamma(k+1) * gamma(n-k+1)
> - = - = 1 / -
> k! (n-k)! gamma(k+1) * gamma(n-k+1) gamma(n+1)
> = 1 / (k * beta(k, n-k+1)) = 1 / ((n-k) * beta(k+1, n-k))
> beta(a, b) = gamma(a) * gamma(b) / gamma(a+b)
> {noformat}
> Note: In converting the Boost beta function implementation (NUMBERS-181) I
> have tested using the beta function to compute the binomial coefficient. It
> is not more accurate than using the current implementation within a loop to
> compute the multiplication of terms.
> I have not tested using LogBeta to compute the LogBinomialCoefficient. The
> accuracy of this should be checked against using the current summation of
> logs within a loop.
>
--
[jira] [Created] (POOL-404) No way to close evictor thread
Patrick Barry created POOL-404:
--
Summary: No way to close evictor thread
Key: POOL-404
URL: https://issues.apache.org/jira/browse/POOL-404
Project: Commons Pool
Issue Type: Bug
Affects Versions: 2.11.1
Reporter: Patrick Barry
Using GenericObjectPool> to help with
lettuce client/redis connection management. I have everything shutting down
cleanly except the commons-pool-evictor. I see this problem has many reported
in the past, but it still not shutting down. I am using version 2.11.1. I
have tried to code around this issue, but because EvictionTimer.java is so
locked down, there is very little that can done to change the behavior of how
this class interacts with GenericObjectPool.
For this thread to shutdown, the taskMap has to be empty, which it never is in
my case. So even thought we call close() on the pool, this class fails to
shutdown the embedded executor because it thinks it has more tasks.
Looking at this code, it did remove 1 entry from taskMap, but we had many more
in that map. Is there a way to clear this map, so it will allow this
thread/executor to shutdown?
{code:java}
static synchronized void cancel(final BaseGenericObjectPool.Evictor evictor,
final Duration timeout,
final boolean restarting) {
if (evictor != null) {
evictor.cancel(); //why does this not interrupt!?
remove(evictor);
}
if (!restarting && executor != null && taskMap.isEmpty()) { //<-- How do
you force taskMap to be empty!?
executor.shutdown();
try {
executor.awaitTermination(timeout.toMillis(),
TimeUnit.MILLISECONDS);
} catch (final InterruptedException e) {
// Swallow
// Significant API changes would be required to propagate this
}
executor.setCorePoolSize(0);
executor = null;
}
}{code}
}
I had all these entries in the taskMap when trying to shut down:
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@73d4066e
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@3c69362a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2412a42b
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@45404d5
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@29138d3a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5cbe2654
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6dbcf214
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@496a31da
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@7c251f90
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@51841ac6
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@5ba26eb0
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@435e60ff
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@17d32e9b
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@66f0548d
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@2e6f610d
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@1e86a5a7
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@10afe71a
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@741f8dbe
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@212dfd39
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@a2ddf26
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@49ede9c7
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@65d57e4e
org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor@6daf7d37
*Method calls:*
pool.close() ->
stopEvictor(); ->
startEvictor(Duration.ofMillis(-1L)); ->
EvictionTimer.cancel(evictor, evictorShutdownTimeoutDuration, false); ->
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (NUMBERS-183) Improve binomial coefficient classes
[
https://issues.apache.org/jira/browse/NUMBERS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479453#comment-17479453
]
Alex Herbert commented on NUMBERS-183:
--
h2. Binomial Coefficient Double
I have written a test comparing the computation of the binomial coefficient
double value using the simple loop against using the precomputed factorials:
{code:java}
// Loop
double result = 1;
for (int i = 1; i <= k; i++) {
result *= n - k + i;
result /= i;
}
return Math.floor(result + 0.5f);
// Factorials
// Small factorials are tabulated exactly
// n! / m! / (n-m)!
double result = Factorial.uncheckedFactorial(n) /
Factorial.uncheckedFactorial(m) /
Factorial.uncheckedFactorial(n - m);
return Math.floor(result + 0.5f); {code}
Assuming that any n < 67 is handled using the exact long computation in
BinomialCoefficient I have tested all coefficients for 67 <= n <= 170. This is
6136 coefficients ignoring symmetric values. The maximum and root mean squared
error are:
||Method||max||rms||
|Loop|16|4.524|
|Factorials|3|0.4180|
This indicates that the use of the precomputed factorials does not reduce
errors and it will have a significant speed increase when min(k, n-k) is large.
h2. Log Binomial Coefficient
Following the logic in the description, the log of the binomial coefficient is:
{noformat}
n!
-= 1 / (k * beta(k, n-k+1))
k! (n-k)!
log(C(n, k)) = -log(k) - log(beta(k, n-k+1)){noformat}
I implemented the LogBinomialCoefficient class using LogBeta. It returns
results within 1 ulp of the result computed to 64 digits using maxima with
either:
{noformat}
bfloat(log(binomial(n, k)))
bfloat(log(gamma(n+1)) - log(gamma(k+1)) - log(gamma(n-k+1))){noformat}
At modest n and k the maxima binomial function is exact. The gamma function is
required when n and k are very large. E.g. The binomial function (or beta
function) in maxima will run for several minutes without returning for
binomial(2147483647, 1073741824). The gamma result is 1.48854e9 and this is
matched by using LogBeta.
Note the gamma function for 2^31 is 1.12845925e+19107526488. With an exponent
this large the computation may be impractical using a simple loop with
arbitrary precision which may be what maxima is computing.
> Improve binomial coefficient classes
>
>
> Key: NUMBERS-183
> URL: https://issues.apache.org/jira/browse/NUMBERS-183
> Project: Commons Numbers
> Issue Type: Improvement
> Components: combinatorics
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Priority: Minor
> Fix For: 1.1
>
>
> The binomial coefficient classes can be improved by several small changes.
> h2. Avoid recursion
> All classes use a recursive method call to compute either C(n, k) or C(n, n -
> k) depending which is smaller. The methods can avoid recursion using m =
> min(k, n - k) and computing C(n, m).
> h2. Threshold for overflow
> The LogBinomialCoeffiecient knows that C(1030, 515) overflows a double. But
> the BinomialCoefficientDouble does not. It will compute C(10, 5) with
> a loop of 5 computations and return infinity. The class should be updated
> with some better thresholds:
> {noformat}
> C(1030, 515) ~ 2.85e308 => m >= 515 is overflow
> C(2147483647, 37) * 37 ~ 5.13e303 => m < 38cannot overflow
> {noformat}
> h2. Overflow protection
> Better overflow protection is required for large results. These all currently
> fail as they overflow to infinity in the intermediate computation:
> {code:java}
> @ParameterizedTest
> @CsvSource({
> "1040, 450, 2.3101613255412135615e307",
> "1029, 514, 1.4298206864989040819e308",
> "1786388282, 38, 7.187239013254065384599502085053593e306",
> "1914878305, 38, 100.6570419073661447979173868523364e306",
> "1179067476, 39, 30.22890249420109200962786203300876e306",
> "2147483647, 37, 1.388890512412231479281222156415993e302",
> })
> void testBinomialCoefficientLargeK(int n, int k, double nCk) {
> final double x = BinomialCoefficientDouble.value(n, k);
> Assertions.assertEquals(nCk, x, Math.ulp(nCk) * 10,
> () -> "ULP error: " + (x - nCk) / Math.ulp(nCk));
> }
> {code}
> A test for overflow in the loop can rearrange the terms to compute the
> correct result.
> h2. Use the known factorials
> The BinomialCoefficientDouble class can exploit the known factorials stored
> in the Factorial class and avoid a loop computation for small n:
> {code:java}
> if (n <= 170) {
> // Use fast table lookup:
> result = Factorial.doubleValue(n);
> // Smaller m will have a more accurate factorial and may be exact
> result /= Factorial.doubleValue(m);
> result /= Factorial.doubleValue(n - m);
[GitHub] [commons-math] avijit-basak opened a new pull request #203: Feature/math 1563 rb fix
avijit-basak opened a new pull request #203: URL: https://github.com/apache/commons-math/pull/203 Fixed issues in examples-ga module. -- 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-605) Failed to parse Non-zip64 signed apk with data descriptor
nick allen created COMPRESS-605: --- Summary: Failed to parse Non-zip64 signed apk with data descriptor Key: COMPRESS-605 URL: https://issues.apache.org/jira/browse/COMPRESS-605 Project: Commons Compress Issue Type: Bug Components: Archivers Affects Versions: 1.21 Reporter: nick allen I can't upload my apk due to security policy of my company, but I do find where the problem lies. In org.apache.commons.compress.archivers.zip.ZipArchiveInputStream#readDataDescriptor we check whether following bytes are signaures to determine whethere size is 8 bytes or 4 bytes. Because what following is apk signing block so it will always thought "size" takes 8 bytes. So (4 + 4 = 8) extra bytes were read. Which leading to org.apache.commons.compress.archivers.zip.ZipArchiveInputStream#isApkSigningBlock also return false. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-dbcp] Shoothzj opened a new pull request #160: Updated Notice file to 2022
Shoothzj opened a new pull request #160: URL: https://github.com/apache/commons-dbcp/pull/160 Updated Notice file to 2022 -- 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] (JEXL-235) Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before release
[
https://issues.apache.org/jira/browse/JEXL-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-235:
---
Assignee: Henri Biestro
> Verify JexlScriptEngineFactory.{getLanguageVersion,getEngineVersion} before
> release
> ---
>
> Key: JEXL-235
> URL: https://issues.apache.org/jira/browse/JEXL-235
> Project: Commons JEXL
> Issue Type: Task
>Affects Versions: 3.2
>Reporter: Henri Biestro
>Assignee: Henri Biestro
>Priority: Major
> Fix For: Later
>
>
> JexlScriptEngineFactory.getLanguageVersion and
> JexlScriptEngineFactory.getEngine version should reflect the syntax version
> and the engine version respectively.
> As a rule, any new operator or syntax should bump the language version, any
> release should update the engine version that should match the jar version.
> (see JEXL-227 for discussion on the issue).
> This task must be checked for each version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JEXL-357) Configure accessible packages/classes/methods/fields
[ https://issues.apache.org/jira/browse/JEXL-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-357: --- Assignee: Henri Biestro > Configure accessible packages/classes/methods/fields > - > > Key: JEXL-357 > URL: https://issues.apache.org/jira/browse/JEXL-357 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: Later > > > The @NoJexl annotation allows 'hiding' functional elements from scripts; this > features will allow Jexl introspection to completely ignore existing > packages/classes/methods/fields ensuring they can not be called. > Acting (more or less) as a security manager, this will allow fine > configuration of what scripts are allowed to access on a platform. Used in > conjunction with Sandboxing, how much is exposed can be limited to explicit > permission. -- This message was sent by Atlassian Jira (v8.20.1#820001)
