metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cestella <>
Subject [GitHub] incubator-metron pull request #421: METRON-283 Migrate Geo Enrichment outsid...
Date Wed, 25 Jan 2017 16:41:34 GMT
Github user cestella commented on a diff in the pull request:
    --- Diff: metron-platform/metron-enrichment/src/main/java/org/apache/metron/enrichment/stellar/
    @@ -0,0 +1,110 @@
    + * 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
    + *
    + *
    + *
    + * 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.enrichment.stellar;
    +import org.apache.log4j.Logger;
    +import org.apache.metron.common.dsl.Context;
    +import org.apache.metron.common.dsl.ParseException;
    +import org.apache.metron.common.dsl.Stellar;
    +import org.apache.metron.common.dsl.StellarFunction;
    +import org.apache.metron.enrichment.adapters.geo.GeoLiteDatabase;
    +import java.util.HashMap;
    +import java.util.List;
    +import java.util.Map;
    +import java.util.Optional;
    +public class GeoEnrichmentFunctions {
    +  private static final Logger LOG = Logger.getLogger(GeoEnrichmentFunctions.class);
    +  @Stellar(name="GET"
    +          ,namespace="GEO"
    +          ,description="Look up an IPV4 address and returns geographic information about
    +          ,params = {
    +                      "ip - The IPV4 address to lookup" +
    +                      "fields - Optional list of GeoIP fields to grab. Options are locID,
country, city, postalCode, dmaCode, latitude, longitude, location_point"
    +                    }
    +          ,returns = "If a Single field is requested a string of the field, If multiple
fields a map of string of the fields, and null otherwise"
    +  )
    +  public static class GeoGet implements StellarFunction {
    +    boolean initialized = false;
    +    @Override
    +    public Object apply(List<Object> args, Context context) throws ParseException
    +      if(!initialized) {
    +        return null;
    +      }
    +      if(args.size() > 2) {
    +        return null;
    --- End diff --
    So it is true that we do not tend to throw exceptions on some errors in Stellar functions
for reasons that may or may not be valid.  The original intent was to not stop topologies
because an error has happened in a specific function.  I happen to think that this isn't correct
reasoning anymore, but that's a discussion for another thread.
    In this specific case, that the user has passed in too many arguments, I think you could
make a reasonable argument for a couple of different semantics:
    * do nothing, passing in too many arguments does no harm
    * throw an exception as Nick suggests
    * return null
    I actually think I agree in this case with Nick, I'd rather err on the side of caution
and throw an exception here so we don't have people using functions wrong and not realizing

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message