metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From merrimanr <...@git.apache.org>
Subject [GitHub] metron pull request #734: METRON-1158: Build backend for grouping alerts int...
Date Fri, 08 Sep 2017 21:05:51 GMT
Github user merrimanr commented on a diff in the pull request:

    https://github.com/apache/metron/pull/734#discussion_r137889738
  
    --- Diff: metron-platform/metron-elasticsearch/src/test/java/org/apache/metron/elasticsearch/integration/ElasticsearchMetaAlertIntegrationTest.java
---
    @@ -0,0 +1,318 @@
    +/*
    + * 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.elasticsearch.integration;
    +
    +import static org.elasticsearch.common.xcontent.XContentFactory.jsonBuilder;
    +
    +import com.fasterxml.jackson.core.JsonProcessingException;
    +import java.io.File;
    +import java.io.IOException;
    +import java.text.SimpleDateFormat;
    +import java.util.ArrayList;
    +import java.util.Date;
    +import java.util.HashMap;
    +import java.util.List;
    +import java.util.Map;
    +import java.util.Optional;
    +import java.util.stream.Collectors;
    +import org.apache.metron.common.Constants;
    +import org.apache.metron.common.utils.JSONUtils;
    +import org.apache.metron.elasticsearch.dao.ElasticsearchDao;
    +import org.apache.metron.elasticsearch.dao.ElasticsearchMetaAlertDao;
    +import org.apache.metron.elasticsearch.dao.MetaAlertStatus;
    +import org.apache.metron.elasticsearch.integration.components.ElasticSearchComponent;
    +import org.apache.metron.indexing.dao.AccessConfig;
    +import org.apache.metron.indexing.dao.IndexDao;
    +import org.apache.metron.indexing.dao.MetaAlertDao;
    +import org.apache.metron.indexing.dao.update.Document;
    +import org.apache.metron.indexing.dao.update.ReplaceRequest;
    +import org.junit.AfterClass;
    +import org.junit.Assert;
    +import org.junit.BeforeClass;
    +import org.junit.Test;
    +
    +public class ElasticsearchMetaAlertIntegrationTest {
    +
    +  private static final int MAX_RETRIES = 10;
    +  private static final int SLEEP_MS = 500;
    +  private static final String SENSOR_NAME = "test";
    +  private static final String INDEX_DIR = "target/elasticsearch_meta";
    +  private static final String DATE_FORMAT = "yyyy.MM.dd.HH";
    +  private static final String INDEX =
    +      SENSOR_NAME + "_index_" + new SimpleDateFormat(DATE_FORMAT).format(new Date());
    +  private static final String NEW_FIELD = "new-field";
    +
    +  private static String metaMappingSource;
    +  private static IndexDao esDao;
    +  private static IndexDao metaDao;
    +  private static ElasticSearchComponent es;
    +
    +  @BeforeClass
    +  public static void setup() throws Exception {
    +    buildMetaMappingSource();
    +    // setup the client
    +    es = new ElasticSearchComponent.Builder()
    --- End diff --
    
    You might want to consider moving this to TestConfig instead.  The REST layer depends
heavily on the InMemory components and reuses them across all the integration tests.  You
are breaking the pattern although I understand why because setting up InMemory components
is usually done in @BeforeClass in other modules.  This would allow other controller integration
tests to leverage this infrastructure without having to do anything.
    
    The SearchController uses a mock ES backend but, in my humble opinion, it's hard to maintain
and is unnecessary.  Would be nice to switch that to what you've done here someday.    


---

Mime
View raw message