IDVsbruck

Кому-то нравится исключительно xml-конфигурация, так как позволяет собрать всю настройку проекта если не в одном файле, то в одной папке с конфигурационными файлами точно, кому-то нет. К примеру, я считаю, что времена persistence.xml ушли безвозвратно — отображения сущностей для ДБ удобнее прописывать в классах сущностей, а маппинги контроллеров и методов удобнее назначать непосредственно в классах контроллеров. Вывод очевиден: если разработчик не страдает анахронизмом, то так или иначе проект будет иметь смешанную настройку — часть в аннотациях, часть в xml-файлах. Это не хорошо и не плохо, это данность времени — все привыкли к web.xml, application.xml, springmvc-servlet.xml и т.д., но при этом активно пользуются аннотациями @ Controller, @ Repository, @ Autowired, @ Value, @ ResponseBody и т.д. Начиная с версии 3 Spring добавил возможность использования Java-based конфигурации, что позволило полностью отказаться от xml-файлов в настройке проекта. Ранее на Хабре была публикация с анализом преимуществ и недостатков одних способов перед другими, с рядом плюсов xml-конфигурации я полностью согласен.

Однако в данной публикации речь не о преимуществах одних или недостатков других, и тем более не попытка агитации за новые технологии и возможности, это только лишь консолидированный отчет о сборке веб-проекта с нуля до рабочего проекта. И главное — с включением в проект embedded сервера Jetty. На самом деле отдельных фрагментов по настройке как встроенного Jetty, так и контекстов Spring Application, MVC, Security, навалом. Но чтобы разобраться в тонкостях этих настроек, не внедрять сложную структуру и не городить костыли, потребовалось кое-какое время и просмотр большого числа документации и исходников. Но даже имея значительный опыт настройки, пришлось столкнуться с рядом затруднений, после решения которых пришла идея опубликовать все это в одном месте.

Решил реализовать на разрабатываемом портале авторизацию (регистрацию) и идентификацию пользователей с помощью инструмента разработчика социальных сетей (Social Networks REST API) – тематика далеко не новаторская, активно используется и очень удобная в использовании. Как бы перечислять все удобства и преимущества использования на своих сайтах подобного функционала не буду, но замечу, что меня очень устраивает не запоминать пароли для каждого сайта (пусть даже если у меня пара-тройка стандартно используемых), не участвовать в утомительных регистрациях с пересылками писем и подтверждениями, а также лишний раз не сталкиваться с каптчами.