Chapter 3. Running the Application

Chapter 3. Running the Application
Prev		Next

Table of Contents

3.1. Structure of a Naked Objects Application

3.1.1. Adding Dependency Management for Wicket Objects
3.1.2. Adding AppLib Dependency

3.2. Running from the commandline project

3.2.1. Adding Dependency to Wicket Objects Viewer
3.2.2. Adding Dependency to Bootstrap
3.2.3. web.xml
3.2.4. Deployment Mode
3.2.5. Configuring Security
3.2.6. Running the Application

3.3. Running from the webapp project

Abstract

This chapter describes how to take a Naked Objects application and get it running using Wicket Objects, with the non-customized, generic OOUI.

Wicket Objects applications, ultimately, are just Wicket applications that happen to boot up Naked Objects. As such, they are bootstrapped with a web.xml that is structured the same as any other Wicket application.

This chapter describes how to run up such a webapp starting with a regular Naked Objects application.

3.1. Structure of a Naked Objects Application

The typical structure for a Naked Objects application (and the one you'll end up with if you use Naked Objects' Maven application archetype) is:

app
Main (parent) module, whose pom.xml references the submodules
app/dom
Domain object model, plus interfaces for services, repositories and factories
app/service
Implementation of services, repositories and factories
app/fixture
Fixtures, used to seed (in-memory) object store when running in exploration/prototype mode
app/commandline
Bootstrap for running from the command line (typically, the DnD viewer or HTML viewer)
app/webapp
Packaging and running as a web application

Note

The example app (as described in Appendix A, Example Application) also has an app/ui submodule which contains custom views for its ClaimWizard class.

The DnD viewer and HTML viewers provided by Naked Objects can also be run a third way, using the org.nakedobjects.runtime.NakedObjects main class. The bootstrapping mechanism for each is proprietary to Naked Objects though; the viewer is specified using the --viewer flag, which ultimately corresponds to an implementation of NakedObjectsViewerInstaller that does the main bootstrapping. Wicket Objects does not, however, support this method, primarily because Apache Wicket developers will be more familiar with bootstrapping using web.xml.

Before you go any further, you'll need to update your POMs to add the required dependencies on Wicket Objects.

3.1.1. Adding Dependency Management for Wicket Objects

In the parent project's pom.xml, specify the modules of Wicket Objects that are used in the submodules, along with the version.

First, define a property for the version:

<properties>
    <wicketobjects.version>0.1-SNAPSHOT</wicketobjects.version>
</properties>

Then, add <dependencyManagement> entries for Wicket Objects itself:

<dependencyManagement>
  <dependencies>
    ...

    <!-- WicketObjects -->
    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>applib</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>viewer</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    ...
  <dependencies>
<dependencyManagement>

If you intend to use any of the custom components (see Chapter 5, Custom Components), then also add in:

<dependencyManagement>
  <dependencies>
    ...

    <!-- WicketObjects view extensions -->
    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-gmap2-applib</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-gmap2-view</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-googlecharts-applib</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-googlecharts-view</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-calendarviews-applib</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-calendarviews-view</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    <dependency>
      <groupId>org.starobjects.wicket</groupId>
      <artifactId>view-cooldatasoftmenu-view</artifactId>
      <version>${wicketobjects.version}</version>
    </dependency>

    ...
  <dependencies>
</dependencyManagement>

3.1.2. Adding AppLib Dependency

In the DOM project, add in a <dependency> to the Wicket Objects applib:

<dependencies>
  ...

  <!-- WicketObjects -->
  <dependency>
    <groupId>org.starobjects.wicket</groupId>
    <artifactId>applib</artifactId>
  </dependency>

  ...
</dependencies>

Again, if you intend to use any of the custom components (see Chapter 5, Custom Components), then also add in dependencies to their respective applibs (if they have one):

<dependencies>
  ...

  <!-- WicketObjects view extensions -->
  <dependency>
    <groupId>org.starobjects.wicket</groupId>
    <artifactId>view-calendarviews-applib</artifactId>
  </dependency>

  <dependency>
    <groupId>org.starobjects.wicket</groupId>
    <artifactId>view-gmap2-applib</artifactId>
  </dependency>

  <dependency>
    <groupId>org.starobjects.wicket</groupId>
    <artifactId>view-googlecharts-applib</artifactId>
  </dependency>

  ...
</dependencies>

It's possible to run the app from either the commandline or the webapp project, in both cases picking up a standard web.xml file to define a webapp. Which you use is largely a matter of preference, and both approaches are outlined here.

Prev		Next
2.8. Specialized Use Cases	Home	3.2. Running from the commandline project