felix http api 2.0.2 에 기존 OSGi R4 Compendium 스펙의 HttpService 인터페이스를 확장한 ExtHttpService가 있다. 서블릿 스펙의 Filter를 register/unregister 하는 것과 서블릿 unregister하는 메소드를 추가로 정의해 놓았음. 아무래도 OSGi 스펙이 너무 오래 전에 정의되어서 그렇다.
실제 구현은 felix http base와 felix http jetty를 보면 되는데, base의 경우 URL match 하는 과정을 직접 다 구현해놨다. (Compendium 스펙에 나온대로 구현해야 될테니까..) AbstractActivator는 왜 굳이 한 계층을 더 나눴는지 잘 모르겠고.. 아무튼 AbstractHttpActivator에서 DispatcherServlet과 HttpServiceController를 생성한다는 점을 기억해야 한다.
HttpServiceController는 register() 메소드에서 HttpService를 서비스하는 HttpServiceFactory를 서비스 레지스트리에 등록한다. HttpServiceFactory는 OSGi ServiceFactory 인터페이스를 구현해서 HttpServiceImpl 생명주기를 관리한다. (unget 할 때 그동안 HttpService에 등록된 서비스와 필터에 대한 모든 참조를 해제함) HttpServiceImpl에서 실제 ExtHttpService 인터페이스를 모두 구현한다.
HttpServiceController의 register()가 호출되는 시점은 DispatcherServlet이 init() 되는 시점이다. felix http jetty에서 JettyService를 시작하게 되면 Jetty의 Context에 DispatcherServlet이 주입되고 서버가 시작되면서 DispatcherServlet의 init()이 호출되게 된다. 즉, Jetty 웹 서버가 시작됨과 동시에 새로운 HttpService가 OSGi 서비스 레지스트리에 등록되는 것이다.
felix http jetty의 경우 https 기동에 필요한 인증서 로딩 관련 필수 정보를 제외하고는 설정할 수 있는 여지가 별로 없고 단일 웹 서버만 동작한다는 문제가 있다. (즉 여러 개의 웹 서버가 서로 다른 포트를 열고 동작하는 기능은 지원하지 않는다.)
가급적 OSGi 스펙을 존중하면서 kraken-http에서 기존에 사용하는 기능을 보존하려고 고민 중.. 빨리 이 부분을 마무리 지어야 예전에 만들었던 xmlrpc 프로토콜도 서블릿으로 연결하고 기존 스톰 센터 백엔드를 크라켄으로 이관할 수 있는데 흠..
그 외 felix http service { bridge | bundle | proxy | whiteboard } 는 아직 분석 안 됨. bundle은 jetty, bridge, whiteboard의 BundleActivator를 몰아서 start / stop 시키는 CombindActivator 밖에 없고.. whiteboard를 http로 연동할 수 있게 확장한 것으로 보인다.
실제 구현은 felix http base와 felix http jetty를 보면 되는데, base의 경우 URL match 하는 과정을 직접 다 구현해놨다. (Compendium 스펙에 나온대로 구현해야 될테니까..) AbstractActivator는 왜 굳이 한 계층을 더 나눴는지 잘 모르겠고.. 아무튼 AbstractHttpActivator에서 DispatcherServlet과 HttpServiceController를 생성한다는 점을 기억해야 한다.
HttpServiceController는 register() 메소드에서 HttpService를 서비스하는 HttpServiceFactory를 서비스 레지스트리에 등록한다. HttpServiceFactory는 OSGi ServiceFactory 인터페이스를 구현해서 HttpServiceImpl 생명주기를 관리한다. (unget 할 때 그동안 HttpService에 등록된 서비스와 필터에 대한 모든 참조를 해제함) HttpServiceImpl에서 실제 ExtHttpService 인터페이스를 모두 구현한다.
HttpServiceController의 register()가 호출되는 시점은 DispatcherServlet이 init() 되는 시점이다. felix http jetty에서 JettyService를 시작하게 되면 Jetty의 Context에 DispatcherServlet이 주입되고 서버가 시작되면서 DispatcherServlet의 init()이 호출되게 된다. 즉, Jetty 웹 서버가 시작됨과 동시에 새로운 HttpService가 OSGi 서비스 레지스트리에 등록되는 것이다.
felix http jetty의 경우 https 기동에 필요한 인증서 로딩 관련 필수 정보를 제외하고는 설정할 수 있는 여지가 별로 없고 단일 웹 서버만 동작한다는 문제가 있다. (즉 여러 개의 웹 서버가 서로 다른 포트를 열고 동작하는 기능은 지원하지 않는다.)
가급적 OSGi 스펙을 존중하면서 kraken-http에서 기존에 사용하는 기능을 보존하려고 고민 중.. 빨리 이 부분을 마무리 지어야 예전에 만들었던 xmlrpc 프로토콜도 서블릿으로 연결하고 기존 스톰 센터 백엔드를 크라켄으로 이관할 수 있는데 흠..
그 외 felix http service { bridge | bundle | proxy | whiteboard } 는 아직 분석 안 됨. bundle은 jetty, bridge, whiteboard의 BundleActivator를 몰아서 start / stop 시키는 CombindActivator 밖에 없고.. whiteboard를 http로 연동할 수 있게 확장한 것으로 보인다.
