Using XDoclet to Build the Web Tier


The web tier of the application builds on the EJB tier. It provides a simple web interface for a user to manage ToDo items. The application uses JavaServer Faces as the controller. The application needs to provide a few simple backing beans to provide an interface to our back-end EJBs and the JSP pages that make up the view. The JSPs are very standard, so we won't look at them in detail. Instead, we'll look at how we are building and deploying the web tier.


Note: The deployment-descriptor subtask generates the web.xml file.

How do I do that?

Once again, XDoclet will come to our aid to make sure we can get the application up and running as fast as possible. While XDoclet isn't quite the hero on the web tier that it is on the EJB tier, it will help us to generate a good deployment descriptor. The webdoclet task invokes XDoclet for us:

     <target name="webdoclet" depends="init">         <mkdir dir="dd/web" />         <webdoclet destdir="${gen.src.dir}" mergedir="${merge.dir}">             <fileset dir="${src.dir}">                 <include name="**/*Servlet.java"/>                 <include name="**/*Filter.java"/>             </fileset>             <deploymentdescriptor servletspec="2.4"                                   destdir="dd/web"                                   distributable="false"/>         </webdoclet>     </target> 


Note: Think of merge files as metadata that isn't associated with any particular Java class.

In the ToDo application, we primarily make use of XDoclet merge files to break up the individual configurable elements. Merge files are small code or deployment descriptor fragments that can be inserted into the generated document. The merge files are loaded from the merge directory.

The servlet.xml file provides the servlet definition for the JSF controller servlet:

     <servlet>         <servlet-name>Faces Servlet</servlet-name>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>         <load-on-startup>1</load-on-startup>     </servlet> 

The servlet-mapping.xml file maps all .faces resources to the faces servlet:

     <servlet-mapping>         <servlet-name>Faces Servlet</servlet-name>         <url-pattern>*.faces</url-pattern>     </servlet-mapping> 

The web-security.xml file declares that the application should require users to log in and be assigned the Users role to access the application:

     <security-constraint>         <web-resource-collection>             <web-resource-name>AllFiles</web-resource-name>             <url-pattern>/*</url-pattern>             <http-method>GET</http-method>             <http-method>POST</http-method>         </web-resource-collection>         <auth-constraint>             <role-name>User</role-name>         </auth-constraint>     </security-constraint>     <login-config>         <auth-method>BASIC</auth-method>         <realm-name>ToDo Application</realm-name>     </login-config> 


Note: JBoss doesn't care if you declare security roles, but it is good to declare roles for portability.

The web-sec-roles.xml file declares that the User role exists:

     <security-role>         <role-name>User</role-name>     </security-role> 

And finally, the web-ejbrefs-local.xml file provides a link to the TaskMaster session bean. The backing beans communicate with the EJB tier through the session bean façade.

     <ejb-local-ref>         <ejb-ref-name>ejb/TaskMasterLocal</ejb-ref-name>         <ejb-ref-type>Session</ejb-ref-type>         <local-home></local-home>         <local></local>         <ejb-link>TaskMaster</ejb-link>     </ejb-local-ref> 

The code for the backing beans is in the src/com/oreilly/jbossnotebook/servlet directory, and the JSPs are in the web directory. The web directory also contains a few additional configuration files the application needs. The most important one is the faces-config.xml file used by JavaServer Faces to determine the behavior of the application controller.

When you build the application, the web application is put into todo.war:

     [todo]$ jar tf build/jars/todo.war     META-INF/     META-INF/MANIFEST.MF     WEB-INF/     WEB-INF/lib/     WEB-INF/lib/commons-beanutils.jar     WEB-INF/lib/commons-collections.jar     WEB-INF/lib/commons-digester.jar     WEB-INF/lib/commons-logging.jar     WEB-INF/lib/jsf-api.jar     WEB-INF/lib/jsf-impl.jar     WEB-INF/lib/jstl.jar     WEB-INF/lib/standard.jar     WEB-INF/classes/     WEB-INF/classes/com/     WEB-INF/classes/com/oreilly/     WEB-INF/classes/com/oreilly/jbossnotebook/     WEB-INF/classes/com/oreilly/jbossnotebook/todo/     WEB-INF/classes/com/oreilly/jbossnotebook/todo/servlet/     WEB-INF/classes/com/oreilly/jbossnotebook/todo/servlet/CreateTaskBean.class     WEB-INF/classes/com/oreilly/jbossnotebook/todo/servlet/DebugBean.class     WEB-INF/classes/com/oreilly/jbossnotebook/todo/servlet/TaskBean.class     WEB-INF/classes/com/oreilly/jbossnotebook/todo/servlet/UserBean.class     WEB-INF/classes/com/oreilly/jbossnotebook/todo/messages.properties     WEB-INF/classes/roles.properties     WEB-INF/classes/users.properties     WEB-INF/faces-config.xml     WEB-INF/web.xml     debug.jsp     front.jsp     list.jsp     style.css     task.jsp 

With that, we have a complete web application.

What just happened?

Perhaps it is better to start by noting what didn't happen. None of the EJB tier code made its way into the WAR file. There are no EJB interfaces or value objects in the web application. The JBoss classloader gives the web application visibility into the EJB JAR file containing the beans. With JBoss, you don't have any of the packaging hassles you have come to expect from J2EE application servers. There were also no JBoss deployment descriptors. The JBoss defaults are quite reasonable for application development.



JBoss. A Developer's Notebook
JBoss: A Developers Notebook
ISBN: 0596100078
EAN: 2147483647
Year: 2003
Pages: 106

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net