September 2020 - infinispan-issues

[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)

5 years, 6 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)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian reopened IPROTO-162: ---------------------------------- Reopening, to be able to edit description, add examples and more notes to ease upgrading > MirrorClass.getEnclosingClass() is broken and always returs null > ---------------------------------------------------------------- > > 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 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: ------------------------------------- Component/s: REST > 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 > 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)

5 years, 6 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: ------------------------------------- Affects Version/s: 12.0.0.Dev04 11.0.3.Final > 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)

5 years, 6 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: --------------------------------- Summary: MirrorClass.getEnclosingClass() is broken and always returs null leading to wrong schema being generated (was: MirrorClass.getEnclosingClass() is broken and always returs null) > 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian closed IPROTO-162. -------------------------------- Resolution: Done > MirrorClass.getEnclosingClass() is broken and always returs null > ---------------------------------------------------------------- > > 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian commented on IPROTO-162: -------------------------------------- The fix was included here [https://github.com/infinispan/protostream/commit/0723b4e86bda16eaa9a0c400...] It seems TypeMirror.getEnclosingType() does not work (always returns null) while TypeElement.getEnclosingElement() works corectly. Bad bad bad javac!! So I used the alternative implementation to work around it. > MirrorClass.getEnclosingClass() is broken and always returs null > ---------------------------------------------------------------- > > 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Fix Version/s: 4.4.0.Alpha1 4.3.4.Final > MirrorClass.getEnclosingClass() is broken and always returs null > ---------------------------------------------------------------- > > 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 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-162) MirrorClass.getEnclosingClass() is broken and always returs null

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/IPROTO-162?page=com.atlassian.jira.plugi... ] Nistor Adrian updated IPROTO-162: --------------------------------- Status: Open (was: New) > MirrorClass.getEnclosingClass() is broken and always returs null > ---------------------------------------------------------------- > > 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 > Priority: Major > > 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2020