ты спринг датой не пользовался чтоли?

пользовался

@Query(…, nativeQuery = true)

все получилось. почему-то сразу не догадался так сделать :)

А эта, есть в природе скидочные коды на Highload++ 2018?

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

там никакой магии нету, стартеры всего лишь дефолтные конфиги и готовые бины

там никакой магии нету, стартеры всего лишь дефолтные конфиги и готовые бины

Я это и имел ввиду. А так бы ручками сконфигурировать дата сорс, транзакшен менеджер. Эх... Прям носиальгия

Я это и имел ввиду. А так бы ручками сконфигурировать дата сорс, транзакшен менеджер. Эх... Прям носиальгия

ничего тебе не мешает это оверрайдить

или не подключать не нужные автоконфигурации

ничего тебе не мешает это оверрайдить

Мне нет. А, вот, человек выше страдает

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

Хочется попробовать на Android что нибудь написать на Eta, но там даже вменяемого редактора нет.

Ребят, посоветуйте что почитать по поводу разработки своих библиотек на предмет описания зависимостей. Есть ощущение, что при разработке библиотеки внешние зависимости следует подключать только при тестах, чтобы конкретную версию указать уже в проекте, который будет использовать эту библиотеку. Но как понять, с какой версией внешней зависимости совместима библиотека? Как избежать dependency hell. Использовать или не использовать bom? Хочется привести мысли в порядок

Ребят, посоветуйте что почитать по поводу разработки своих библиотек на предмет описания зависимостей. Есть ощущение, что при разработке библиотеки внешние зависимости следует подключать только при тестах, чтобы конкретную версию указать уже в проекте, который будет использовать эту библиотеку. Но как понять, с какой версией внешней зависимости совместима библиотека? Как избежать dependency hell. Использовать или не использовать bom? Хочется привести мысли в порядок

Собственные зависимости у библиотек - это вполне норма (например, slf4j, всякие apache-commons и guava). А лучшее средство от dependency hell - не использовать библиотеки, забивающие на обратную совместимость. BOM скорее для фреймворков.

Собственные зависимости норма - это понятно. Но какой скоуп (если в рамках maven) должен быть у них?

Как понять забивает библиотека на обратную совместимость или нет?

Собственные зависимости норма - это понятно. Но какой скоуп (если в рамках maven) должен быть у них?

Про Maven не скажу, а у Gradle есть такая штука, как implementation, чтобы они не утекали в compile classpath клиента

это provided scope

это provided scope

provided же вроде не тянет зависимость в runtime? Наверное, к нему ещё runtime добавить надо, и будет такой же эффект.

это provided scope

нет

implementation специфичен для gradle-android и более-менее эквивалентем compile

provided же вроде не тянет зависимость в runtime? Наверное, к нему ещё runtime добавить надо, и будет такой же эффект.

а implementation тянет?

а implementation тянет?

Да

он не только для андройда применим

Вот я пишу две библиотеки. Одна использует гуаву:А, другая гуаву:B. Если использовать provided, то в проект, использующем обе эти либы нужно указать конкретную версию гуавы. Вопрос, какую? Если дефолтный скоуп использовать, то внешняя зависимость придет и в проект. Тогда (при использовании энфорсер-плагина) нужно будет поэксклюдить одну зависимость. И тут уже начинается hell

implementation специфичен для gradle-android и более-менее эквивалентем compile

Давно уже не только там

Hibernate - магически исчезающий ORM фреймворк

Да

сорян, вспомнил. не совсем в provided же фишка

Вот я и ищу какой-то аргументированный мануал

Вот я пишу две библиотеки. Одна использует гуаву:А, другая гуаву:B. Если использовать provided, то в проект, использующем обе эти либы нужно указать конкретную версию гуавы. Вопрос, какую? Если дефолтный скоуп использовать, то внешняя зависимость придет и в проект. Тогда (при использовании энфорсер-плагина) нужно будет поэксклюдить одну зависимость. И тут уже начинается hell

Вполне безопасно брать последнюю (как и делает gradle)

Java - магически исчезающий ЯП

Куда исчезает то?

кажется, кто-то просто хочет срача

это просто провокатор

пхпшник наверно

hibernate умрёт только тогда когда никогда, не в ближайшем будущем, в общем

Андроид разработчик который писал на 6ой джаве и тут увидел котлин

есть книжки по концентрации для программистов? Часто отвлекаюсь на всякую муть, может кто знает? Вообще топово для perfomance'а было бы

Вот эта книжка неплоха

https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning

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

жесть че я написал

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

в чём проблема? читай внешний файл

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

сложна чет, пришлось доку открывать

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

ответ - да

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

да у меня не настока сложный вопрос был

For example, if additional locations of classpath:/custom-config/,file:./custom-config/ are configured, the search order becomes the following file:./custom-config/ classpath:custom-config/ file:./config/ file:./ classpath:/config/ classpath:/ This search ordering lets you specify default values in one configuration file and then selectively override those values in another

меня вот че интересовало

то есть кароч да - пропертисы из файла оверрайдят пропертисы из джярника

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

спринг? бут?

спринг? бут?

АТО

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

все автоматом

и да, пользуемся бутом, пользуйтесь yml наконец

пхпшник наверно

ява скриптер

ява скриптер

батхерт понятен

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

и да, пользуемся бутом, пользуйтесь yml наконец

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

нет, будет такой порядок поиска application-prod.properties внешний-> application-prod.properties внутренний -> application.properties внешний-> application.properties внутренний

ой, вру

нет, будет такой порядок поиска application-prod.properties внешний-> application-prod.properties внутренний -> application.properties внешний-> application.properties внутренний

Услышал вас, понел принел

Вреш?!!

ERROR: S client not available

application-prod.properties внешний-> application.properties внешний-> application-prod.properties внутренний -> application.properties внутренний

вот так

внешний конфиг всегда главнее

А ну тогда ставлю ?

и да application-prod.properties внешний обычно не используется ибо достаточно просто внешнего application.properties

и да application-prod.properties внешний обычно не используется ибо достаточно просто внешнего application.properties

схоронил, спасибо, тоже пригодится

и да application-prod.properties внешний обычно не используется ибо достаточно просто внешнего application.properties

вот я об етом и думалъ, мол тупа будет иметь внешний профаел специфек конфиг... спасибо... ты настоящий друг

=*

батхерт понятен

это стеб над жо ес

application-prod.properties внешний-> application.properties внешний-> application-prod.properties внутренний -> application.properties внутренний

проще не запоминать, а указать вручную: /usr/bin/java -Dspring.config.location=file:/srv/bot/application-production.properties -jar /srv/bot/bot-2.1.0.jar

проще не запоминать, а указать вручную: /usr/bin/java -Dspring.config.location=file:/srv/bot/application-production.properties -jar /srv/bot/bot-2.1.0.jar

Не всегда удобно

привет! подскажите плз, если я гружу jar с помощью URLClassLoader, повлияет ли это на значение Thread.currentThread().getContextClassLoader?

вызов getContextClassLoader внутри самого jar

проще не запоминать, а указать вручную: /usr/bin/java -Dspring.config.location=file:/srv/bot/application-production.properties -jar /srv/bot/bot-2.1.0.jar

И что? Этим параметром спрингу говорится не искать application.properties рядом с приложением, а смотреть файл такой то. В данном случае правила будут те же самые, только указанный файл будет заместо внешнего application.properties

и если я использую URLClassLoader, может ли это спровоцировать ошибку при загрузке .properties файла внутри подгружаемого jar

привет! подскажите плз, если я гружу jar с помощью URLClassLoader, повлияет ли это на значение Thread.currentThread().getContextClassLoader?

Да

и если я использую URLClassLoader, может ли это спровоцировать ошибку при загрузке .properties файла внутри подгружаемого jar

Нет

Вроде нет. Был какой то старый кейс с karaf, но тут ты же сам грузишь

А, вспомнил, там с другого модуля пытались тянуть

А, вспомнил, там с другого модуля пытались тянуть

другого модуля файл properties?

у меня проблема в том что если я упаковываю в свой jar файл все зависимости то при их иницализации вылетает ошибка NullPointerException при вызове java.util.Properties$LineReader.readLine, если же зависимости инициализируются не внутри моей jar либы а напрямую из приложения то все нормально

Тут не конкретно в properties дело, любой ресурс

Надо смотреть. Какой тут делаешь?

Надо смотреть. Какой тут делаешь?

какой что?

Тьфуты, не то набралось, путь какой?

Тьфуты, не то набралось, путь какой?

"com/sun/syndication/rome.properties"

вот эта либа https://github.com/ralph-tice/rome/blob/master/src/main/java/com/sun/syndication/io/impl/PropertiesLoader.java#L81

classpath:/ добавь в начале

classpath:/ добавь в начале

в эту строку?

или куда