this post describes how to configure the jetty-maven-plugin and the jetty servlet container to run a web application that uses a data source and requires users to log in, which are the basic requirements of most web applications. i use jetty in development because it’s fast and easy to work with.

why jetty?

well, because it’s much faster then the websphere as i normally use and it really well supports fast (or shall i say agile? ) development thanks to its fast turnaround. and because it’s simply cool to type

bash$ svn checkout http://example.com/repo/trunk/mywebapp
bash$ cd mywebapp
bash$ mvn jetty:run
bash$ firefox http://localhost:8080/mywebapp

and to be able to immediatelly log into and interact with the application.

however it should be noted that jetty isn’t a full-featured javaee server and thus may not be always usable.

project setup

general configuration

you need to add the jetty plugin to your pom.xml :

<project xmlns="http://maven.apache.org/pom/4.0.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"
  xsi:schemalocation="http://maven.apache.org/pom/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelversion>4.0.0</modelversion>
  <groupid>com.example</groupid>
  <artifactid>mywebapp</artifactid>
  <packaging>war</packaging>
  ...
  <build>
  	...
  	<plugins>
    <plugin>
      <groupid>org.mortbay.jetty</groupid>
      <artifactid>maven-jetty-plugin</artifactid>
      <version>6.1.0</version>
      <configuration>
        <scanintervalseconds>3</scanintervalseconds>
          ...
      </configuration>
      ...
    </plugin>
    ...
  </plugins>

  </build>
</project>

as you can see, i’m using jetty 6.1.0.

defining a datasource

let’s assume that the application uses a datasource configured at the server and accesses it normally via jndi. then we must define a reference to the data source in src/main/webapp/ web-inf/web.xml :

<?xml version="1.0" encoding="utf-8"?>
<web-app id="webapp_id" version="2.4"
	xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"
	xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
	...
	<servlet>...</servlet>
	...
	<resource-ref>
		<res-ref-name>jdbc/lmsdb</res-ref-name>
		<res-type>javax.sql.datasource</res-type>
		<res-auth>container</res-auth>
		<res-sharing-scope>shareable</res-sharing-scope>
	</resource-ref>
</web-app>

next we need to describe the datasource to jetty. there are multiple ways to do that, i’ve chosen to do so in src/main/webapp/ web-inf/jetty-env.xml :

<?xml version="1.0"?>
<!doctype configure public "-//mort bay consulting//dtd configure//en" "http://jetty.mortbay.org/configure.dtd">
<configure class="org.mortbay.jetty.webapp.webappcontext">
  <new id="lmsdb" class="org.mortbay.jetty.plus.naming.resource">
    <arg>jdbc/lmsdb</arg>
    <arg>
    	<new class="com.ibm.db2.jcc.db2simpledatasource">
                 <set name="databasename">lmsdb</set>
                 <set name="user">myuser</set>
                 <set name="password">secret</set>
                 <set name="servername">db.toronto.ca.ibm.com</set>
                 <set name="portnumber">3711</set>
     </new>
    </arg>
  </new>
</configure>

notice that the class used is db2simpledatasource and not a jdbc driver. that is, of course, because we need a datasource, not a driver. the jetty wiki pages also contain examples of datasource configuration for other dbs .

finally we must make the corresponding jdbc implementation available to jetty by adding it to the plugin’s dependencies in the pom.xml :

<plugin>
  <groupid>org.mortbay.jetty</groupid>
  <artifactid>maven-jetty-plugin</artifactid>
  <version>6.1.0</version>

  <configuration>
	<...
  </configuration>

  <dependencies>
	<dependency>
		<groupid>com.ibm.db2</groupid>
		<artifactid>db2jcc</artifactid>
		<version>9.7</version>
		<type>jar</type>
		<scope>system</scope>
		<systempath>${basedir}/../lms.sharedlibraries/db2/db2jcc.jar</systempath>
	</dependency>
	<dependency>
		<groupid>com.ibm.db2</groupid>
		<artifactid>db2jcc_license_cisuz</artifactid>
		<version>9.7</version>
		<type>jar</type>
		<scope>system</scope>
		<systempath>${basedir}/../lms.sharedlibraries/db2/db2jcc_license_cisuz.jar</systempath>
	</dependency>
  </dependencies>
</plugin>

please do not scorn me for using system-scoped dependencies , sometimes that is unfortunatelly the most feasible way.

enabling security and configuring an authentication mechanism

we would like to limit access to the application only to the authenticated users in the admin role with the exception of pages under public/. therefore we declare the appropriate security constraints in web.xml:

...
<security-constraint>
	<display-name>authorizedusers</display-name>
	<web-resource-collection>
		<web-resource-name>all urls</web-resource-name>
		<url-pattern>/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>admin</role-name>
	</auth-constraint>
	<!--user-data-constraint>
		<transport-guarantee>confidential</transport-guarantee>
	</user-data-constraint-->
</security-constraint>

<security-constraint>
	<display-name>publicaccess</display-name>
	<web-resource-collection>
		<web-resource-name>public pages</web-resource-name>
		<url-pattern>/public/*</url-pattern>
	</web-resource-collection>
</security-constraint>

<login-config>
	<auth-method>basic</auth-method>
	<realm-name>learning@ibm mini person feed management</realm-name>
</login-config>

<security-role>
	<description>administrator access</description>
	<role-name>admin</role-name>
</security-role>
...

beware that jetty doesn’t support https out of the box and thus if you will add the data constraint confidential to any resource, you will automatically get http 403 forbidden no matter what you do.  that’s why i’ve commented it out above. it is possible to enable ssl in jetty but i didn’t want to bother with certificate generation etc.

next we need to tell jetty how to authenticate users. this is done via realms and we will use the simplest, file-based one. again there are multiple ways to configure it, for example in the pom.xml :

<plugin>
  <groupid>org.mortbay.jetty</groupid>
  <artifactid>maven-jetty-plugin</artifactid>
  <version>6.1.0</version>

  <configuration>
	<scanintervalseconds>3</scanintervalseconds>
	  <userrealms>
		<userrealm implementation="org.mortbay.jetty.security.hashuserrealm">
		  <name>learning@ibm mini person feed management</name>
		  <config>src/test/resources/jetty-users.properties</config>
		</userrealm>
	  </userrealms>
  </configuration>

  <dependencies>...</dependencies>
</plugin>

the name must match exactly the realm-name in web.xml. you then define the users and their passwords and roles in the declared file, in this case in src/test/resources/ jetty-users.properties :

user=psw,admin

the format of the file is username=password[,role1,role2,...].

when you download jetty, you will find a fine example of using jaas with a file-based back-end for authentication and authorization under examples/test-jaas-webapp (invoke mvn jetty:run from the folder and go to http://localhost:8080/jetty-test-jaas/). however it seems that jaas causes an additional overhead visible as a few-seconds delay when starting the server so it might be preferrable not to use it.

conclusion

with jetty it’s easy to enable security and create a data source, which are the basic requirements of most web applications. anybody can then very easily run the application to test and develop it. development is where jetty really shines provided that you don’t need any feature it doesn’t have.

when troubleshooting, you may want to tell jetty to log at the debug level with mvn -ddebug .. or to log requests , which can be also configured in the jetty-env.xml.

beware that this post describes configuration for jetty 6.1.0. it can be different in other versions and it certainly is different in jetty 7.

from http://theholyjava.wordpress.com/2010/09/10/jetty-maven-plugin-running-a-webapp-with-a-datasource-and-security/