JEE & Spring

А пойдешь сам.

костыльненько

Бинго. Вобщем все как всегда - страсть к велосипедостроению связана с нежеланием читать и вникать в доки.

Ну, вечная история. Если человек не вкуривает в что-то сразу, то чаще всего это обзывается говном и на этом история заканчивается. Я и за собой такое замечал в принципе.

Это хороший вариант, но это же приблуда к web фреймворку а не к core spring?

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

Ты уже вернулся?

Метод register объявлен в интерфейсе org.springframework.context.annotation.AnnotationConfigRegistry. А это spring-context, к вебу особого отношения не имеющий.

Че тебе надо, убогий? Конструктива внести в дискуссию ты не способен, то хотя бы не воняй.

костыльненько

Ну, что первое в голову пришло. Хотя где тут особые костыли?

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

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

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

Места знать надо =))

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

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

На удивление приятный язык

да яб на нем только ради вывода типов генериков писал, не говоря об остальных плюшках 8(

Ну да, вывод типов для локальных|private переменных, наконец то нормальные свойства без угребищных get/set, всякие map(), filter() etc. которые можно применить не к Stream а к Iterable напрямую итд. И при этом статическая типизация и нет 100500 способов написать нечитаемый звиздец как в скале (поэтому вменяемый явер способен на нем начать писать через пол дня). Весь проект с удовольствием бы на нем сделал, если бы jetbrains выложили roadmap и клятвенно пообещали на проект не забивать.

а, собственно, зачем нужен JEE

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

А если сравнивать даже не со спрингом, а с другими стэками

А спринг и другие стеки - это конкретные реализации библиотек для построения веб- и энтерпрайзных приложений. При этом разные их части могут соответствовать, а могут и не соответствовать спецификациям JEE. Например, ORM в том же спринге реализует в т.ч. JPA, а Google Guice вроде как до сих пор является reference implementation для JSR-330.

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

Я вот попробовал собрать проектик на спринге года два назад с mvc, jpa, и т.д., это звиздец какой то товарищи, поспрашивал как другие делают, говорят - копипастят из старых проектов.

Говнокодеры-с, сэр.

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

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

И как все это можно применить к примеру к анотаци @EnableJpaRepositories? Сверкни квалификацией?

Умиляет, да, но в проде его не использовал, так что тормоза подтвердить или опровергнуть не могу. Наверняка же нужно просто уметь его готовить. Я вообще кроме WAS последние джва года ничего не юзал.

И таки ви хаотите сказать, что спринг тормозной? Тормозной в чем и по сравнению с чем? Если на нем хэлоуворлд работает в 2, к примеру, раза медленнее, совсем не показатель.

Как минимум ради Servet API его стоило пилить. И Spring, и другие фреймворки мне известные, с вебом работают через Servlet'ы.

Еще из более менее хороших вещей видел там JSF - сранивал правда лишь с GWT.

В принципе, при небольшом желании, энная часть стека JEE запускается на контейнере сервлетов, типа Tomcat и прекрасно работает. JPA, JSF, Servlet, JDBC - а что еще надо для маленького проекта? А удобства становится гораздо больше.

И таки ви хаотите сказать, что спринг тормозной? Тормозной в чем и по сравнению с чем?

Таки все что хотел я сказал, человеку который не знает про унутренности AOP (который используется как минимум в security и для транзакций) мне больше сказать нечего, ибо бессмысленно.

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

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

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

На Java не только ынтерпрайз пишут. Есть и другие приложения, у которых есть таки определенные требования к скорости работы.

И таки ви хаотите сказать, что спринг тормозной?
ынтерпрайз продукты работают медленно

Слушай, зачем тебе я? Ты отлично сам отвечаешь на свои вопросы.

чтобы достичь этого ты 10 лет питался крышками от консервных банок

ЭЭ что?

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

Расскажи о юз кейсах, которые заставляют тебя такое делать.

Заставляют меня делать что? Ты же сам все написал?

Использовать в одном и том же месте jpa репозитории и, скажем, JdbcTemplate, в зависимости от переменной энвайронмента?

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

нелепом количестве кода и эксэмеля.

С разморозкой вас, товарищ, в spring давно уже аннотациями все конфигурируется, xml там нафиг не нужен уже давно.

Тем временем его фанаты пробрались в комитеты JavaEE и украли из Spring все что можно, сделав современный JavaEE 7-8 по сути спрингом по функционалу, но сделаным хорошо с чистого листа. Компании одобрили и бросили сотни програмистов на разработку современных серверов. Они написали быстрые, легкие, современные сервера вроде Wildfly. Теперь все будут по чуть-чуть закапывать Spring

А как на Java EE 7-8 выглядит простой код типа

@RequestMapping("/bla")
public String foo(@RequestParam String moo, Model model) {
    model.addAttribute("zoo", moo);
    return "view";
}

А то я не фанат спринга, но аналога SpringMVC пока не нашёл. Голые сервлеты пробовал юзать — в итоге постоянно пишу свой Spring MVC, только не такой удобный. Из вменяемых альтернатив только какой то Ninja Framework нашёл, но не разбирался с ним, хотя внешне выглядит многообещающе.

Например, ORM в том же спринге реализует в т.ч. JPA

В спринге нет ORM. Ты спринг с хибернейтом перепутал, похоже.

Сервлеты это отвратительное API даже для своего времени. Вменяемое низкоуровневое API можно посмотреть у go (или в библиотеке express у node.js). Хорошее апи у библиотеки Netty.

В JavaEE7 это пишется, хотя не совсем тривиально, там основная идея пока-что в HTML5+JAX-RS. Но вот в JavaEE 8 добавили точно такой MVC с pluggable renderers, можешь любой шаблонизатор засунуть

Спасибо, интересно.

Our goal for the Java EE 8 specification is for it to be finalized in the second half of 2016.

нескоро будет. Неторопливые они ребята.

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

Как минимум ради Servet API его стоило пилить. И Spring, и другие фреймворки мне известные, с вебом работают через Servlet'ы.

Servlet'ы это довольно старый API с кучей проблем которые никогда не решат.

Из популярных фреймворков, Play, к пример, успешно сам реализует HTTP.

Servlet'ы это довольно старый API с кучей проблем которые никогда не решат.

например? из того что мне попадалось это извращенный AsycnContext но это совсем не старое api

например?

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

Клиенту эта синхронность тоже как правило не нужна; но тут больше засад — 3.0 не позволяет делать асинхронный ввод-вывод. А 3.1 совсем безумен по API и по факту плохо поддерживается разными серверами, так что юзать его довольно стремно.

Еще можно припомнить использование коллекций Java 1.0 и всякие подобные мелочи.

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

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

Остается netty и jetty.

Не говоря уже о том что большинство все также работает в стиле: томкат->сервлет->ждем ответа от субд - и их это устраивает.

Ничего не мешает обычному jax-rs отдавать html через какой нибудь движек шаблонов, аля freemaker, не выдумывай.

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

А там и не нужно из каропки решение, АПИ очень простой и очевидный, это все равно что искать фреймворк который будет 2+2 из каропки решать.