Использование облачных конечных точек Google в AppEngine

Question

Обычно я использую конечные точки Google Cloud на AppEngine (Java), как описано в:

https://cloud.google.com/appengine/docs/java/endpoints/helloendpoints-java-maven

Зависимость для библиотеки конечных точек, которую я использую:

<plugin>
   <groupId>com.google.appengine</groupId>
   <artifactId>appengine-endpoints</artifactId>
   <version>1.9.48</version>
</plugin>

Используя это, я могу запустить локальный сервер разработки, используя команду: mvn clean package appengine: devserver

Тем не менее, похоже, что существует новая версия облачных конечных точек. https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java.

Новая структура находится здесь

<dependency>
<groupId>com.google.endpoints</groupId>
<artifactId>endpoints-framework</artifactId>
<version>${endpoints.framework.version}</version>
</dependency>

Те же самые команды maven здесь не работают. Я не могу запустить локальный сервер разработки, открыть проводник API или использовать локальное хранилище данных (все это было возможно раньше) . Может кто-нибудь, пожалуйста, подскажите, как работать с новым фреймворком.

Кроме того, вероятно, что прежняя структура будет устаревшей?

Answer 1

Есть несколько проблем, с которыми вы сталкиваетесь, и этот материал слишком чувствителен к проблемам конфигурации:

Чтобы решить проблемы, следуйте инструкциям в: https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java

1. Используйте правильный идентификатор проекта Google при замене YOUR_PROJECT_ID в pom.xml. Это должен быть действительный идентификатор проекта для всех этапов работы.
2. То же самое при замене YOUR-PROJECT-ID в echo.java

Если идентификатор проекта недействителен (фактически существует в AppEngine), следующие шаги не будут работать

3. выполнить: mvn exec:java -DGetSwaggerDoc
4. выполнить: gcloud service-management deploy openapi.json
5. выполнить: export ENDPOINTS_SERVICE_NAME=echo-api.endpoints.<your project id>.cloud.goog

Краткое руководство не очень полезно для шага 5. Шаг 4 должен заканчиваться сообщением об успешном завершении.

Наконец, пример поставляется с плагином Maven, который, похоже, не работает с новыми конечными точками. Вместо того, чтобы использовать:

    <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>appengine-maven-plugin</artifactId>
        <version>${appengine.maven.plugin.version}</version>
    </plugin>

использовать:

    <plugin>
        <groupId>com.google.appengine</groupId>
        <artifactId>appengine-maven-plugin</artifactId>
        <version>1.9.44</version>
    </plugin>

Ответ на вопрос, почему mvn appengine: devserver не работает, заключается в том, что цель devserver не существует в новом плагине. Старый плагин Maven позволяет выполнять: mvn appengine: devserver

Answer 2

Чтобы частично ответить на мой собственный вопрос: я мог бы, наконец, заставить работать приложение "Эхо" (упомянутое в https://cloud.google.com/endpoints/docs/frameworks/java/quickstart-frameworks-java)

Но мне пришлось сделать 2 изменения: а) Закомментируйте блок в appengine-we b.xml . т.е.

<!--
<basic-scaling>
  <max-instances>2</max-instances>
</basic-scaling>
-->

После этого я получил другую ошибку: "fail endpoints-api-configuration: com.google.api.config.ServiceConfigException: не удалось получить версию конфигурации по умолчанию для службы". Чтобы обойти это:

б) закомментируйте ServiceManagementConfigFilter из web.xml, т.е.

<!--
    <filter>
      <filter-name>endpoints-api-configuration</filter-name>
      <filter-class>com.google.api.control.ServiceManagementConfigFilter</filter-class>
   </filter>
-->
<!--    
<filter-mapping>
    <filter-name>endpoints-api-configuration</filter-name>
    <servlet-name>EndpointsServlet</servlet-name>
</filter-mapping>
-->

После этого,

1. Для сборки: mvn clean package

2. Для локального запуска: appengine-java-sdk/1.9.44/appengine-java-sdk/appengine-java-sdk-1.9.44/bin/dev_appserver.sh /path/to/war/directory

Было бы замечательно, если бы кто-то мог пролить больше света на последствия этих изменений, и на то, как мы могли бы заставить его работать из коробки