[GitHub] [commons-lang] codecov-commenter commented on pull request #993: NumberUtils check if Number is null or zero
codecov-commenter commented on PR #993: URL: https://github.com/apache/commons-lang/pull/993#issuecomment-1333129356 # [Codecov](https://codecov.io/gh/apache/commons-lang/pull/993?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 [#993](https://codecov.io/gh/apache/commons-lang/pull/993?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (6baea48) 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 **not change** coverage. > The diff coverage is `100.00%`. ```diff @@Coverage Diff@@ ## master #993 +/- ## = Coverage 92.04% 92.04% - Complexity 7430 7435+5 = Files 193 193 Lines 1567415674 Branches 2898 2899+1 = Hits 1442714427 Misses 674 674 Partials573 573 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-lang/pull/993?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/993/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.04% <100.00%> (+0.02%)` | :arrow_up: | | [...main/java/org/apache/commons/lang3/ClassUtils.java](https://codecov.io/gh/apache/commons-lang/pull/993/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-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2NvbW1vbnMvbGFuZzMvQ2xhc3NVdGlscy5qYXZh) | `93.23% <0.00%> (-0.04%)` | :arrow_down: | :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] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641608#comment-17641608 ] Jeremy Long commented on JCS-232: - I believe the solution to the problem is split the log4j adapter and factory into an independent JAR. > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Priority: Major > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-lang] PiMaDaum opened a new pull request, #993: NumberUtils check if Number is null or zero
PiMaDaum opened a new pull request, #993: URL: https://github.com/apache/commons-lang/pull/993 Added new methods in NumberUtils to check whether an number is null or zero -- 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 #178: Verifier tests on various opcodes and fixed typo testCommonsLang1->2
nbauma109 commented on code in PR #178:
URL: https://github.com/apache/commons-bcel/pull/178#discussion_r1036425276
##
src/test/java/org/apache/bcel/verifier/VerifierTestCase.java:
##
@@ -126,6 +126,16 @@ public void testDefinitionImpl() throws
ClassNotFoundException {
testNestHostWithJavaVersion("com.ibm.wsdl.DefinitionImpl");
}
+@Test
+public void testJvmOpCodes() throws ClassNotFoundException {
+
testDefaultMethodValidation("org.apache.bcel.verifier.tests.JvmOpCodes");
+}
+
+@Test
+public void testObjectBrowser() throws ClassNotFoundException {
+testDefaultMethodValidation("groovy.inspect.swingui.ObjectBrowser");
// contains SWAP instruction
Review Comment:
this seems to belong to discontinued maven coordinates though
https://search.maven.org/artifact/org.codehaus.groovy/groovy-all-minimal
--
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 #178: Verifier tests on various opcodes and fixed typo testCommonsLang1->2
garydgregory commented on code in PR #178:
URL: https://github.com/apache/commons-bcel/pull/178#discussion_r1036422816
##
src/test/java/org/apache/bcel/verifier/VerifierTestCase.java:
##
@@ -126,6 +126,16 @@ public void testDefinitionImpl() throws
ClassNotFoundException {
testNestHostWithJavaVersion("com.ibm.wsdl.DefinitionImpl");
}
+@Test
+public void testJvmOpCodes() throws ClassNotFoundException {
+
testDefaultMethodValidation("org.apache.bcel.verifier.tests.JvmOpCodes");
+}
+
+@Test
+public void testObjectBrowser() throws ClassNotFoundException {
+testDefaultMethodValidation("groovy.inspect.swingui.ObjectBrowser");
// contains SWAP instruction
Review Comment:
This is not maintainable IMO because it's too easy to update Groovy and
loose whatever this test thinks it's testing. If you want to test a specific
instruction, add a class file and test that.
--
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] (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=17641473#comment-17641473
]
Henri Biestro commented on JEXL-388:
Documentation for permissions is in the 3.3 Javadoc which can be generated
using 'mvn clean install site'.
Wrt JEXL-342, the proposal has been
[here|https://github.com/apache/commons-jexl/tree/master/src/test/java/org/apache/commons/jexl3/jexl342]
for some time.
Wrt JEXL-387, I suspect the Uberspect receives a null logger which ultimately
is related to a logging misconfiguration; I'd suggest solving this first,
ideally using a dedicated logger (create the Uberspect, pass it to the
JexlBuilder).
> 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=17641437#comment-17641437
]
Garret Wilson edited comment on JEXL-388 at 11/30/22 4:35 PM:
--
{quote}… to restrict what JEXL can see using permissions …{quote}
On the face of it that sounds reasonable. Where can I find the documentation
for this, since this is a breaking change?
{quote}Btw, any comment on JEXL-342?{quote}
I'm not sure what comment you want. That was a feature request that is still
open, even though a third party indicated they had added something to a
modified fork of the library.
In any case JEXL is pretty much stuck at the same place it was years ago, since
v3.2.1 is completely broken because of JEXL-387, v3.3 is not released, and
[there will be no v3.2.2 to fix the
bug|https://issues.apache.org/jira/browse/JEXL-387?focusedCommentId=17640302&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17640302].
was (Author: garretwilson):
{quote}… to restrict what JEXL can see using permissions …{quote}
On the face of it that sounds reasonable. Where can I find the documentation
for this, since this is a breaking change?
{quote}Btw, any comment on JEXL-342?{quote}
I'm not sure what comment you want. That was a feature request that is still
open, even though a third party indicated they had added something to a
modified fork of the library.
> 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] [Resolved] (COLLECTIONS-817) BloomFilter: Converting Double to Int
[ https://issues.apache.org/jira/browse/COLLECTIONS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved COLLECTIONS-817. -- Resolution: Done BloomFilter estimate computations have been updated to correct the implementation, document the expected behaviour and handle infinite values. > BloomFilter: Converting Double to Int > - > > Key: COLLECTIONS-817 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-817 > Project: Commons Collections > Issue Type: Bug > Components: Collection >Reporter: Claude Warren >Priority: Minor > Labels: bloom-filter > Fix For: 4.5 > > > [https://github.com/Claudenw/commons-collections/blob/9f2945cc98747893456b73f42ab53f46a866ac37/src/main/java/org/apache/commons/collections4/bloomfilter/BloomFilter.java#L216-L251] > Should this be a double? > Since this is a pass through method that is converting a precise value from > the shape into an imprecise one I would recommend removing it. A paragraph > can be added to the class javadoc on how to estimate N and also the size of > the union and intersection with another filter. Those methods also suffer > from the same inaccuracy. If this functionality was moved to class javadoc > then it is clear to the user how to compute it and what the computation > requires. > Another issue is that the argument filter's shape is not checked. The merge > should join the smaller filter into the bigger one and then the estimateN > called on the larger filter. Otherwise this method is not symmetric. One way > would be fine but the other would result in a merge error. > If this is only intended for filters with the same number of bits then the > expected result of a mismatch is not documented. > -- 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=17641437#comment-17641437
]
Garret Wilson commented on JEXL-388:
{quote}… to restrict what JEXL can see using permissions …{quote}
On the face of it that sounds reasonable. Where can I find the documentation
for this, since this is a breaking change?
{quote}Btw, any comment on JEXL-342?{quote}
I'm not sure what comment you want. That was a feature request that is still
open, even though a third party indicated they had added something to a
modified fork of the library.
> 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)
[GitHub] [commons-collections] asfgit closed pull request #358: Collections-817: Reworked calculations and updated javadoc for estimateN(), estimateIntersection() and estimateUnion()
asfgit closed pull request #358: Collections-817: Reworked calculations and updated javadoc for estimateN(), estimateIntersection() and estimateUnion() URL: https://github.com/apache/commons-collections/pull/358 -- 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] (STATISTICS-14) BigDecimalStatistics
[ https://issues.apache.org/jira/browse/STATISTICS-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved STATISTICS-14. Fix Version/s: 1.0 Resolution: Won't Do No use case provided. > BigDecimalStatistics > > > Key: STATISTICS-14 > URL: https://issues.apache.org/jira/browse/STATISTICS-14 > Project: Commons Statistics > Issue Type: New Feature >Reporter: Aleksander Ściborek >Priority: Major > Fix For: 1.0 > > > The idea is to create a util class for reducing stream of BigDecimal objects > and then getting an object which contains statistics such as > 1)Min and max value > 2)Average > 3)Total sum -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
[ https://issues.apache.org/jira/browse/JCS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641286#comment-17641286 ] Jeremy Long commented on JCS-232: - Additionally, the documentation for the logging abstraction is incorrect. The services file should be `org.apache.commons.jcs3.log.LogFactory` instead of `org.apache.commons.jcs.log.LogFactory` > ClassNotFoundException When Using Custom Log Adapter > > > Key: JCS-232 > URL: https://issues.apache.org/jira/browse/JCS-232 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-3.1 >Reporter: Jeremy Long >Priority: Major > > If one implements a new logging abstraction as documented: > [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] > Unless log4j is on the classpath a ClassNotFoundException exception is thrown > because `org/apache/logging/log4j/message/MessageFactory` does not exist and > is referenced > [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] > > I have a library that uses sl4j and is used in several other tools - so I > thought I would make an adapter to point to slf4j: > [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will > have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (STATISTICS-61) Exponential distribution parameterized by the rate (1 / mean)
[
https://issues.apache.org/jira/browse/STATISTICS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved STATISTICS-61.
Resolution: Won't Do
The difference between the exponential distribution evaluated using the rate as
opposed to 1/rate is only a few ULP due to rounding errors. This is the limit
of accuracy for the current implementation against reference data.
The only parameterization that cannot be implemented using the mean is the
extreme situation where 1/rate is infinite. In this case the rate will be
sub-normal and accuracy will be reduced due to the limited precision of the
floating-point mantissa as the rate approaches zero.
In the interest of simplicity to minimise the API this is marked this as 'Won't
Do'. Note that adding this functionality at a later point (if a use case
requires it) will be possible without breaking binary compatibility as the
implementation can be provided in an internal class.
A note has been added to the class javadoc to state that you should use: mean =
1/rate to create the distribution.
> Exponential distribution parameterized by the rate (1 / mean)
> -
>
> Key: STATISTICS-61
> URL: https://issues.apache.org/jira/browse/STATISTICS-61
> Project: Commons Statistics
> Issue Type: New Feature
> Components: distribution
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Priority: Minor
>
> The exponential distribution is currently parameterized by the mean. This
> matches the parameterization used by SciPy and Matlab.
> The distribution can also be parameterized by the rate. This is the
> parameterization used by R and Mathematica.
> A distribution for the rate can be created as:
> {code:java}
> double rate = ...
> ExponentialDistribution dist = ExponentialDistribution.of(1 / rate);{code}
> The formulas for the two parameterization are simple rearrangements. In
> certain cases direct use of the rate formula can have a large difference to
> the mean formula.
> Investigate the option to provide a rate parameterization as:
> {noformat}
> ExponentialDistribution dist = ExponentialDistribution.ofRate(rate);{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCS-232) ClassNotFoundException When Using Custom Log Adapter
Jeremy Long created JCS-232: --- Summary: ClassNotFoundException When Using Custom Log Adapter Key: JCS-232 URL: https://issues.apache.org/jira/browse/JCS-232 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-3.1 Reporter: Jeremy Long If one implements a new logging abstraction as documented: [https://commons.apache.org/proper/commons-jcs/UpgradingFrom2x.html#Logging_Abstraction] Unless log4j is on the classpath a ClassNotFoundException exception is thrown because `org/apache/logging/log4j/message/MessageFactory` does not exist and is referenced [https://github.com/apache/commons-jcs/blob/master/commons-jcs-core/src/main/java/org/apache/commons/jcs3/log/Log4j2Factory.java#L30] I have a library that uses sl4j and is used in several other tools - so I thought I would make an adapter to point to slf4j: [https://github.com/jeremylong/jcs3-slf4j]. Unfortunately, to use this I will have to add an unused dependency. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641249#comment-17641249 ] Michael Osipov commented on COMPRESS-635: - Don't get me started :-D > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641242#comment-17641242 ] Gary D. Gregory commented on COMPRESS-635: -- Log4j _is_ a facade API: https://logging.apache.org/log4j/2.x/manual/api-separation.html But tell us how you really feel... > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641220#comment-17641220 ] PJ Fanning commented on COMPRESS-635: - [~michael-o] I'm neutral about which logging framework to use - slf4j would be fine for me if that was preferred. With there being quite an overlap in the Apache Commons and Apache Logging teams, I thought log4j would be preferred. > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated COMPRESS-635: Summary: switch system.err/system.out printlns to be log4j or slf4j logging (was: switch system.err/system.out printlns to be log4j logging) > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
