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.

n800 and eclipse remote system explorer

Eclipse Target Management Project have an set of plugins called Remote System Explorer. Integrates ftp, sftp, ssh into Eclipse - they also have their own agent to run on a *nix box as an alternative (it can remotely explore tar files for example)

I've set this up now to explore my shuttle pc (winxp), remote hosting account, and just added the n800. With openssh already installed on the tablet, getting connected is straightforward.

here's the recipe:


  1. Make sure you're installed openssh for maemo (you'll have had to have accepted the red pill for this to install)

  2. Install Eclipse (I've used 3.3 M7)

  3. Use the Update Manager to select Remote System Explorer from the Remote Access and Device Development category under Europa Discovery Site

  4. Switch perspective to Remote System Explorer

  5. Use the new connection icon on the Remote Systems view or from the File | New wizard

  6. Choose Linux, add the basic connection details, and on all the subsequent pages of the wizard choose ssh over datastore

  7. You should now be able to click on sftp files to browse the file system, shell processes to view (and kill) processes, and ssh shells to connect in

  8. (default root password for maemo is rootme)

exploring



content assist


The shell has Eclipse style content assist (ctrl-space) doing the traditional bash job of the tab key, although this is pretty slow over ssh.

remote file system





New in the latest builds of RSE is integration with EFS, which is like fuse.sourceforge.net">FUSE for Eclipse. You can now mount a remote file system via ssh, ftp or datastore and access it inside any Eclipse project. (Go to FusePort if you want to do this the other way round, mounting a remote file system via ssh inside maemo)

To do this, use New Folder on any Eclipse project, choose Advanced, click Link to Folder in the File System and change the File System Provider to RSE. You should now get a drop down of remote FS you've previously set up in RSE.

As you'll see from the example, the remote folder gets identified by a little shortcut decorator.

downsides


sshd on maemo seemed a little stretched by the demands, and had to be restarted several times. even over a local (everything within 2 metres) 802.11g connection, it's too slow for practical editing, although RSE does cache the directory structure to make browsing speedy.