Run Vaadin Server in Jetty Instance on Android Tablet?


The requirement:

A group of people in the field temporarily have no connection to the corporate servers and no connection to the internet.

However, they do have a P2P wireless network between their mobile devices.

They would like to instantiate an instance of Vaadin running on one of their Android tablets (a Xoom).

That device would function as the server.

The overall workload would be very light - - - the Vaadin app would only process periodic small transactions with very little overlap.


The question:

Assuming all the Vaadin .class files are merged into and Android .dex file - - - would Vaadin run OK within an instance of i-Jetty (or a self-instantiated Jetty instance)?

Has anyone tried this before? What problems might be encountered?

Thanks,

Steve G.

If it works as they describe, there is no reason that it wouldn’t work… A servlet server is just a Java application with nothing much special other than listening to ports. Once that part is done (which is what i-Jetty did), the rest should just work…

Well, I did try this. That is, I packaged up Vaadin exactly according to what the Android OS wants (all class files packaged as a .dex file). I then tried to run the simple “hello world” Vaadin app from within an i-Jetty instance running on my Motorola Xoom.

The result:

Vaadin reports a generic “System Error” with no further detail. The good news, I suppose, is that Vaadin is running at some level . . . because Vaadin reports the error.

But I am trying to get more detail on the error message. Nothing appears in the Android system log (so far as I can tell).

Does anyone have any idea how to debug this type of problem?

I suppose I will take the plunge and subscribe . . . hoping someone will then be more likely to respond.

I did succeed in getting the vaadin “Hello World” application to run within an instance of i-Jetty running on a Motorola Xoom (Android 3.2.4).

I have not yet tested any other vaadin UI components, and I have not tested performance.

But so far it does look encouraging.

Again, my goal is limited: To run a temporary copy of vaadin from a tablet PC so that a group of users who are “out in the field” and disconnected from all primary networks (including the internet) will still be able run a simple application. The leader of the group will establish a temporary on-the-fly P2P wireless network.

In order to make this work, all of the .class files in your application (as well as those embedded in all dependency jars) must be repackage as a single zipped dex file.

.dex is a “compiled Android application code file” which is what the Dalvik virtual machine reads and executes.

You can create your dex file like this:

(yes you could automate this with Ant or Maven)

  1. Create a temporary folder named “dex-build” anywhere you like.
  2. Copy your app’s primary classes from WEB-INF/classes into “dex-build”.
    [list]
  3. Make sure to preserve the same namespace-ordered folder structure found in WEB-INF/classes.
[*]

Unzip all of your app’s dependency jars into a temporary folder.
[list]

	[*]

A jar file is simply a zip file with a .jar extension.
[*]
At the very least, this means:
[list=1]

		[*]

The vaadin .jar file, and
[*]
The gwt-user .jar file.

[/list]

[/list]
[*]
Copy all of the dependency classes from those jar files into “dex-build”.
[list]

	[*]

Make sure to preserve the same namespace-ordered folder structure found in those .jar files.
[]
Basically you are just consolidating all of the class files needed by your app into the “dex-build” folder.
[
]
If done correctly, the top-level folder within “dex-build” will be the “com” folder.
[*]
You might also have other top-level folders such as “org” or whatever . . . depending on what your app’s dependencies are.

[/list]
[]
Open a command prompt to one folder level higher than the “dex-build” folder.
[
]
Execute a command something like this:


java -jar “{path to platform tools}/lib/dx.jar” --dex --core-library --verbose --output=./classes.dex --positions=lines ./dex-build/


[list]

	[*]

Result: All class files within “dex-build” are recursively consolidated into a single .dex file named “classes.dex”.
[list]

		[*]

Any non-class files within “dex-build” are automatically ignored - that is OK.
[*]
Note: platform-tools is a sub-folder located wherever you installed the Android SDK.

[/list]

[/list]
[*]
Next execute a command something like this:


jar cvf ./classes.zip ./classes.dex


[list]

	[*]

Result: “classes.dex” is zipped into a file called “classes.zip”.
[list]

		[*]

At this point you no longer need “classes.dex”.

[/list]

[/list]
[*]
Create the
war
file for your project.
[list]

	[*]

This will vary based on your IDE. However, in Eclipse it is just File->Export->war.

[/list]
[*]
Unzip your
war
file to a temporary directory.
[list]

	[*]

A war file is just a zip file renamed with a .war extension.

[/list]
[*]
In the tmp war folder, delete everything within WEB-INF/classes and WEB-INF/lib.
[list]

[*]

No need to panic. All of that stuff should at this point exist in the classes.zip file you created earlier.
[*]
Just for clarity: Don’t delete anything within the folder structure of your project’s source code.
[list]

	[*]

Everything we are doing here is related to the
war
file you just created and that should have been created outside your source code folder structure.

[/list]

[/list]
[]
Copy the earlier-created “classes.zip” folder to the WEB-INF/lib folder inside the tmp war folder.
[
]
Re-zip your tmp war folder to “MyPublishableProject.zip” or whatever.
[]
Rename “MyPublishableProject.zip” to “MyPublishableProject.war”.
[
]
Upload “MyPublishableProject.war” to a delivery server somewhere.
[list]

	[*]


war
files are installed into i-Jetty by downloading from a delivery server.

[/list]
[*]
On your Android test device, install “MyPublishableProject.war” to i-Jetty.
[list]

	[*]

Detailed instructions can be found on the i-Jetty web site.

[/list]

[/list]
Well, that’s it. It worked for me.

I freely admit that all of the above can be streamlined and automated by means of Maven or Ant.

Good luck.

That sounds very interesting!

Please keep us posted on the progress for the real application. If you manage to build off-line database functionality, synchronize data base with the online one and maybe even use TouchKit components for the application, this would be a game-changer for the largest “impossible to do with Vaadin” use-case.

Hi,

I made a quick test but didn’t quite get it working. It’s a bit difficult to analyze as i-jetty doesn’t seem to write a log of any kind. I get two possible results, either 1) the Vaadin application starts and I get an “Internal Error” from the first UIDL request, 2) some “Servlet not Initialized” error from the server.

That step is actually missing from your instructions - you only instructed to put the classes.dex into the classes.zip. So I’m assuming that the non-class-file content in the original WEB-INF/classes and in the jars should be put in the zip. Well at least it seems to load the theme and stuff when I do so.

So, I’m having:

  Length      Date    Time    Name
---------  ---------- -----   ----
        0  2012-02-13 01:56   META-INF/
      120  2012-02-13 01:56   META-INF/MANIFEST.MF
        0  2012-02-11 20:16   WEB-INF/
        0  2012-02-13 01:56   WEB-INF/lib/
  2802045  2012-02-13 01:56   WEB-INF/lib/classes.zip
     1323  2012-02-11 20:16   WEB-INF/web.xml
---------                     -------
  2803488                     6 files

Another question is the gwt-user.jar, why woud it be needed? It’s not needed in regular Vaadin WARs so why would it be needed in this case? If I include it, I get the “Servlet not Initialized” error.

I know, this looks like a necroposting, but…
https://vaadin.com/forum/#!/thread/12302658