Last but not least, we need to package and deploy the final application. Choosing the target environment highly depends on the requirements. Jspresso supports as of now 5 different deployment scenarios : Swing, AJAX (qooxdoo) and Flash (Flex).
For swing you should simply package your application classes and resources in a jar (or multiple jars) and distribute it on the clients either manually or through a more advanced deployement mechanism like Java Web Start. Be aware in that case that the client JVM will handle everything except the database and that the network will support the JDBC calls from the application backend. This 2-tier architecture is certainly not the preferred scenario when you have limited bandwith between the clients and the server or limited resources on the client machines but it might perfectly fit for a limited number of clients residing on the same LAN than the database server. Although, this option is not commonly considered as a good option, it should not be underestimated especially when dealing with small-scale deployments.
Qooxdoo and Flex deployments require a servlet 2.5 compatible application server (Apache tomcat is one of them, free and production-robust). This means that you can just package your application as a WAR archive and drop it in the application server to have it deployed. Jspresso, although very powerful and flexible doesn't require an overkilling, latest specifications compliant, application server. Once this is said, there are times when your application specific needs might require one of them. For instance, if you need some heterogeneous transaction capability and must use a full fledged JTA compliant transaction service, you have little other choice than going to one of the market big application servers. Of course, we encourage you to stay in the free and opensource world.
We won't discuss here the database side since Jspresso database support is directly linked to the Hibernate database support.
Note
Refer to the Hibernate documentation to get a complete understanding of the support and limitations of the database engine you plan to deploy. By the way, you will rarely find any limitation on this side regarding the huge and excellent support Hibernate has on almost each and every common database vendors.
Jspresso introduced with the 3.0 release a native support for Adobe's Flex. As for the other deployment options, there is absolutely nothing to code against the Flex API (no MXML, no ActionScript). Jspresso takes care at runtime of the frontend display and client/server communication through :
a generic Flex rendering engine that reads everything it needs from the server side
a generic communication layer based on BlazeDS that takes care of exchanging low-level GUI commands back and forth with the server.
Your Jspresso application will then be able to run in any Flash enabled browser.
Starting from the 3.5 release, Jspresso supports qooxdoo, a very high quality Javascript UI library (qooxdoo is actually more than that, so feel free to dig into their web site). The Jspresso qooxdoo UI channel shares the same architecture than the Flex UI channel. Beyond the custom qooxdoo java RPC servlet, the same codebase is used to adapt the client server communication.
Whatever option you take to deploy your Jspresso application (you may choose all of them), everything is already prepared in the project and the Maven build will take care of every complicated packaging steps.
Surely the shortest section of the manual. Just launch :
mvn package
Go to hrsample/webapp/target/ and you will
have a ready-to deploy war archive containing your Jspresso application.
The generated Jspresso project is also ready to to be used in Eclipse
WTP. Just add it to the Eclipse managed Tomcat you've created when
setting-up the development environment and start the server.
Now that you have a complete WAR archive, it is time to deploy it
in the application server. This step highly depends on the application
server you will choose and ranges from a simple copy into a deployment
directory to the use of a specific deployment tool; so refer to the
documentation of your J2EE server to know how to perform this task. As
an example, in the Apache Tomcat AS, deploying a WAR is a matter of
copying it to the webapps/ directory.
There is still one thing to achieve before being able to go live.
The JAAS configuration (held in the jaas.config
file) is a per-JVM configuration. This means that you cannot package
your jaas.config file into the WAR itself, but you
need to make it accessible somewhere in the environment so that you can
refer to it in the java.security.auth.login.config java
system property on the application server JVM level (as we did it at
development time for the standalone swing application). The
jaas.config file will then gather the JAAS
configurations of all the applications deployed in
your server. Again, refer to the documentation of your J2EE server to
know how to set a java system property in your application server
instance. As an example, in the Apache Tomcat AS, setting a system
property is achieved by setting the CATALINA_OPTS
environment variable, e.g. :
CATALINA_OPTS=-Djava.security.auth.login.config=/path/to/my/jaas.config
We can now see the result of the deployment.
Point your browser to the flex context :
http://[machine]:[port]/hrsample-webapp/flex/
The browser shows you the Flex login dialog.
And you can play with the same application but in Flash
!
Point your browser to the qooxdoo context :
http://[machine]:[port]/hrsample-webapp/qooxdoo/
The browser shows you the qooxdoo login dialog.
And you can play with the same application but in
Javascript using the qooxdoo library !
Congratulations! we have now closed the circle and in tenth of the effort usually required to achieve the equivalent, we developped and deployed a multi-channel, distributed desktop-like business application.