September 2020 - infinispan-issues

[JBoss JIRA] (ISPN-12366) infinispan-commons is not a valid Multi-Release jar

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/ISPN-12366?page=com.atlassian.jira.plugi... ] Radoslav Husar updated ISPN-12366: ---------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8726 > infinispan-commons is not a valid Multi-Release jar > --------------------------------------------------- > > Key: ISPN-12366 > URL: https://issues.redhat.com/browse/ISPN-12366 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 12.0.0.Dev05 > > > While the {{META-INF/versions/11}} part is correct, the MANIFEST.MF file must declare MRJAR explicitly which is absent. > See spec on https://openjdk.java.net/jeps/238. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12366) infinispan-commons is not a valid Multi-Release jar

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/ISPN-12366?page=com.atlassian.jira.plugi... ] Work on ISPN-12366 started by Radoslav Husar. --------------------------------------------- > infinispan-commons is not a valid Multi-Release jar > --------------------------------------------------- > > Key: ISPN-12366 > URL: https://issues.redhat.com/browse/ISPN-12366 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 12.0.0.Dev05 > > > While the {{META-INF/versions/11}} part is correct, the MANIFEST.MF file must declare MRJAR explicitly which is absent. > See spec on https://openjdk.java.net/jeps/238. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12366) infinispan-commons is not a valid Multi-Release jar

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/ISPN-12366?page=com.atlassian.jira.plugi... ] Radoslav Husar reassigned ISPN-12366: ------------------------------------- Assignee: Radoslav Husar > infinispan-commons is not a valid Multi-Release jar > --------------------------------------------------- > > Key: ISPN-12366 > URL: https://issues.redhat.com/browse/ISPN-12366 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 12.0.0.Dev05 > > > While the {{META-INF/versions/11}} part is correct, the MANIFEST.MF file must declare MRJAR explicitly which is absent. > See spec on https://openjdk.java.net/jeps/238. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12366) infinispan-commons is not a valid Multi-Release jar

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/ISPN-12366?page=com.atlassian.jira.plugi... ] Radoslav Husar updated ISPN-12366: ---------------------------------- Status: Open (was: New) > infinispan-commons is not a valid Multi-Release jar > --------------------------------------------------- > > Key: ISPN-12366 > URL: https://issues.redhat.com/browse/ISPN-12366 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 12.0.0.Dev05 > > > While the {{META-INF/versions/11}} part is correct, the MANIFEST.MF file must declare MRJAR explicitly which is absent. > See spec on https://openjdk.java.net/jeps/238. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12366) infinispan-commons is not a valid Multi-Release jar

by Radoslav Husar (Jira)

Radoslav Husar created ISPN-12366: ------------------------------------- Summary: infinispan-commons is not a valid Multi-Release jar Key: ISPN-12366 URL: https://issues.redhat.com/browse/ISPN-12366 Project: Infinispan Issue Type: Bug Components: Build Affects Versions: 12.0.0.Dev04, 11.0.3.Final Reporter: Radoslav Husar Fix For: 12.0.0.Dev05 While the {{META-INF/versions/11}} part is correct, the MANIFEST.MF file must declare MRJAR explicitly which is absent. See spec on https://openjdk.java.net/jeps/238. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12309) Creating cache with invalid configuration leaves inconsistent state

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12309?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12309: ------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/8725, https://github.com/infinispan/infinispan/pull/8693 (was: https://github.com/infinispan/infinispan/pull/8693) > Creating cache with invalid configuration leaves inconsistent state > ------------------------------------------------------------------- > > Key: ISPN-12309 > URL: https://issues.redhat.com/browse/ISPN-12309 > Project: Infinispan > Issue Type: Bug > Components: Core, REST > Affects Versions: 11.0.3.Final, 12.0.0.Dev04 > Reporter: Katia Aresti > Assignee: Gustavo Fernandes > Priority: Critical > > When a cache is created using the EmbeddedCacheManagerAdmin with a configuration that prevents the cache from starting, it will throw an error but will persist the cache nonetheless. > Further operations involving cache manager can throw exceptions, for example, {{Health.getHealth()}} since it tries to access the invalid cache that cannot be started -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Description: Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite and not the compile time variant so it flew under the radar. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting (but please note the structure of messages does not change!). These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name. The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix (all types are top level). was: Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name. The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix. > MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated > -------------------------------------------------------------------------------------------------------- > > Key: IPROTO-162 > URL: https://issues.redhat.com/browse/IPROTO-162 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.4.0.Alpha1, 4.3.4.Final > > > Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. > > Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite and not the compile time variant so it flew under the radar. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. > > Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. > The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting (but please note the structure of messages does not change!). These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name. > The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix (all types are top level). > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Description: Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name. The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix. was: Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix. > MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated > -------------------------------------------------------------------------------------------------------- > > Key: IPROTO-162 > URL: https://issues.redhat.com/browse/IPROTO-162 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.4.0.Alpha1, 4.3.4.Final > > > Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. > > Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite, and not the compile time variant. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. > > Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. > The fix will have the important side effect of breaking the compatibility of data stored as a WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. These usages are not affected if the message types in question have a TypeId annotation, in which case WrappedMessage identifies the type base on its numeric id rather than its fully qualified name. > The only way to work around the data compat issue is to change your java classes so as not to use nesting with the end result of the schema being generated exactly as before this bug fix. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Description: Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix. was: Message types generated with annotation processing during compile time should follow the nesting of the classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types becoming top level types in the generated schema. Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. > MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated > -------------------------------------------------------------------------------------------------------- > > Key: IPROTO-162 > URL: https://issues.redhat.com/browse/IPROTO-162 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 4.4.0.Alpha1, 4.3.4.Final > > > Message types generated with annotation processing during compile time should follow the nesting of the (annotated) classes from which they are generated. But since getEnclosingClass() always returns null that leads to all types wrongly becoming top level types in the generated schema starting with 4.3.0 when this bug appeared. > > Interestingly, the runtime variant of this, ReflectionClass.getEnclosingClass() works correctly and we only test that one in our suite. The schema generated by the runtime annotation processor does indeed follow the nesting of the initial classes. > > Fixing this issue is very important in the long run but will be disruptive for some users currently using nested annotated classes with compile time annotation processing. > The fix will have the important side effect of breaking the compatibility of data stored as WrappedMessage (notably Infinispan) because the type name changes as a consequence of the nesting. > The only way to work around the data compat issue is to change your java classes do as not to use nesting and basically with the end result of the schema being generated exactly as before the fix. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12309) Creating cache with invalid configuration leaves inconsistent state

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12309?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12309: ------------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/8693 > Creating cache with invalid configuration leaves inconsistent state > ------------------------------------------------------------------- > > Key: ISPN-12309 > URL: https://issues.redhat.com/browse/ISPN-12309 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Katia Aresti > Assignee: Gustavo Fernandes > Priority: Critical > > When a cache is created using the EmbeddedCacheManagerAdmin with a configuration that prevents the cache from starting, it will throw an error but will persist the cache nonetheless. > Further operations involving cache manager can throw exceptions, for example, {{Health.getHealth()}} since it tries to access the invalid cache that cannot be started -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2020