This project is just a proof of concept and therefore as dirty as it is. It's here only for the use, to get an idea how much effort it will take to bring RAP and JSR356 together. The main driver for the idea is to decrease network latency to make RAP applications behave smooth even on a network with a perceptible round trip time ( proxy, firewall, ssl-handshake and so on ).
| directory | content |
|---|---|
cnf/ |
bnd workspace |
org.eclipse.jetty.osgi.httpservice.websocket/ |
replacement for org.eclipse.jetty.osgi.httpservice to enable jsr356 websockets |
org.eclipse.rap.rwt.osgi.websocket/ |
main project to wrap the client-server communication within a websocket |
org.eclipse.emf.ecp.makeithappen.application.sample.rap |
EMF Forms RAP example makeithappen |
org.eclipse.emf.ecp.makeithappen.application.sample.rap.e4 |
contributes a EMF Forms Part to RAP E4 Demo |
Run the following command from the root of the Git repository (at least JDK-8 required):
gradlew build run.rap-controls-demo
or
gradlew build run.rap-examples-demo
After the application is built and started, point your browser to http://localhost:9090.
The workbench based demos could be run by:
gradlew build run.rap-workbench-demo
which provides the entrypoints
- http://localhost:9090
- http://localhost:9090/app
- http://localhost:9090/business
- http://localhost:9090/fancy
- http://localhost:9090/databinding
You can also start the RAP E4 Demo application (at least JDK-9 required) by:
gradlew build run.rap-e4-demo
which can be found at http://localhost:9090/hello
Last but not least, there are also examples for EMF Forms on RAP E3 and RAP E4 respectively. You can start them by:
gradlew build run.rap-emf-demo
available at http://localhost:9090/rap and
gradlew build run.rap-e4-emf-demo
available at http://localhost:9090/hello.
You should now be able to inspect the traffic with the tool of your choice. As an example, how it should look like, here is a screen shoot of Chrome DevTools
Eclipse Public License (EPL) v2.0
- FileUpload not working - needs to be revisited
- bundle load order matters for
o.e.j.osgi.httpservice.websocketando.e.j.websocket.javax.websocket.server
because of the ServiceLoader runtime dependency, which can't be expressed by Require-Capability
see also Jetty 3543 - OSGI Http Whiteboard Spec lacks support for websockets
hopefully it shows up in future releases
see also Liferay Doc and Liferay Git