[
https://issues.apache.org/jira/browse/METRON-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672266#comment-16672266
]
ASF GitHub Bot commented on METRON-1850:
----------------------------------------
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.
> Stellar REST function
> ---------------------
>
> Key: METRON-1850
> URL: https://issues.apache.org/jira/browse/METRON-1850
> Project: Metron
> Issue Type: New Feature
> Reporter: Ryan Merriman
> Priority: Major
>
> It would be useful to be able to enrich messages with Stellar using 3rd party
> (or internal) REST services. At a minimum this function would:
> * Stellar function available to GET from an HTTP API
> * Optional parameters for basic auth (user/password) which generate correct
> Authorization header
> * Function returns null value for errors, connection failures etc and logs
> error
> * Function must provide and use pooled connection objects at the process
> level
> * Function must send Accept: application/json header
> * A global setting must be available to set a proxy for all API calls, and
> if present the proxy must be used.
> * Proxy authentication must also be supported using basic auth.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
