2015-05-29 4 views
0

Я работаю над приложением Grails 2.4.2, и такая же база кода используется для множества клиентов. Каждый клиент получает веб-интерфейс, основанный на GSP, с индивидуальными значками, текстовыми строками и т. Д. Я убедился, что настройки выполняются на страницах GSP с использованием переменных Groovy, определенных в Config.groovy. То есть что-то вроде этого:Скомпилированы страницы GSP, связанные с контекстным путем?

customerName = '' 
favicon = '' 

if (appName == 'foo') { 
    customerName = 'Foo' 
    favicon = "favicon_${appName}.ico" 
} 

Эти переменные затем ссылаются на страницы GSP. Это прекрасно работает. Проблема в том, что для каждого клиента требуется отдельный файл войны. Таким образом, сервер CI создает войну для клиента A, затем запускает grails clean, изменяет имя приложения и т. Д. В файле application.properties, строит войну для клиента B и т. Д. Каждая сборка военного файла занимает около 4,5 м, умноженная на 10 клиентов строит. Поэтому я подумал, что лучшим способом было бы создать военный файл один раз, а затем CI-сервер скопировал его N раз и изменил бы файл application.properties с именем клиента, контекстом контекста сервлетов и т. Д. Внутри каждого военного файла , Кто-то указал мне, что страницы GSP скомпилированы во время сборки файла войны, и что они заканчивают путь контекста как часть имени класса. Мне это кажется немного странным. То есть допустим, у меня есть клиент «Foo», и я решил создать военный файл с именем foo.war, который будет развернут в контексте контекста сервлета/foo. Скомпилированный результат для страницы «bar.gsp» будет что-то вроде этого:

WEB-INF/classes/gsp_foo_bar.class 
WEB-INF/classes/gsp_foo_bar_gsp_html.data 
WEB-INF/classes/gsp_foo_bar_gsp_linenumbers.data 

Я экспериментировал с принятием уже скомпилированный войны файл для клиента А, изменив название приложения и контекст, и переброски его в качестве клиент B. Он отлично работает, и я вижу значки клиента B и т. д. Итак, сводка вопроса, на мой взгляд, сводится к тому, связывает ли страница _foo_ страницу с контекстным путем/foo, или если это просто косметическая штука? Я, конечно, не хочу, чтобы удар производительности ленивой компиляции или перекомпиляции во время выполнения. И поскольку содержимое страницы GSP в этом случае в основном статично и не изменяется, похоже, что его не нужно привязывать к контексту или имени приложения. Кто-нибудь знает, является ли это просто именованием, или я столкнулся с проблемами, не перекомпилируя войну, когда я меняю имя приложения/контекст? Может быть, есть лучший способ выполнить то, что я хочу? Благодарю.

+0

Название внутреннего класса ваших GSPS это просто способ назвать их. Какова ваша настоящая проблема? Вы можете развернуть ту же войну с разными именами путей контекста на одном сервере без каких-либо проблем. Ты пробовал? – albertovilches

+0

Спасибо albertovilches. Да, я пробовал, но не был уверен, есть ли недостаток, например, приложение не может использовать скомпилированные страницы или что-то в этом роде. Рад слышать, что это не так. – user2337270

ответ

0

Как использовать внешнюю конфигурацию и динамически настроить favicon в своем макете/шаблоне?

Grails external configuration file

+0

Я не уверен, что понимаю, что вы имеете в виду. Фейвикон ссылается через переменную на странице GSP, как сейчас. Наверное, я не мог четко сформулировать свой вопрос. Проблема в том, что мне нужен файл войны для каждого клиента, и я бы хотел, чтобы он не перестраивал его для каждого клиента. Но просмотр контекстного пути, отображаемого в имени класса для скомпилированного GSP, заставил меня подумать, что он каким-то образом связан с контекстным путем. – user2337270

+0

Моя идея состоит в том, чтобы иметь внешнюю конфигурацию и хранить всю эту конкретную информацию о клиенте. Затем вы запускаете приложения со своей конфигурацией. Что касается контекста, большинство веб-контейнеров позволяют определить путь к контексту приложения - см. Http://stackoverflow.com/questions/2593472/define-servlet-context-in-war-file – defectus

+0

Это в значительной степени то, я делаю. И да, у различных развертываний клиентов есть свой уникальный контекстный путь. Думаю, мне следовало бы перефразировать этот вопрос. Это не та конфигурация, о которой мне интересно, поэтому путь контекста становится частью скомпилированных классов страниц GSP и независимо от того, привязан ли он к контекстному пути после компиляции. То естьесли я решит изменить контекстный путь после создания файла войны, это вызовет проблемы с GSP? Я стараюсь избегать повторного создания файла войны для каждого клиента (включая компиляцию всех страниц Groovy и страниц GSP). – user2337270

Смежные вопросы