Интеграция RWT/RAP + Jetty + JAX-WS

При разработке RAP/RCP приложения у меня возникла проблема: как сделать кастомные error-pages и интегрировать их в embedded jetty. В интернете есть множество обучалок тому, как это сделать, если вы встраиваете Jetty в свое приложение. Но с RWT все сложнее. RWT сам занимается запуском Jetty и стартует его как managed service. При этом сам интерфейс Jetty скрыт от других бандлов и работать с ним напрямую не получится.
Я пошел немного дальше и решил расширить фнкциональность до исполнения любых сервлетов тем самым Jetty, который встроен в RWT приложение. И, самое главное интегрировать JAX-WS веб-сервисы туда же. Сочувствующим, добро пожаловать под кат.



Подраземевается, что приложение запускается из OSGi платфопмы, у меня это Equinox.

Для начала, из документации известно, что можно сделать некоторый Jetty customizer и, передав системным свойством его название, получить некоторую кастомизацию. Так и сделаем: при запуске всего приложения передадим

-Dorg.eclipse.equinox.http.jetty.customizer.class=ru.futurelink.jetty.customizer.MyJettyCustomizer

Код кастомайзера:

public class MyJettyCustomizer extends JettyCustomizer {
	@Override
	public Object customizeContext(Object context,
			Dictionary<String, ?> settings) {

		ServletContextHandler c = (ServletContextHandler) context;

		// Сервлет, раздающий файлы
		c.getServletHandler().addServletWithMapping(
			MyFileServlet.class, "/files/*");

		// Сервлет, обслуживающий веб-сервисы JAX-WS
		// import com.sun.xml.ws.transport.http.servlet.WSServlet;
		c.getServletHandler().addServletWithMapping(
			WSServlet.class, "/service/mobile");

		// Сервлет-обработчик страниц ошибок
		ErrorHandler errorHandler = new MyJettyErrorHandler();
		errorHandler.setShowStacks(true);		
		c.setErrorHandler(errorHandler);

		// Добавляем веб-сервисы JAX-WS (самое интересное внизу)
		c.getServletContext().getContextHandler().
			addEventListener(new MyServletContextListener());

		return c;	
	}
}

Тут мы делаем следующее:
1) Мапим какие-то сервлеты, по определенным урлам, теперь они там будут доступны, тут все просто.
2) Устанавливаем кастомный обработчиик для ошибочных страниц.
3) Добавляем обслуживание веб-сервисов JAX-WS — об этом подробнее в конце, это интересно ;)

Если с первым пунктом все понятно и просто — пишем сервлет, мапим его на URL и вуаля, он доступен, то второй требует примера кода обработчика, вот он:

public class MyJettyErrorHandler extends ErrorHandler {
	@Override
	protected void handleErrorPage(HttpServletRequest request,
			Writer writer, int code, String message) throws IOException {
		if (code == 404) {
			writer.write("No,no,no!!! This page does not exist!");
			return;
		}
		
		super.handleErrorPage(request, writer, code, message);
	}
}

Теперь можно обработать любой HTTP response code нужным нам способом.

Теперь самое интересное, интергируем JAX-WS в наше RWT прлиожение. Сложность тут возникает при реализации самого веб-сервиса. Нам надо сделать XML описание, которое разместить в WEB-INF/sun-jaxws.xml.

<?xml version="1.0" encoding="UTF-8"?>
<endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime" version="2.0">
	<endpoint name="ClientService" 
		implementation="ru.futurelink.mo.mobile.server.ClientService" 
		url-pattern="/service/mobile"/>
</endpoints>

Но наше приложение никак не хочет видеть этот файл описание и создавать эти самые конечные точки. А стандартное решение, которое предлагается для JAX-WS для создания конечных точек в рантайме не подходит, т. к. порождает еще один веб-сервер com.sun.net.httpserver. Надо вешать его на отдельный порт, да и вообще, как-то коряво это. Надо другое решение, которое будет использовать уже существующий Jetty для обработки запросов к веб-сервисам.

Мы уже добавили сам сервлет, который будет обрабатывать запросы к веб-сервису, теперь надо чтобы заработали конечные точки (endpoints). Однако, так, как наш проект работает в OSGi фреймворке, то файл описание, который мы только что создали JAX-WS не видит. Все дело в том, что JAX-WS не является совместимым OSGi бандлом, хотя мы его перепаковали (надеюсь это так?) в бандл из простого JAR и добавили ему манифест. Надо заставить его скушать этот файл, при этом сделать все правильно в стиле OSGi.

Весь наш кастомайзер мы упаковываем во фрагмент к хосту org.eclipse.equinox.http.jetty. Это обязательно, как известно фрагмент расширяет classpath, тем самым позволяет хосту находить и загружать какие-то кастомные части из classpath фрагмента, как из своего собственного. Мы заставим JAX-WS использовать jetty как HTTP транспорт, вместо обычного дефолтового com.sun.net.httpserver.

Далее, берем несколько классов из JAX-WS (к сожалению, архитектура этого пакета не позволяет корректно наследоваться и нам придется переопределить все), из com/sun/xml/ws/transport/http/servlet. Вот пример:

public final class WSServletContextListener {…}

Не знаю зачем они так сделали… теперь нам придется переписать кусок JAX-WS к себе во фрагмент. Переписанные файлы можно найти в github: github.com/futurelink/habrahabr

Всего нам понадобится 4 класса:
WSServletContextListener — MyServletContextListener,
ServletResourceLoader — MyServletResourceLoader,
ServletContainer — MyServletContainer,
DeploymentDescriptorParser — MyDeploymentDescriptorParser

Все это нужно нам было ради изменения одной единственной строки кода в WSServletContextListener:

static final String JAXWS_RI_RUNTIME = "/WEB-INF/sun-jaxws.xml";

заменили на:

static final String JAXWS_RI_RUNTIME = "/META-INF/sun-jaxws.xml";

Проблема в том, что теперь, с равертыванием новой версии JAX-WS, надо следить и за этим фрагментом, чтобы он нормально работал. Но другого способа интегрироваться в Jetty я не обнаружил. Если кто-то захочет пройти этот путь с начала, будет интересно почитать иное решение.