LINUX.ORG.RU

Конфигурация БД в DTD - говнокод?

 ,


0

2

Есть одна конфигурация JPA, которая разворачивается на нескольких системах. В каждой могут быть свои параметры БД (сервер, логин-пароль и т.д.).

Поэтому в приложении один на всех persistence.xml, который выглядит примерно так:

<property name="javax.persistence.jdbc.url" value="&contoso_jdbc;"/>
<property name="javax.persistence.jdbc.driver" value="&contoso_driver;"/>
<property name="javax.persistence.jdbc.user" value="&contoso_username;"/>
<property name="javax.persistence.jdbc.password" value="&contoso_password;"/>

Соответственно, в начале persistence.xml стоит доктайп и в отдельном файле DTD написано что-нибудь вроде

<!ENTITY mysql_server "127.0.0.1">
<!ENTITY mysql_db "contoso">
<!ENTITY contoso_username "user">
<!ENTITY contoso_password "password">
<!ENTITY contoso_jdbc "jdbc:mysql://&mysql_server;:3306/&mysql_db;?блаблабла">

Ну, смысл понятен. На этапе сборки в WAR кладётся нужный DTD-файл из нескольких.

А теперь вопрос: насколько такой подход - говнокод, и не лучше ли сделать это, например, через properties при создании EntityManagerFactory?

Это плохо только тем, что так делать «не принято», а через property - принято. Поэтому сферический кодер в вакууме будет инстинктивно искать проперти-файл, а вовсе не DTD. Когда таких мест, где приняты нестандартные решения, будет много настанет момент «в проекте черт ногу сломит».

maloi ★★★★★
()

такой подход - эталонный говнокод

сменили пароль на субд и тот кто будет искать почему_нихрена_не_работает не догадается про сей изврат проклянет авторов сего изврата.

Deleted
()
Ответ на: комментарий от vertexua

JNDI не канает. Конфигурацию сервера в данном случае трогать нельзя, поэтому параметры БД прописываются в самом варнике.

reserved
() автор топика
Ответ на: комментарий от reserved

JNDI не канает. Конфигурацию сервера в данном случае трогать нельзя, поэтому параметры БД прописываются в самом варнике.

Антипаттерн, причем эталонно угребищный. Соединение с базой - дело контенера. Точка.

Но если вы упоролись, то во время сборки можете процессить с помощью maven-resources-plugin плейсхолдеры в persistence.xml согласно необходимому профилю. В профиле вычитывайте из отдельного properties свойства с помощью maven properties plugin

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

легкость деплоя, следование концепции - «все настройки в одном месте», возможность в одном контейнере держать тучу приложений которые не будут бодаться друг с другом и т.п.

Deleted
()
Ответ на: комментарий от vertexua

Он кастомно собран будет в любом случае.

Там кроме настроек БД зашиты ещё разные настройки логирования, всякие параметры development/production mode, адреса рассылки почты (когда валится исключение, отправляется отчёт разработчику) и т.д. Причём на одном контейнере может одновременно крутиться несколько экземпляров приложения, с разными базами и настройками (одно - копия продакшена, другое - тестовая база).

Или прикажете это всё тоже в настройки контейнера запихать?

reserved
() автор топика
Ответ на: комментарий от Deleted

Что может быть проще чем приложение без настроек базы? А если таки решиться на кастомные варники, то мой вариант с мавеном по крайне мере удаляет лишнюю сущность, jndi, которая теперь профитов не дает. Относительно бодаться, то скажите, база одна и та же, или разные. Если разные, то никто не бодается, если одна, то общий пул вполне норм и один ресурс.

vertexua ★★★★★
()
Ответ на: комментарий от Deleted

У вашего варианта есть сильный плюс, что если контейнер будет настроен, то от вашего способа можно будет легко отказаться не меняя код

vertexua ★★★★★
()
Ответ на: комментарий от reserved

Разные env при этом делаются как угодно, или префикс к свойствам, или отдельный столбец, а можно и отдельную базу конфигурации

Стандарт jee намекает на такое решение, потому как там вообще ничего серьезного для работы с properies нет, свыше java se

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

проще приложения которое работает из коробки нет ничего, а вы предлагает гимор с настройками

Deleted
()
Ответ на: комментарий от Deleted

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

maloi ★★★★★
()
Ответ на: комментарий от Deleted

Так ничего нет в самом приложении, локально собраный и оттестированый war в том же виде заливается на prod. А геморов нет, просто копипаста конфига из томката старого проекта в новый. И админы могут двигать базы как хотят. Настройки для локального запуска вообще запросто встраиваются в мавен, который конфигурирует контейнер

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

а прод конфигуряет пушкин, и получается часть настроек - там, а часть вот там, и еще тут надо подкрутить, и кинуть jdbc к томкату в папочку и прописать параметрик при запуске и т.п. 8)

Deleted
()
Ответ на: комментарий от Deleted

ну так покажи как без пересборки, без настройки и без перезапуска заставить приложение работать с новыми настройками? на любом выбранном тобой контейнере.

maloi ★★★★★
()
Ответ на: комментарий от maloi

Если руками написать сложную поддержку изменений properties, то может и завестись. Но я бы спокойно уже не спал

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

ну для начала я бы хотел услышать на основании чего будут выбираться дефолтные настройки подключения (оно же работает изкоробки? значит дефолт где-то прописан, и он очевидно разный для test, uat и prod).

maloi ★★★★★
()

Относительно dtd метода - говнокод 80-го уровня, автору - медаль за хорошее знание стандартов xml и особенностей парсера persistence.xml

vertexua ★★★★★
()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от maloi

как без настройки настроить приложение это Вы уж сами расскажите, ибо это Вы такой бред ляпнули.

а ежели настройки JNDI в META_INF/context.xml то томкат сам редеплоит контекст

Deleted
()
Ответ на: комментарий от Deleted

как без настройки настроить приложение это Вы уж сами расскажите, ибо это Вы такой бред ляпнули.

ну ты же сам сказал - приложение работает искаропки? расскажи хотя бы как на разных окружениях один и тот же варник запускается с разным дефолтом (без настроек окружения, конечно же).

а ежели настройки JNDI в META_INF/context.xml то томкат сам редеплоит контекст

ништяк, а завтра придет новый варник, его задеплоят, а там старые настройки.

maloi ★★★★★
()
Ответ на: комментарий от maloi

приложение работает искаропки?

работает тебя удивляет?

расскажи хотя бы как на разных окружениях один и тот же варник запускается

не запускается, окружений тестовое и продакшен, дальше догадаешься?

ништяк, а завтра придет новый варник, его задеплоят, а там старые настройки.

старые настройки в новом? ты точно не на больничном?

Deleted
()
Ответ на: комментарий от Deleted

работает тебя удивляет?

я же тебя уже просил рассказать как ты хочешь этого достичь.

не запускается, окружений тестовое и продакшен, дальше догадаешься?

русский язык вроде придумали в вашей стране, а говорите все так, что ничерта понять не возможно.

старые настройки в новом? ты точно не на больничном?

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

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

ты пропустил пункт: подумать головой

Deleted
()
Ответ на: комментарий от Deleted

подумать головой

Это противоречит «искаропки». Зачем заявлять искоробочность, если её нет и приходится каждый раз при деплое думать, «не забыл ли я что-то настроить?» «а не поменял ли ночью дежурный админ настройки JNDI, т.к. базу переключили на Disaster Recovery окружение?» и т.д.?

maloi ★★★★★
()
Ответ на: комментарий от maloi

Зачем заявлять искоробочность, если её нет

она есть

приходится каждый раз при деплое думать

думать вообще нужно каждый раз когда ты лезешь на продакшен своими ручками

Deleted
()

хак занимательный, но чем это отличается от подмены файла конфигурации полностью, или сборки его по шаблону? ничем, так что обычная такая конфигурация с небольшим извратом. но работает, какая разница. задачи решает ну и здорово.

trashymichael ★★★
()
Ответ на: комментарий от Deleted

она есть

её нет

думать вообще нужно каждый раз когда ты лезешь на продакшен своими ручками

Как показывает практика, научить остальных людей думать - достаточно тяжело, поэтому на случай отсутствия тебя на рабочем месте нужны инструкции, понятные даже недостаточно квалифицированному специалисту. В твоем случае либо инструкции будут слишком запутанными (включающими в себя половину документации tomcat-а), либо останется высокий bus factor.

maloi ★★★★★
()
Ответ на: комментарий от maloi

её нет

Ты мне тут мастер класс по солипсизму решил устроить или тупо бодаешься? Интеллект!

Как показывает практика

когда приложение достаточно тупо залить - это отлично.

когда для правки подключения к базе нужно лесть в конфиг контейнера и ломать все остальные приложения то надо учить всю документацию томката, и все равно чудики будут все ронять

Deleted
()
Ответ на: комментарий от Deleted

когда приложение достаточно тупо залить - это отлично.

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

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

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

maloi ★★★★★
()
Ответ на: комментарий от maloi

в твоем случае - недостаточно

Заливаю - работает. ЧЯДНТ? Ты наверное чемто страдаешь?

у остальных-то это не так.

у вас там никто не может разобраться, ЧИТД

Deleted
()
Ответ на: комментарий от Deleted

Заливаю - работает. ЧЯДНТ?

работаешь в сферических условиях в вакууме, т.к. сегодня заливаешь - работает, а завтра - уже не работает.

Ты наверное чемто страдаешь?

безусловно, я страдаю недолюбливанием вранья.

у вас там никто не может разобраться

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

ЧИТД

кому?

maloi ★★★★★
()
Последнее исправление: maloi (всего исправлений: 1)
Ответ на: комментарий от maloi

работаешь в сферических условиях в вакууме, т.к. сегодня заливаешь - работает, а завтра - уже не работает.

бгг ты сам уже заврался, в сферических условиях какраз таки все работает по твоим словам 8)

у нас тут никому не надо разбираться, т.к. все и так понятно

какойто один гейний надрочился настраивать опухший конфиг контейнера и его все дергают, понятно

Deleted
()
Ответ на: комментарий от Deleted

бгг ты сам уже заврался, в сферических условиях какраз таки все работает по твоим словам 8)

ну так работает в сферических условиях == не работает на практике, неужели не понятно?

какойто один гейний надрочился настраивать опухший конфиг контейнера и его все дергают, понятно

какие у тебя интересные фантазии, не пробовал к доктору с ними обратится?

maloi ★★★★★
()
Ответ на: комментарий от maloi

ну так работает в сферических условиях == не работает на практике, неужели не понятно?

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

Deleted
()
Ответ на: комментарий от Deleted

Поддерживаю. Что за тупость деплоить код без конфигов? Конфиги, что такая фигня? Правда прям в варник зашивать тоже плохо. То есть нужно деплоить варник + конфиг.

dizza ★★★★★
()
Ответ на: комментарий от dizza

. То есть нужно деплоить варник + конфиг.

это было бы совсем замечательно, но в tomcat без костылей это не прокатит

Deleted
()
Ответ на: комментарий от Deleted

Да, стандартно такого нет. На моей памяти уже три решения решения - грузить конфиги из конфиг-бд, грузить конфиги с другого томкета, закатывать варку в deb-пакет. В первых двух слчаях при деплое конфиг либо инсертится в базу, либо закидывается по ssh в томкет. При запуске приложение запрашивает конфиги предав параметры - id приложения и environment.

В случае дебки конфиги менеджаться с помощью админских программулин вроде Puppet.

Ну и вариант с зашиванием конфигов тоже имеет место быть, ничего страшного я в нем не вижу, кроме нарушения segregation: формально прод конфиг девелоперы трогать не могут.

dizza ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.