An Expresso Newbie's Guide
Expresso is the most popular architectural framework. Expresso is a robust and mature development framework built on top of Apache Struts, utilizing solid architectural principles that will accommodate from the simple projects with few users to the complex corporate high use projects. This guide will attempt to navigate the novice user through the various areas of Expresso.
Developing a web application entirely from scratch can be a massive overkill. There just isn't enough time/money in the world to reinvent the wheel every time for each web application. It is better to leverage an open-sourced framework and toolkit, like the Expresso because it has far more virtual Internet resources to help debug and maintain it - thus more robust, productive, and efficient than 'going it alone'.
Expresso is maintained and supported by many developers and users - in fact the largest framework community globally. There is the standard open source argument that OS projects are better because there are many people working on it.Most people who develop the next generation of web software prefer to build on something that already works out of the box. So now that you have completed the installation process, this document describes the Getting Started process for Expresso. Many thanks to Geeta Ramani for her ideas to this resource document.
Version: |
Expresso 5.5 |
Maintainer: |
Introduction
This guide will attempt to navigate the novice user through the various areas of Expresso. Most, if not all, of which has been documented before in other documents. The purpose of this roadmap is to point you to those documents when possible and hopefully you won't have to hunt down the right document for what you need, when you need it.
Many clever developers realized that JavaServer Pages *and* servlets could
be used together to deploy web applications which became known as
Model 2. It is now commonplace to use the terms Model 2 and MVC (Model-View-Controller)
interchangeably. The servlets help with the control-flow, and the JSPs focus
on the business of writing HTML. With the release of 4.0, Expresso was
integrated with Struts, which provides a standard MVC framework to the Java
community. With the release of 5.5.Expresso is now integrated with Struts
1.1. For an introduction to Struts please read the Struts
Users Guide.
The ready-made web application is on the horizon, where you as a software developer,
professional or otherwise, will look in distaste if you had to code your own
security, database persistence layers, session management, controller, actions,
input and output, validation, and user profiling entirely from scratch. Many
users are thrilled to find Expresso because of all the complexities and tedium
it solves, and because of its rapid development capabilities. But the next question
is finding the way out from the basic starting point. This document describes
the process of taking that next step with Expresso.
By now it is recommended that you have read the Expresso
Pre-requisites and started the installation.
There are no "post-install" steps to Expresso other than connecting
to an alternate database or beginning development.
For a list of available documentation for Expresso, try the Expresso
Documentation page. This document references the links available on this
documentation page. You can also reference most of these document locally
on your system if you have the Expresso engine running on your computer,
by referencing http://localhost:8080/expresso/doc/index.html. To
faciliate this, local file names are provided throughout this document, i.e.
configuration.html. Third party resources are also links throughout this
document to provide additional learning material.
What is a Framework?
A framework is a set of prefabricated software building blocks that programmers can use, extend, or customize to suit their application. With frameworks. developers don't have to start from scratch each time they build an application: both tile design and the code of a framework may be reused. A Java web development framework is a collection of tools and API's that enhance Sun's standard Java APIs by providing:
- Structure to web development
- Generic services that are needed on most projects (logging, persistence, etc...)
- Tools and methods that simplify and accelerate web development.
Frameworks capture the programming expertise and best practices necessary to solve a particular class of problems and make them pervasive. In this case, it is the web centric, multi-tiered, enterprise environment that the Expresso application framework addresses. Programmers purchase or reuse frameworks to obtain such problem solving expertise without having to reinvent the wheel.
What Can I do with the Expresso Framework?
Based on feedback from some newbies, the main question a newbie asks is: "what
can i do with Expresso"? And many newbies say that though Expresso seems
to be a *wonderful* application, the amount of stuff is certainly overwhelming.
So we're going to try to make it a little easier.
Expresso is a good, powerful, flexible framework which provides a number of
services that assist in building web applications. The major areas that these
services are used are:
- Provides Application Organization and Configuration
- Provides Database access and Database Objects toolkit
- Support MVC Architecture and provides package of components for creating several types of "Controller" objects
- Provides Job Queueing/Handling
- Provides a means for easily and quickly creating useful servlets and JSP pages
- Provides a mechanism for defining "events" that occur within the web application.
- Provides a number of other userful utilities.
Getting Started User Questions
Before reading the Expresso Developers Guide (EDG) as a reference document, here are some questions/answers and reference material as suggested by some newbies getting started withe Expresso:
- Why would I choose Expresso over developing my own framework?
Expresso is maintained and supported by many developers and users. Thus the standard open source argument certainly holds: OS projects are better than homegrown because there are many people working on it and using it in a huge diversity of environments. Thus Expresso evolves and reflects the huge real world experiences of its users. Further, since Expresso is open source, code can be modified to fit individual needs. Although, a better/easier approach would be to extend the framework which, happily, is pretty easy. Moreover, many developers are already familiar with Expresso and/or Struts so new team members may not need training as in a proprietary framework. Struts and Expresso are becoming so popular that it's darn near a standard in Java web development.
- What does a person need to know about Struts before (s)he works with
Expresso?
It would probably be wishful thinking to assume that you could pick up Struts along the way as you catch up with Expresso. Struts is a wonderful and powerful framework in its own right, and well worth study. The good news is that since Expresso is now tightly integrated with Struts, learning Struts is a good first step to learning Expresso. Further, Struts has a gentle learning curve, is well documented, and has an active and friendly list serve. - What does Struts do for Expresso?
Struts is open source framework which implements a Model 2, JSP web application architecture for building web applications in Java Servlets and JavaServer Pages. This approach is characterised by using a Servlet as a command request dispatcher. Further, Struts unifies Java Beans and JSPs through the using custom action tag libraries. It is particularly strong in coupling business logic and views without excessive cohesion. There is a clear separation of business logic and presentation with the library if the edicts are followed. The rich custom action tag libraries, use of XML technology, and for some people whose natural language is not English, built-in in support for internationalisation, means that Struts is clear popular winner across the world. Please refer to the Struts_Integration documentation for more information, which includes the diagram of the Struts /Controller execution in Expresso for a graphical representation.
- What is the difference between Tomcat, JBoss and Expresso?
Tomcat is a servlet/JSP container, and JBoss is an EJB container. Thus, Tomcat doesn't know what to do with EJBs as JBoss doesn't know what to do with servlets and JSPs. Moreover, there is a JBoss bundle that comes with Tomcat set up to run with it. JBoss is not an alternative to Expresso either, but, again, they can work together if you really need EJBs. Otherwise, Expresso's DBObjects and controllers can make the deal..
- How loosely coupled are the services/components in the Expresso Framework The question can be rephrased as folows: If you have already developed internally some framework you'd like to continue using, could you still supplement with Expresso services?
About the only parts of Expresso you can't get away from are:- DBObjects and Derivatives
- Expresso Configuration,
- and Expresso Logging system.
Without these, pretty much none of the services will work. After that you can start picking and choosing... for example, we talked to a guy on the Struts list one time that JUST used DBObjects and skipped the whole controller stuff, and was just using Struts for the controller. I've found for myself that it was easier extending 4.0 to do things just the way I wanted it rather than building my own custom services from scratch and then using Expresso for the other things.
- Where is the "servlet stuff" hidden?
Most of us are used to dealing with servlets and so on but Expresso treats even HttpRequest/HttpResponse objects are too "core" for an app writer to have to deal with and so are hidden from view. An explanation of how this is achieved in Expresso as well (as how an app writer should infact take advantage of this) would be great. Does anyone have any tips on how to debug Expresso apps and what tools are used to do this?
- Is there an Expresso "tutorial"?
Check out the Weblog Example, Location Example and the Contacts Example. The latter example is also used by the How To document and may be referenced throughout other documentation as the reference for learning.
- Does anyone have any tips on how to debug Expresso apps and what tools
are used to do this?
You can use Expresso's own log4j implementation, which is documented on the site. It is quite easy to use, and can be turned on and off in each area, with ease. It has been a very powerful approach for many users. You can use your IDE too. For example the setup for use Forte's IDE with standard breakpoints is documented in detail at http://Expresso.badfw.org/. IBM's VisualAge for Java also works very well, which in addition to the interactive debugger, has the advantage of incremental compilation making the debug, edit, test cycle very quick. You could also use the JUnit implementation within Expresso to utilize standardized testing regimens. You will find many such tests sprinkled throughout the Expresso class structure. IDE specific notes can also be found in the main Documentation page.
Installation
With Expresso complete it is very straightforward install. You can simplify
the server and database steps by using the Expresso Complete bundle, which
has the Tomcat servlet
container (a freely available and mature servlet runner) already bundled
and configured with Expresso. You could use any servlet runner compliant
with version 2.2 or 2.3 of the Java
Servlet API.
Without Expresso complete there is addition pre-requisites that make it straightforward
ONLY IF, you have all the pre-requisites in place. It is suggested that this
be attacked as a completely separate project, and completed before any attempt
at installing Expresso is made.
Please consult the following documents:
| Expresso Pre-requisites |  |
prereq.html
|
|
| System Requirements | |
requirements.html | |
| Expresso Installation for Complete-Bundle | |
expressocomplete.html | |
| Expresso Installation Overview | |
installation.html
|
|
| Struts Users: Expresso Integration Overview and Reference | |
edg_overview.html | |
| Frameworks for Building Component Based Applications | |
Best Practice with the Expresso Framework
Please review the "Best Practice with Expresso Framework: Using a framework to create a web application" written by Peter Pilgrim. Expresso Framework is a large toolkit of classes. Getting started can be overwhelming because there are so many classes [well over 200] to look at. This document directs a newbie's focus to the "important" classes so that is really helpful. The document also divides the framework classes into four types and discusses the roles of each of these types of classes:
- schemas
- database object persistence
- controller design
- and the rest of the kit, which involves job control, utilities, etc
It is essential that you understand the first three parts. Expresso Framework is also very much database-driven. That is, you will need to use a reliable, scalable relational database to make full use of the kit. Mysql, Sybase, Oracle, DB2, and Postgres are all suitable candidates. The document demosnstrates best practices by describing a simple stock trading program that displays stocks trades, and allows the user to buy and sell stocks. Hopefully, you can take this best of practice, using a framework, custom tag action libraries, JSP's, and Servlets, elsewhere and make it a success in your web applications.
Where is the Root of My Application Supposed to Be?
Based on feedback from Newbies, another prominent question is: "Where
is the root of My applications supposed to be"? So we want to give an
explanation of the suggested directory structure. First you might want to
review the package
and file organization of Expresso. All Expresso apps fall under the same
context as Expresso (so the apps can use Expresso's classes).
First, a brief review of the notion of "contexts" in your servlet/JSP
container.
Contexts
Your JSP container (for the sake of simplicity let say it is TOMCAT), defines a directory for web applications as it needs to know about all the contexts you have defined. This is because, when Tomcat receives a request to serve a web page, it checks the "context" of the request URI. For example, if the URI is http://www.mycompany.com/myapp/index.jsp, then the "context" is "myapp", and so it looks for the "myapp" context.
Contexts are defined in two ways: either explicitly via a definition in the container's "server.xml" or due to the presence of subdirectories within a special subdirectory called "webapps" present in the root of $TOMCAT_HOME: $TOMCAT_HOME/webapps. For example, the "default web app" is the one stored in the "ROOT" subdirectory, and is accessed via the URI "http://www.mycompany.com/". Standalone Tomcat installations usually create this default context/subdirectory as well as an "examples" context/subdirectory.
In particular, Tomcat can run multiple web applications because each web application which is a subdirectory under the "webapps" directories defines a distinct context (and can be accessed via a distinct URI).
Expresso Framework is one web application when it is properly installed: there is a subdirectory called "Expresso" in "webapps": $TOMCAT_HOME/webapps/Expresso. Thus the URI "http://www.mycompany.com/Expresso" can be considered the front page for web application, Expresso.
In keeping with this "usual" scenario, earlier versions of Expresso Framework created an "Expresso" context/subdirectory, and stored its root "frame.jsp" page in the this context (eg. in $TOMCAT_HOME/webapps/Expresso/frame.jsp for Unix) which translates to a URI of "http://www.mycompany.com/Expresso/frame.jsp". However, in later versions, the root frame page was moved to a directory further down - into another subdirectory, also called "Expresso": So for example, for Unix systems, this is in $TOMCAT_HOME/webapps/Expresso/Expresso/frame.jsp, accessible via an URI: http://www.mycompany.com/Expresso/Expresso/frame.jsp
Due to this change, you can now insert your own customised welcome page (accessed via "http://www.mycompany.com/Expresso/frame.jsp" and stored in $TOMCAT_HOME/webapps/Expresso/frame.jsp for Unix) while the Expresso pages, which may in fact be thought of as the "Administration" directory no longer "takes over" your site.
Next, we move to the question of where to put your own web apps. Since each JSP container allocates a unique class loader for each context, there are two possible ways of incorporating the Expresso Framework with your preexisting applications. We describe them both below:
- Install the Expresso Framework for each of your web applications
in separate contexts. For example, if you have three web applications,
alpha, beta, and gamma, you could have the following set up, with three
separate installations of the Expresso Framework:
- [( Class loader for "alpha" created/defined as follows:]
webapps/alpha
webapps/alpha/Expresso/ - [( Class loader for "beta" created/defined as follows:]
webapps/beta
webapps/beta/Expresso/ - [( Class loader for "gamma created/defined as follows:]
webapps/gamma
webapps/gamma/Expresso/
- [( Class loader for "alpha" created/defined as follows:]
- On the other hand, you can have more than one application with in the
Expresso framework. It is just a matter of organising the directory structures.
The way to achieve this is to install just one instance of the Expresso
Framework . Divide and reorganise the context to whatever you feel your
architecture requires so all your applications (or more properly "sub-applications")
belong to the *same* context as does "Expresso". For example,
you could have the following subdirectories:
- webapps/Expresso/Expresso
- webapps/Expresso/alpha
- webapps/Expresso/beta
- webapps/Expresso/gamma
Each approach has its advantages and disadvantages. The individual requirements of your applications should dictate which approach you take.
In the first case, you will have three separate & different installations
of the Expresso Framework! However, the three web applications will belong
to three distinct contexts and therfore are completely independent (and ignorant
) of each other. In particular, they can never share any application code
or sessions etc. When you publicize your web application on the Internet
you probably dont want to broadcast that Expresso is being used until you
have secured the application. You can rename the `Expresso' sub directory
to the `Expresso235' and then change the set up value `%Expresso%' in the
database. So can secure the admin site of your site. Lastly you should leave
the java classes in `%context%/WEB-INF/classes' because Java has packages
and readily support namespaces. Just call them different eg. `com.acme.work.webapp.*'
and it won't interference with Expresso's `com.jcorporate.*'.
Put your custom tag library descriptors in `WEB-INF/tlds' and your libraries
jar files in `WEB-INF/lib'. See the spec at http://java.sun.com/products/jsp/.
On the other hand, in the second case, all three of your sub-applications
share the same context and can therfore share sessions, code, state, database
pooling etc. For example, in the example above, sub-application beta can
seamlessly switch over to sub-application gamma. Further, session data stored
by sub-application beta can be picked up by sub-application gamma.
The JSP Container (Tomcat) can run multiple web applications because each one
is a subdirectory under the 'webapps' directories. With standalone Tomcat there
is at least two delivered out of the box 'ROOT' and 'examples'. The ROOT subdirectory
is special because that is the default web applicationthat you see when you
type in 'http://localhost:8080/' on your web browser. The 'examples' subdirectory
is another web application with example servlets and JSPs. The java classes
for each web application are loaded with its own class loader so that they
don't interfere with one another.
Directory Structure Details
You would be well advised to take a bit of time to go through the directory structure of both the com.jcorporate.xxxx.java files, but also through the expresso .jsp files, to get a handle on how things are built before you start.
When I did this at first, I felt pretty overwhelmed, and was ready to chunk
the whole thing as being too complex. But then I look at some of the simpler
projects I have built, and see the same complexity. And then there is java
itself: At first I thought java was "just too hard," but then I grew to understand
that it is not that it is too hard, but "it just does so much." The
same seems to apply to Expresso.
Below are some references for getting started with the directory structure:
- DBMaint: A Step-by-Step Example: This document is ideal because it was written by a user just getting started with Expresso. It address both an introduction to the directory structure as well as walks the user through a step-by-step example.
| webapps |
The directory where your servlets reside |
|||||
| - | ROOT |
The default installation root directory. This
may be named differently depending on your site specific setup. |
||||
| - | expresso |
The root directory of all that is 'browse-able'
by users hitting the website. |
||||
| - | components |
The root directory of expresso add-on
components such as ePoll, eForum, demos, etc. |
||||
| - | doc |
Documentation, papers, FAQs. |
||||
| - | help |
Runtime help for expresso features. |
||||
| - | jsp |
The Java Server Pages directly used by
the framework. |
||||
| - | xsl |
Stylesheets for XML output. |
||||
| - | WEB-INF |
The private access root directory. |
||||
| - | bin |
Scripts for testing, building, and specialty
items. |
||||
| - | classes |
Java class files and property bundles
placed in the servlet's classpath. |
||||
| - | config |
Configuration files for expresso and
any components (this includes your application). |
||||
| - | db |
HyperSonic's database directory - the
default installation's pre-configured database. |
||||
| - | lib |
All required jar files not provided by
your application server. |
||||
| - | log |
Expresso's log file destination. |
||||
| - | src |
Expresso's src code, if you downloaded
it. The code comes standard in the 'complete' distribution. |
||||
| - | tiles-definitions |
Expresso now has support for Strut's
Tiles! |
||||
| - | tld |
Tag Library Definition files. | ||||
Root Folder
The ROOT folder is, well, the root of the installation. Typically, this folder has no files other than a handful of no-risk HTML or JSP pages. Personally, I like to place my index.jsp here that includes files from under WEB-INF if I need to do processing. Any publically available resource, such as logo images, privacy policy, etc., can also be in this directory or sub-folder. All protected documents should be somewhere under the WEB-INF directory, as it is guarenteed to be not generally accessable by all decent servers.
WEB-INF
NThe WEB-INF folder contains all private resources and configuration. All
servlets must have a web.xml file in this directory that specifies its characteristics. Consult
your server's documentation for information on the web.xml file. TomCat 4
ships with a well documented web.xml. The
subfolders specify additional configuration, your private resources, and
the servlet code required to run your site.
|
|
config |
The config directory initially contains
the configuration files for Struts, Expresso, and Tiles. As you
install or create additional components, they too will have one or
more configuration files here.
|
||||||||||||
|
|
classes |
Java class files, resource bundles, etc.
required by Expresso and/or your application that do not reside in
a jar file in the lib directory. |
||||||||||||
|
|
lib |
Jar files required by Expresso and your
applications. For example, you will need to add your database
driver here if you use anything other than HyperSonic SQL. |
||||||||||||
|
|
src |
Expresso source code if you have it. It
comes separate or in the 'complete' bundle. You could put your
code here also, if you desired. |
||||||||||||
|
|
tiles-definition |
Application specific tile definitions. Would
you like to know more? Even
More? |
||||||||||||
|
|
tld |
Tag library definition files. If
you use JSP and don't use tags, you're missing out on great, clean
code! Check
them out here. |
configuration.html)
of log directory, cryptography, service class handlers, and
For more information on the code and CVS folder structure, read the following:
| Package and File Organization "Map" | |
expressoMap.html | |
Expresso Folder
This directory is the context-path for Expresso. All of Expresso's front jsp files are located here.
Components Folder
The components folder is where Jcorporate will install any demo applications, and thier add-on components; eSearch, ePoll, eForum, and eContent. New users of expresso should seriously consider placing their applications here to facilitate looking at examples and it wouldn't hurt to keep them there either.
Setting up Different Database and/or Servlet Engine
Database setup and configuration is so ubiquitous it must be mentioned in
this document. Expresso should work with most databases. See Database-specific
Installation Notes . Specific
databases known to work are:
- InstantDB Database
- Interbase Database
- Oracle DBMS
- IBM DB2 Database
- MySQL Database
- Postgres SQL Database
- Microsoft SQL Server Database
- Sybase Database
- Hypersonic - see the expresso-config.xml file that comes with Expresso for a working example.
- SapDB
There are different database and Servlet engine specific installation notes onsite under the Documentation link.
Using an IDE
Expresso can be used with any of the IDEs on the market. There are notes onsite for specific IDEs under the " IDE-specific Installation Notes" section of the Expresso Documentation.
First Time Setup
Before anything meaningful can be accomplished with a new database (like after installation), Expresso needs to create the tables that it uses and insert the default values for its run-time. You may not like these values and you can change them.