Приложение Grails 2.5.1 периодически теряет корневой контекст

У нас есть несколько приложений, развертываемых на одном сервере tomcat (в настоящее время мы работаем над обновлением до Grails 3, так что в ближайшие несколько месяцев это может быть OBE, но это уже давно нас беспокоит), и два приложения иногда будут теряют свой относительный корневой путь контекста.

Допустим, у нас есть app1 и app2, которые развертываются в server:port/app1 и server:port/app2.

app1 работает нормально, но app2 ИНОГДА (примерно в 20% случаев) развертывается, и все ссылки <g:link/> (или любые другие сгенерированные ссылки, такие как местоположения активов) генерируются относительно корня сервера ... приложение правильно развернуто под /app2, поэтому ссылки указывают на плохие места.

Например, <g:link controller='hello' action='index'/> создаст ссылку как /hello/index, а не /app2/hello/index.

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

Мы будем очень признательны за любые идеи о том, что может быть причиной этого или где искать.

Изменить: используемые плагины:

compile "org.springframework.boot:spring-boot-starter-logging"
compile "org.springframework.boot:spring-boot-autoconfigure"
compile "org.grails:grails-core"
compile "org.springframework.boot:spring-boot-starter-actuator"
provided "org.springframework.boot:spring-boot-starter-tomcat"
compile "org.grails:grails-dependencies"
compile "org.grails:grails-web-boot"
compile 'org.grails.plugins:cache:4.0.0.M2'
compile 'org.grails.plugins:cache-ehcache:3.0.0.M1'
compile "org.grails.plugins:scaffolding"
compile "org.grails.plugins:hibernate4"
compile "org.hibernate:hibernate-core:4.3.10.Final"
compile "org.hibernate:hibernate-ehcache:4.3.10.Final"
console "org.grails:grails-console"
profile "org.grails.profiles:web"
runtime "com.bertramlabs.plugins:asset-pipeline-grails:2.14.1"
runtime "com.h2database:h2"
testCompile "org.grails:grails-plugin-testing"
testCompile "org.grails.plugins:geb"
testRuntime "org.seleniumhq.selenium:selenium-htmlunit-driver:2.47.1"
testRuntime "net.sourceforge.htmlunit:htmlunit:2.18"

grails grails3 grails-2.5
person Trebla    schedule 28.03.2017    source источник
comment
На каком сервере / контейнере вы развертываете? Кроме того, какие плагины вы используете? Можете ли вы воссоздать проблему с новым приложением, используя только стандартную конфигурацию?   -  person Joshua Moore    schedule 08.08.2017
comment
Мы выполняем развертывание на tomcat, обновили вопрос с помощью плагинов из build.gradle ... есть некоторые дополнительные внутренние плагины, но это основные сторонние плагины. Мы не можем воспроизвести это ни с чем, кроме двух (из 13) приложений, в которых возникает эта проблема. Большинство приложений используют один и тот же набор сторонних плагинов (или очень похожие)   -  person Trebla    schedule 08.08.2017

Ответы (1)


arrow_upward
1
arrow_downward

Решено (аш)

Мы наконец обнаружили причину этого. grailsLinkGenerator (DefaultLinkGenerator класс) либо теряет contextPath, либо неправильно настраивается при запуске. Это приводит к тому, что все ссылки, сгенерированные с помощью синглтона генератора ссылок (которого большинство, но, видимо, не все), генерируются в корне сервера.

Мы все еще работаем над расчетом времени, чтобы выяснить, можно ли это запустить в BootStrap и отложить до завершения запуска сервера, но пока, в качестве обходного пути, мы добавили действие незащищенного контроллера для сброса этого, что, похоже, решает проблема (до следующего перезапуска сервера).

def resetContextPath() {
  grailsLinkGenerator.contextPath = grailsApplication.config.getProperty("server.contextPath")

  if (grailsLinkGenerator instanceof CachingLinkGenerator) {
    grailsLinkGenerator.clearCache()
  }
}

До сих пор не знаю, почему это происходит только в некоторых приложениях на некоторых серверах (вероятно, время запуска приложений), но это, по крайней мере, позволяет нам исправить проблему, не требуя перезапуска.

person Trebla    schedule 23.08.2018