Re: [Springframework-developer] Creating reusable component packages with Spring

[<co...@di...>]

Hi all,

We have just tried to solve the same challenge as James. We have found a 
partial solution by putting the applicationContext.xml files into each 
module jar.

For example, if we have a module called module1, we have a 
"module1-applicationContext.xml" which goes to a "spring" folder inside 
the module1.jar. Then, if we want to use the module1 into one of our 
webapps, we only have to add the jar into the WEB-INF/lib folder and add 
its applicationContext.xml file to the config locations, like this:

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:spring/module1-applicationContext.xml
      classpath:spring/module2-applicationContext.xml
      classpath:spring/module3-applicationContext.xml
      applicationContext.xml
    </param-value>
  </context-param>

It works very well, except for those beans whose properties can be 
modified by more than one module. One example is the 
org.springframework.orm.hibernate.LocalSessionFactoryBean  
mappingResources property. Each of our modules have their own hibernate 
mappings, with relationships between modules, and all of them have to be 
handled by the same SessionFactory.

One way to handle it could be to extend the spring beans definition 
format to allow to modify already defined beans, instead of redefining 
them, maybe something like:

module1-applicationContext.xml:
  <bean id="mySessionFactory" definition="add">
    <property name="mappingResources">
      <list>
        <value>module1/Element.hbm.xml</value>
      </list>
    </property>
  </bean> 

module2-applicationContext.xml:
  <bean id="mySessionFactory" definition="add">
    <property name="mappingResources">
      <list>
        <value>module2/Order.hbm.xml</value>
        <value>module2/Line.hbm.xml</value>
      </list>
    </property>
  </bean> 

For now, we have solved the LocalSessionFactoryBean issue by extending 
it and allowing the list of mapping resources to be added by other 
beans. Also we have developed a simple BeanPostProcessor which allows us 
to put the hibernate mappings per module, and it adds them to the 
extended LocalSessionFactoryBean automatically.

Anyway, we are looking also for a more general solution, like the one 
stated by Rod. Our projects are based on portlets, and we would like to 
extract common modules of each portlet webapp to be handled by a common 
parent context. I still haven't tried the 
ContextSingletonBeanFactoryLocator class.
Rod Johnson wrote:

> James
>
> I agree that this would be useful--especially for Geronimo, which you 
> and I have discussed before. In fact it's something we could consider 
> for 1.2, so I'd like to see a discussion here about what it should 
> entail.
>
> I also agree with Mike re no enforcement of JNDI for cross-referencing 
> if at all possible.
>
> I would like a deployment unit to:
>
> - accommodate any config format, not just XML
> - allow a hierarchy of contexts in a single deployment unit
>
> Rgds
> Rod
>
> jas...@ma... wrote:
>
>> Its an interesting question. Just one immediate thought; I can see 
>> there being a need for a Spring deployment unit of some kind; e.g. a 
>> jar containing an applicationContext.xml file in APP-INF/ or 
>> something - maybe having any additional jars required inside the jar 
>> in APP-INF/lib.
>>
>> One there's a deployment unit we can add native support to Geronimo 
>> (and other containers could support it too) plus we could support hot 
>> deployment of units inside Spring natively rather than relying on the 
>> J2EE deployment units (WAR / EAR / RAR)
>>
>> If there was a deployment unit; the only real issue is how to handle 
>> cross-deployment unit references; but we could always use JNDI / JMX 
>> for that or use a hierarchy of BeanFactory instances.
>>
>>
>> On 9 Nov 2004, at 22:51, James Cook wrote:
>>
>>> We have been developing a large enterprise application using Spring 
>>> and it
>>> has proven to be a very effective framework. We use the Data access
>>> abstractions heavily, along with transaction management and Hibernate
>>> support.
>>>
>>> Now that we have most of the concepts down, some coworkers and 
>>> myself are
>>> now considering the challenges inherent in packaging our business 
>>> objects,
>>> service layers, spring configuration files, etc. into reusable 
>>> component
>>> packages. We want to be able to give other developers in the company 
>>> a jar
>>> file that contains all of this content and simply drop it into their
>>> project.
>>>
>>> There are a lot of similarities (and differences) between what we 
>>> face and
>>> what EJB components deal with. EJB has solutions for mapping 
>>> dependencies in
>>> a component package to the primary application (ejb-ref, etc.) and 
>>> we are
>>> beginning to talk about how to accomplish similar behavior using 
>>> Spring.
>>>
>>> Ultimately, there are probably many nuances to this process that we 
>>> won't
>>> know until we actual do it, but I was wondering if the development 
>>> team has
>>> some insight into some of the Spring features that already exist 
>>> that can
>>> assist in some of these challenges? Perhaps also there are some 
>>> features
>>> that are on the drawing board to assist in this matter also?
>>
-- 
Cèsar Ordiñana
CTO, DiSiD SLL  http://www.disid.com
Parc Tecnològic. Av. Benjamin Franklin, 12
Centre de Negocis Edifici CEEI
46980 València - España
Tel +34 646 10 92 84