Enhancing IDE support for custom Spring Namespace elements

Spring offers many namespaces for the XML Application Context configuration to make your life a lot easier. Although not often needed, it is easy to create your own namespaces and provide custom elements. It makes configuration easier. However, I noticed that the some of the IDE support is lost. By chance, I found an undocumented feature that resolves this issue.

Spring namespace support

If you have ever configured Spring AOP aspects using plain bean definitions, you should know how powerful Spring Namespace support is. Instead of wiring lots of beans, just one or two elements take its place.

If you want to create your own namespaces for a Spring Context, you’ll find yourself creating an XSD file, a NamespaceHandler and BeanDefinitionParsers. Sounds complicated, but all there is to it is translating the XML in an application context into a BeanDefinition.

But that’s not what I want to dive into in this article. Spring has documented it pretty well in its reference documentation. It’s what happens in my IDE (IntelliJ, but similar stuff probably happens in Eclipse and SpringSource Tool Suite) that made me look for a solution.

First of all, the IDE starts warning me about “Custom Spring Beans” not being parsed. There is a quick fix for it, but it pops back as soon as any changes are made. It’s just a warning, everything will work fine at runtime. But annoying nonetheless.

But even more annoying is that the IDE doesn’t help me check whether references to other beans exist or are of the correct type. It does to for other beans, why not for mine?

The tool namespace

When browsing my way through one of Spring’s own XSD’s, I accidentally stumbled upon the tool namespace (http://www.springframework.org/schema/tool). At first, I assumed that it was just another namespace. But it seemed to be used in a completely different way.

The namespace was used inside the XSD:

The xsd:appinfo element is used to provide information to applications parsing the XSD. It may contain any number and type of elements.

I took my chances and started adding the tool:annotation elements in my XSD. Two of the elements in the tool namespace are particularly useful.

When an attribute represents a reference to a bean of a certain type, you use the following structure:

<xsd:attribute name="myattribute" use="optional" type="xsd:string">
    <xsd:annotation>
        <xsd:appinfo>
            <tool:annotation kind="ref">
                <tool:expected-type type="expected.type.of.Bean" />
            </tool:annotation>
        </xsd:appinfo>
    </xsd:annotation>
</xsd:attribute>

When a custom element produces a bean of a certain type, you can tell the IDE as follows:

<xsd:element name="MyElement">
    <xsd:annotation>
        <xsd:appinfo>
            <tool:annotation>
                <tool:exports type="fully.qualified.ClassName" />
            </tool:annotation>
        </xsd:appinfo>
    </xsd:annotation>
    <!-- Acutal element definition here -->
</xsd:element>

You can repeat the tool:exports element if an element produces more than one bean.

You can probably guess the result:

Not only are the annoying warnings gone, the IDE now also knows what type of bean is expected in an attribute, and uses this information in the autocomplete feature. Only beans of the expected type (or subtypes) are offered in the auto-complete.

Conclusion

When creating custom namespaces for Spring, the tool namespace allows you to tell IDE’s (tested with IntelliJ, but I can’t imagine it won’t work for SpringSource Tool Suite) what type of beans elements produce and which types the custom attributes should reference.

For an XSD with examples on how to use it, take a look at axon-code.xsd.

The tool namespace provides a little more elements than just exports and expected-type, but I didn’t quite figure out what they’re used for. If you know, don’t hesitate to write it in a comment.