Many times, when developing JAX-RS demos, I had to solve the following issue: how to describe the demo endpoints to be run in OSGI and the same endpoints to be run in Tomcat.
Typically I'd create a Spring context file describing few JAX-RS endpoints and use it when running a demo in Tomcat. Next I'd create an equivalent Blueprint context file and run the demo in Karaf.
It works but having to duplicate the contexts in Spring and Blueprint languages is unfortunate. Granted, one can use Spring DM to run the endpoints described in Spring contexts in Karaf but OSGI developers know Spring DM is a finished line.
So we did some work first to make a CXFBlueprintServlet referencing a Blueprint context working in OSGI - the same way a CXFServlet can work with Spring contexts in OSGI with the help of Sprinjg DM.
Next, my colleague Alex suggested to have the same mechanism working in non-OSGI deployments - for the reason described above, i.e, to reuse the same context language (Blueprint) when deploying CXF endpoints to OSGI and servlet containers. As it happens Apache Aries team already did some work for supporting Blueprint in non-OSGI setups, so after doing some more work in CXF and Aries we can now have CXFBlueprintServlet loading Blueprint contexts in standalone Tomcat/Jetty too. Some work still needs to be done here, particularly ensuring such endpoints can run offline, but overall it looks promising.
The short overview is here. Note the same web.xml and Blueprint context is used in OSGI and non-OSGI setups - the only thing which changes is a single Maven Aries dependency.
Note this mechanism works for CXF JAX-RS and JAX-WS endpoints.
If you are a Blueprint fan: Enjoy!
Wednesday, October 7, 2015
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment