Building custom Spring config tags for a framework

I have a framework which currently requires pretty verbose setup in Spring:

   <bean id="dpHibernateRemotingAdapter"
            class="org.springframework.flex.core.ManageableComponentFactoryBean">
            <constructor-arg value="org.dphibernate.adapters.RemotingAdapter" />
            <property name="properties">
                    <value>
                            {"dpHibernate" :
                            {
                            "serializerFactory" : "org.dphibernate.serialization.SpringContextSerializerFactory"
                            }
                            }
    </value>
            </property>
    </bean>
    <bean id="dataAccessService" class="org.dphibernate.services.SpringLazyLoadService"
            autowire="constructor">
            <flex:remoting-destination />
    </bean>
    <bean id="dpHibernateSerializer" class="org.dphibernate.serialization.HibernateSerializer"
            scope="prototype">
            <property name="pageSize" value="10" />
    </bean>
    <bean id="dpHibernateDeserializer" class="org.dphibernate.serialization.HibernateDeserializer"
            scope="prototype" />

I'd like to look at providing a more elegant configuration tag, similar to user-friendly tags used elsewhere in spring:

 <context:annotation-config />
 <mvc:annotation-driven />
 <tx:annotation-driven />
 <flex:message-broker/> 

etc.,

However, I don't really know where to start.

How does this approach work? What are these tags called? What's their base class?

If someone could p开发者_Python百科oint me to the class names in the source (ideally, the <flex:message-broker />, as that's the closest problem set to my project), then I can go from there. I just don't really know where to start!

Custom XML namespaces are certainly possible (see Appendix D), but in my experience a royal pain to get working properly.

I strongly recommend that instead you use @Bean-style configuration. This lets you use Java to compose your bean graphs, instead of XML. Not only can it be much more concise in certain situations, it's properly type-safe, and more easily re-used.

Either way, you'll end up writing some Java that wires objects together. It's a question of how you want to expose that.

See Appendix D. Extensible XML authoring.