December 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8629) Javadoc modules' build invokes a new instance of Maven

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8629?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8629: ------------------------------- Status: Open (was: New) > Javadoc modules' build invokes a new instance of Maven > ------------------------------------------------------ > > Key: ISPN-8629 > URL: https://issues.jboss.org/browse/ISPN-8629 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 9.2.0.Beta1, 9.1.3.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.2.0.Beta2 > > > During the javadoc modules build, {{maven-javadoc-plugin}} tries to detect the apidocs location of each dependency. If a module dependency doesn't have an apidocs directory, it tries to run a new Maven instance in order to build it, leading to messages like this: > {noformat} > [INFO] The goal 'org.apache.maven.plugins:maven-javadoc-plugin:3.0.0-M1:javadoc' has not been previously called for the module: 'org.infinispan:infinispan-extended-statistics:jar:9.2.0-SNAPSHOT'. Trying to invoke it... > [ERROR] MavenInvocationException: Error when invoking Maven, consult the invoker log file: /home/dan/Work/infinispan/javadoc/javadoc-embedded/target/invoker/maven-javadoc-plugin2134174433.txt > [WARNING] Creating fake javadoc directory to prevent repeated invocations: /home/dan/Work/infinispan/extended-statistics/target/apidocs > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-6395) Unify clustered queries with non clustered queries

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-6395?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-6395: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.0.Beta2 Resolution: Done > Unify clustered queries with non clustered queries > -------------------------------------------------- > > Key: ISPN-6395 > URL: https://issues.jboss.org/browse/ISPN-6395 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Affects Versions: 9.2.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.0.Beta2, 9.2.0.Final > > > Clustered queries currently have a different method, and they work on top on non-shared indexes. > We should detect (or make it explicitly configurable) the fact that the index is not shared and use clustered query internally, but exposing a single method, with a new parameter to allow doing a query in a single step or two steps (broadcast). > Last, but not least, we should offer the possibility to broadcast Ickle queries apart from Lucene Queries, as Ickle queries are String and don't have serialization issues. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-8628: -------------------------------- Status: Open (was: New) > Simplify QueryEngine handling of Broadcast vs Fetch queries > ----------------------------------------------------------- > > Key: ISPN-8628 > URL: https://issues.jboss.org/browse/ISPN-8628 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > > [~anistor] commented > The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. > I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8628: ------------------------------------ Priority: Minor (was: Major) > Simplify QueryEngine handling of Broadcast vs Fetch queries > ----------------------------------------------------------- > > Key: ISPN-8628 > URL: https://issues.jboss.org/browse/ISPN-8628 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Minor > > [~anistor] commented > The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. > I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-8628: --------------------------------------- Summary: Simplify QueryEngine handling of Broadcast vs Fetch queries Key: ISPN-8628 URL: https://issues.jboss.org/browse/ISPN-8628 Project: Infinispan Issue Type: Task Reporter: Gustavo Fernandes [~anistor] commented The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-8628: --------------------------------------- Assignee: Gustavo Fernandes > Simplify QueryEngine handling of Broadcast vs Fetch queries > ----------------------------------------------------------- > > Key: ISPN-8628 > URL: https://issues.jboss.org/browse/ISPN-8628 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > [~anistor] commented > The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. > I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8601) Support entity and collection sharing same region name

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8601?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8601: ----------------------------------- Status: Open (was: New) > Support entity and collection sharing same region name > ------------------------------------------------------ > > Key: ISPN-8601 > URL: https://issues.jboss.org/browse/ISPN-8601 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Final > > > This is not fully working since you get an error that you're trying to inject same interceptor twice. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8142) Configuration Serializer doesn't handle global security

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8142?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8142: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.0.Beta2 9.2.0.Final Resolution: Done > Configuration Serializer doesn't handle global security > ------------------------------------------------------- > > Key: ISPN-8142 > URL: https://issues.jboss.org/browse/ISPN-8142 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 9.1.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.2.0.Beta2, 9.2.0.Final > > > The Configuration Serializer is missing support for serializing global security configs. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8624) Extend unmarshalling white list to GenericJBossMarshaller

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8624?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8624: ----------------------------------- Status: Open (was: New) > Extend unmarshalling white list to GenericJBossMarshaller > --------------------------------------------------------- > > Key: ISPN-8624 > URL: https://issues.jboss.org/browse/ISPN-8624 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling, Server > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Beta2, 9.2.0.Final > > > White list unmarshalling list can be injected via ClassResolver implementations. > We should also update the user guide that if developing a custom marshaller, you should add white list unmarshalling capabilities to avoid injection attacks. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8624) Extend unmarshalling white list to GenericJBossMarshaller

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8624?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8624: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5639 > Extend unmarshalling white list to GenericJBossMarshaller > --------------------------------------------------------- > > Key: ISPN-8624 > URL: https://issues.jboss.org/browse/ISPN-8624 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling, Server > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.2.0.Beta2, 9.2.0.Final > > > White list unmarshalling list can be injected via ClassResolver implementations. > We should also update the user guide that if developing a custom marshaller, you should add white list unmarshalling capabilities to avoid injection attacks. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2017