Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

XDoclet Meets Eclipse: Code Generation Made Easy : Page 2

In an earlier article, you learned how to use an Eclipse plugin that supports XDoclet to administer a JBoss application server. Now, take it to the next level: Learn how to use the XDoclet plugin to generate code via a simple servlet-driven, EJB-based example.


advertisement
Webdoclet and Ejbdoclet
In order to execute XDoclet, we need an Ant build file. This build file will call XDoclet tasks that generate the necessary files and put them in a specified location. The beauty of the XDoclet functionality provided by the plugin is that we don't have to write any Ant code by hand. We can use the plugin's GUI to define the XDoclet configuration that we want, and the GUI will generate the Ant script for us. Right-click on the project and go to Properties —> XDoclet Configurations. Using this properties view, you can define XDoclet configurations for any type of XDoclet code generation you want. In this case, you'll generate a Web and an EJB configuration.

Figure 1. The XDoclet Configurations Menu: Here is where you define the configurations for your code generated projects.
Figure 1 shows the XDoclet Configurations view. The top pane allows you to add and select configurations to edit. The bottom left pane displays the "doclets" and their "entries." A doclet is equivalent to an Ant task and its entries are equivalent to Ant nested elements. The bottom right pane shows the property keys and values for each doclet.

Figure 1 shows a portion of a doclet called ejbdoclet. This doclet is used to generate the EJB interfaces and deployment descriptors. Everything in the ejbdoclet configuration is generic except for the JBoss subtask. This can be substituted or used in conjunction with an entry for a different application server, such as WebSphere or WebLogic. This makes it possible to provide support for multiple application servers, thus allowing you to remain vendor-neutral.



Here is how the generated ejb-jar.xml file compares to the JavaDoc in the EJB bean class: JavaDoc

JavaDoc

Generated

/** 

* @ejb.bean

<session>

 * display-name="EJB Capitalizer"

<display-name>EJB Capitalizer</display-name>

 * name="Capitalizer"

<ejb-name>Capitalizer</ejb-name>

 

<home>ejb.CapitalizerHome</home>

 

<remote>ejb.Capitalizer</remote>

 

<local-home>ejb.CapitalizerLocalHome</local-home>

 

<local>ejb.CapitalizerLocal</local>

 

<ejb-class>ejb.CapitalizerBean</ejb-class>

 * type="Stateless"

<session-type>Stateless</session-type>

 

<transaction-type>Container</transaction-type>

 * jndi-name="ejb/CapitalizerHome"

 

 */

</session>

The other doclet that we use is called webdoclet. Its main purpose is to generate the web.xml file, but it also has entries that allow it to generate application server-specific Web deployment descriptors. For example, it can generate the jboss-web.xml file for JBoss or the ibm-web-bnd.xmi and ibm-web-ext.xmi files for IBM Websphere Application Server.

Here is how the generated web.xml file compares to the JavaDoc in the servlet class: JavaDoc

JavaDoc

Generated Code

/** *

<servlet>

  * @web.servlet name = HelloWorldServlet"

<servlet-name>HelloWorldServlet</servlet-name>

 

<servlet-class>web.HelloWorldServlet</servlet-class>

 

</servlet>

 

 

 

<servlet-mapping>

 

<servlet-name>HelloWorldServlet</servlet-name>

  * @web.servlet-mapping url-pattern = "/Howdy"

<url-pattern>/Howdy</url-pattern>  

  */

</servlet-mapping>

 

 

After defining your configurations, a Jakarta Ant build file called xdoclet-build.xml is generated in the top level of the project. This file is included with the source code for the article. After importing our project, you should be able to go to the XDoclet Configurations menu and look through the configuration.

Figure 2. The src and gen_src Directories: You can see the files before and after Xdoclet generates them.
In order to generate the code, you must right-click on the project in Eclipse's Package Explorer view and click on 'Run XDoclet.' Again, the included source code for this article comes with all of the generated XDoclet files, so you might want to look through the files before trying to run XDoclet on your machine so you know what to expect. Figure 2 shows both the source and the generated source for the example program.

Figure 3. Capped String: The sample program in action.
After generating the XDoclet code, you probably want to package and deploy it as an EAR file. Our source code also provides the packaging configuration that generates a deployable EAR file. It is beyond the scope of this article to cover the process of EAR packaging. However, you can refer to the plugin's documentation (http://heanet.dl.sourceforge.net/sourceforge/jboss/Tutorial-1.2.2.pdf—Editor's Note: If the preceding link does not load a PDF, copy and paste the URL into a separate browser instance), which provides a detailed walkthrough on packaging. Figure 3 shows a screen shot of the application after being executed.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap