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.    


---

Reply via email to