RAP/FAQ

This FAQ is still developing. Please also scan the RAP newsgroup archives for answers.

Writing RAP Applications

How to create a fullscreen application

• use the style-bit SWT.NO_TRIM before creating the Shell. This will remove the title-bar, the minimize/maximize/close buttons and the ability for manually resizing the window.
• overwrite the WorkbenchWindowAdvisor.postWindowCreate() method. Here we set the state of the Shell to maximized.
• optional: depending on the requirements and complexity of our application it may be desirable to hide the menu bar by calling getWindowConfigurer().setShowMenuBar( false ). This is usually a good choice for small applications where the menu bar may not be needed.

public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
 
  // ...
 
 public void preWindowOpen() {
   // ...
   getWindowConfigurer().setShellStyle( SWT.NO_TRIM );
   getWindowConfigurer().setShowMenuBar( false );
 }
 
 public void postWindowCreate() {
   Shell shell = getWindowConfigurer().getWindow().getShell();
   shell.setMaximized( true );
 }
}

Take a look [1] for a more detailed discussion of the topic.

How do I add an applet / flash / an existing Javascript libary

• A very simplistic approach is to create a html page (or a servlet) containing your applet / flash / JS. You can simply use the browser widget to load that page within your application.

• A tighter integration can be achieved by developing a custom widget as explained here (integrating GMap): custom widget tutorial

Deployment

Problems using Import-Package header

Since RAP 1.1 the workbench introduced a concept of so-called "split packages". This is a way of OSGi to have virtual packages which are physically splitted across several bundles. See this post and the OSGi 4.1 specification (§3.13.3) for more informations about split packages.

A common problem with them is that a split-package is only resolved when there is at least one additional split part available during runtime. As the RAP infrastrcuture only contains the workbench bundle at the moment this constrain is not met. In RCP world you often have the org.eclipse.ui.ide bundle available which contributes to these split packages and let Equinox resolve the constrains.

In order to work around this problem you are able to import only a certain part of the package (the part of the workbench in our example). You just need to extend your Import-Package declaration with the split attribute as shown in the following MANIFEST.MF fragment:

Manifest-Version: 1.0
...
Import-Package: org.eclipse.ui; ui.workbench="split",
org.eclipse.ui.part; ui.workbench="split"

The ui.workbench="split" directive tells Equinox to use only the "ui.workbench" part of this split package.

Exported .war does not work

My application is working at development time, but when I export it the web application does not work. Check the following:

• check your build.properties
  • are you exporting the plugin.xml
  • are all libraries you are using in the plugin.jars
  • TIP: As pde build sometimes swallows error messages try exporting your feature with "Deployable feature" export, this may turn up error messages
• enable the osgi console by adding this init-param to the web.xml:

<init-param>
  <param-name>commandline</param-name>
  <param-value>-console</param-value>			
</init-param>

• • you may want to add a port after -console in unix environments, you can then telnet to the osgi console
  • type ss in the console and see if all bundles are started. If not try starting them with "start <bundle-id>"
  • the stack traces may hint to what is missing
• start with a working example: rapdemo.war and integrate your plugins

How do I make remote calls to EJB's deployed on Jboss 4.x AS

This is not a solution for calling local interface EJB's (I wasn't able to do it :( ), neither for EJB3 specification (didn't tried yet)

Nevertheless is more useful to make remote calls as the RAP application and the JBoss AS could be on separate machines (or will be sometime in the application life-cycle)

• prepare a jar with EJB's interfaces which you are about to call from RAP (I think here you may use it wrapped as a bundle if you want to separate it from your application bundle)
• put the jar in the application runtime classpath or add it as a dependency plugin if you use it as a bundle
• add the following jar's from the jboss installation folder in the application runtime classpath : jboss.jar, jboss-remoting.jar, jboss-serialization.jar, jbosssx.jar, jboss-transaction.jar, jnpserver.jar

Here's an example code for calling the EJB's remote interface :

Hashtable<String, String> props = new Hashtable<String, String>();
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
props.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
props.put(Context.PROVIDER_URL, "jnp://localhost:1099"); //here you put your JBoss AS server's address
Context ctx = null;
try {
	ctx = new InitialContext(props);
} catch (NamingException e) {
	throw new RuntimeException("fail to get initial context", e);
}
Object obj = null;
try {
	obj = ctx.lookup("Test"); //The jndi ejbs name is Test
} catch (NamingException e) {
	throw new RuntimeException("could not obtain test home interface", e);
}
TestHome home = (TestHome) PortableRemoteObject.narrow(obj, TestHome.class);
try {
	testService = home.create();
} catch (CreateException e) {
	throw new RuntimeException("could not create test remote interface", e);			
} catch (RemoteException e) {
	throw new RuntimeException("remote exception when creating test remote interface", e);
}
try {
	testService.callSomeBusinessMethod(...);
} catch (RemoteException e) {
	throw new RuntimeException("remote exception when calling business method", e);
}

How do I use a RWT standalone application in Tomcat

To use the RWT standalone application in Tomcat follow the steps below:

• Create a new Java project.
• In the project create the folders:
  • "WEB-INF"
  • "WEB-INF\lib"
  • "WEB-INF\classes"
  • "WEB-INF\conf"
• In "WEB-INF" create a file "web.xml":

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
  version="2.4">
 
  <display-name>Welcome to Tomcat</display-name>
  <description>Welcome to Tomcat</description>
 
  <context-param>
    <param-name>org.eclipse.rwt.entryPoints</param-name>
    <param-value>org.eclipse.rap.helloworld.HelloWorld</param-value>
  </context-param>
 
  <listener>
    <listener-class>
      org.eclipse.rwt.internal.engine.RWTServletContextListener
    </listener-class>
  </listener>
 
  <servlet>
    <servlet-name>rapServlet</servlet-name>
    <servlet-class>
      org.eclipse.rwt.internal.engine.RWTDelegate
    </servlet-class>
  </servlet>
 
  <servlet-mapping>
    <servlet-name>rapServlet</servlet-name>
    <url-pattern>/main</url-pattern>
  </servlet-mapping>
</web-app>

• You can use different features (branding + theming), that normally are done with extension points by specifying some variables.

This is optional:

<context-param>
  <param-name>org.eclipse.rwt.themes</param-name>
  <param-value>useradmin#theme/theme.properties</param-value>
</context-param>
 
<context-param>
  <param-name>org.eclipse.rwt.brandings</param-name>
  <param-value>rap.RAPUseradminBranding</param-value>
</context-param>

• In "WEB-INF\conf" create a file "w4t.xml":

<?xml version="1.0" encoding="UTF-8"?>
<w4t:application xmlns:w4t="http://w4toolkit.com/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://w4toolkit.com/ w4t.xsd ">
  <initialisation>
    <lifecycle>
      org.eclipse.rwt.internal.lifecycle.RWTLifeCycle
    </lifecycle>
  </initialisation>
</w4t:application>

• Copy the folloing jars from RAP in "WEB-INF\lib":
  • org.eclipse.core.commands
  • org.eclipse.equinox.common
  • org.eclipse.rap.jface
  • org.eclipse.rap.rwt
• Add these jars to the project build path as external jars.
• Change the project output directory to "WEB-INF\classes".
• Use a normal implementation of IEntryPoint.createUI - HelloWorld.java:

package org.eclipse.rap.helloworld;
 
import org.eclipse.rwt.lifecycle.IEntryPoint;
import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;
 
public class HelloWorld implements IEntryPoint {
 
  public int createUI() {       
    Display display = new Display();
    Shell shell = new Shell(display);
    shell.setLayout(new GridLayout());
 
    Label label = new Label ( shell, SWT.NONE );
    label.setText( "Hello RAP World" );
    label.setSize( 80, 20 );
 
    shell.setSize(500, 400);        
    shell.open();
    while (!shell.isDisposed()) {
      if (!display.readAndDispatch())
        display.sleep();
    }
    display.dispose();      
 
    return 0;
  }
}

• ZIP the the "WEB-INF" directory (including the directory) as "RWT_Standalone.war".
• Deploy the "RWT_Standalone.war" in Tomcat.
• Start the standalone RWT application from:

http://<host>:<port>/RWT_Standalone/main

Theming

Why doesn't RAP simply use CSS for styling, such as e.g. GWT?

In GWT for example, every widget has a configurable style name that is rendered as class attribute. Styling is done by adding a CSS file to the target HTML document. Although this is a simple technique, it does not work out for RAP for a number of reasons:

1. One of the main objectives of RAP is to prevent vendor lock-in by allowing for exchangeable client implementations. Although our current client-side technique is based on JavaScript, there are completely different technologies out there that might be interesting candidates for RAP clients (GWT, Flex, Silverlight ...). Not all of those technologies can necessarily deal with CSS.

2. In RAP, all layouts are computed on the server side, thus the server needs to know about any variable dimensions like paddings and borders on the server. This is not possible if a style sheet is applied only on the client side.

3. Due to browser bugs and differences, writing cross-browser CSS code is a complex task. Client technologies may work around those browser issues. In fact, the qooxdoo library does so.