[
https://issues.apache.org/jira/browse/GEODE-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095191#comment-16095191
]
ASF GitHub Bot commented on GEODE-3213:
---------------------------------------
Github user WireBaron commented on a diff in the pull request:
https://github.com/apache/geode/pull/646#discussion_r128597628
--- Diff:
geode-protobuf/src/main/java/org/apache/geode/protocol/operations/Failure.java
---
@@ -0,0 +1,47 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF
ANY KIND, either express
+ * or implied. See the License for the specific language governing
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.protocol.operations;
--- End diff --
In terms of package layout, I had thought the intent was to have generic
code that could be used for any protocol in this package, while protobuf
specific code would be under org.apache.geode.protocol.protobuf.* All of the
Result and OperationContext code is now protobuf specific. Should it be moved?
> Refactor Protobuf Serialization Implemenation
> ---------------------------------------------
>
> Key: GEODE-3213
> URL: https://issues.apache.org/jira/browse/GEODE-3213
> Project: Geode
> Issue Type: Improvement
> Components: client/server, serialization
> Reporter: Udo Kohlmeyer
>
> In the Protobuf serialization implementation, there are some refactorings we
> want to make:
> * OperationHandlers take OperationRequest and OperationResponse message, not
> the parent Request/Response Object
> * A generic flow needs to be implemented that all OperationHandlers follow.
> No bespoke flows for any OperationHandlers... way too much maintenance
> * Use Functional semantics to configure the functionality to extract
> OperationRequest from Request (per OperationHandler)
> * Use Functional semantics to configure the functionality to populate
> OperationResponse in the relevant Response
> * Have generic Error Handling framework to populate "known" errors and error
> codes
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
