[Red Hat JIRA] (ISPN-12565) Entries stream does not convert maxidle and lifespan to seconds
by Katia Aresti (Jira)
Katia Aresti created ISPN-12565:
-----------------------------------
Summary: Entries stream does not convert maxidle and lifespan to seconds
Key: ISPN-12565
URL: https://issues.redhat.com/browse/ISPN-12565
Project: Infinispan
Issue Type: Bug
Components: REST
Affects Versions: 12.0.0.Dev07
Reporter: Katia Aresti
Assignee: Katia Aresti
The REST endpoint that streams key values, does not convert lifespan and maxidle to milliseconds, while the REST API works with those parameters with seconds even if internally they are stored as milliseconds
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months
[Red Hat JIRA] (ISPN-9165) ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/ISPN-9165?page=com.atlassian.jira.plugin... ]
Boris Unckel commented on ISPN-9165:
------------------------------------
[~dmlloyd] We had the same issue. Please find a possible solution attached. I don't have a stacktrace (anymore) and no unit test. It solved the issue for our productive system. The idea is similar to #2 in the description above. It seems with [ISPN-10274 Remove uberjar warnings|https://github.com/infinispan/infinispan/commit/6d598c530ab73539...] this is obsolete and the issue can be closed?
> ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
> ---------------------------------------------------------------------
>
> Key: ISPN-9165
> URL: https://issues.redhat.com/browse/ISPN-9165
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.2.Final
> Reporter: David Lloyd
> Priority: Critical
> Labels: security-manager
> Attachments: ManifestUberJarDuplicatedJarsWarner.java
>
>
> {{ManifestUberJarDuplicatedJarsWarner}} has a method called {{isClasspathCorrectAsync}} which dispatches a task to the fork-join pool. The task loads resources from the Infinispan JAR.
> This fails under a security manager. The common FJP executes tasks with no permissions. One of two things must be done:
> # Do not use the fork-join pool; find some other async solution which preserves the access control context.
> # Capture and propagate the current AccessControlContext when calling {{isClasspathCorrectAsync}}. This can be done by calling {{AccessController.getContext()}} before submitting the task, and then, within the submitted lambda, wrap the call to isClasspathCorrect with a call to {{AccessController.doPrivileged()}} which restores the captured context (by giving it as the second parameter). Note that this will entail a nested lambda or anonymous class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months
[Red Hat JIRA] (ISPN-9165) ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/ISPN-9165?page=com.atlassian.jira.plugin... ]
Boris Unckel updated ISPN-9165:
-------------------------------
Attachment: ManifestUberJarDuplicatedJarsWarner.java
> ManifestUberJarDuplicatedJarsWarner uses FJP without privileged block
> ---------------------------------------------------------------------
>
> Key: ISPN-9165
> URL: https://issues.redhat.com/browse/ISPN-9165
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.2.Final
> Reporter: David Lloyd
> Priority: Critical
> Labels: security-manager
> Attachments: ManifestUberJarDuplicatedJarsWarner.java
>
>
> {{ManifestUberJarDuplicatedJarsWarner}} has a method called {{isClasspathCorrectAsync}} which dispatches a task to the fork-join pool. The task loads resources from the Infinispan JAR.
> This fails under a security manager. The common FJP executes tasks with no permissions. One of two things must be done:
> # Do not use the fork-join pool; find some other async solution which preserves the access control context.
> # Capture and propagate the current AccessControlContext when calling {{isClasspathCorrectAsync}}. This can be done by calling {{AccessController.getContext()}} before submitting the task, and then, within the submitted lambda, wrap the call to isClasspathCorrect with a call to {{AccessController.doPrivileged()}} which restores the captured context (by giving it as the second parameter). Note that this will entail a nested lambda or anonymous class.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months
[Red Hat JIRA] (ISPN-12564) Remove support for property "infinispan.query.lucene.max-boolean-clauses" from the index config
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12564?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12564:
-------------------------------------
Description:
The Lucene max Clauses is a JVM level (static config) and affects all caches, so it doesn't make sense to have:
{code:java}
builder.indexing().enable()
.storage(LOCAL_HEAP)
.addIndexedEntity("sample_bank_account.User")
.addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
{code}
was:
This config is a JVM level config and affects all caches, so it doesn't make sense to have:
{code:java}
builder.indexing().enable()
.storage(LOCAL_HEAP)
.addIndexedEntity("sample_bank_account.User")
.addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
{code}
> Remove support for property "infinispan.query.lucene.max-boolean-clauses" from the index config
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-12564
> URL: https://issues.redhat.com/browse/ISPN-12564
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
> Priority: Major
>
> The Lucene max Clauses is a JVM level (static config) and affects all caches, so it doesn't make sense to have:
> {code:java}
> builder.indexing().enable()
> .storage(LOCAL_HEAP)
> .addIndexedEntity("sample_bank_account.User")
> .addProperty("infinispan.query.lucene.max-boolean-clauses", "1025");
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 4 months