In contrast to the parameterized JUnit test, the Theories-runner will try out all possible combinations of data points against your test methods marked with the @Theory annotation.

But let’s get your hands dirty. Obviously the first thing to do is run the test with the Theories-runner and declare some data points:

@RunWith(Theories.class)
public class DistanceCalculatorTest {
 
  @DataPoint
  static public LatLng es_1 = new LatLng( 49.0060285, 8.4006111 );
  @DataPoint
  static public LatLng es_2 = new LatLng( 49.0060285, 8.4005789 );
  @DataPoint
  static public LatLng es_3 = new LatLng( 49.0060056, 8.4005611 );
...

The implementation of the distance calculator should be:

• Commutative,
• Positive semidefinite
• And fullfill the triangle equality

Which can be written down using the following three @Theory annotated test methods (which do not accept null values):

@Theory(nullsAccepted = false)
public void distanceIsCommutative(LatLng p1, LatLng p2) {
    assertThat(distanceCalculator.calculate(p1, p2), is(distanceCalculator.calculate(p2, p1)));
}
 
@Theory(nullsAccepted = false)
public void distanceIsPositiveSemidefinite(LatLng p1, LatLng p2) {
    assertThat(distanceCalculator.calculate(p1, p2), is(greaterThanOrEqualTo(0.)));
}
 
@Theory(nullsAccepted = false)
public void distanceFulfillsTriangleEquality(LatLng p1, LatLng p2, LatLng p3) {
    assertThat(distanceCalculator.calculate(p1, p2) + distanceCalculator.calculate(p2, p3), 
        is(greaterThanOrEqualTo(distanceCalculator.calculate(p1, p3) - delta)));
}

Sometimes you have to assume preconditions to test specific parts of your implementation. In the following @Theory the assumption is either p1 or p2 is null, which should lead to an IllegalArgumentException when using the calculator…

@DataPoint
public static LatLng nullPoint = null;
 
@Rule
public ExpectedException distanceCalculatorException = ExpectedException.none();
 
@Theory
public void distanceToNullNotDefined(LatLng p1, LatLng p2) throws Exception {
    assumeTrue(p1 == null || p2 == null);
    distanceCalculatorException.expect(IllegalArgumentException.class);
    distanceCalculator.calculate(p1, p2);
}

It is very simple to add more corner cases. The following snippet adds two representations of the north pole:

@DataPoint
static public LatLng north_pole_1 = new LatLng( 90, 10 );
@DataPoint
static public LatLng north_pole_2 = new LatLng( 90, 20 );

If you add a test which won’t work with the whole data points available (e.g. near the poles in this example) they can be easily filtered out by adding a more complex assumption at the beginning of the test method.

@Theory(nullsAccepted = false)
public void runningTowardsThePole(LatLng pt) {
 
    // this test does not work at the poles
    assumeThat(pt.lat, is(allOf(greaterThan(-89.), lessThan(89.))));
...
}

Just a side note. Rewriting the tests for the distance calculator in fact discovered a bug in the original implementation of the distance calculator using LatLng(-1, -1) as NIRVANA. Thanks again Hauke for teaching me this lesson.

Have fun verifying your code with theories.

The first part guides you through the setup of your Eclipse IDE and Virgo Jetty Server. The second part is a short walkthrough on how to create a Hello World Web Application Bundle (WAB) with RAP.

Feedback welcome.

[1] Developing Web Application Bundles with RAP and Virgo – http://eclipsesource.com/blogs/tutorials/developing-web-application-bundles-with-rap-and-virgo/
[2] RAP – Enabling modular business apps for desktop, browser and mobile – http://eclipse.org/rap
[3] Virgo from eclipseRT – http://eclipse.org/virgo/

Hot on the heels of the release of RAP 2.0 the bundles have been uploaded to Maven Central. Time for another coffee break with RAP and Maven.

Before you get your coffee grab the updated sample project from GitHub[1].

$ cd /tmp
$ git clone git://github.com/eclipsesource/rap-maven-examples.git

and trigger the Maven action:

$ cd rap-maven-examples/com.eclipsesource.rap.examples.maven
$ mvn jetty:run

While maven is doing it’s job downloading the new RAP jars you can either go for a coffee or have a quick look at the changes done to migrate the RAP 1.5 based example to RAP 2.

No surprise the version of RAP has been bumped to 2.0.0:

                <dependency>
                        <groupId>org.eclipse.rap</groupId>
                        <artifactId>org.eclipse.rap.rwt</artifactId>
-                       <version>1.5.0</version>
+                       <version>2.0.0</version>
                </dependency>

The Java packages have been renamed from org.eclipse.rwt to org.eclipse.rap.rwt. An organize import will update your java code easily.

-import org.eclipse.rwt.application.Application;
-import org.eclipse.rwt.application.ApplicationConfiguration;
-import org.eclipse.rwt.client.WebClient;
+import org.eclipse.rap.rwt.application.Application;
+import org.eclipse.rap.rwt.application.ApplicationConfiguration;
+import org.eclipse.rap.rwt.client.WebClient;

But do not forget about the other locations like web.xml:

        <listener>
-               <listener-class>org.eclipse.rwt.engine.RWTServletContextListener</listener-class>
+               <listener-class>org.eclipse.rap.rwt.engine.RWTServletContextListener</listener-class>
        </listener>
 
        <servlet>
                <servlet-name>rwtServlet</servlet-name>
-               <servlet-class>org.eclipse.rwt.engine.RWTServlet</servlet-class>
+               <servlet-class>org.eclipse.rap.rwt.engine.RWTServlet</servlet-class>
        </servlet>

The RAP team decided to consolidate the interface names and removed the “I” in interfaces like the IEntryPoint. The interfaces with “I” are still available, but have been marked deprecated.

-import org.eclipse.rwt.lifecycle.IEntryPoint;
+import org.eclipse.rap.rwt.application.EntryPoint;
 import org.eclipse.swt.SWT;
 import org.eclipse.swt.layout.GridLayout;
 import org.eclipse.swt.widgets.Button;
 import org.eclipse.swt.widgets.Display;
 import org.eclipse.swt.widgets.Shell;
 
-public class DemoApplication implements IEntryPoint {
+public class DemoApplication implements EntryPoint {

Please have a look at the RAP 2.0 Migration Guide[2] for more details how to migrate your own applications.

In the meantime your console should show something like:

[INFO] Scanning for projects...
...
2013-02-14 09:14:17.272:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8080
[INFO] Started Jetty Server
[INFO] Starting scanner at interval of 10 seconds.

and the RAP 2.0 standalone application should be available at http://localhost:8080/maven_example

I hope you enjoyed your still hot cup of coffee while following the steps above…

–

[1] RAP Maven examples – https://github.com/eclipsesource/rap-maven-examples
[2] RAP 2.0 Migration Guide – http://eclipse.org/rap/noteworthy/2.0/migration-guide/

The image is from http://www.flickr.com/photos/stephaniewatson/5020665036/

image from http://www.flickr.com/photos/danramarch/2875308394/

During the last few weeks we collected around 150 replies. First I thought I was looking at the results from our
poll started two years ago. The distribution is almost the same as back then.
The lion’s share will keep running their RAP applications using war deployment.

Most of the participants will run RAP on a plain Servlet Container. Followed by those who plan to deploy on an application server and only a small number target war deployment in the cloud.
There seem to be a small group of war deployment users migrating from application server deployment towards plain Servlet Container (remember numbers are very small).

About a third of the participants are planning to run RAP in a standalone Equinox and/or with a homebrewed launch script, almost the same percentage as in 2010.

The group of people planning to use OSGi containers like Virgo, Karaf or Felix gain some weight, but are still outnumbered 1:3 by those using plain Equinox.

What is holding you back using a cool Web admin console to deploy and manage artifacts? To use the excellent diagnostics features available in Virgo?

I wonder if you could assist the Virgo project that I work on by taking a few minutes to complete the Virgo Community Survey[1] (including fun quiz)

–

[1] Virgo Community Survey – http://bit.ly/ZX73GL

I’m curious to see if the landscape of RAP installations has changed over the last two years… and would like to invite you to participate in this quick poll. Thanks for your time!

How will you run your RAP application in 2013?

War deployment in a plain Servlet Container (Tomcat, Jetty)

War deployment in an application server (JBoss, Glassfish, …)

Standalone Equinox with plain OSGi HttpService

Other OSGi container (Virgo, Karaf, Felix, …)

War deployment in a cloud environment

Command Line / homebrewed launch script

View results

Powered by BooRoo.com

War deployment in a plain Servlet Container (Tomcat, Jetty)0%

War deployment in an application server (JBoss, Glassfish, …)0%

Standalone Equinox with plain OSGi HttpService0%

Other OSGi container (Virgo, Karaf, Felix, …)0%

War deployment in a cloud environment0%

Command Line / homebrewed launch script0%

Other: (Please specify)0%

Create a poll like this

We’ll publish the results of this poll here on this blog early in 2013.

Before version 2.0 M2, the RAP framework did not try to load configuration classes from the thread’s context class loader (TCCL). Therefore, it was not possible to put the RAP libraries outside of your WAR file or use WABs with unmodified RAP artifacts.

With Bug 367033[3] solved it has become very easy to develop Web Application Bundles with RAP. We’ve prepared a short tutorial[4] and a small example at GitHUB[5].

We invite you to take a look at our new tutorial, clone the example code “com.eclipsesource.rap.examples.helloworld.webbundle” and give it a try …

[1] 2.0 M2 Milestone Build – http://www.eclipse.org/downloads/download.php?file=/rt/rap/2.0/rap-2.0.0-M2-20121001-1623.zip
[2] Virgo – http://www.eclipse.org/virgo/
[3] Bug 367033 – RWTServletContextListener should use context class loader to load configurator class https://bugs.eclipse.org/bugs/show_bug.cgi?id=367033
[4] Tutorial: Developing Web Application Bundles with RAP and Virgo – http://eclipsesource.com/blogs/tutorials/developing-web…-rap-and-virgo/
[5] WAB example using RAP – https://github.com/eclipsesource/rap-virgo-examples

Well it depends…

on the content of your local Maven directory and/or your internet connection.

To make this happen you should postpone getting your coffee for now. Just go to a local temporary folder and grab the sample project from GitHub[1]

$ cd /tmp
$ git clone git://github.com/eclipsesource/rap-maven-examples.git

Change into the directory of the example and start the RAP example with the Maven-Jetty-Plugin:

$ cd rap-maven-examples/com.eclipsesource.rap.examples.maven
$ mvn jetty:run

Now it’s a perfect time to go and get some tea or coffee…

[INFO] Scanning for projects...
...
2012-09-13 09:12:07.425:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:8080
[INFO] Started Jetty Server
[INFO] Starting scanner at interval of 10 seconds.

Point your browser to http://localhost:8080/maven_example and see the RAP example in action.

If you have a fast internet connection I’m pretty positive that your coffee is still hot. So maybe there is even some time of the coffee break left to have a look at the example code…or to leave a comment.

[1] RAP Maven examples – https://github.com/eclipsesource/rap-maven-examples

Essentially, a Blueprint documents an architecture or an engineering design. Sounds promising. In addition, with the releases of Apache Aries[3] and Gemini Blueprint[4], the reference implementation for the Blueprint Container (chapter 121 of the OSGi 4.2 Compendium Specification), there are two open source implementations available.

Blueprint components are defined inside Blueprint XML resources. The location of these resource files can be specified with the Bundle-Blueprint manifest header. If the header is absent the default value: OSGI-INF/blueprint/*.xml will be used.

The sample below shows the body of a Blueprint definition:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">
 
    <!-- Declare your beans here -->
 
</blueprint>

Let’s test drive a Gemini Blueprint.

We’re going to develop two OSGi bundles. One contains an embedded database and exports a datasource as an OSGi service. The second bundle connects to the datasource provided and extends the built-in shell with basic functionality to execute simple SQL commands.

The following Blueprint Definitions describe the blueprint of the first of our bundles, a DataSourceProxy wrapping a simple DataSource:

<bean id="h2.datasource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
  <property name="driverClass" value="org.h2.Driver" />
  <property name="url" value="jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1" />
</bean>
 
<bean id="datasource.proxy" class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy">
  <argument ref="h2.datasource" />
</bean>

The dependency graph facilitates visual inspection of the blueprint.

Blueprint of bundle exporting javax.sql.DataSource

We grant access to our lazy proxy to other OSGi bundles as as an OSGi service via the standard javax.sql.DataSource interface:

<service ref="datasource.proxy" interface="javax.sql.DataSource" />

Hidden in the logs you will find an entry “Publishing service under classes [{javax.sql.DataSource}]” telling you that the definition has been successfully interpreted by the Blueprint Container.

INFO  region-dm-11                 o.e.g.b.e.i.d.startup.DependencyWaiterApplicationContextExecutor  No outstanding OSGi service dependencies, completing initialization for OsgiBundleXmlApplicationContext(bundle=com.eclipsesource.examples.virgo.blueprint, config=bundleentry://156.fwk1968988860/OSGI-INF/blueprint/beans.xml) 
INFO  region-dm-11                 o.s.beans.factory.support.DefaultListableBeanFactory              Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@6dbe7935: defining beans [driver,datasource,.org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#0,blueprintBundle,blueprintBundleContext,blueprintContainer,blueprintConverter]; root of factory hierarchy 
INFO  region-dm-11                 o.e.g.blueprint.service.exporter.support.OsgiServiceFactoryBean   Publishing service under classes [{javax.sql.DataSource}]

Consuming an OSGi service is just as easy. Instead of defining a service with a reference, a reference is defined with an Id:

<reference id="datasource" interface="javax.sql.DataSource" />

The following definition shows how to inject the DataSource into the JdbcTemplate and the JdbcTemplate into the SqlCommandProvider,

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
  <property name="dataSource" ref="datasource" />
</bean>
 
<bean id="sqlCommandProvider" class="com.eclipsesource.examples.virgo.blueprint.sql.SqlCommandProvider">
  <property name="jdbcTemplate" ref="jdbcTemplate" />
</bean>

which results in this blueprint for our second bundle.

Blueprint of the bundle importing javax.sql.DataSource

In addition to consuming an OSGi service, the second bundle contributes to the Apache Felix Gogo[5] Shell. This requires defining additional service properties as shown in the snippet below:

<service ref="sqlCommandProvider" auto-export="all-classes">
  <service-properties>
    <entry key="osgi.command.scope">
      <value>sql</value>
    </entry>
    <entry key="osgi.command.function">
      <array value-type="java.lang.String">
        <value>execute</value>
        <value>queryForInt</value>
      </array>
    </entry>
  </service-properties>
</service>

Putting it all together allows us to access the database via the OSGi console:

osgi> sql:execute CREATE TABLE TEST(ID INT PRIMARY KEY, NAME VARCHAR(255))
osgi> sql:queryForInt SELECT COUNT(*) FROM TEST
0
osgi> sql:execute INSERT INTO TEST VALUES(1, \'Hello\')                   
osgi> sql:queryForInt SELECT COUNT(*) FROM TEST        
1

Let’s document the architecture of OSGi applications!

The example code has been written using Virgo Jetty Server 3.5.0.RELEASE with Gemini Blueprint 1.0.1.M01 and is available on GitHUB.

–

[1] OSGi Alliance Specifications – http://www.osgi.org/Specifications/HomePage
[2] Spring Dynamic Modules – http://www.springsource.org/osgi/
[3] Apache Aries – http://aries.apache.org/modules/blueprint.html
[4] Gemini Blueprint – http://www.eclipse.org/gemini/blueprint/
[5] Apache Felix Gogo – http://felix.apache.org/site/apache-felix-gogo.html

Extend Virgo Kernel 3.0 to support the RAP Widget Toolkit 1.5

Setup has become easier with the use of Jetty 8.1.3 and the RAP OSGi integration. If you’re using Virgo 2.1.x and RAP 1.4 please follow the instructions How to extend the Virgo Jetty Server to support the RAP Widget Toolkit[1] and Running RAP on Virgo[2].

In the following installation we will provide a RAP runtime based on Virgo using an HttpService provided by Jetty. The runtime is built on top of a Virgo Kernel. Jetty, the HttpService and RAP are added as extensions described in plan artifacts[3]. These plans are added to the list of initial artifacts. Let’s get started:

Download Virgo Kernel 3.0.3.RELEASE from Virgo Releases[4] and install VK to a location of your choice. This location will be referenced as ${VIRGO_HOME} throughout the next steps.

The following bundles from the Jetty and Equinox project provide an OSGi HttpService:

org.eclipse.jetty.continuation_8.1.3.v20120522.jar
org.eclipse.jetty.http_8.1.3.v20120522.jar
org.eclipse.jetty.io_8.1.3.v20120522.jar
org.eclipse.jetty.security_8.1.3.v20120522.jar
org.eclipse.jetty.server_8.1.3.v20120522.jar
org.eclipse.jetty.servlet_8.1.3.v20120522.jar
org.eclipse.jetty.util_8.1.3.v20120522.jar

javax.servlet_3.0.0.v201112011016.jar
org.eclipse.equinox.http.jetty_3.0.0.v20120522-1841.jar
org.eclipse.equinox.http.servlet_1.1.300.v20120522-1841.jar

Another two bundles for the RAP widget toolkit and it’s OSGi integration.

org.eclipse.rap.rwt_1.5.0.20120612-1458.jar
org.eclipse.rap.rwt.osgi_1.5.0.20120612-1458.jar

The easiest way to get all those bundles is to download the RAP runtime. Otherwise please visit the projects download pages listed below:

• Jetty Distributions from Eclipse[5]
• Equinox Integration Build: 3.8[6]
• RAP downloads[7]

Copy all the listed bundles into ${VIRGO_HOME}/repository/ext to make them available for use in plan artifacts. To extend the core functionality of Virgo add the plan artifacts jetty-8.1.3.plan[8] and rap-1.5.0.plan[9] next to the downloaded bundles into ${VIRGO_HOME}/repository/ext.

Add the two plan artifacts describing your extensions to the list of initial artifacts to your ${VIRGO_HOME}/config/org.eclipse.virgo.kernel.userregion.properties.

# the next line must not be broken with back-slashes
initialArtifacts = repository:plan/org.eclipse.virgo.kernel.userregion.springdm,repository:plan/org.eclipse.jetty,repository:plan/org.eclipse.rap.rwt

NOTE:
On Unix systems access to the HttpService default port is restricted (<1024). The HttpService port can be easily configured by adding a line similar to

org.osgi.service.http.port=18080

to the {VIRGO_HOME}/lib/org.eclipse.virgo.kernel.launch.properties. This is described in detail in the blog post, “Extending Virgo with a HttpService.“[10]

Fire up the Virgo instance by running ${VIRGO_HOME}/bin/startup.sh with the two new extensions and look for the script that shows that the plans defining the two extensions have been started:

[2012-06-19 17:44:36.248] start-signalling-1            Started bundle 'org.eclipse.equinox.http.jetty' version '3.0.0.v20120522-1841'. 
[2012-06-19 17:44:36.249] start-signalling-1            Started plan 'org.eclipse.jetty' version '8.1.3'. 
[2012-06-19 17:44:36.361] system-artifacts              Installing plan 'org.eclipse.rap.rwt' version '1.5.0'. 
[2012-06-19 17:44:38.255] system-artifacts              Installing bundle 'org.eclipse.rap.rwt' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.324] system-artifacts              Installing bundle 'org.eclipse.rap.rwt.osgi' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.391] system-artifacts              Installed bundle 'org.eclipse.rap.rwt' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.394] system-artifacts              Installed bundle 'org.eclipse.rap.rwt.osgi' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.396] system-artifacts              Installed plan 'org.eclipse.rap.rwt' version '1.5.0'. 
[2012-06-19 17:44:38.451] system-artifacts              Starting plan 'org.eclipse.rap.rwt' version '1.5.0'. 
[2012-06-19 17:44:38.455] system-artifacts              Starting bundle 'org.eclipse.rap.rwt' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.461] start-signalling-1            Started bundle 'org.eclipse.rap.rwt' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.465] system-artifacts              Starting bundle 'org.eclipse.rap.rwt.osgi' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.629] start-signalling-1            Started bundle 'org.eclipse.rap.rwt.osgi' version '1.5.0.20120605-1606'. 
[2012-06-19 17:44:38.631] start-signalling-1            Started plan 'org.eclipse.rap.rwt' version '1.5.0'. 
[2012-06-19 17:44:38.634] sync Event Dispatcher Thread  User region ready.

Hello Virgo World

Now that the Virgo/RAP runtime is prepared it’s a good time to setup your Eclipse / Virgo tooling[11]. Then, you can follow the step by step guide to get the demo up and running on your own computer. This demo has been written using Spring Tool Suite 3.0.0.M2 with Eclipse Virgo Tools installed.

Use the Virgo Tools to create a Server definition pointing to the Virgo Kernel prepared in the section above.

Create a new OSGi bundle project with the New Bundle Project wizard as shown in the screenshot below.

Find your Server in the Server view and open the context menu to “Add and Remove…” the created bundle project or simply drag’n'drop the project onto your freshly created server definition.

A final small step and we can start programming the actual RAP demo application. Make RWT known to your bundle by adding it as a dependency. The infrastructure bundle org.eclipse.rap.rwt.osgi is not a necessary dependency. It just works in the background and will connect our application to the HttpService once we have added our ApplicationConfiguration.

Now it’s time for some Java hacking. Create a demo application,

public class DemoApplication implements IEntryPoint {
 
	@Override
	public int createUI() {
		Display display = new Display();
		Shell mainShell = new Shell(display, SWT.TITLE);
		mainShell.setText("RAP Virgo Demo");
		mainShell.setMaximized(true);
		mainShell.setLayout(new GridLayout());
 
		Button button = new Button(mainShell, SWT.PUSH);
		button.setText("Hello Virgo world!");
 
		mainShell.layout();
		mainShell.open();
		return 0;
	}
}

and a basic configuration:

public class DemoApplicationConfiguration implements ApplicationConfiguration {
 
	@Override
	public void configure(Application application) {
		Map properties = new HashMap();
		properties.put(WebClient.PAGE_TITLE, "RAP Virgo Demo");
		application.addEntryPoint("/virgo_demo", DemoApplication.class, properties );
	}
 
}

The demo application as well as the configuration should be self explanatory. We expect to see a button “Hello Virgo world!” registered at the web context path “/virgo_demo” in a browser with the title “RAP Virgo Demo.” To make this happen we simply need to register our DemoApplicationConfiguration as an OSGi service.

There are many ways to do this. In this demo we create a Spring application context to register the configuration for us.

Create a new “Spring Bean Configuration File” with:

• A configuration bean
• and an OSGi service referencing the configuration bean.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:osgi="http://www.springframework.org/schema/osgi"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd">
 
    <bean id="simpleConfiguration" class="com.eclipsesource.rap.virgo.demo.DemoApplicationConfiguration" />
 
    <osgi:service ref="simpleConfiguration" interface="org.eclipse.rwt.application.ApplicationConfiguration" />
</beans>

If your server is already running, saving this file will automatically trigger a redeployment of the demo bundle. The  org.eclipse.rap.rwt.osgi bundle will do the necessary steps and register the demo application at the HttpService that is already running. You should be able to observe a successful deployment in the Console view:

Check the result at localhost:18080/virgo_demo … Congratulations! You successfully deployed your first RAP application on Virgo!

If you are curious enough, extend your RWT extension with Tabris[12] and enjoy your demo app on mobile devices without changing a single line of code…

Running the demo on an Android device without changing a line of code

Install two more bundles in your Virgo server and replace your RAP extension plan with the following Tabris variant:

<?xml version="1.0" encoding="UTF-8"?>
<plan name="com.eclipsesource.tabris" version="0.6.0" scoped="false" atomic="true"
        xmlns="http://www.eclipse.org/virgo/schema/plan"
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:schemaLocation="
		        http://www.eclipse.org/virgo/schema/plan
		        http://www.eclipse.org/virgo/schema/plan/eclipse-virgo-plan.xsd">
 
	<artifact type="bundle" name="org.json" version="[1, 2)" />
	<artifact type="bundle" name="com.eclipsesource.tabris" version="[0.6, 1)" />
 
	<artifact type="bundle" name="org.eclipse.rap.rwt" version="[1.5, 2)" />
	<artifact type="bundle" name="org.eclipse.rap.rwt.osgi" version="[1.5, 2)" />
</plan>

Do not forget to update the VK configuration and replace the initial artifact org.eclipse.rap.rwt with com.eclipsesource.tabris.

Restart your server to pick up the Tabris extension instead of plain RAP, then fire up your Tabris profile[13] and you’ll be able to see the Android version of the demo application.

Get the source of the rap-virgo-examples and enjoy developing RAP applications for Virgo.

–

[1] How to extend the Virgo Jetty Server to support the RAP Widget Toolkit
[2] http://eclipsesource.com/blogs/2010/10/28/running-rap-on-virgo/
[3] http://www.eclipse.org/virgo/documentation/virgo-documentation-3.0.0.x/docs/virgo-programmer-guide/html/ch04s03.html
[4] Virgo Releases – http://www.eclipse.org/virgo/download/
[5] Jetty Distributions from Eclipse – http://www.eclipse.org/jetty/downloads.php
[6] Equinox Integration Build: 3.8 – http://download.eclipse.org/equinox/drops/R-3.8-201206081400/index.php
[7] Eclipse RAP downloads – http://eclipse.org/rap/downloads/
[8] Jetty 8.1.3 plan artefact- http://download.eclipsesource.com/~fwaibel/virgo/jetty-8.1.3.plan
[9] RAP 1.5 plan artefact – http://download.eclipsesource.com/~fwaibel/virgo/rap-1.5.0.plan
[10] Extending Virgo with a HttpService – http://codewax.org/osgi/extending-virgo-with-a-httpservice/
[11] Virgo/Tooling http://wiki.eclipse.org/Virgo/Tooling
[12] Tabris – http://developer.eclipsesource.com/tabris/
[13] Tabris profile – https://yoxos.eclipsesource.com/userdata/profile/9b581113715eee8f5ac61b12ec08dd1d

Basically I followed the instructions available at the Jetty Wiki page Session Clustering Using a Database [1].

There are two Jetty configuration files involved:

• /etc/jetty.xml defining a JDBCSessionIdManager
• /WEB-INF/jetty-web.xml defining a JDBCSessionManager

The main jetty.xml resides in the folder etc of the jetty.home.bundle which itself is a fragment of org.eclipse.jetty.osgi.boot. The jetty.osgi.boot bundle is provided by the Jetty team and is responsible for bootstrapping Jetty in an OSGi environment.

The main configuration file contains the JDBCSessionIdManager definition using a H2 database:

 <Set name="sessionIdManager">
  <New id="jdbcidmgr" class="org.eclipse.jetty.server.session.JDBCSessionIdManager">
    <Arg>
      <Ref id="Server" />
    </Arg>
    <Set name="workerName">
      <SystemProperty name="worker.name" default="primary" />
    </Set>
    <Call name="setDriverInfo">
      <Arg>org.h2.Driver</Arg>
      <Arg>jdbc:h2:tcp://localhost:9101/sessions</Arg>
    </Call>
    <Set name="scavengeInterval">60</Set>
  </New>
</Set>
<Call name="setAttribute">
  <Arg>jdbcIdMgr</Arg>
  <Arg>
    <Ref id="jdbcidmgr" />
  </Arg>
</Call>

Note: To reuse the configuration in multiple cluster nodes I use a SystemProperty tag to give every node a unique “worker.name”. The database configuration is hardwired to a local H2 database.

With additional system properties I can tell the Jetty bootstrapper where to look for the global Jetty configuration and which port the Jetty instance should bind to:

-Dworker.name=primary
-Djetty.port=18081
-Djetty.home.bundle=com.eclipsesource.cluster.jetty.home.bundle

To enable the Jetty server to load the H2 database drivers I added a dynamic import directive via the fragment org.eclipse.jetty.serverdynamic.import:

Fragment-Host: org.eclipse.jetty.server;bundle-version="7.4.2"
DynamicImport-Package: *

The web application specific configuration /WEB-INF/jetty-web.xml is located in the web bundle, com.eclipsesource.cluster.jetty.demo.webbundle. This configuration file contains the JDBCSessionManager definition.

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Get name="server">
    <Get id="jdbcIdMgr" name="sessionIdManager" />
  </Get>
  <Set name="sessionHandler">
    <New class="org.eclipse.jetty.server.session.SessionHandler">
      <Arg>
        <New class="org.eclipse.jetty.server.session.JDBCSessionManager">
          <Set name="idManager">
            <Ref id="jdbcIdMgr" />
          </Set>
        </New>
      </Arg>
    </New>
  </Set>
</Configure>

Note: “jdbcIdMgr” is a Reference to the jetty.xml from jetty.home.bundle.

If you want to try it out yourself, the code is available at GitHUB [2].

Note: The bundle com.eclipsesource.cluster.h2 contains an Eclipse launch configuration to start a local H2 database which is needed to run the example.

[1] http://wiki.eclipse.org/Jetty/Feature/Session_Clustering_Using_a_Database
[2] https://github.com/eclipsesource/com.eclipsesource.cluster