[sca-j] NEW ISSUE: SCA Spring C & I specification need to mention how SCAruntime should load multiple application context files.

[Ramkumar R1 <ramkumar_rj@in.ibm.com>]

Raiser:        
       Ramkumar Ramalingam

Target:        sca-springci-1.1-spec-WD01.doc
 
Description:
 
The SCA Spring Client and Implementation specification should mention how
SCA runtime should deal with loading multiple application context files
using Spring Framework. Since there could be different possible ways to
load multiple application context in spring framework as shown below...


Scenario 1:
Multiple application context can be loaded
using <import resource=""/> element of the spring configuration
file, as shown below.

<beans>

   <import resource="application-context1.xml"/>

   <import resource="application-context2.xml"/>

           <!-- this definition is not required, and the bean SCAReference could also

         have been inherited from the parent context -->

   <sca:reference name=”SCAReference” type="com.xyz.SomeType"/>

        <bean name="X">

           <property name="foo" ref="Y"/>

        </bean>

        <bean name="Y">

           <property name="bar" ref="SCAReference"/>

           <property name="goo" ref="sca-property-name"/>

        </bean>

   <!-- expose an SCA property named “sca-property-name” -->

   <sca:property name="sca-property-name" type="java.lang.String"/>

</beans>

As mentioned in the last paragraph of Section 2.1 of the specification, The SCA runtime is responsible for setting up the references and exposing them as beans with their indicated names in the spring context.  This is usually accomplished by creating a parent context which has the appropriate beans defined and the context supplied by the implementation becomes the child of this context.  Thus, the references – e.g. the “SCAReference” that bean “Y” uses for it’s “bar” property – are available to the context.

While importing multiple application context files using import, all the beans/references/properties defined in the imported application context also becomes part of the importing application context, so in this case the approach suggested by the specs of creating a parent context which has the appropriate beans defined for the sca:references & sca:properties, for the context supplied by the implementation works well.

Scenario 2:
Multiple application context can be loaded using ClassPathXmlApplicationContext bean of the spring configuration file, as shown below.

<beans>
    <bean id="beanRefFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
        <constructor-arg>
           <list>
                <value>application-context1.xml</value>
                    <value>application-context2.xml</value>
                <value>application-context3.xml</value>
           </list>
        </constructor-arg>
    </bean>
</beans>

Here the spring framework creates an application context using ClassPathXmlApplicationContext for the bean id "beanRefFactory", by loading all the application context files mentioned in the list. Also the spring framework creates another application context for the context supplied by the implementation (i.e., in our case for the above context which defines the beanRefFactory bean). By default in spring framework, the context created using the file supplied by the implementation becomes a parent context for the context created using ClassPathXmlApplicationContext.

In this scenario its quite possible that, the application_context1.xml and application_context2.xml might contain implicit/explicit sca:references & sca:properties. As suggested by the specs of creating a parent context which has the appropriate beans defined for the sca:references & sca:properties, for the context supplied by the implementation would not solve the issue, because as per hierarchy the parant context for the ClassPathXmlApplicationContext is going to be the context supplied by the implementation. So when the context created using ClassPathXmlApplicationContext wants appropriate beans definition for the sca:references & sca:properties defined, we will not have them defined in the parent instead we will be having them defined as part of the parent to parent context. So we need a new solution to resolve this issue.

Scenario 3:
Multiple application context can be loaded using FileSystemXmlApplicationContext bean element of the spring configuration file, as shown below.

<beans>
    <bean id="beanRefFactory" class="org.springframework.context.support.FileSystemXmlApplicationContext">
        <constructor-arg>
           <list>
                <value>application-context1.xml</value>
                    <value>application-context2.xml</value>
                <value>application-context3.xml</value>
           </list>
        </constructor-arg>
    </bean>
</beans>

This one works very much similar to Scenario 2, except that the class used in this case is FileSystemXmlApplicationContext for creating the application context for beanRefFactory bean, but the issue remains the same as Scenario 2.


Proposal:

As mentioned for Scenario 1, we are in good shape as the suggested approach mentioned in Section 2.1 of the specs holds good for this case.

For Scenario 2 and Scenario 3, the specs need to mention the following to support loading of multiple application context using ClassPathXmlApplicationContext and FileSystemXmlApplicationContext.

In scenarios where the spring application context tries to loads multiple application context files using the ClassPathXmlApplicationContext OR FileSystemXmlApplicationContext as shown below.

// application_context.xml
<beans>
    <bean id="beanRefFactory" class="org.springframework.context.support.ClassPathXmlApplicationContext">
        <constructor-arg>
           <list>
                <value>context1.xml</value>
                    <value>context2.xml</value>
                <value>context3.xml</value>
           </list>
        </constructor-arg>
    </bean>
</beans>

Here the application_context.xml file will act as the context supplied by the implementation (i.e., the file mentioned in the location attribute of <implementation.spring> element). As the aim is to support loading multiple application context, in these scenario the application_context.xml can only have one bean defined within as shown above (i.e., a bean of class ClassPathXmlApplicationContext OR FileSystemXmlApplicationContext). Other bean definitions OR sca:references OR sca:service OR sca:property definitions will not be allowed.

Now the SCA runtime (after verifying that we have only one bean defined in such cases) should programmatically create a ClassPathXmlApplicationContext/FileSystemXmlApplicationContext using the list of files mentioned as constructor argument, instead of following the usual way of creating an application context for the context supplied by the implementation. In this case, there will not be any application context created for the context supplied by the implementation (i.e., application_context.xml file).

The SCA runtime is responsible for reading all the sca:references and sca:properties used in the list of context files that are mentioned in the application_context.xml and expose them as beans with their indicated names in the spring context called SCAParentContext. This SCAParentContext will now act as a parent context for the programmatically created ClassPathXmlApplicationContext/FileSystemXmlApplicationContext.

This solution looks ideal for such scenarios.


Thanks & Regards,

R Ramkumar
Open Source SOA Development - Apache Tuscany
Phone : 91-80-41927623
Email  : ramkumar_rj@in.ibm.com