- Installing Struts Console
- Upgrading Struts Console
- Running Struts Console (Standalone)
- Using Struts Console
- Using Struts Console with Borland JBuilder
- Using Struts Console with Eclipse and IBM WebSphere Application Developer
- Using Struts Console with IntelliJ IDEA
- Using Struts Console with NetBeans and Sun One Studio (Forte)
- Using Struts Console with Oracle JDeveloper
1. Installing Struts Console
Installation is quick and easy when following these simple steps.
- Download the latest Struts Console release.
- Unzip the distribution file to the directory where you want the Struts Console software installed at.
i.e. "c:\Program Files\" on Microsoft Windows
i.e. "/home/<username>/" on Unix/Linux
The distribution contains a parent directory named after the release with all of the directories and files underneath it. For example, the 1.0 release distribution would have a parent directory called "struts-console-1.0".
2. Upgrading Struts Console
Upgrading from one version of Struts Console to a newer version is pretty straight forward. If you are only using the standalone Struts Console and no IDE plugins then all you have to do is follow the installation instructions for the new version. Each Struts Console realease has a different parent directory, thus allowing for multiple versions to be installed at once.
You may decide to remove the previous version once the new version is installed. Simply delete the parent directory for the previous version from where you installed it and the old version will no longer be installed.
If you are using the Struts Console as a plugin to an IDE then you should only need to repeat the "struts-console.jar" portion of the installation process for that IDE plugin. Please see the installation instructions for the IDE plugin.
3. Running Struts Console (Standalone)
a. Microsoft Windows Platforms
There are two ways to run the Struts Console on Windows machines:b. Unix/Linux Platforms
- Using Windows explorer, navigate to the directory where you unzipped the Struts Console distribution to. Go into the "bin" directory and double click on "console".
- Open a DOS command prompt window and navigate to the directory where you unzipped the Struts Console distribution to. Go into the "bin" directory and type "console".
- Navigate to the directory where you unzipped the Struts Console distribution to.
- If you have not already done so, change "console.sh" file permissions to be exceutable.
- Go into the "bin" directory and run "console.sh".
4. Using Struts Console
The Struts Console is a simple GUI for editing the elements of Struts and Struts-related config files. For information on what each config file element does and what values it accepts, please see the config file DTDs hyperlinked below.
Please see the FAQ page for other topics related to using Struts Console.
a. Supported Config Files
Below is a list of the config files and their associated DOCTYPEs that Struts Console supports. If your config file does not specify one of these DOCTYPEs then Struts Console will not recognize your config file and thus will not be able to open it.
Struts<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd"> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd"> <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.0//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd">Tiles<!DOCTYPE tiles-definitions PUBLIC "-//Apache Software Foundation//DTD Tiles Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd">Validator<!DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1.3//EN" "http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd"> <!DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN" "http://jakarta.apache.org/commons/dtds/validator_1_1.dtd"> <!DOCTYPE form-validation PUBLIC "-//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.0//EN" "http://jakarta.apache.org/commons/dtds/validator_1_0.dtd">JSP Tag Library<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd"> <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
b. Turning Off DTD Validation
If your config file uses an altered DTD or simply has no DTD, then the Struts Console will not be able to open your config file. To get around this you can turn off config file validation, thus allowing non-standard files to be opened.
In the standalone version of the software you can turn off this validation by selecting the option for it on the "Options" menu. For instructions on how to turn off validation for IDE plugins, see the specific plugin's section on this page.
c. Configuring Output Options
The Struts Console reads in Struts config XML files and then manipulates them in memory using the JDOM XML library. Unfortunately, XML parser libraries do not retain all of a file's original formatting when it is parsed. This leads to poorly formatted XML output when the files are saved.
By default, the Struts Console saves/outputs XML files using JDOM's built in XMLOutputter functionality, which results in poorly formatted XML files. To get around this limitation, the standalone version of the Struts Console allows for the configuration of how XML output will be generated. Underneath the "Options" menu in the standalone version you can select "Output". This will bring up a dialog with options for generating "Pretty" output. Following is an explanation of each of the output options.
NOTE: Enabling the "Pretty" output options will remove any comments and formatting from your original config files. The "Pretty" output option simply outputs config files' elements and their attributes.
- Enables and disables the use of "Pretty" output options.
- Determines the type of newlines to use. System Default is the default and recommended setting. For example, if you are using the Struts Console on a Windows system the System Default will use Windows newlines.
- Determines the number of new lines to place in between elements.
- Determines the number and type of indenting to use. Indenting is used for elements and is leveled. Each level in the element hierarchy is a level of indenting.
- Determines whether an element's attributes should each be placed on a new line or if they should be placed on the same line as the element.
- Determines whether or not empty elements, elements without sub elements, should be expanded. For example, if you have an <action> element with no child elements and have selected to expand empty elements it will be outputted as <action></action> instead of just <action/>.
- Shows an example of how the output will look with the output options applied. This changes as you change the output options.
If you attempt to open a Tiles Config file that is using deprecated settings you will get a warning dialog notifying you that the Struts Console has upgraded the Tiles Configuration. What this means is that the config file you have opened is using settings that have been changed and are no longer the favored approach. The old settings will still work with Tiles, but the Struts Console does not recognize them. Since the Struts Console does not recognize them it goes ahead and upgrades the in-memory copy of the config file to use the newer, preferred settings.
After you dismiss the dialog, you will notice that the config file will be marked as being altered. Typically this is indicated with an asterisk "*" beside the file's name, but may differ depending on how you're using (stanadlone vs. IDE plugin) Struts Console. This just means that the in-memory version of the file has been modified and is different from the saved version.
The following settings will be upgraded:
- <definition> tags should use "path" attributes and not "page" or "template" attributes
- <put> tags should use "value" attributes and note "content" attributes
- <put> tags' "type" attribute should use "page" and not "template" as attribute value
- <add> tags' "type" attribute should use "page" and not "template" as attribute value