Github user merrimanr commented on a diff in the pull request:
https://github.com/apache/metron/pull/1250#discussion_r230209150
--- Diff:
metron-stellar/stellar-common/src/main/java/org/apache/metron/stellar/dsl/functions/RestConfig.java
---
@@ -0,0 +1,147 @@
+/**
+ * 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.metron.stellar.dsl.functions;
--- End diff --
I looked at 2 different patterns that already exist.
The first was the pattern you mentioned, the ConfigOptions interface. The
problem is that this class lives in metron-common which depends on
stellar-common. Regardless I don't think pattern is a great fit because it
doesn't serialize/deserialize easily and contains a lot of features that are
not needed here (functional interfaces for example).
The second was the PROFILER_INIT function in the ProfilerFunctions class.
This approach uses a java bean (ProfilerConfig) to hold configuration which
allows easy serialization/deserialization. This is actually what I used at
first until I made the change to accept a config as an argument expression.
I actually went with option 2 at first but found it cumbersome to merge
configs together. I ended up with the pattern I did because a map supports
applying properties on top of each other well and serialization/deserialization
works without issue. We ended having to do this for PcapConfig and PcapOptions
in the REST layer by creating the PcapRequest class which extends a Map.
---
