[jira] [Issue Comment Deleted] (CRYPTO-139) adding suuport for AARCH64 architecture in common crypto
[ https://issues.apache.org/jira/browse/CRYPTO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ossdev updated CRYPTO-139: -- Comment: was deleted (was: Please close this issue ..) > adding suuport for AARCH64 architecture in common crypto > > > Key: CRYPTO-139 > URL: https://issues.apache.org/jira/browse/CRYPTO-139 > Project: Commons Crypto > Issue Type: New Feature >Reporter: puresoftware >Priority: Critical > Attachments: CRYPTO-139-commons-crypto.patch > > > AARCH 64 architecture support is missing in the exiting common-crypto code. > Now we did some modification in the code level and add the support for > AARCH64. Now the common-crypto project can be used in aarch64 platform and > also compatible with openssl 1.1.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CRYPTO-139) adding suuport for AARCH64 architecture in common crypto
[ https://issues.apache.org/jira/browse/CRYPTO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850474#comment-16850474 ] ossdev commented on CRYPTO-139: --- Issue is fixed by PRs [https://github.com/apache/commons-crypto/pull/93] [https://github.com/apache/commons-crypto/pull/92] please close this issue ... > adding suuport for AARCH64 architecture in common crypto > > > Key: CRYPTO-139 > URL: https://issues.apache.org/jira/browse/CRYPTO-139 > Project: Commons Crypto > Issue Type: New Feature >Reporter: puresoftware >Priority: Critical > Attachments: CRYPTO-139-commons-crypto.patch > > > AARCH 64 architecture support is missing in the exiting common-crypto code. > Now we did some modification in the code level and add the support for > AARCH64. Now the common-crypto project can be used in aarch64 platform and > also compatible with openssl 1.1.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NUMBERS-104) Speed up trial division
Heinrich Bohne created NUMBERS-104:
--
Summary: Speed up trial division
Key: NUMBERS-104
URL: https://issues.apache.org/jira/browse/NUMBERS-104
Project: Commons Numbers
Issue Type: Improvement
Components: primes
Reporter: Heinrich Bohne
Currently, the method {{SmallPrimes.boundedTrialDivision(int, int,
List)}} skips multiples of 2 and 3, thereby reducing the amount of
integers to be tried to 1/3 of all integers. This can be improved at the cost
of extra memory by extending the set of prime factors to be skipped in the
trial division, for example, to 2, 3, 5, 7, and 11.
However, instead of code duplication, which is the way the code currently
achieves this, a way to implement this could be:
* First, precompute and store all integers between 0 (inclusive) and
2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime
numbers (480 numbers in total, according to my experiments).
* Then, when performing the trial division, one only needs to try out numbers
of the form 2310⋅k + c, where k is a non-negative integer and c is one of the
480 numbers described in the previous step.
That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%, instead
of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the current
algorithm. Of course, with more prime factors eliminated, less numbers will
have to be tried, but it seems that the returns are quickly diminishing
compared to the required memory. For example, when also eliminating the prime
factors 13, 17 and 19, the memory required increases to 1658880 integers,
whereas the percentage of integers to be tried only drops to about 17.10%.
Since the class {{SmallPrimes}} already stores an array containing the first
512 prime numbers, a 480-element {{int}} array seems like a reasonable size and
a small price to pay for a 60.42% speedup.
I'm just not entirely sure whether this should go here or on the developer
mailing list. Since this is actually not a new idea, but just an enhancement of
an already existing idea, I'm putting it here, but on the other hand, it
requires some re-writing and some new code, so maybe I'm wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NUMBERS-101) Cleanup build configuration for maven-surefire-plugin
[
https://issues.apache.org/jira/browse/NUMBERS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16850185#comment-16850185
]
Karl Heinz Marbaise commented on NUMBERS-101:
-
NUMBERS-103 should be done first so I can rebase this PR and remove the
configuration change in {{.travis.yml}}.
> Cleanup build configuration for maven-surefire-plugin
> -
>
> Key: NUMBERS-101
> URL: https://issues.apache.org/jira/browse/NUMBERS-101
> Project: Commons Numbers
> Issue Type: Task
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Problem*
> * currently the configuration for {{maven-surefire-plugin}} is given with
> configuration like this:
> {code:xml}
>
> **/*Test.java
>
>
> **/*AbstractTest.java
>
> {code}
> The configuration violates convention over configuration paradigm. The
> exception here is {{*AbstractTest.java}} but there is no java class like this
> in Test code at the moment.
> *Goal*
> * Remove the configuration which is not needed and keep the convention over
> configuration paradigm.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NUMBERS-103) Travis build fails every time based on usage of oraclejdk8
[
https://issues.apache.org/jira/browse/NUMBERS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated NUMBERS-103:
Description:
*Problem*
* The Travis build uses {{oraclejdk8}} which is not available on Travis.
* Remove also {{sudo: false}} which is not supported anymore on Travis.
*Goal*
* Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
* Remove {{sudo: false}}
was:
*Problem*
* The Travis build used {{oraclejdk8}} which is not available on Travis.
* Remove also {{sudo: false}} which is not supported anymore on Travis.
*Goal*
* Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
* Remove {{sudo: false}}
> Travis build fails every time based on usage of oraclejdk8
> --
>
> Key: NUMBERS-103
> URL: https://issues.apache.org/jira/browse/NUMBERS-103
> Project: Commons Numbers
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Problem*
> * The Travis build uses {{oraclejdk8}} which is not available on Travis.
> * Remove also {{sudo: false}} which is not supported anymore on Travis.
> *Goal*
> * Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
> * Remove {{sudo: false}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] khmarbaise opened a new pull request #39: [NUMBERS-103] - Travis build fails every time based on usage of oracl…
khmarbaise opened a new pull request #39: [NUMBERS-103] - Travis build fails every time based on usage of oracl… URL: https://github.com/apache/commons-numbers/pull/39 …ejdk8 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-103) Travis build fails every time based on usage of oraclejdk8
[
https://issues.apache.org/jira/browse/NUMBERS-103?focusedWorklogId=249667&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249667
]
ASF GitHub Bot logged work on NUMBERS-103:
--
Author: ASF GitHub Bot
Created on: 28/May/19 21:49
Start Date: 28/May/19 21:49
Worklog Time Spent: 10m
Work Description: khmarbaise commented on pull request #39: [NUMBERS-103]
- Travis build fails every time based on usage of oracl…
URL: https://github.com/apache/commons-numbers/pull/39
…ejdk8
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 249667)
Time Spent: 10m
Remaining Estimate: 0h
> Travis build fails every time based on usage of oraclejdk8
> --
>
> Key: NUMBERS-103
> URL: https://issues.apache.org/jira/browse/NUMBERS-103
> Project: Commons Numbers
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: 1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Problem*
> * The Travis build used {{oraclejdk8}} which is not available on Travis.
> * Remove also {{sudo: false}} which is not supported anymore on Travis.
> *Goal*
> * Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
> * Remove {{sudo: false}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-103) Travis build fails every time based on usage of oraclejdk8
Karl Heinz Marbaise created NUMBERS-103:
---
Summary: Travis build fails every time based on usage of oraclejdk8
Key: NUMBERS-103
URL: https://issues.apache.org/jira/browse/NUMBERS-103
Project: Commons Numbers
Issue Type: Bug
Affects Versions: 1.0
Reporter: Karl Heinz Marbaise
Fix For: 1.0
*Problem*
* The Travis build used {{oraclejdk8}} which is not available on Travis.
* Remove also {{sudo: false}} which is not supported anymore on Travis.
*Goal*
* Replace {{oraclejdk8}} with {{openjdk8}} which will succeed the build.
* Remove {{sudo: false}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NUMBERS-102) Upgrade maven-compiler-plugin to 3.8.1
[ https://issues.apache.org/jira/browse/NUMBERS-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated NUMBERS-102: Description: *Problem* * Several bug fixes etc. and issues have been fixed for maven-compiler-plugin since 3.5.1 in particular related to JDK8, JDK9+ etc. *Goal* * Upgrade to maven-compiler-plugin 3.8.1 This will make it easy to test builds on JDK9, JDK10, JDK11, JDK12 and JDK13 was: *Problem* * Several bug fixes etc. and issues have been fixed for maven-compiler-plugin since 3.5.1 in particular related to JDK8, JDK9+ etc. *Goal* * Upgrade to maven-compiler-plugin 3.8.1 > Upgrade maven-compiler-plugin to 3.8.1 > -- > > Key: NUMBERS-102 > URL: https://issues.apache.org/jira/browse/NUMBERS-102 > Project: Commons Numbers > Issue Type: Task >Affects Versions: 1.0 >Reporter: Karl Heinz Marbaise >Priority: Trivial > Fix For: 1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > *Problem* > * Several bug fixes etc. and issues have been fixed for maven-compiler-plugin > since 3.5.1 in particular related to JDK8, JDK9+ etc. > *Goal* > * Upgrade to maven-compiler-plugin 3.8.1 > This will make it easy to test builds on JDK9, JDK10, JDK11, JDK12 and JDK13 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (NUMBERS-102) Upgrade maven-compiler-plugin to 3.8.1
[ https://issues.apache.org/jira/browse/NUMBERS-102?focusedWorklogId=249647&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249647 ] ASF GitHub Bot logged work on NUMBERS-102: -- Author: ASF GitHub Bot Created on: 28/May/19 21:26 Start Date: 28/May/19 21:26 Worklog Time Spent: 10m Work Description: khmarbaise commented on pull request #38: [NUMBERS-102] - Upgrade maven-compiler-plugin to 3.8.1 URL: https://github.com/apache/commons-numbers/pull/38 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 249647) Time Spent: 10m Remaining Estimate: 0h > Upgrade maven-compiler-plugin to 3.8.1 > -- > > Key: NUMBERS-102 > URL: https://issues.apache.org/jira/browse/NUMBERS-102 > Project: Commons Numbers > Issue Type: Task >Affects Versions: 1.0 >Reporter: Karl Heinz Marbaise >Priority: Trivial > Fix For: 1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > *Problem* > * Several bug fixes etc. and issues have been fixed for maven-compiler-plugin > since 3.5.1 in particular related to JDK8, JDK9+ etc. > *Goal* > * Upgrade to maven-compiler-plugin 3.8.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-numbers] khmarbaise opened a new pull request #38: [NUMBERS-102] - Upgrade maven-compiler-plugin to 3.8.1
khmarbaise opened a new pull request #38: [NUMBERS-102] - Upgrade maven-compiler-plugin to 3.8.1 URL: https://github.com/apache/commons-numbers/pull/38 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NUMBERS-102) Upgrade maven-compiler-plugin to 3.8.1
Karl Heinz Marbaise created NUMBERS-102: --- Summary: Upgrade maven-compiler-plugin to 3.8.1 Key: NUMBERS-102 URL: https://issues.apache.org/jira/browse/NUMBERS-102 Project: Commons Numbers Issue Type: Task Affects Versions: 1.0 Reporter: Karl Heinz Marbaise Fix For: 1.0 *Problem* * Several bug fixes etc. and issues have been fixed for maven-compiler-plugin since 3.5.1 in particular related to JDK8, JDK9+ etc. *Goal* * Upgrade to maven-compiler-plugin 3.8.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (NUMBERS-101) Cleanup build configuration for maven-surefire-plugin
[
https://issues.apache.org/jira/browse/NUMBERS-101?focusedWorklogId=249643&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249643
]
ASF GitHub Bot logged work on NUMBERS-101:
--
Author: ASF GitHub Bot
Created on: 28/May/19 21:19
Start Date: 28/May/19 21:19
Worklog Time Spent: 10m
Work Description: khmarbaise commented on pull request #37: [NUMBERS-101]
- Cleanup build configuration for maven-surefire-plugin
URL: https://github.com/apache/commons-numbers/pull/37
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 249643)
Time Spent: 10m
Remaining Estimate: 0h
> Cleanup build configuration for maven-surefire-plugin
> -
>
> Key: NUMBERS-101
> URL: https://issues.apache.org/jira/browse/NUMBERS-101
> Project: Commons Numbers
> Issue Type: Task
>Affects Versions: 1.0
>Reporter: Karl Heinz Marbaise
>Priority: Trivial
> Fix For: 1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Problem*
> * currently the configuration for {{maven-surefire-plugin}} is given with
> configuration like this:
> {code:xml}
>
> **/*Test.java
>
>
> **/*AbstractTest.java
>
> {code}
> The configuration violates convention over configuration paradigm. The
> exception here is {{*AbstractTest.java}} but there is no java class like this
> in Test code at the moment.
> *Goal*
> * Remove the configuration which is not needed and keep the convention over
> configuration paradigm.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] khmarbaise opened a new pull request #37: [NUMBERS-101] - Cleanup build configuration for maven-surefire-plugin
khmarbaise opened a new pull request #37: [NUMBERS-101] - Cleanup build configuration for maven-surefire-plugin URL: https://github.com/apache/commons-numbers/pull/37 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (NUMBERS-101) Cleanup build configuration for maven-surefire-plugin
Karl Heinz Marbaise created NUMBERS-101:
---
Summary: Cleanup build configuration for maven-surefire-plugin
Key: NUMBERS-101
URL: https://issues.apache.org/jira/browse/NUMBERS-101
Project: Commons Numbers
Issue Type: Task
Affects Versions: 1.0
Reporter: Karl Heinz Marbaise
Fix For: 1.0
*Problem*
* currently the configuration for {{maven-surefire-plugin}} is given with
configuration like this:
{code:xml}
**/*Test.java
**/*AbstractTest.java
{code}
The configuration violates convention over configuration paradigm. The
exception here is {{*AbstractTest.java}} but there is no java class like this
in Test code at the moment.
*Goal*
* Remove the configuration which is not needed and keep the convention over
configuration paradigm.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws MissingResourceException instead of returning null
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed TEXT-165.
-
Resolution: Fixed
Fix Version/s: 1.7
In git master.
> ResourceBundleStringLookup.lookup(String) throws MissingResourceException
> instead of returning null
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.7
>
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws Mi
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-165:
--
Summary: ResourceBundleStringLookup.lookup(String) throws Mi (was:
ResourceBundleStringLookup.lookup(String))
> ResourceBundleStringLookup.lookup(String) throws Mi
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TEXT-165) ResourceBundleStringLookup.lookup(String) throws MissingResourceException instead of returning null
[
https://issues.apache.org/jira/browse/TEXT-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-165:
--
Summary: ResourceBundleStringLookup.lookup(String) throws
MissingResourceException instead of returning null (was:
ResourceBundleStringLookup.lookup(String) throws Mi)
> ResourceBundleStringLookup.lookup(String) throws MissingResourceException
> instead of returning null
> ---
>
> Key: TEXT-165
> URL: https://issues.apache.org/jira/browse/TEXT-165
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method
> {{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
> throws a {{MissingResourceException}} instead of returning {{null}} if a key
> is absent.
> This is a problem when you are using a resource bundle like this for example,
> when the key is missing, we want the method to return null such that an
> interpolator can supply a default value.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TEXT-165) ResourceBundleStringLookup.lookup(String)
Gary Gregory created TEXT-165:
-
Summary: ResourceBundleStringLookup.lookup(String)
Key: TEXT-165
URL: https://issues.apache.org/jira/browse/TEXT-165
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.6
Reporter: Gary Gregory
Assignee: Gary Gregory
The method
{{org.apache.commons.text.lookup.ResourceBundleStringLookup.lookup(String)}}
throws a {{MissingResourceException}} instead of returning {{null}} if a key is
absent.
This is a problem when you are using a resource bundle like this for example,
when the key is missing, we want the method to return null such that an
interpolator can supply a default value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-bcel] suztomo commented on issue #26: [BCEL-317] Pluggable cache for ConstantUtf8
suztomo commented on issue #26: [BCEL-317] Pluggable cache for ConstantUtf8 URL: https://github.com/apache/commons-bcel/pull/26#issuecomment-496653423 @garydgregory Thank you for the feedback. My approach in this PR tries to avoid modifying other classes than `ConstantUtf8`. While waiting for other maintainers' comments, I will think about another approach that does not change the behavior of `getInstance` and `getCachedInstance`. Removed `System.out.println` from this PR. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (DAEMON-402) frequent crash in prunsrv
[ https://issues.apache.org/jira/browse/DAEMON-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849857#comment-16849857 ] Mark Thomas commented on DAEMON-402: Can you provide some more details about the circumstances under which you observe these crashes? To what extent has this patch been tested? I am concerned that the patch is addressing a symptom rather than the root cause. > frequent crash in prunsrv > - > > Key: DAEMON-402 > URL: https://issues.apache.org/jira/browse/DAEMON-402 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.1.0 > Environment: windows 10 >Reporter: lode leroy >Priority: Critical > Labels: easyfix, patch, windows > Fix For: 1.1.1 > > Attachments: fix-crash-on-repeated_wmclose.diff > > > I see frequent crashes in prunsrv.exe on Windows 10. > I have the impression that the WM_CLOSE windows message is sent multiple > times - and the code does not expect that, resulting in an attempt to free > memory that was already freed. > Here is a stack trace from a minidump: > ntdll.dll!7ff903af6e1e() Unknown > AcLayers.dll!7ff87cd77a56() Unknown > prunsrv.exe!HeapFREE(void * hHeap, unsigned long dwFlags, void * lpMem) > Line 71 C > prunsrv.exe!__apxPoolFreeCore(void * lpMem) Line 133 C > prunsrv.exe!apxFree(void * lpMem) Line 402 C > prunsrv.exe!__apxProcessCallback(stAPXHANDLE * hObject, unsigned int > uMsg, unsigned __int64 wParam, __int64 lParam) Line 396 C > prunsrv.exe!apxCloseHandle(stAPXHANDLE * hObject) Line 498 C > prunsrv.exe!__apxPoolCallback(stAPXHANDLE * hObject, unsigned int uMsg, > unsigned __int64 wParam, __int64 lParam) Line 190 C > prunsrv.exe!__apxPoolCallback(stAPXHANDLE * hObject, unsigned int uMsg, > unsigned __int64 wParam, __int64 lParam) Line 184 C > prunsrv.exe!apxCloseHandle(stAPXHANDLE * hObject) Line 498 C > prunsrv.exe!apxHandleManagerDestroy(...) Line 291 C > prunsrv.exe!main(int argc, char * * argv) Line 1830 C -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-bcel] garydgregory commented on issue #26: [BCEL-317] Pluggable cache for ConstantUtf8
garydgregory commented on issue #26: [BCEL-317] Pluggable cache for ConstantUtf8 URL: https://github.com/apache/commons-bcel/pull/26#issuecomment-496505333 I'm not sure if this PR is a good thing. I'd like feedback from the community. **TL;DR** If you want caching, use the existing `getCachedInstance()` API, it's an existing feature. **Details** [Please do not hesitate to correct details I may have wrong] Right now, before this PR, we have two clear and simple APIs: - `getInstance()` always returns a new instance. - `getCachedInstance()` returns a cached instance unless the cache is full. Some thoughts: - The PR adds 2 global variables as system properties, this is definitely not a good thing, even if the current code already uses a sys prop. - The PR removes an existing sys prop, therefore breaking compatibility. - The PR changes the behavior of `getInstance()` which can now return a cached instance, which could (or not) break things but definitely falls into the unexpected category IMO. **More Details** The PR should not write to the console. The existing code might be better re-implemented using a ConcurrentHashMap for simpler synchronization. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BEANUTILS-520. -- Resolution: Fixed Fix Version/s: 2.0.0 In git master. > BeanUtils2 mitigate CVE-2014-0114 > - > > Key: BEANUTILS-520 > URL: https://issues.apache.org/jira/browse/BEANUTILS-520 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.3 >Reporter: Melloware >Priority: Major > Labels: security > Fix For: 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://nvd.nist.gov/vuln/detail/CVE-2014-0114 > Due to the above CVE in 1.9.2 they added a Suppression but it is still being > marked as a security risk through most major checks from OWASP and Sonatype > IQ. > "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes > a specialized instance of itself as the SUPPRESS_CLASS constant beginning in > version 1.9.2 that specifically suppresses the class property. +However, this > fix is not enabled by default.+" > For BeanUtils2 why not make this the default and have people "enable" it if > it they want to get the feature. > Thanks for your consideration. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114
[ https://issues.apache.org/jira/browse/BEANUTILS-520?focusedWorklogId=249302&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249302 ] ASF GitHub Bot logged work on BEANUTILS-520: Author: ASF GitHub Bot Created on: 28/May/19 12:31 Start Date: 28/May/19 12:31 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #7: BEANUTILS-520: Mitigate CVE-2014-0114 by enabling SuppressPropertiesB… URL: https://github.com/apache/commons-beanutils/pull/7 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 249302) Time Spent: 20m (was: 10m) > BeanUtils2 mitigate CVE-2014-0114 > - > > Key: BEANUTILS-520 > URL: https://issues.apache.org/jira/browse/BEANUTILS-520 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 1.9.3 >Reporter: Melloware >Priority: Major > Labels: security > Fix For: 2.0.0 > > Time Spent: 20m > Remaining Estimate: 0h > > https://nvd.nist.gov/vuln/detail/CVE-2014-0114 > Due to the above CVE in 1.9.2 they added a Suppression but it is still being > marked as a security risk through most major checks from OWASP and Sonatype > IQ. > "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes > a specialized instance of itself as the SUPPRESS_CLASS constant beginning in > version 1.9.2 that specifically suppresses the class property. +However, this > fix is not enabled by default.+" > For BeanUtils2 why not make this the default and have people "enable" it if > it they want to get the feature. > Thanks for your consideration. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-beanutils] garydgregory merged pull request #7: BEANUTILS-520: Mitigate CVE-2014-0114 by enabling SuppressPropertiesB…
garydgregory merged pull request #7: BEANUTILS-520: Mitigate CVE-2014-0114 by enabling SuppressPropertiesB… URL: https://github.com/apache/commons-beanutils/pull/7 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] garydgregory edited a comment on issue #28: Fix tests which compare against the environment
garydgregory edited a comment on issue #28: Fix tests which compare against the environment URL: https://github.com/apache/commons-configuration/pull/28#issuecomment-496489547 We need help fixing the build on Java 13-EA... ;-) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] garydgregory merged pull request #28: Fix tests which compare against the environment
garydgregory merged pull request #28: Fix tests which compare against the environment URL: https://github.com/apache/commons-configuration/pull/28 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-configuration] garydgregory commented on issue #28: Fix tests which compare against the environment
garydgregory commented on issue #28: Fix tests which compare against the environment URL: https://github.com/apache/commons-configuration/pull/28#issuecomment-496489547 We need help fixing the build on java 13-EA... ;-) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (DAEMON-401) Environment variables set on service not available in JNI dll
[ https://issues.apache.org/jira/browse/DAEMON-401?focusedWorklogId=249246&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249246 ] ASF GitHub Bot logged work on DAEMON-401: - Author: ASF GitHub Bot Created on: 28/May/19 10:27 Start Date: 28/May/19 10:27 Worklog Time Spent: 10m Work Description: jgallimore commented on pull request #475: DAEMON-401 - updating Windows service binaries URL: https://github.com/apache/tomee/pull/475 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 249246) Time Spent: 20m (was: 10m) > Environment variables set on service not available in JNI dll > - > > Key: DAEMON-401 > URL: https://issues.apache.org/jira/browse/DAEMON-401 > Project: Commons Daemon > Issue Type: Bug >Reporter: Jonathan Gallimore >Priority: Major > Fix For: 1.1.1 > > Attachments: daemon-1.diff, daemon-env.diff, simple-jni.zip > > Time Spent: 20m > Remaining Estimate: 0h > > I have a JNI dll loaded by a Java process running as a Windows service on > Windows 2019 using prunsrv. The JNI library is built with VC14, and makes > calls to getenv(), which is imported from ucrtbase.dll. > This call to getenv does not pick up environment variables that are set on > the service via //US//Service ++Environment "key=value". Commons Daemon is > setting these environment variables using _wputenv(), which is imported from > msvcrt.dll. > I started a discussion on the mailing list regarding this. I have patch which > dynamically loads ucrtbase.dll and calls its _wputenv method as well, if it > is available. > I'm happy to provide changes or further patches, and work on this issue, but > feedback would be useful and very much appreciated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (DAEMON-401) Environment variables set on service not available in JNI dll
[ https://issues.apache.org/jira/browse/DAEMON-401?focusedWorklogId=249243&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-249243 ] ASF GitHub Bot logged work on DAEMON-401: - Author: ASF GitHub Bot Created on: 28/May/19 10:25 Start Date: 28/May/19 10:25 Worklog Time Spent: 10m Work Description: jgallimore commented on pull request #475: DAEMON-401 - updating Windows service binaries URL: https://github.com/apache/tomee/pull/475 This updates the Windows Service binaries to version 5616a31 from Commons-Daemon. This includes https://issues.apache.org/jira/browse/DAEMON-401 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 249243) Time Spent: 10m Remaining Estimate: 0h > Environment variables set on service not available in JNI dll > - > > Key: DAEMON-401 > URL: https://issues.apache.org/jira/browse/DAEMON-401 > Project: Commons Daemon > Issue Type: Bug >Reporter: Jonathan Gallimore >Priority: Major > Fix For: 1.1.1 > > Attachments: daemon-1.diff, daemon-env.diff, simple-jni.zip > > Time Spent: 10m > Remaining Estimate: 0h > > I have a JNI dll loaded by a Java process running as a Windows service on > Windows 2019 using prunsrv. The JNI library is built with VC14, and makes > calls to getenv(), which is imported from ucrtbase.dll. > This call to getenv does not pick up environment variables that are set on > the service via //US//Service ++Environment "key=value". Commons Daemon is > setting these environment variables using _wputenv(), which is imported from > msvcrt.dll. > I started a discussion on the mailing list regarding this. I have patch which > dynamically loads ucrtbase.dll and calls its _wputenv method as well, if it > is available. > I'm happy to provide changes or further patches, and work on this issue, but > feedback would be useful and very much appreciated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (STATISTICS-15) Class Diagram of "math4.stat.descriptive" module & development flow
Virendra Singh created STATISTICS-15: Summary: Class Diagram of "math4.stat.descriptive" module & development flow Key: STATISTICS-15 URL: https://issues.apache.org/jira/browse/STATISTICS-15 Project: Apache Commons Statistics Issue Type: Sub-task Reporter: Virendra Singh Attachments: Class_Diagram-math4.stat.descriptive.jpg, stat Classes.docx As my GSoC project(commons-statistics-descriptive) is to refactor "commons.math4.stat.descriptive.*", and upgrade it using Java 8 features like Stream API, Functional Interface etc. I've created a Class-Diagram of "commons.math4.stat.descriptive.*" so as to understand the old code, it's flow and working. The class-diagram and flow of the development of the classes are attached here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DAEMON-388) jsvc does not play nice with JMX
[
https://issues.apache.org/jira/browse/DAEMON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849513#comment-16849513
]
Michael Osipov commented on DAEMON-388:
---
No real problem, but I'd expect the deamon to look like {{java(1)}} for
external tools like jconsole, jps, etc.
> jsvc does not play nice with JMX
>
>
> Key: DAEMON-388
> URL: https://issues.apache.org/jira/browse/DAEMON-388
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.1.0
> Environment: FreeBSD 10.4-STABLE #22 r94: Wed May 9 08:53:46
> CEST 2018 i386
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 1.1.1
>
>
> * Installed Commons Daemon through Ports, installed Tomcat 8.5 (uses JSVC)
> through Ports.
> * Started Tomcat
> * Launched JConsole locally to attach to VM
> The VM does not display with its PID. After some search, I figured out that
> {{com.sun.management.jmxremote}} is not set, but enabled by {{java(1)}} since
> version 6. I'd expect the same behavior. After setting it, the VM is visible
> in JConsole, but the startup class is not visible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-388) jsvc does not play nice with JMX
[
https://issues.apache.org/jira/browse/DAEMON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16849447#comment-16849447
]
Mark Thomas commented on DAEMON-388:
What problem are you trying to solve by adding the additional properties?
> jsvc does not play nice with JMX
>
>
> Key: DAEMON-388
> URL: https://issues.apache.org/jira/browse/DAEMON-388
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.1.0
> Environment: FreeBSD 10.4-STABLE #22 r94: Wed May 9 08:53:46
> CEST 2018 i386
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 1.1.1
>
>
> * Installed Commons Daemon through Ports, installed Tomcat 8.5 (uses JSVC)
> through Ports.
> * Started Tomcat
> * Launched JConsole locally to attach to VM
> The VM does not display with its PID. After some search, I figured out that
> {{com.sun.management.jmxremote}} is not set, but enabled by {{java(1)}} since
> version 6. I'd expect the same behavior. After setting it, the VM is visible
> in JConsole, but the startup class is not visible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
