Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

New in Spring 2, anyone can register their own namespace in the Spring XML configuration file and either insert complete elements or decorate existing ones. This whiteboard is to explore how the Struts 2 XML configuration could be merged into the Spring XML file with its own namespace.

Proposal 1 - Beans as actions

For this proposal, we would reuse beans as actions by decorating them with a few key attributes, then let packages be defined in their full glory as siblings. The result would look something like this:

Code Block
langxml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:s2="http://struts.apache.org/schema/2.0/package"
      xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://struts.apache.org/schema/2.0/package http://struts.apache.org/schema/struts-2.0-package.xsd">

   <s2:package name="somePackage" extends="struts-default" namespace="/foo">
      <s2:default-action-ref>index</s2:default-action-ref>
   </s2:package>

   <bean id="bar" class="com.myapp.BarAction" s2:package="somePackage">
      <s2:result name="success">/bar.jsp</s2:result>
   </bean>
</beans>

The advantage here is that actions can easily leverage all the features beans have to offer with little duplication. The disadvantage is it isn't immediately obvious what actions are in what packages.

Proposal 2 - Beans as actions, but referenced in packages

Much like proposal #1, we use beans as actions, but here they have to be referenced within the package and there are no decoration attributes. For example:

Code Block
langxml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:s2="http://struts.apache.org/schema/2.0/package"
      xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://struts.apache.org/schema/2.0/package http://struts.apache.org/schema/struts-2.0-package.xsd">

   <s2:package name="somePackage" extends="struts-default" namespace="/foo">
      <s2:default-action-ref>index</s2:default-action-ref>
      <s2:action ref="bar">
         <s2:result name="success">/bar.jsp</s2:result>
      </s2:action>
   </s2:package>

   <bean id="bar" class="com.myapp.BarAction" />
</beans>

The advantage is that the configuration is much like existing Struts 2 config, but on the other hand, you don't really seem to gain much by merging the XML configuration.

Motivations

Sure, it is kinda nice to nix one more configuration file, but since the configurations don't share much, you may wonder why merge them at all. Well, my primary motivation is not to save typing for normal Struts 2 apps, but pave the way for Struts 2 OSGi enabled apps by leveraging Spring Dynamic Modules (SDM) . Spring has put a lot of thought into making OSGi easy to use for Spring apps and it makes sense to build on all this effort rather than reinventing it. Therefore, the Struts 2 XML needs to be in the Spring configuration to make the most use of SDM's configuration loading and management code.