[
https://issues.apache.org/jira/browse/FLINK-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16138084#comment-16138084
]
ASF GitHub Bot commented on FLINK-7040:
---------------------------------------
Github user zentol commented on a diff in the pull request:
https://github.com/apache/flink/pull/4569#discussion_r134690587
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/rest/messages/ParameterMapper.java
---
@@ -0,0 +1,83 @@
+/*
+ * 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.flink.runtime.rest.messages;
+
+import java.util.Collections;
+import java.util.Iterator;
+import java.util.Map;
+import java.util.Set;
+
+/**
+ * This class is used to map query/path {@link Parameter}s to their actual
value.
+ */
+public abstract class ParameterMapper {
+
+ /**
+ * Maps the given query {@link Parameter}s to their actual value.
+ *
+ * @param queryParameters parameters to map
+ * @return map containing the parameters and their associated value
+ */
+ public Map<Parameter, String> mapQueryParameters(Set<Parameter>
queryParameters) {
+ return Collections.emptyMap();
+ }
+
+ /**
+ * Maps the given path {@link Parameter}s to their actual value.
+ *
+ * @param pathParameters parameters to map
+ * @return map containing the parameters and their associated value
+ */
+ public Map<Parameter, String> mapPathParameters(Set<Parameter>
pathParameters) {
+ return Collections.emptyMap();
+ }
+
+ /**
+ * Resolves the given URL (e.g "jobs/:jobid") using the given
path/query parameters.
+ *
+ * @param genericUrl URL to resolve
+ * @param pathParameters path parameters
+ * @param queryParameters query parameters
+ * @return resolved url, e.g "/jobs/1234?state=running"
+ */
+ public static String resolveUrl(String genericUrl, Map<Parameter,
String> pathParameters, Map<Parameter, String> queryParameters) {
+ StringBuilder sb = new StringBuilder(genericUrl);
+
+ pathParameters.forEach((parameter, value) -> {
+ int start = sb.indexOf(":" + parameter.getKey());
+ sb.replace(start, start + parameter.getKey().length() +
1, value);
+ });
--- End diff --
Technically it could still be a valid URL.
My conclusion is that this implementation for handling parameters is
inherently flawed.
* The mapper gets a set of parameters in a map but can decide to completely
ignore it, (which is how most implementation will most likely look like)
* There is no good means of verifying whether parameters were set or not
* It doesn't it handle optional parameters, which is common for query
parameters
* it is limited to the client side, on the server side we're still dealing
with String:String maps
I think I've come up with something that addresses the above short-comings,
hang tight.
> Flip-6 client-cluster communication
> -----------------------------------
>
> Key: FLINK-7040
> URL: https://issues.apache.org/jira/browse/FLINK-7040
> Project: Flink
> Issue Type: New Feature
> Components: Cluster Management, Mesos
> Reporter: Till Rohrmann
> Assignee: Chesnay Schepler
> Priority: Critical
> Labels: flip-6
>
> With the new Flip-6 architecture, the client will communicate with the
> cluster in a RESTful manner.
> The cluster shall support the following REST calls:
> * List jobs (GET): Get list of all running jobs on the cluster
> * Submit job (POST): Submit a job to the cluster (only supported in session
> mode)
> * Lookup job leader (GET): Gets the JM leader for the given job
> * Get job status (GET): Get the status of an executed job (and maybe the
> JobExecutionResult)
> * Cancel job (PUT): Cancel the given job
> * Stop job (PUT): Stops the given job
> * Take savepoint (POST): Take savepoint for given job (How to return the
> savepoint under which the savepoint was stored? Maybe always having to
> specify a path)
> * Get KV state (GET): Gets the KV state for the given job and key (Queryable
> state)
> * Poll/subscribe to notifications for job (GET, WebSocket): Polls new
> notifications from the execution of the given job/Opens WebSocket to receive
> notifications
> The first four REST calls will be served by the REST endpoint running in the
> application master/cluster entrypoint. The other calls will be served by a
> REST endpoint running along side to the JobManager.
> Detailed information about different implementations and their pros and cons
> can be found in this document:
> https://docs.google.com/document/d/1eIX6FS9stwraRdSUgRSuLXC1sL7NAmxtuqIXe_jSi-k/edit?usp=sharing
> The implementation will most likely be Netty based.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
