Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
/*
* Licensed to Elasticsearch under one or more contributor
* license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright
* ownership. Elasticsearch 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.codelibs.elasticsearch.common.xcontent;
import org.codelibs.elasticsearch.common.ParseField;
import org.codelibs.elasticsearch.common.ParseFieldMatcherSupplier;
import org.codelibs.elasticsearch.common.ParsingException;
import org.codelibs.elasticsearch.common.xcontent.ObjectParser.ValueType;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.function.BiConsumer;
import java.util.function.BiFunction;
import java.util.function.Consumer;
import java.util.function.Function;
/**
* Like {ObjectParser} but works with objects that have constructors whose arguments are mixed in with its other settings. Queries are
* like this, for example ids requires types but always parses the values field on the same level. If
* this doesn't sounds like what you want to parse have a look at
* {ObjectParser#declareNamedObjects(BiConsumer, ObjectParser.NamedObjectParser, Consumer, ParseField)} which solves a slightly
* different but similar sounding problem.
*
* Anyway, {@linkplain ConstructingObjectParser} parses the fields in the order that they are in the XContent, collecting constructor
* arguments and parsing and queueing normal fields until all constructor arguments are parsed. Then it builds the target object and replays
* the queued fields. Any fields that come in after the last constructor arguments are parsed and immediately applied to the target object
* just like {@linkplain ObjectParser}.
*
*
* Declaring a {@linkplain ConstructingObjectParser} is intentionally quite similar to declaring an {@linkplain ObjectParser}. The only
* differences being that constructor arguments are declared with the consumer returned by the static {#constructorArg()} method and
* that {@linkplain ConstructingObjectParser}'s constructor takes a lambda that must build the target object from a list of constructor
* arguments:
*
*
{@code
* private static final ConstructingObjectParser PARSER = new ConstructingObjectParser<>("thing",
* a -> new Thing((String) a[0], (String) a[1], (Integer) a[2]));
* static {
* PARSER.declareString(constructorArg(), new ParseField("animal"));
* PARSER.declareString(constructorArg(), new ParseField("vegetable"));
* PARSER.declareInt(optionalConstructorArg(), new ParseField("mineral"));
* PARSER.declareInt(Thing::setFruit, new ParseField("fruit"));
* PARSER.declareInt(Thing::setBug, new ParseField("bug"));
* }
* }
*
* This does add some overhead compared to just using {@linkplain ObjectParser} directly. On a 2.2 GHz Intel Core i7 MacBook Air running on
* battery power in a reasonably unscientific microbenchmark it is about 100 microseconds for a reasonably large object, less if the
* constructor arguments are first. On this platform with the same microbenchmarks just creating the XContentParser is around 900
* microseconds and using {#linkplain ObjectParser} directly adds another 300 or so microseconds. In the best case
* {@linkplain ConstructingObjectParser} allocates two additional objects per parse compared to {#linkplain ObjectParser}. In the worst case
* it allocates 3 + 2 * param_count objects per parse. If this overhead is too much for you then feel free to have ObjectParser
* parse a secondary object and have that one call the target object's constructor. That ought to be rare though.
*
*
* Note: if optional constructor arguments aren't specified then the number of allocations is always the worst case.
*
*/
public final class ConstructingObjectParser extends AbstractObjectParser {
/**
* Consumer that marks a field as a required constructor argument instead of a real object field.
*/
private static final BiConsumer