[jira] [Commented] (AVRO-2079) Add ability to use Java 8 date/time types instead of Joda time.
[
https://issues.apache.org/jira/browse/AVRO-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484642#comment-16484642
]
ASF GitHub Bot commented on AVRO-2079:
--
pvorb commented on issue #309: AVRO-2079: Add ability to generate Java8 native
date/time classes (new)
URL: https://github.com/apache/avro/pull/309#issuecomment-391153063
Recent changes:
- added a commit that replaces `JAVA8` by `JSR310` as suggested by me
earlier in this thread. If anybody from the Avro project disagrees with that
change, I will remove it.
- removed the runtime dependency on Guava's `Strings` class from the
`AbstractAvroMojo`, which caused the archetype modules to fail.
- added a new entry in the `CHANGES.txt` describing the feature
@nandorKollar Is there anything else I can do?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add ability to use Java 8 date/time types instead of Joda time.
> ---
>
> Key: AVRO-2079
> URL: https://issues.apache.org/jira/browse/AVRO-2079
> Project: Avro
> Issue Type: Improvement
> Components: java, logical types
>Affects Versions: 1.8.2
>Reporter: Auke van Leeuwen
>Priority: Major
> Labels: patch-available
>
> Currently, for the date/time related logical types, we are generating Joda
> date/time objects. Since we've moved to Java-8 (AVRO-2043) it seems logical
> to also provide the possibility to generate {{java.time.*}} date/time objects
> instead of the Joda time variants.
> I propose to make this is a switch in {{SpecificCompiler.java}} which will
> default to Joda (I think), but can be set to generate the Java 8 versions.
> (I'm currently trying to run through the code to see if I can make it work.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AVRO-2180) grpc-avro|Java: transport exceptions from client to server as Metadata in
Srujan Narkedamalli created AVRO-2180: - Summary: grpc-avro|Java: transport exceptions from client to server as Metadata in Key: AVRO-2180 URL: https://issues.apache.org/jira/browse/AVRO-2180 Project: Avro Issue Type: Improvement Components: java Affects Versions: 1.8.2 Reporter: Srujan Narkedamalli Context: Currently in grpc-avro library, avro RPC exceptions are transported to from server to client as part of a response (using a boolean field at the head of response payload to indicate whether its actual response or error) similar to avro-ipc's response serialization logic. Problem: By encapsulating server exception as a regular response, its not visible for gRPC to know when an error response is being sent. And any error metrics computed gRPC on their stream listeners won't capture these errors. Proposed Solution: Send server error as io.grpc.StatusRuntimeException (which is perferred way of error), with appropriate Status code(probably Internal), and include the actual avro serialized error as Metadata attached to it. Impact: This would change RPC response wire format and won't be backward compatible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AVRO-2180) grpc-avro|Java: transport exceptions from client to server as Metadata in io.grpc.StatusRuntimeException
[ https://issues.apache.org/jira/browse/AVRO-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srujan Narkedamalli updated AVRO-2180: -- Summary: grpc-avro|Java: transport exceptions from client to server as Metadata in io.grpc.StatusRuntimeException (was: grpc-avro|Java: transport exceptions from client to server as Metadata in ) > grpc-avro|Java: transport exceptions from client to server as Metadata in > io.grpc.StatusRuntimeException > > > Key: AVRO-2180 > URL: https://issues.apache.org/jira/browse/AVRO-2180 > Project: Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.8.2 >Reporter: Srujan Narkedamalli >Priority: Major > > Context: > Currently in grpc-avro library, avro RPC exceptions are transported to from > server to client as part of a response (using a boolean field at the head of > response payload to indicate whether its actual response or error) similar to > avro-ipc's response serialization logic. > Problem: > By encapsulating server exception as a regular response, its not visible for > gRPC to know when an error response is being sent. And any error metrics > computed gRPC on their stream listeners won't capture these errors. > Proposed Solution: > Send server error as io.grpc.StatusRuntimeException (which is perferred way > of error), with appropriate Status code(probably Internal), and include the > actual avro serialized error as Metadata attached to it. > Impact: > This would change RPC response wire format and won't be backward compatible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AVRO-2180) grpc-avro|Java: transport exceptions from server to client as Metadata in io.grpc.StatusRuntimeException
[ https://issues.apache.org/jira/browse/AVRO-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srujan Narkedamalli updated AVRO-2180: -- Summary: grpc-avro|Java: transport exceptions from server to client as Metadata in io.grpc.StatusRuntimeException (was: grpc-avro|Java: transport exceptions from client to server as Metadata in io.grpc.StatusRuntimeException) > grpc-avro|Java: transport exceptions from server to client as Metadata in > io.grpc.StatusRuntimeException > > > Key: AVRO-2180 > URL: https://issues.apache.org/jira/browse/AVRO-2180 > Project: Avro > Issue Type: Improvement > Components: java >Affects Versions: 1.8.2 >Reporter: Srujan Narkedamalli >Priority: Major > > Context: > Currently in grpc-avro library, avro RPC exceptions are transported to from > server to client as part of a response (using a boolean field at the head of > response payload to indicate whether its actual response or error) similar to > avro-ipc's response serialization logic. > Problem: > By encapsulating server exception as a regular response, its not visible for > gRPC to know when an error response is being sent. And any error metrics > computed gRPC on their stream listeners won't capture these errors. > Proposed Solution: > Send server error as io.grpc.StatusRuntimeException (which is perferred way > of error), with appropriate Status code(probably Internal), and include the > actual avro serialized error as Metadata attached to it. > Impact: > This would change RPC response wire format and won't be backward compatible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
