Pull to refresh

Comments 34

А чем плохо использовать нативные средства java ee для имплементации сервисов?
Не плохо, просто можно делать проще. KISS, как говорится :) Мой пример не просто игрушка, у меня есть опыт работы с реально работающими приложениями, написаными похожим образом. Подход хорошо зарекомендовал себя, а именно: легко писать тесты, легко деплоить, т.к. не нужен внешний контейнер, jar-ник можно легко покавать в deb, минималистичные библиотеки вроде guice легко поддаются расширению, очень простое конфигурирование приложения.
ну, если Jersey да еще Grizzle, то по KISS логично остановиться на Glassfish Web Profile, а guice — лишняя сущность :)
Зависит от целей, которые вы преследуете. У меня в приоритете простой, unix-way деплой.
а сложно паковать Glassfish в deb? В любом случае есть Embedded Glassfish.
Боюсь сейчас все скатится к холивару javaee vs альтернативы. Давайте остановимся на том, что я не использую app-серверы :) Просто не нравится такой подход в целом.
холивар, конечно, зло, но я как раз не против альтернатив, а за то, чтобы строго соблюдать неприкосновенность своей лени и пользоваться готовыми решениями. Ведь всегда хорошо, когда за тебя умные дяди уже подумали.
Хм. В общем случае умные дяди не могут подумать «за тебя», только лишь за некого усредненного разработчика.

И под простотой мы видимо разные вещи понимаем. Я склоняюсь к тому, что более простые решения как раз требуют большего интеллектуального вклада. «Ленивые» решения — это как правило лишь локальный оптимум.
В данном случае дяди подумали именно за меня, используя Glassfish я просто ставлю те же аннотации @Singleton, @Path и @Get и все работает. REST в Java это проще :)
Дело в том, что я не стремлюсь, что бы за меня кто-то думал. Это для меня не есть критерий простоты.
Ну вот ставьте и успокойтесь уже, и не склоняйте людей на свою сторону зла.
Мы вас не трогаем — вы нас не трогаете.
Не навязывайте нормальным людям свои страшные монструозные java ee-шные «фреймворки».
Совершенно с вами согласен. Из-за этого пример ещё более синтетически выглядит чем мог быть. Глаз за класс Counter цепляется сразу и хочется его банально удалить :)
А я совершенно с ним несогласен.
Это камент для статистики.
Неплохой пост.
Есть еще Restlet framework аналог Jersey.
Правда сейчас в своем проекте использую сервлеты с GSON сериализатором для вывода в json.
А можно было не создавать пустой сервлет, а передать DefaultServelet в Guice?
А DefaultServlet — это разве не из Tomcat? Вообще я думаю можно.
UFO landed and left these words here
Оно у меня на другом компе осталось, как доберусь выложу, конечно :)
Тарбол… какое древнее слово, а
Добавил ссылку на исходники в svn
Первым пользуюсь. Все же связка spring + jersey для rest по-удобнее spring mvc, а связка guice + jersey мне понравилась еще больше :) Второй — просто еще одна имплементация JAX-RS (и не только) на ряду с Jersey, вполтную не пользовался, так что не знаю дружит ли он с guice.
Все же связка spring + jersey для rest по-удобнее spring mvc

Почему? Сейчас стою как раз перед выбором?
Вся-таки Jersey (JAX-RS) специально создавался для создания REST-сервисов. Чуть API более лаконичен именно для REST-сервисов. Хотя разница в целом мизерная. Если выберете spring mvc 3, то ничего особо не потеряете.
Извините за занудство но тут «И так, поехали:», «итак» слитно, по-моему, надо писать в данном случае, просто глаз резануло, в любом случае спасибо за статью, очень интересно.

возник вопрос, может немного не в тему. видно, что вы применяете guice активно. мы на работе много дела имеем с подобного рода сервисами, обычно используется связка spring+jetty. поскольку банк большой, процессы сложные, надо деплоить приложение то туда, то сюда, на разные энвайроменты, соответственно проблема решается стандартным образом — в спринг конфигурации используются плейсхолдеры на проперти, есть файлы пропертей для каждого энвайромента, типа dev, UAT, SIT, Prod. ну а проперти включают себя параметры подключения к базе, к jms и к другим системам

при запуске приложение получает параметер типа -Denv=dev и файл с пропертями всасывается в спринг конфигурацию.

в свое время любопытствовал по поводу guice, но так и не воткнул, как в нем решать проблему множественности конфигураций. вы берете порт из системных параметров, неужели приходится все параметры пачкой передавать через -Dxxx=yyy? или используете адские скрипты, которые поставляют проперти в системные переменные? или вообще guice для такого рода приложений не годится?

«Итак» поправил, спасибо.

Насчет guice. Мы конфигурируем там: через -D передается путь к property файлу, который потом байндится как guice-бин. При создании guice-контекста этот файлик само собой используется для конфигурировании бинов. jar-ка вместе c property файлом пакуется в deb. После первой установки пакета в конекретном окружении property файл правится. При переустановке пакета проверка изменений в property файле осуществляется dpkg автоматически, если изменений «пакетного» конфига нету, то правленый конфиг оставляется нетронутым.

Ту схему, что описали вы, я думаю можно запросто повторить и в guice. Просто вместо place holders будет извлечение проперти из конфига в java-коде.

спасибо за разьяснение, идею понял, попробую сделать так в каком-нибудь проекте своем. Еще jar-ка очень улыбнула :) как вы с ними нежно, мы их все — жарник, или жар
Спасибо, интересно. Теперь у меня на один повод меньше не любить java.
Насколько я понял, в описанном примере поднимается свой джуйс. А что делать в случае, когда Jersey ресурс подключается к большому проекту со своим джуйсом и нужно брать классы именно из него?
Когда мы передаем в метод Guice.createInjector наши модули, то все они будут работать в одном контексте. Бины из одного модуля тогда смогут инжектить бины из другого.

ЗЫ. Случайно не свои люди? :)
Да, свои. Мир дейстительно тесен. (:
Only those users with full accounts are able to leave comments. Log in, please.