Кто-нибудь может объяснить как работает java web приложение с аннотациями и spring-mvc
совместно с сервером приложений? (В моем случае это Glassfish 4)
Когда мы работаем с консольным приложением java, мы указываем команде java имя скомилированного
класса. Я так понимаю, JRE ищет в указанном классе метод public static void main(String
args[]) и выполняет его. И этот метод main считается точкой входа в программу.
А когда у нас web приложение, у нас имеется какая-то точка входа? Я по началу думал,
что точка входа это web.xml. Но если мы используем spring-mvc и конфигурируем его с
помощью аннотаций, то я так понял web.xml вообще может быть пустым.
Когда глассфишу скармливается war'ник, то я так понимаю в памяти создаются экземпляры
классов которые помечены аннотациями @Service и @Controller, но кто их создает? Я читал,
что это делает спринг, в рамках его IoC, DI и его контейнерной роли, но спринг тоже
кто-то должен запустить?
По логике, инициализация спринга должна происходить при явном или неявном вызове
его конструкторов в точке входа, но где тогда она? Или его инициализацию производит
сервер приложений? Но каким образом мы указываем ему это сделать?
Вот мой SpringInitializer, я так понимаю основная магия происходит здесь?
Этот код выполняет Glassfish? Как он понимает, что именно этот класс надо выполнить?
import javax.servlet.MultipartConfigElement;
import javax.servlet.ServletRegistration;
import org.springframework.web.servlet.support.AbstractAnnotationConfigDispatcherServletInitializer;
public class SpringInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected Class[] getRootConfigClasses() {
return new Class[] { SpringConfiguration.class };
}
@Override
protected Class[] getServletConfigClasses() {
return null;
}
@Override
protected String[] getServletMappings() {
return new String[] { "/" };
}
}
Я рылся в руководстве Шилдта по Java, а также в Spring in Action, и пару недель пробую
различные запросы по сабжу в гугл. Или в этих книгах не было явных ответов на эти вопросы,
или я их пропустил, или не понял.
Буду признателен за объяснение, или если кто тыкнет носом где читать.
Ответы
Ответ 1
Я рылся в руководстве Шилдта по Java, а также в Spring in Action
Если вы хотите разобраться с базовыми механизмами работы веб-приложений начинать
стоит со спецификации Servlet API (3.0, 3.1).
А когда у нас web приложение, у нас имеется какая-то точка входа?
Как таковой точки входа нет. Есть контейнер сервлетов, который берет ваш WAR и, если
все хорошо, стартует жизненный цикл вашего веб-приложения: устанавливает параметры,
оповещает слушателей, пробрасывает запросы в сервлеты, пропускает их через фильтры.
По сути, контейнер сервлетов занимается тем, что оперирует объектами, которые можно
описать в web.xml, а, начиная с 3й версии спецификации, он должен уметь искать их и
без web.xml.
... но кто их создает? Я читал, что это делает спринг, в рамках его IoC, DI и его
контейнерной роли, но спринг тоже кто-то должен запустить?
Все верно, IoC-контейнер спринга (а именно AnnotationConfigWebApplicationContext
в вашем случае) сканирует видимый ему CLASSPATH и создает ваши бины, ориентируясь на
аннотации. Осталось понять, кто создает экземпляр этого ApplicationContext и запускает
его жизненный цикл (см. ниже).
По логике, инициализация спринга должна происходить при явном или неявном вызове
его конструкторов в точке входа, но где тогда она? Или его инициализацию производит
сервер приложений? Но каким образом мы указываем ему это сделать?
Вы очень верно рассуждаете. Начиная со спецификации Servlet API 3.0 появилась возможность
не использовать web.xml. Но контейнер сервлетов должен как-то узнать, где находится
код, инициализирующий веб-приложение. Тут помогает механизм, известный как Service
Provider. Если коротко, он ищет в CLASSPATH для контейнера сервлетов файл-дескриптор
META-INF/services/javax.servlet.ServletContainerInitializer, который указывает на реализацию
интерфейса ServletContainerInitializer. В случае Spring-а это будет класс SpringServletContainerInitializer.
Давайте без стеснения посмотрим на его исходники. На объявлении класса висит аннотация
@HandlesTypes:
@HandlesTypes(WebApplicationInitializer.class)
public class SpringServletContainerInitializer implements ServletContainerInitializer {}
По контракту интерфейса ServletContainerInitializer контейнер обязуется передать
конкретной реализации в её единственный метод onStartup коллекцию классов, попадающих
в перечисленные в аннотации @HandlesTypes. Здесь у нас указан только интерфейс WebApplicationInitializer,
поэтому Glassfish передаст все найденные реализации WebApplicationInitializer. Для
каждой реализации будет создан экземпляр и вызван метод onStartup:
for (WebApplicationInitializer initializer : initializers) {
initializer.onStartup(servletContext);
}
И именно ваш SpringInitializer является такой реализацией. Кроме того SpringInitializer
наследует AbstractDispatcherServletInitializer. И вот именно этот AbstractDispatcherServletInitializer
и "запускает Spring", создавая WebApplicationContext. Все сошлось.
PS. Читайте спецификации и ознакомьтесь с JavaDoc упомянутых в моем ответе классов.
В Spring вообще любят подробно описывать все "магические" механизмы в документации
ключевых абстрактных классов и интерфейсов.
Ответ 2
Точка входа в виде метода main есть в любом Java приложении. Просто в случае web
приложений исполняемой Java программой является контейнер сервлетов / сервер приложений
(вот, например, main-метод Tomcat). WEB приложение разворачивается (deploy) внутри
контейнера сервлетов. Например, подумайте, если вам требуется задать приложению какие-то
аргументы JVM, кому вы их будете передавать? Серверу приложений. Потому что именно
он и есть исполняемое приложение, а написанная вами логика существует внутри него и
подчиняется спецификации JEE.
До версии JEE 6, когда было введено Servlet 3.0 API, эта спецификация требовала помещать
конфигурацию вашего приложения в deployment descriptor - web.xml. Начиная с Servlet
3.0 API, этот файл не является обязательным, вместо него приложение может использовать
интерфейс ServletContainerInitializer. Когда вы разворачиваете web-приложение, контейнер
сервлетов сканирует classpath этого приложения на предмет наличия имплементации указанного
интерфейса, а когда находит, то выполняет метод onStartup(), в котором должна выполняться
инициализация приложения.
Поскольку Spring Web построен на сервлетах, все написанное выше относится к нему
самым прямым образом. Конфиг на аннотациях в Spring доступен с версии Servlet 3.0+
API. Реализация интерфейса ServletContainerInitializer находится в модуле spring-web,
вы его получаете сразу как подключаете соответствующую зависимость в maven или gradle.
Взгляните что делает этот код. Выдержка из документации:
Interface which allows a library/runtime to be notified of a web
application's startup phase and perform any required programmatic
registration of servlets, filters, and listeners in response to it.
Implementations of this interface may be annotated with HandlesTypes,
in order to receive (at their onStartup(java.util.Set>,
javax.servlet.ServletContext) method) the Set of application classes
that implement, extend, or have been annotated with the class types
specified by the annotation
Он получает все классы, которые помечены аннотацией WebApplicationInitializer и инициализирует
их. AbstractAnnotationConfigDispatcherServletInitializer, если вы посмотрите его иерархию,
как раз является таким классом.
Дальше, извините, я просто процитирую ответ в параллеьного сайта, где то же самое
расписано пошагово:
Servlet context listener (web.xml) approach
A web application WAR is being deployed by user.
Servlet container (Tomcat) reads web.xml.
Servlet context listener ContextLoaderListener is being instantiated (if defined
as inside the web.xml) by servlet container.
ContextLoaderListener creates new WebApplicationContext with application context
XML configuration.
Your ROOT context beans are registered and instantiated by BeanFactory inside the
application context.
DispatcherServlet is being instantiated by servlet container.
DispatcherServlet creates its own WebApplicationContext (WEB-INF/{servletName}-servlet.xml
by default) with the ROOT context as its parent.
Your servlet beans are registered and instantiated by BeanFactory inside the application
context.
DispatcherServlet registers some default beans in case you did not provide them yourself.
Servlet container initializer (non web.xml) approach
This one is possible with Servlet 3 features.
A web application WAR is being deployed by user.
Servlet container searches for classes implementing ServletContainerInitializer via
Java's ServiceLoader.
Spring's SpringServletContainerInitializer is found and instantiated by servlet container.
Spring's initializer reads web application's class-path and searches for WebApplicationInitializer
implementations.
Your WebApplicationInitializer is found (btw. check its JavaDoc!!!) and instantiated
by SpringServletContainerInitializer.
Your WebApplicationInitializer creates new ROOT WebApplicationContext with XML or
@Configuration based configuration.
Your WebApplicationInitializer creates new servlet WebApplicationContext with XML
or @Configuration based configuration.
Your WebApplicationInitializer creates and registers new DispatcherServlet with the
context from previous step.
Servlet container finishes the web application initialization and instantiates components
which were registered by their class in previous steps (none in my example).
Т.о. чтобы запустить приложение на Spring при помощи аннотаций, нужно имплементировать
интерфейс WebApplicationInitializer - можно как напрямую, так и унаследоваться от одного
из абстрактных классов, которые есть в поставке, и передать туда конфигурационный файл
(в вашем примере SpringConfiguration). Дальше Spring получает из него аннтотации @EnableWebMvc,
@ComponentScan (это самые основные) и вытягивает остальную конфигурацию.
Все вместе это образует ApplicationContext (несмотря на то что написано в единственном
числе, их может быть несколько) - описание среды окружения приложения, который как
раз и предоставляет возможность обращаться в бинам, переменным и прочим ресурсам приложения
с помощью аннотаций.
Ответ 3
Точкой входа и есть сам web.xml к которому обращается контейнер сервлетов при деплое,
которым в вашем случае является гласфиш. Когда вы деплоите варку или запускаете проект
в своей среде разработки, глазфиш поднимает, все сервлеты и конфигурации из web.xml.
1) web.xml в спринге не остается пустым, просто его работу с сервлетами берет на
себя диспетчер сервлетов спринга, но в web.xml мы все равно указываем конфигурации
диспетчера.
2)Этот вопрос я несколько раз перечитал и не могу понять его суть. Какой варник и
причем здесь аннотации контроллеров и сервисов? Спринг никто запускать не должен, это
просто упрощенная версия контейнера бинов, в которой используются аннотации для быстрой
и понятной разработки. В памяти создается один бин, который с помощью аннотаций Autowired
или Inject можно инжектить не создавая новых экземпляров этого класса, а в случае нескольких
реализаций бина, можно выбрать какую именно вы хотите использовать добавив аннотацию
Qualifier(name="").
3)В вашем примере приведен, как я понял, конфигурационный файл, который так же должен
быть прописан в вашем web.xml. Если вы используете xml конфигурации, тогда они явно
указываются в веб.хмл в приблизительно таком виде:
appServlet
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
/WEB-INF/spring/servlet-context.xml
1
Если вы используете классы, тогда как глазфиш понимает, что ему надо дергать это
уже зашито в аннотациях самими разработчиками спринга и почему оно так работает, дать
ответ я не могу.
