[jira] [Created] (CRYPTO-174) Allow override of SSL library name
Sebb created CRYPTO-174: --- Summary: Allow override of SSL library name Key: CRYPTO-174 URL: https://issues.apache.org/jira/browse/CRYPTO-174 Project: Commons Crypto Issue Type: New Feature Reporter: Sebb Assignee: Sebb Windows seems to install all the crypto libraries in C:\Windows\SYSTEM32. The default has the name libcrypto.dll, and alternates may have names such as libcrypto-1_1-x64.dll. This is different from Unix and macOS, where different versions are stored in different directories. The default library name is a softlink to the versioned name, so there is no need to change the name. This means allowing for the override of both the JNI name and JNA name. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CRYPTO-167) Cannot use env to report missing env!
[
https://issues.apache.org/jira/browse/CRYPTO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CRYPTO-167.
-
Resolution: Fixed
> Cannot use env to report missing env!
> -
>
> Key: CRYPTO-167
> URL: https://issues.apache.org/jira/browse/CRYPTO-167
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are several places (e.g. [1]) where the code does the following or
> similar:
> {code}
> if (!env || !handle) {
> THROW(env, "java/lang/InternalError", NULL);
> return NULL;
> }
> {code}
> This does not make sense, as the THROW macro tries to use the env variable to
> report the problem. This will cause a crash which may be hard to decipher. If
> the env parameter is NULL, different action should be taken if possible.
> [1]
> https://github.com/apache/commons-crypto/blob/5bb858cbcffb3aff915a6928e7761d5f33d56b6b/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h#L84
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CRYPTO-167) Cannot use env to report missing env!
[
https://issues.apache.org/jira/browse/CRYPTO-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782940#comment-17782940
]
Sebb commented on CRYPTO-167:
-
I now think this issue is wrong; the problem is that the code should not be
checking for a missing env.
The check is only done for calls to methods internal to the native code via the
macros LOAD_DYNAMIC_SYMBOL and LOAD_DYNAMIC_SYMBOL_FALLBACK.
> Cannot use env to report missing env!
> -
>
> Key: CRYPTO-167
> URL: https://issues.apache.org/jira/browse/CRYPTO-167
> Project: Commons Crypto
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are several places (e.g. [1]) where the code does the following or
> similar:
> {code}
> if (!env || !handle) {
> THROW(env, "java/lang/InternalError", NULL);
> return NULL;
> }
> {code}
> This does not make sense, as the THROW macro tries to use the env variable to
> report the problem. This will cause a crash which may be hard to decipher. If
> the env parameter is NULL, different action should be taken if possible.
> [1]
> https://github.com/apache/commons-crypto/blob/5bb858cbcffb3aff915a6928e7761d5f33d56b6b/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h#L84
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CRYPTO-172) Add support for Linux-riscv64
[ https://issues.apache.org/jira/browse/CRYPTO-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CRYPTO-172. - Resolution: Fixed > Add support for Linux-riscv64 > - > > Key: CRYPTO-172 > URL: https://issues.apache.org/jira/browse/CRYPTO-172 > Project: Commons Crypto > Issue Type: Improvement > Components: Build >Reporter: Ludovic Henry >Priority: Major > > Java supports RISC-V since version 19. Given Apache Common Crypto is a > commonly used library in the Java ecosystem, it's important for it to support > RISC-V as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782280#comment-17782280
]
Thomas Vandahl edited comment on JCS-240 at 11/4/23 5:15 PM:
-
See https://bugs.openjdk.org/browse/JDK-8237213 for an explanation. The issue
JDK-8237213 hints that Java 8 from Update 241 on will show this behaviour, too,
as will JDK 11.0.6.
The recommended way of resolving this is to redeclare the methods to be called
remotely.
For the record: The actual cause seems to be the fix for
https://bugs.openjdk.java.net/browse/JDK-8230967 which is not public,
unfortunately.
was (Author: tv):
See https://bugs.openjdk.org/browse/JDK-8237213 for an explanation. The issue
JDK-8237213 hints that Java 8 from Update 241 on will show this behaviour, too.
The recommended way of resolving this is to redeclare the methods to be called
remotely.
> Remote cache appears incompatible with JDK 8u241 and above
> --
>
> Key: JCS-240
> URL: https://issues.apache.org/jira/browse/JCS-240
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.2
>Reporter: Greg Parmiter
>Assignee: Thomas Vandahl
>Priority: Critical
>
> After setting up remote RMI cache, with the central cache service running in
> the same app server/JVM (JDK version 11) as ~4 clients, there were
> intermittent put and remove failures, as well as issues similar to JCS-237,
> JCS-238, and JCS-239.
> While investigating the intermittent put/remove issues, the remote server log
> showed the following-
> {code:java}
> Error while running event from Queue: PutEvent for key: key1 value: null.
> Retrying...
> java.rmi.RemoteException: Method is not Remote: interface
> org.apache.commons.jcs3.engine.behavior.ICacheListener::public abstract void
> org.apache.commons.jcs3.engine.behavior.ICacheListener.handlePut(org.apache.commons.jcs3.engine.behavior.ICacheElement)
> throws java.io.IOException
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> ~[?:?]
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> ~[?:?]
> at com.sun.proxy.$Proxy2195.handlePut(Unknown Source) ~[?:?]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:277)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:216)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:829) ~[?:?]{code}
> This pointed to an incorrect listener being registered from the client(s),
> but when debugging, I saw that the clients were registering the correct
> listener type, which implements the Remote interface-
> {code:java}
> listener =
> RemoteCacheListener:
> AbstractRemoteCacheListener:
> RemoteHost = localhost:1101
> ListenerId = 4 {code}
> I understand there's a class hierarchy in place where the RemoveCacheListener
> implements the IRemoteCacheListener interface, which is a sub-interface of
> Remote, but therein lies the issue. When the event queue is being processed
> at runtime and the ICacheListener is being proxied to the appropriate
> concrete class, the JVM does not recognize the sub-interface and thus, the
> Remote interface is not seen. *The appears to occur in JDK 11 JVMs but not
> JDK 8. In other words, JCS 3.2 remote cache does not appear to work properly
> in JDK 11 (and higher?) runtimes.*
> I "resolved" this by implementing the Remote interface in the ICacheListener,
> and this actually resolved JCS-237, JCS-238, and JCS-239. That said, it's
> likely not the optimal solution here. Another option-
> Create another abstract class, AbstractRemoteCacheEventQueue, that passes the
> IRemoteCacheListener rather than the base ICacheListener to the applicable
> listener. This would obviously have to be added into the appropriate place(s)
> in the hierarchy (i.e., RemoteCacheListener, etc.).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCS-240) Remote cache appears incompatible with JDK 8u241 and above
[
https://issues.apache.org/jira/browse/JCS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782909#comment-17782909
]
Thomas Vandahl commented on JCS-240:
I'm planning to release this as a patch release 3.2.1 because I consider this a
quite serious problem. I will be trying to find some time in next weeks.
> Remote cache appears incompatible with JDK 8u241 and above
> --
>
> Key: JCS-240
> URL: https://issues.apache.org/jira/browse/JCS-240
> Project: Commons JCS
> Issue Type: Bug
> Components: RMI Remote Cache
>Affects Versions: jcs-3.2
>Reporter: Greg Parmiter
>Assignee: Thomas Vandahl
>Priority: Critical
>
> After setting up remote RMI cache, with the central cache service running in
> the same app server/JVM (JDK version 11) as ~4 clients, there were
> intermittent put and remove failures, as well as issues similar to JCS-237,
> JCS-238, and JCS-239.
> While investigating the intermittent put/remove issues, the remote server log
> showed the following-
> {code:java}
> Error while running event from Queue: PutEvent for key: key1 value: null.
> Retrying...
> java.rmi.RemoteException: Method is not Remote: interface
> org.apache.commons.jcs3.engine.behavior.ICacheListener::public abstract void
> org.apache.commons.jcs3.engine.behavior.ICacheListener.handlePut(org.apache.commons.jcs3.engine.behavior.ICacheElement)
> throws java.io.IOException
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:214)
> ~[?:?]
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:162)
> ~[?:?]
> at com.sun.proxy.$Proxy2195.handlePut(Unknown Source) ~[?:?]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$PutEvent.doRun(AbstractCacheEventQueue.java:277)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> org.apache.commons.jcs3.engine.AbstractCacheEventQueue$AbstractCacheEvent.run(AbstractCacheEventQueue.java:216)
> ~[commons-jcs3-core-3.2.jar:3.2]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:829) ~[?:?]{code}
> This pointed to an incorrect listener being registered from the client(s),
> but when debugging, I saw that the clients were registering the correct
> listener type, which implements the Remote interface-
> {code:java}
> listener =
> RemoteCacheListener:
> AbstractRemoteCacheListener:
> RemoteHost = localhost:1101
> ListenerId = 4 {code}
> I understand there's a class hierarchy in place where the RemoveCacheListener
> implements the IRemoteCacheListener interface, which is a sub-interface of
> Remote, but therein lies the issue. When the event queue is being processed
> at runtime and the ICacheListener is being proxied to the appropriate
> concrete class, the JVM does not recognize the sub-interface and thus, the
> Remote interface is not seen. *The appears to occur in JDK 11 JVMs but not
> JDK 8. In other words, JCS 3.2 remote cache does not appear to work properly
> in JDK 11 (and higher?) runtimes.*
> I "resolved" this by implementing the Remote interface in the ICacheListener,
> and this actually resolved JCS-237, JCS-238, and JCS-239. That said, it's
> likely not the optimal solution here. Another option-
> Create another abstract class, AbstractRemoteCacheEventQueue, that passes the
> IRemoteCacheListener rather than the base ICacheListener to the applicable
> listener. This would obviously have to be added into the appropriate place(s)
> in the hierarchy (i.e., RemoteCacheListener, etc.).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IMAGING-362) TIFF tags 0x111 and 0x117 have wrong descriptive names
[ https://issues.apache.org/jira/browse/IMAGING-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782892#comment-17782892 ] Gary Lucas commented on IMAGING-362: I've been away for awhile, so I don't know when this happened... But it appears that Imaging is using the ExifTagConstants class rather than TiffTagConstants when reading these elements. Perhaps it was always that way. The ExifTagConstants has the same mistake as the code I fixed. I will investigate further. I don't think that having redundant specifications is ideal, but I don't know what the level-of-effort/potential-to-break-things would be for trying to unify the code. At the very least, I will update ExifTagConstants to be correct. > TIFF tags 0x111 and 0x117 have wrong descriptive names > -- > > Key: IMAGING-362 > URL: https://issues.apache.org/jira/browse/IMAGING-362 > Project: Commons Imaging > Issue Type: Bug > Components: Format: TIFF >Affects Versions: 1.0-alpha2 >Reporter: Gary Lucas >Priority: Minor > Fix For: 1.0 > > > The TIFF standard defines metadata elements using integer code values. For > code values 0x111 and 0x117, Commons Imaging associates these with incorrect > names "PreviewImageStart" and "PreviewImageLength". According to the > specification "TIFF Revision 6.0 Final – June 3, 1992", the correct names for > these are "StripOffsets" and "StripByteCounts". In fact, the word "preview" > never even shows up in the TIFF specification. > This should be an easy fix. No new test cases will be required, since these > are descriptive elements only. > The role of these two elements is to define the file position and length of > data elements for TIFF files that are encoded as strips. > One of the example programs in the Commons Imaging distribution (which is not > compiled) is called ReadTagsAndImages.java. It can be used to dump TIFF tags. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Simplify native code by moving differences into macros [commons-crypto]
sebbASF merged PR #266: URL: https://github.com/apache/commons-crypto/pull/266 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Simplify native code by moving differences into macros [commons-crypto]
sebbASF opened a new pull request, #266: URL: https://github.com/apache/commons-crypto/pull/266 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] CRYPTO-172: Add support for Linux-riscv64 [commons-crypto]
luhenry commented on PR #264: URL: https://github.com/apache/commons-crypto/pull/264#issuecomment-1793411674 @sebbASF Thank you for the review and continuous feedback as well! :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] CRYPTO-172: Add support for Linux-riscv64 [commons-crypto]
sebbASF commented on PR #264: URL: https://github.com/apache/commons-crypto/pull/264#issuecomment-1793410602 Thanks for your patience dedication getting this together! Any further tweaks can be made in the main repo -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] CRYPTO-172: Add support for Linux-riscv64 [commons-crypto]
sebbASF merged PR #264: URL: https://github.com/apache/commons-crypto/pull/264 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Unnecessary profiles; use -Dtarget.name instead [commons-crypto]
sebbASF commented on PR #263: URL: https://github.com/apache/commons-crypto/pull/263#issuecomment-1793389523 It does seem to be possible to detect a specific value of target.name and use that to define another property. -- 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
