October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3978) Updating to Infinispan 6.0 on JBoss AS 7.1.1

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-3978?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3978: --------------------------------------- Just a note: the modules that the infinispan team publishes do not replace those used by the internal clustering of WildFly, but are for application use only. > Updating to Infinispan 6.0 on JBoss AS 7.1.1 > -------------------------------------------- > > Key: ISPN-3978 > URL: https://issues.jboss.org/browse/ISPN-3978 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 6.0.0.Final > Environment: Windows 7 FR, NetBeans 7.4, JBoss AS 7.1.1 > Reporter: Adriano Labate > Priority: Minor > Labels: infinispan, jboss-as7, update > > JBoss AS 7.1.1 is bundled with Infinispan 5.1.2.FINAL. > On the page http://infinispan.org/download, there's a green button "AS 7 Modules" with description "Packaged modules for deploying in JBoss AS 7". > I understand that this AS 7 module is for updating to Infinispan version 6.0. > I downloaded and extracted the infinispan-as-modules-6.0.0.Final.zip file in the "\modules" folder. I didn't deleted anything, just copied the archive content into modules. > Now when I run my application that uses the cache, I can read in my log file the following: > {code} > [org.infinispan.factories.GlobalComponentRegistry] ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.2.FINAL > {code} > So I supposed something is wrong. > Either the log file displays the wrong version, or my update operation was not sufficient for updating Infinispan to version 6.0 on AS 7. > For information, in my application POM, I added dependency as below: > {code:xml} > <dependency> > <groupId>org.infinispan</groupId> > <artifactId>infinispan-core</artifactId> > <version>6.0.0.Final</version> > <scope>provided</scope> > </dependency> > {code} > After some basic tests, I can notice that I can query the cache and put data in it, and find data. So it seems to work. But with which version of Infinispan? > Could anybody know how to correctly update Infinispan to 6.0? Or why the 5.1.2 version is mentioned in the log file instead of version 6.0? > Thanks. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10669) MurmurHash3 should have a special case for WrappedBytes

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10669?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10669: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > MurmurHash3 should have a special case for WrappedBytes > ------------------------------------------------------- > > Key: ISPN-10669 > URL: https://issues.jboss.org/browse/ISPN-10669 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.CR3 > > > {{MurmurHash3.hashCode(Object)}} has a special case for {{WrappedBytesArray}}, but not for other implementations of {{WrappedBytes}} like {{ProtobufValueWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10676) Docs: max-idle expiration and xsite

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10676?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10676: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.CR3 Resolution: Done > Docs: max-idle expiration and xsite > ----------------------------------- > > Key: ISPN-10676 > URL: https://issues.jboss.org/browse/ISPN-10676 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > Fix For: 10.0.0.CR3 > > > Docs for ISPN-10650 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10665) Evictions should be logged (DEBUG?) to show it happen and how many entries are evicted

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10665?page=com.atlassian.jira.plugin... ] Will Burns resolved ISPN-10665. ------------------------------- Resolution: Duplicate Issue This is duplicate of ISPN-10668 > Evictions should be logged (DEBUG?) to show it happen and how many entries are evicted > -------------------------------------------------------------------------------------- > > Key: ISPN-10665 > URL: https://issues.jboss.org/browse/ISPN-10665 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > There is no log message if entries are evicted. > It should be possible to track that with the logging -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10442) Expose XSite information via REST

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10442?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10442: ------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7392 > Expose XSite information via REST > --------------------------------- > > Key: ISPN-10442 > URL: https://issues.jboss.org/browse/ISPN-10442 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > Expose x-site info (status) via REST -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Nistor Adrian updated IPROTO-120: --------------------------------- Status: Open (was: New) > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-120) Null collection fields always unmarshalled as empty collection implementation

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-120?page=com.atlassian.jira.plugin... ] Nistor Adrian commented on IPROTO-120: -------------------------------------- See this issue on protostream: https://issues.jboss.org/browse/IPROTO-64 It came after Galder reported this in infinispan: https://issues.jboss.org/browse/ISPN-9072, which results from a discussion happening on IRC or Zulip, don't remember where. I'm not one of the people that thinks this is a must, but rather a nice to have, but I accepted that some need this, and coincidentally protobuf-java also does it like this. If you listen to their arguments, indeed, from a domain modelling perspective we should prefer empty collections instead of nulls. I also passionately hate java.util.Optional and would rather use nulls whenever possible. I do not like the default value handling for missing fields in protobuf (which ATM I did not implement even though some people chase me with a stick for that). Would you like to get an empty string instead of a null? Seriously? So what do we do? At the time I accepted implementing IPROTO-64 I was suggesting a possible flag to enable that behaviour per field. Or the flag could be also per class or global, whatever. But I did not implement a public flag yet. But 4.3.x is still alpha, so it's theoretically still doable. Have a look at AbstractMarshallerCodeGenerator.noDefaults to see what I! mean. > Null collection fields always unmarshalled as empty collection implementation > ----------------------------------------------------------------------------- > > Key: IPROTO-120 > URL: https://issues.jboss.org/browse/IPROTO-120 > Project: Infinispan ProtoStream > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Nistor Adrian > Priority: Major > > The following Pojo always returns an empty collection after being unmarshalled, regardless of whether {{stringList}} was null or empty when marshalled. > {code:java} > public class SomePojo { > @ProtoField(number = 1, collectionImplementation = ArrayList.class) > final List<String> stringList; > @ProtoFactory > public SomePojo(List<String> stringList) { > this.stringList = stringList; > } > } > {code} > This is because the generated marshaller always creates the collection instance before attempting to read the collection content: > {code:java} > java.util.ArrayList __c$1 = new java.util.ArrayList(); > boolean done = false; > while (!done) { > final int tag = $2.readTag(); > switch (tag) { > case 0: > done = true; > break; > case 10: { > java.lang.String __v$1 = $2.readString(); > __c$1.add(__v$1); > break; > } > default: { > if (!$2.skipField(tag)) done = true; > } > } > } > > return new org.infinispan.query.dsl.embedded.testdomain.hsearch.SomePojo(__c$1); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10442) Expose XSite information via REST

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10442?page=com.atlassian.jira.plugin... ] Work on ISPN-10442 started by Gustavo Fernandes. ------------------------------------------------ > Expose XSite information via REST > --------------------------------- > > Key: ISPN-10442 > URL: https://issues.jboss.org/browse/ISPN-10442 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > Expose x-site info (status) via REST -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10442) Expose XSite information via REST

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10442?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10442: ------------------------------------- Status: Open (was: New) > Expose XSite information via REST > --------------------------------- > > Key: ISPN-10442 > URL: https://issues.jboss.org/browse/ISPN-10442 > Project: Infinispan > Issue Type: Feature Request > Components: REST > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Labels: console-ng > > Expose x-site info (status) via REST -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-98) Schema parser should recognize and enforce the 'reserved' statement

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/IPROTO-98?page=com.atlassian.jira.plugin.... ] Nistor Adrian updated IPROTO-98: -------------------------------- Fix Version/s: 5.0.0.Final > Schema parser should recognize and enforce the 'reserved' statement > ------------------------------------------------------------------- > > Key: IPROTO-98 > URL: https://issues.jboss.org/browse/IPROTO-98 > Project: Infinispan ProtoStream > Issue Type: Enhancement > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 5.0.0.Final > > > This is a continuation of IPROTO-11 > See > https://developers.google.com/protocol-buffers/docs/proto#reserved > https://developers.google.com/protocol-buffers/docs/proto3#reserved > The 'reserved' keyword was added in protobuf-java v3.0.0-alpha-3, which came years after the protoparser 4.0.3 we use so this cannot work unless we upgrade/replace protoparser. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2019