[Red Hat 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:
---------------------------------
Fix Version/s: 4.4.0.Alpha5
(was: 4.4.0.Alpha4)
> 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.3.4.Final, 4.4.0.Alpha5
>
>
> 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
[Red Hat JIRA] (IPROTO-63) writeObject throws IllegalArgumentException with oneof label
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-63?page=com.atlassian.jira.plugin... ]
Nistor Adrian updated IPROTO-63:
--------------------------------
Fix Version/s: 4.4.0.Alpha5
(was: 4.4.0.Alpha4)
> writeObject throws IllegalArgumentException with oneof label
> ------------------------------------------------------------
>
> Key: IPROTO-63
> URL: https://issues.redhat.com/browse/IPROTO-63
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Reporter: Ryan Emerson
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.4.0.Alpha5
>
>
> The below schema results in the following exception:
> Schema:
> {code:java}
> message EntryVersion {
> oneof version {
> NumericVersion numeric = 1;
> ClusteredVersion clustered = 2;
> }
> // optional NumericVersion numeric = 1;
> // optional ClusteredVersion clustered = 2;
> }
> message NumericVersion {
> required int64 version = 1;
> }
> message ClusteredVersion {
> required int64 version = 1;
> required int32 topology = 2;
> }
> {code}
> Exception:
> {code:java}
> java.lang.IllegalArgumentException: Declared field type is not a message or an enum : numeric
> {code}
> It seems this is caused because the type for the field "numeric" is null in the associated FieldDescriptor object that is retrieved in the [writeObject impl|https://github.com/infinispan/protostream/blob/master/core/src/main/...].
> If the oneof label is replaced with the commented optional fields, the marshallers work as expected.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[Red Hat JIRA] (IPROTO-89) Provide means to calculate serialised message size
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/IPROTO-89?page=com.atlassian.jira.plugin... ]
Nistor Adrian updated IPROTO-89:
--------------------------------
Fix Version/s: 4.4.0.Alpha5
(was: 4.4.0.Alpha4)
> Provide means to calculate serialised message size
> --------------------------------------------------
>
> Key: IPROTO-89
> URL: https://issues.redhat.com/browse/IPROTO-89
> Project: Infinispan ProtoStream
> Issue Type: Enhancement
> Affects Versions: 4.2.2.Final
> Reporter: Ryan Emerson
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.4.0.Alpha5
>
>
> In order to be able to better estimate the size of output buffers etc, it would be useful to provide a means for a user application to retrieved the anticipated size of a serialized message from an object's current state. For example, in the protobuf-java library this is exposed via {{com.google.protobuf.MessageLite#getSerializedSize}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[Red Hat JIRA] (IPROTO-180) Require java 11 for build
by Nistor Adrian (Jira)
Nistor Adrian created IPROTO-180:
------------------------------------
Summary: Require java 11 for build
Key: IPROTO-180
URL: https://issues.redhat.com/browse/IPROTO-180
Project: Infinispan ProtoStream
Issue Type: Enhancement
Affects Versions: 5.0.0.Final
Reporter: Nistor Adrian
Starting with version 5 we should require jdk 11 for build; this would save us from various javac bugs that impact annotation processors.
Source version and target version should still be kept to 8 for now.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years