You access most of the features of Spring IDE when editing the configuration files for your application. Spring IDE itself does not provide any XML editing capabilities; instead, it uses standard extension mechanisms to add features to any Eclipse text editor. This means that you can use Spring IDE with the plain text editor included with Eclipse or with any one of the many XML plugins available for the Eclipse platform.
We have found that Spring IDE works best in conjunction with a full XML editor such as the freely available XMLBuddy (http://xmlbuddy.com/) from Bocaloco Software or the fantastic <oXygen/> XML Editor (www.oxygenxml.com) from SyncRO Soft. We have used both of these XML editors to great effect with Spring IDE, and we recommend that you give them both a try. For the examples in this appendix, we used the <oXygen/> XML Editor version 5.0.
Before you can take advantage of Spring IDE's features for editing your configuration files, you must tell Spring IDE which files in your application you want it to work on. To do this, right- click the project icon in Navigator and choose Properties from the menu to bring up the project's Properties dialog. In the panel list on the left side of the Properties dialog, you will see a list of property panels for the project, one of which is the Spring Beans Project; click this to bring up the Spring Beans Project properties sheet.
The Spring Beans Project properties sheet contains two tabs: Config Files and Config Sets. The Config Files tab allows you to configure which files Spring IDE should treat as Spring configuration files. The Config Sets tab is covered later in the section entitled "Using Multiple Configuration Files." To add files to the Config Files set of your Spring project, use the Add button to select all the XML files present in your application.
Figure C-8 shows the property sheet for a Spring Beans–enabled project containing four separate Spring configuration files.
Figure C-8: Configuring Spring IDE
If a configuration file is not configured in the Spring Beans Project tab, then you cannot use Spring IDE's features when editing that file.
One of most frustrating aspects of developing a Spring application is the number of runtime errors that arise during development from misspelled class names in the configuration file. Before we started using Spring IDE, we were used to the configure/run/reconfigure cycle of creating Spring applications that resulted from misspelled class names. Using Spring IDE, we can validate class names contained in our configuration files at design time, thus reducing the number of runtime errors we experience during development.
To experience an example of this, try constructing a <bean> definition using an invalid class name, such as that shown in Figure C-9.
Figure C-9: Detecting invalid class names
Here you can see that we used a nonexistent class name for the testBean definition, and this is highlighted by Spring IDE using the error icon next to the offending line of XML. In addition to the error icon shown in the code editor, Spring IDE adds a comprehensive description of the error to the Eclipse Problems window, as shown in Figure C-10.
Figure C-10: Viewing configuration problems
This is one of our favorite Spring IDE features, simply because it saves so much time by reducing the number of runtime errors we experience during development.
Another big annoyance when developing Spring applications is the number of runtime errors caused by misspelled property names in configuration files. Just like misspelled class names, this is a problem that can easily present itself and is a frequent cause of frustration for developers. Using Spring IDE, you can validate that the bean properties you configure in your configuration files correspond to actual setXXX() methods in the bean class.
Figure C-11 shows what happens when you try to configure an invalid property when you are using Spring IDE.
Figure C-11: Configuring invalid properties
As you can see, Spring IDE highlights the invalid property name right in the code window using the error marker. As with invalid class names, errors regarding invalid property names are shown in the Eclipse Problems window (see Figure C-12).
Figure C-12: Identifying invalid property names
You can validate many bean references using a standard XML editor or parser; however, a reference to a parent element cannot be validated in this way, because it is possible that the parent bean may exist in a completely different configuration file and this functionality is not supported by standard XML parsers.
With Spring IDE, it is possible to validate that the bean specified as the parent of another bean does exist, as shown in Figure C-13.
Figure C-13: Validating parent bean existence
As you can see from Figure C-13, Spring IDE highlights references to nonexistent parent beans directly in the code editor using the error marker. As you would expect, and as Figure C-14 shows, this is backed up by an entry in the Problems window.
Figure C-14: Identifying nonexistent parent beans
In most nontrivial Spring applications, it is common to see the configuration spread across multiple physical configuration files. In this case, Spring IDE allows you to group configuration files into named Config Sets. When working on a file in a Config Set, Spring IDE checks all files in the Config Set when trying to resolve parent bean references.
To configure a Config Set, open up the Spring Beans Project property sheet for your project and choose the Config Sets tab. In the Config Sets tab, click the New button to bring up the Create New Spring Beans Config Set dialog, as shown in Figure C-15.
Figure C-15: Adding a Config Set
To create the Config Set, give it a meaningful name and choose the files you want to be part of it. By default, Spring IDE checks to see if a bean definition in one file of the Config Set overrides a definition in another file in the set. Figure C-16 gives an example of this.
Figure C-16: Identifying bean overriding
Here, the contextTwo.xml file is part of a Config Set with the contextOne.xml file. Both files contain a definition of the bean bean, and Spring IDE flags the definition in contextTwo.xml as an invalid override using error marking. In many cases, bean overriding is done by mistake and indicates an error in the configuration, but in some cases, such as when you are using nested ApplicationContexts, bean overriding is a desirable feature. In this case, Spring IDE allows you to disable overriding warnings for a Config Set by checking the Enable bean override box when you are creating the Config Set.