See: Description
| Package | Description |
|---|---|
| controller |
Root controller package.
|
| controller.user |
Controllers for users and associated JSF pages.
|
| model |
Database entities.
|
| service |
Beans for accessing persistence layer.
|
| test |
Test classes.
|
| util |
Package of utils.
|
The Java layout is pretty vanilla. Packages controller and controller.user have @Model annotated beans for supporting their respective web pages. The model package has entities, and service has EJB's for interfacing the controllers to the model. The service/RoleSingletonBean is implemented as a Singleton because roles are static in this application: they are loaded on initialization and never change.
The security is configured in WEB-INF/web.xml and enforced by the container via the security-domain configuration. the webapp/views directory is not restricted, the webapp/views/user directory is restricted to accounts with a "USER" role, and the webapp/views/admin directory is restricted to accounts with a "ADMIN" role. Security annotations are also placed on the service/UserSessionBean, though there is currently nothing in the application that depends on them.
The src/test/java/test/SiteTest class uses arquillian, done, and graphene to test the site through the web pages. These testers depend on id's and parameters in the jsf/html files to find input fields and submit buttons. It will also be a challenge for the application developer to maintain useful and current testing.
The front end is implemented with twitter bootstrap. Care was taken to insure that JSF and Java conventions don't interfere with bootstrap and jquerys' needs, so that those resoures are references with html scripting tags.
There is also a primefaces version stashed away in the webapp/views.primefaces directory. Copy to the webapp/views directory, overwriting the bootstrap versions and restart the application.
To extend the model create new model entities and add service beans. Add controllers in support of new views. As the application grows it might be a good idea to move navigation into faces-config.xml. Often, more sophisticated functionality requires more specialized view models, which should be made as simple POJO's in a separate package, say web/view or web/form.
Finally, this archetype is meant to give users and general idea of java conventions and best practices. While it is far short of any type of production ready application it should provide a lot of useful information for novice Java EE architects.