I wrote in a previous article about my problems with Jetty and Vaadin push support.
I found the problem in the meantime and Jetty works well on my Raspi. The performance is a little bit better than with Tomcat 8.
What was the problem?
Vaadin 7.1 push implementation was incompatible with Jetty 9.2.6. I had to use Jetty 9.0.7.
I didn't use Jetty as embedded server, it runs standalone via bin/jetty.sh. It was a little bit tricky to add an external lib to the classpatch because the commandline argument changed from 9.0 to 9.2.
It seems that Vaadin' websocket implementation for Jetty is better than for Tomcat because Vaadin handles multiple rotate/resize events faster with less communication. I know that Vaadin 7.3 has a better websocket implementation and it's also up-to-date and should work with Jetty 9.2.6, but I still use Vaadin 7.1.
I recommend Jetty for your embedded project because it's fast and simple. If you prefer Tomcat, you can't do anything wrong.
Oh... I also solved the problem with missing request from / to /index.html. The redirection won't work if you don't have a file with the name index.html in your public web area because Jetty does nothing in that case. I didn't find an option for that, but creating an empty index.html solved my problem because I had a Servlet which was listening on /index.html.
It's about two years ago that I wrote about controlling window shutters. The system run for 2 years without problems but it was time to change "something" because it was vacation time and I thought it would be useful to showcase our vaadin UI
The old system was controled via (good old) SMS - without GUI. It had a lot of commands but only en/disable up/down were heavily used because the integrated public holiday and weekend automatism solved most use cases. The SMS contol was great and worked without problems but it was a problem if you didn't know the commands and syntax by heart!
Another consideration was a simple real-world showcase for our vaadin UI, the responsive feature and push support. Our application frame was already responsive and worked on desktop, tablet and smartphone browsers. I thought about using AngularJS or different "hypeware" but I didn't have weeks to research and implement. My new GUI had to be finished in few hours. And it should be maintainable for the next two (or more) years without problems.
I love researching hypeware... but simply read some articles if you want:
There are too many frameworks, everyone is different - no real standard APIs (didn't count HTML and CSS). You can't be sure that the framework is future-proof because developers love to change software to be incompatible with previous versions just to be state-of-the-art.
And why should a developer use 5 or more frameworks to create a simple application for desktop and mobile? You'll need more libs if your application needs DB and CRUD support.
C'mon we need simple and small frameworks and not what we have right now! The world is talking about microservices and what about "micro frameworks"?
Conclusio: I didn't find something comparable to JVx. Of course, it's my opinion and I'm JVx developer, but I'm a researcher and the technology isn't a problem if it makes sense to use it.
To be honest: Our Vaadin UI in combination with other JVx features is unbeatable for most application types. Of course, it's not recommended for web pages with custom layout requirements. If you need an "application style" solution with menu and screen/work area or form based - there's nothing comparable.
After I knew that my new GUI would be a JVx' vaadin solution, I had to think about the details. The whole application should be responsive to support every modern device and desktop browsers as well. The application server should be Jetty or Tomcat and it should run on the RasPi. The performance is not critical because the hardware is limited (but cheap).
Next step was development. This was easy because I re-used existing classes and added some get/set methods to access internal members. The most important change was an event listener because every vaadin client should be updated immediate via push. It wasn't possible without notification mechanism. I thought about an event bus and played around with mbassador. It's a nice and small lib, fast and just works (recommendable).
To be honest: I didn't need it because I didn't need more than one listener and an event bus is not much more than a listener abstraction (with some extras).
After some hours developing and refactoring, everything was ready for a test.... The next decission: Jetty or Tomcat?
I worked with Tomcat for many years and didn't know much about Jetty, only that it's the number one for embedding into applications, supports SPDY and has websocket support. I played around with Jetty and got it running. The installation of my GUI worked like a charme and everything worked except push. I found solutions for embedded run mode but not for standalone Jetty. I'm pretty sure that I missed something, but I wasn't very patient and switched to Tomcat 8.
Not only because of my push problem but Jetty didn't handle requests as expected:
http://localhost/house/ didn't redirect to http://localhost/house/index.html automatically. I didn't have an index.html file in the public file area, anyway the request should be executed. Such requests work with Tomcat without additional configuration.
I'm not happy that my Jetty server didn't work but I'll retry it in the next days
Here's a simple screencast of my solution because it's easier to understand:
Window shutter web control
It took me less than one day to finish my GUI and the best: It's family safe.
I tried the GUI with PS4 and WiiU integrated browser and it was great to see shutters moving.
Summary
I've used a RaspberryPi, installed Tomcat 8 with Java8 and deployed my application as war file. The GUI is responsive and supports push via websockets and runs on every device in my house. It wasn't planned using gaming consoles
Oh, I forgot to mention: During my tests I found out that Android and iOS support custom Bookmark images for Desktop links but this needs additional tags in index.html (works without, but it's better to include the tags). Our VaadinUI now has built-in support for such images
If you read my postings about NFC Reader, you know that I use an USB TTL module for the communication with my NFC Reader (UART mode). If you don't own such a module, it's not a big problem to connect the reader with GPIO pins of your RaspberryPi.
My idea was to create a programmable timer for some lamps at home. I wanted to control the timer via mobile phone (not only smartphone). I decided to use simple SMS'.
The timer app was not really a challenge and the SMS interface was also very straight forward, so I added a little bit network communication and complexity. The result:
My first question was - Which application server should I use for my Pi? I thought that JBoss or Tomcat would be overhead and I would save resources. I decided for Vert.x and a simple socket server. I wanted to show the integration of Vert.x with JVx and so my server got a JVx application with some business logic for publishing messages.
The server "thing" was clear and for reading SMS' I wrote a simple polling app. The app reads SMS from my hardware via RS232 and forwards received SMS via JVx APIs to my server (with Vert.x' NetClient).
I didn't use the EventBus for sending messages becasue I wanted to show the seamless integration of JVx and Vert.x.
The server application is a standard JVx application (only server-side). It uses a standard XmlSecurityManager without the need for a database. The "business logic" is very simple:
public Vertx getVertx() { return(Vertx)get("vertx"); }
I made some tests with vert.x clustering and decided to implement a (very) simple JavaFX application that shows published SMS'. The application contains following code:
Finally, I created a short video that shows all in action. It shows three applications on the same laptop. The first is the JavaFX application that shows published SMS. The second is the Power control (includes SMS check), started via PuTTY. The third application is the server instance, started via PuTTY. You can see a table lamp that will be turned on and off with SMS, sent from a smartphone.
I ordered a Raspberry Pi model B two month ago from RS-Components... it arrived today. It was not a problem because I had a Beagleboard for tests and JavaFX for Pi is available since yesterday.
One of my friends received a (more expensive) Pi some weeks ago and we made some tests with JBossAS 7.1 and JavaSE 7 (without JavaFX). It worked like a charm and it's cool to have a JBossAS on a Pi. But without JavaFX it was not too funny.
My first attempt didn't work - Raspberry Pi didn't boot (no flashing lights on my Pi - only PWR, screen was black) .... Wrote the image once again and removed the device cleanly from my Laptop - worked.
The second problem was not really a problem, but I had no idea. Used pi as username and raspberry as password (see here)
First actions after boot and setup:
apt-get update apt-getinstall librxtx-java mc locate
Pi is up and running, but the image is not comparable with my Angstrom image. Some modules/drivers are missing... but that's not too important now.
My Time tracking software works on my Pi without problems. Startup time is a little bit longer as on my Beagleboard.
The next steps are some performance tests...
But Pi is definitely a MUST have.
Order your own one asap and enter the world of embedded systems with JavaFX.