Введение
Хотел бы поделиться своим опытом необычной интеграции этих двух фреймворков. Мне очень бы не хотелось касаться таких исключительно важных вопросов «а зачем вообще нужна JSF», оговорюсь, что я не являюсь сторонником этой технологии.
Достаточно длительный срок разрабатывалось приложение-зоопарк на Spring + Hibernate + большое количество PL/SQL файлов и пакетов Oracle. Интерфейс пользователя создавался на ExtJS 4-й и 2-й версии, местами использовался самопальный JavaScript и HTML. В общем нормальный корпоративный франкенштейн. Обстоятельства непреодолимой силы вынудили меня использовать JSF для создания некоторой части интерфейсов, таким образом, JSF должен быть интегрирован в уже существующую систему обработки запросов на базе Spring MVC. Я использовал Primefaces, но полагаю, что все для остальных реализаций применимы те же способы.
Очевидные вещи
Для начала создадим отдельный сервлет в файле web.xml.
<servlet>
<servlet-name>JSF</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>JSF</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
А в файле faces-config.xml добавим поддержку Spring, чтобы в xhtml объектах можно было использовать бины, созданные спринговыми аннотациями.
<application>
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>
Оборачиваем запросы
До сих пор все достаточно просто и описано практически везде. Сейчас нам предстоить решить следующие задачи:
- обеспечить передачу get и post запросов через spring в JSF.
- добавить поддержку транзакций (у нас внутри Hibernate с lazy-коллекциями)
- создать бины с временем жизни «view»
- запретить доступ пользователю к xhtml файлам
Первые два пункта можно решить одновременно. В нашем приложении все URL по которым будут создаваться интерфейсы на JSF имеют вид "/app/*/jsf/*"
@Controller("")
@RequestMapping("/app/*/jsf")
public class JSFTestController {
@RequestMapping(value = "/*", method = {RequestMethod.GET})
@Transactional(rollbackFor = Exception.class)
public void redirectToJSF(HttpServletRequest request, HttpServletResponse response) throws Exception {
String uri = request.getRequestURI();
// зачем это нужно станет ясно позднее
RequestContextHolder.getRequestAttributes().setAttribute(JSF_REQUEST_URL, uri, RequestAttributes.SCOPE_REQUEST);
String xhtmlPath= getXHTMLPath(uri); // здесь выбираем xhml файл, подробности специфичны для приложения
// здесь много полезного кода, специфичного для приложения
request.getRequestDispatcher(xhtmlPath).forward(request, response);
}
// пригодится потом
public static String getURLFromRequest(HttpServletRequest request) {
return (String) RequestContextHolder.getRequestAttributes().getAttribute(JSF_REQUEST_URL, RequestAttributes.SCOPE_REQUEST);
}
метод getXHTMLPath возpашает путь до xhtml файла, например /resources/jsf/accounts/find_create.xhtml для доступа к файлу, который лежит в [war file]\resources\jsf\accounts\find_create.xhtml.
Этого достаточно для того, чтобы увидеть отрендеренную xhtml страницу, однако PrimeFaces богата POST запросами построения интерфейса, а они явно идут по неправильным адресам. За формирование пути POST запроса (т.е. за значение атрибута action у form) отвечает рендерер формы. Нужно изменить всего одну статическую функцию getActionStr, к несчастью ее сделали статической и придется перекрыть ту функцию, которая ее вызывает:
public class ActCorrectFormRenderer extends FormRenderer {
private static final com.sun.faces.renderkit.Attribute[] ATTRIBUTES = AttributeManager.getAttributes(AttributeManager.Key.FORMFORM);
private boolean writeStateAtEnd;
public ActCorrectFormRenderer() {
WebConfiguration webConfig = WebConfiguration.getInstance();
writeStateAtEnd = webConfig.isOptionEnabled(WebConfiguration.BooleanWebContextInitParameter.WriteStateAtFormEnd);
}
@Override
public void encodeBegin(FacesContext context, UIComponent component)
throws IOException {
rendererParamsNotNull(context, component);
if (!shouldEncode(component)) {
return;
}
ResponseWriter writer = context.getResponseWriter();
assert (writer != null);
String clientId = component.getClientId(context);
// since method and action are rendered here they are not added
// to the pass through attributes in Util class.
writer.write('\n');
writer.startElement("form", component);
writer.writeAttribute("id", clientId, "clientId");
writer.writeAttribute("name", clientId, "name");
writer.writeAttribute("method", "post", null);
writer.writeAttribute("action", getActionStr(context), null);
String styleClass =
(String) component.getAttributes().get("styleClass");
if (styleClass != null) {
writer.writeAttribute("class", styleClass, "styleClass");
}
String acceptcharset = (String)
component.getAttributes().get("acceptcharset");
if (acceptcharset != null) {
writer.writeAttribute("accept-charset", acceptcharset,
"acceptcharset");
}
RenderKitUtils.renderPassThruAttributes(context,
writer,
component,
ATTRIBUTES);
writer.writeText("\n", component, null);
// this hidden field will be checked in the decode method to
// determine if this form has been submitted.
writer.startElement("input", component);
writer.writeAttribute("type", "hidden", "type");
writer.writeAttribute("name", clientId,
"clientId");
writer.writeAttribute("value", clientId, "value");
writer.endElement("input");
writer.write('\n');
// Write out special hhidden field for partial submits
String viewId = context.getViewRoot().getViewId();
String actionURL =
context.getApplication().getViewHandler().getActionURL(context, viewId);
ExternalContext externalContext = context.getExternalContext();
String encodedActionURL = externalContext.encodeActionURL(actionURL);
String encodedPartialActionURL = externalContext.encodePartialActionURL(actionURL);
if (encodedPartialActionURL != null) {
if (!encodedPartialActionURL.equals(encodedActionURL)) {
writer.startElement("input", component);
writer.writeAttribute("type", "hidden", "type");
writer.writeAttribute("name", "javax.faces.encodedURL", null);
writer.writeAttribute("value", encodedPartialActionURL, "value");
writer.endElement("input");
writer.write('\n');
}
}
if (!writeStateAtEnd) {
context.getApplication().getViewHandler().writeState(context);
writer.write('\n');
}
}
private static String getActionStr(FacesContext context) {
return JSFTestController.getURLFromRequest(HttpUtils.getCurrentRequest());
}
}
Это неудобно, но другого варианта изменить статическую функцию ее нету. Но таким образом удалось изменить action формы и пост запросы будут идти по тому же адресу, что и get запрос, построивший view для страницы. Осталось прописать свой рендерер в файле faces-config:
<render-kit>
...
<renderer>
<component-family>org.primefaces.component</component-family>
<renderer-type>org.primefaces.component.MenuRenderer</renderer-type>
<renderer-class>com.XXXXX.ActCorrectMenuRenderer</renderer-class>
</renderer>
...
</render-kit>
В приложении при обработке GET и POST запросов используются немного разные проверки, поэтому методы разделены, но для простого примера методу redirectToJSF можно поставить аннотацию @RequestMapping(value = "/*", method = {RequestMethod.GET, RequestMethod.POST})
«view» scope
В JSF необходимы бины, которые существуют в рамках view, т.е. порождаются при каждом GET запросе и живут при POST запросах, которые происходят со страницы, порожденной этим GET запросом. Не станем изобретать велосипед, позаимствуем код для класса вот тут: forum.springsource.org/showthread.php?80595-View-scope-with-Spring
Безопасность
Приложение имело возможность работать под несколькими пользователями одновременно с одного браузера, GUID сессии добавлялся в URL, поэтому прямое обращение к xhtml файлу блокируется как не авторизованное (Форма логина была сделана без JSF), а вытащить его(или заставить JSF обработать запрос пользователя напрямую) используя запрос с GUID сессии вида:
localhost:8443/<имя приложения>/app/ea10efcb-4a2e-4eeb-aa71-24310882f7ad/jsf/accounts/find_create.xhtml
не получится, так как никакого файла [xxx.war]/app/ea10efcb-4a2e-4eeb-aa71-24310882f7ad/jsf/accounts/find_create.xhtml
Дополнительно были установлены следующие фильтры:
- "/javax.faces.resource/** " — пустой фильтр(нам не жалко, бери чего хочешь)
- /themes/** — пустой фильтр
- /**/resources/jsf/** — с проверкой авторизации
Заключение
Ну вот мы и рассмотрели основные моменты относительно безболезненного (для программы, для разработчика многие моменты были исключительно болезненны) добавления JSF в сложное приложение. За кадром остались вопросы обработки исключения при POST запросах, борьбу с хаотичными обращениями компонентов к бинам для оптимизации производительности, но это уже тема для отдельной статьи.