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-шные «фреймворки».
Мы вас не трогаем — вы нас не трогаете.
Не навязывайте нормальным людям свои страшные монструозные java ee-шные «фреймворки».
Совершенно с вами согласен. Из-за этого пример ещё более синтетически выглядит чем мог быть. Глаз за класс Counter цепляется сразу и хочется его банально удалить :)
Неплохой пост.
Есть еще Restlet framework аналог Jersey.
Правда сейчас в своем проекте использую сервлеты с GSON сериализатором для вывода в json.
Есть еще Restlet framework аналог Jersey.
Правда сейчас в своем проекте использую сервлеты с GSON сериализатором для вывода в json.
А можно было не создавать пустой сервлет, а передать DefaultServelet в Guice?
А DefaultServlet — это разве не из Tomcat? Вообще я думаю можно.
DefaultServlet — это часть спеки J2EE, иначе контейенры никогда не смогли бы отдать статику и показать 404 и т.п.
В jetty он тут: jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/servlet/DefaultServlet.html
В jetty он тут: jetty.codehaus.org/jetty/jetty-6/apidocs/org/mortbay/jetty/servlet/DefaultServlet.html
UFO just landed and posted this here
Первым пользуюсь. Все же связка spring + jersey для rest по-удобнее spring mvc, а связка guice + jersey мне понравилась еще больше :) Второй — просто еще одна имплементация JAX-RS (и не только) на ряду с Jersey, вполтную не пользовался, так что не знаю дружит ли он с guice.
Недавно обсуждали, может быть кому-то покажется интересным
community.livejournal.com/ru_java/1019047.html
community.livejournal.com/ru_java/1019047.html
Извините за занудство но тут «И так, поехали:», «итак» слитно, по-моему, надо писать в данном случае, просто глаз резануло, в любом случае спасибо за статью, очень интересно.
возник вопрос, может немного не в тему. видно, что вы применяете guice активно. мы на работе много дела имеем с подобного рода сервисами, обычно используется связка spring+jetty. поскольку банк большой, процессы сложные, надо деплоить приложение то туда, то сюда, на разные энвайроменты, соответственно проблема решается стандартным образом — в спринг конфигурации используются плейсхолдеры на проперти, есть файлы пропертей для каждого энвайромента, типа dev, UAT, SIT, Prod. ну а проперти включают себя параметры подключения к базе, к jms и к другим системам
при запуске приложение получает параметер типа -Denv=dev и файл с пропертями всасывается в спринг конфигурацию.
в свое время любопытствовал по поводу guice, но так и не воткнул, как в нем решать проблему множественности конфигураций. вы берете порт из системных параметров, неужели приходится все параметры пачкой передавать через -Dxxx=yyy? или используете адские скрипты, которые поставляют проперти в системные переменные? или вообще guice для такого рода приложений не годится?
возник вопрос, может немного не в тему. видно, что вы применяете 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-коде.
Насчет guice. Мы конфигурируем там: через -D передается путь к property файлу, который потом байндится как guice-бин. При создании guice-контекста этот файлик само собой используется для конфигурировании бинов. jar-ка вместе c property файлом пакуется в deb. После первой установки пакета в конекретном окружении property файл правится. При переустановке пакета проверка изменений в property файле осуществляется dpkg автоматически, если изменений «пакетного» конфига нету, то правленый конфиг оставляется нетронутым.
Ту схему, что описали вы, я думаю можно запросто повторить и в guice. Просто вместо place holders будет извлечение проперти из конфига в java-коде.
Спасибо, интересно. Теперь у меня на один повод меньше не любить java.
Насколько я понял, в описанном примере поднимается свой джуйс. А что делать в случае, когда Jersey ресурс подключается к большому проекту со своим джуйсом и нужно брать классы именно из него?
Sign up to leave a comment.
REST-сервис на Java — это просто