Showing posts with label osgi. Show all posts
Showing posts with label osgi. Show all posts

Monday, 28 May 2007

liftWeb on OSGi

Bundled up lift as an OSGi bundle to test out the server-side Eclipse Equinox functionality (and throw a little Scala in there too).

It works, with a little wrapping. The Ajax chat example works fine, but the link has to be changed to /chat.html rather than /chat

All made easier by switching to Eclipse 3.3RC2, which now ships with all the plugins needed to make jetty work, including servlets and JSPs. Made harder by the Eclipse implementation dumping the web.xml in favour of extension point contributions by individual bundles. There's a reason for that, but it makes it unlikely that complex webapps will port easily, and even the simplest won't be a war-drop-in.


Tried this out on my maemo box (nokia n800 tablet), running cacao as a jvm. Much slower start up than cvm; able to run some simple web-apps. All the required bundles resolved for lift, but couldn't get any pages to load - some stacktraces with reentrant lock failures to investigate.

To try this out, add the following files to the liftweb war, repackaging it as an OSGi bundle:

plugin.xml



<plugin>
<extension point="org.eclipse.equinox.http.registry.resources">
<resource alias="/images" base-name="/images"
httpcontextId="liftweb" />
<resource alias="/scripts" base-name="/scripts"
httpcontextId="liftweb" />
<resource alias="/style" base-name="/style"
httpcontextId="liftweb" />
<resource alias="/templates-hidden"
base-name="/templates-hidden" httpcontextId="liftweb" />
<resource alias="/" base-name="/" httpcontextId="liftweb" />

</extension>
<extension point="org.eclipse.equinox.http.registry.servlets">
<servlet alias="/*.html" class="net.liftweb.http.Servlet:/"
httpcontextId="liftweb">
<init-param name="debug" value="1"></init-param>
<init-param name="listings" value="true"></init-param>
</servlet>
</extension>
<extension point="org.eclipse.equinox.http.registry.httpcontexts">
<httpcontext id="liftweb">
<resource-mapping path="/"></resource-mapping>
</httpcontext>

</extension>
</plugin>





MANIFEST.MF



Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Liftweb Plug-in
Bundle-SymbolicName: liftweb;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-ClassPath: .,
WEB-INF/classes/,
WEB-INF/lib/commons-codec-1.3.jar,
WEB-INF/lib/derby-10.2.2.0.jar,
WEB-INF/lib/lift-core-0.1.0.jar,
WEB-INF/lib/scala-actors-2.3.3.jar,
WEB-INF/lib/scala-compiler-2.3.3.jar,
WEB-INF/lib/scala-library-2.3.3.jar
Export-Package: net.liftweb.http
Require-Bundle: org.eclipse.equinox.http.registry
Import-Package: javax.servlet;version="2.4.0",
javax.servlet.http;version="2.4.0",
org.osgi.service.http;version="1.2.0"

Saturday, 12 May 2007

osgi on n800

Spotted a post yesterday on running OSGi on maemo. Up and running with a servlet container inside OSGi (the Eclipse Equinox implementation) on my Nokia N800.

Missing the bluetooth GPS device to try the Google GPS Mashup on OSGi

After setting up an OSGi console running over ssh to my n800, I tried directly installing bundles from remote http sites (if you've only ever used Eclipse and it's update manager you're probably not aware of the framework's ability to directly install and uninstall bundles from any http site at the console command line).

However, it's a long way from rubygems or cpan - there are a few repositories around, but no more than web sites hosting files. It's hit and miss finding a bundle that meets the java execution environment of Java CDC, or doesn't have the wrong sort of native code, and although the bundles themselves know their dependencies, there's nothing to connect those logical dependencies with their physical resolution. OSGi RFC-0112 is supposed to solve that problem.