Using this container in Websphere (6.0, 6.1, 7) some problems occur when you want to do the following:

• You use a resource environment reference for your destination, specified in the web.xml, for the Destination.
• You use the property destinationName on the DefaultMessageListenerContainer in combination with a JndiDestinationResolver to look up your resource environment reference like this: java:comp/env/jms/(your destination)

problem
When you try to start the application, you will get an exception like this: javax.naming.NameNotFoundException: Name "comp/env/jms/(your destination)" not found in context "java:"., although you are sure that your resource environment reference is defined correctly.

cause
The cause of this problem lies in the fact that the lookup occurs in a Thread started by the DefaultMessageListenerContainer, which is unmanaged by Websphere. This thread will not have the jndi queue bindings in its InitialContext.

solution
You can either:

1. Specifiy the jndi object beforehand with a JndiObjectFactoryBean, or a
<jee:jndi-lookup id="myqueue" jndi-name="java:comp/env/jms/(your destination)"/>, and then
   setting the destination property of the DefaultMessageListenerContainer to the ref myqueue, so no actual lookup occurs within the thread of the listener itself.
2. Delegate the listener’s thread to Websphere with the help of the Spring class WorkManagerTaskExecutor. You can then set the property taskExecutor on the message listener container to reference this class. See the IBM article here for details on how to do this.

Alles goed en wel, maar wat nu als je component, behalve referenties naar andere beans, ook simpele String en Integer values nodig heeft? De enige mogelijkheid die tot nu toe had is de beandefinitie alsnog in je applicationContext op te nemen.

Spring 3.0 krijgt gelukkig de annotatie @Value waarmee je dit kan bereiken. Je kan dan je method als volgt annoteren:

@Value("#{my.property}")
public void setDezeProperty(String myProperty) {
...
}


In Spring 2.5 bestaat deze voorziening nog niet, maar Op StackOverflow heeft iemand een PropertyAnnotationPlaceholderConfigurer geschreven die precies hetzelfde doet.

In Spring 2.5 kan je dan je method als volgt annoteren:

@Property(value="my.property")
public void setDezeProperty(String myProperty) {
...
}


Waarbij my.property dan de naam van een property is die uit een property file komt.

De listeners zijn geimplementeerd met Spring MessageListenerContainer types, en staan gewired in de Spring applicatie context:

  <bean id="myMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer">
  ...properties..
</bean>

Het issue is nu dat de JMS listeners dienen in bepaalde omgevingen (zoals een aantal acceptatie en productie omgevingen) geactiveerd dienen te worden, en in andere omgevingen niet. Dit moet op zo’n manier kunnen dat het voor een beheer organisatie gemakkelijk is deze componenten aan en uit te zetten.

Je kan een Spring component natuurlijk uitcommentarieren in de applicationContext, maar je wilt een beheerclub eigenlijk niet opzadelen met zo’n taak, omdat deze taak vrij technisch is en behoorlijk foutgevoelig. Bovendien wil je niet dat beheer in je applicatie wiring wijzigingen gaat zitten maken. Import / configuratie van verschillende applicationContexts in verschillende omgevingen levert ook teveel overhead op.

Hoe maken we dit nu toch beheersbaar?

Een mogelijkheid zou zijn om het lazy-init attribuut van een Spring bean te wijzigen. Voor een bean als een MessageListenerContainer zou dit betekenen dat in het geval van lazy-init="true" de bean nooit wordt opgetuigd, aangezien er geen andere beans zijn die een referentie naar deze bean hebben.

  <bean id="myMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer" lazy-init="true">
  ...properties..
</bean>

Echter levert dit nog steeds geen configurabel component voor beheer op, in het bovenstaande voorbeeld wordt de bean nooit gestart. Je zou geneigd zijn om te zeggen: los het met een externe property op:

  <bean id="myMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer" lazy-init="${myListener.enabled}">
  ...properties..
</bean>

De PropertyPlaceholderConfigurer postprocessor kan dit echter niet aan, aangezien deze wel in kan grijpen na de constructie van het object maar niet ervoor. Er is ook geen mogelijkheid om via een eigen geschreven postprocessor het aanroepen van een init methode op een bean (wat in het geval van een MessageListenerContainer daadwerkelijk de JMS connnectie opzet) te onderdrukken.

Om toch het issue te kunnen oplossen heb ik een ConditionalInstantiationBean geschreven, die op basis van een beanName string property en een instantiate boolean een Spring bean uit de context ophaalt, waardoor deze geconstrueerd en geinitializeerd wordt:

package nl.project.util;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
import org.springframework.beans.factory.InitializingBean;

/**
 * A Spring bean-factory-aware bean that will onyl instantiate the bean with
 * name beanName if the property instantiate is set to true. Use this bean for
 * being able to control instantiation of beans depending on a true|false value
 * that is imported as a property from an external property file.
 *
 * It is not possible to do this with the "lazy-init" because you cannot switch
 * this value with an external property.
 *
 */
public class ConditionalInstantiationBean implements BeanFactoryAware,
        InitializingBean {

    /** Logger available to subclasses */
    protected final Log logger = LogFactory.getLog(getClass());

    private BeanFactory beanFactory;

    private String beanName;

    private boolean instantiate;

    /**
     * Will instantiate the target bean defined by beanName if instantiate is
     * set to true.
     */
    public void afterPropertiesSet() throws Exception {
        if (instantiate) {
            if (logger.isDebugEnabled()) {
                logger.debug("Instantiating bean with name '" + beanName + "'");
            }
            //keeping result is not necessary since we only want to instantiate
            // the bean.
            beanFactory.getBean(beanName);
        } else {
            if (logger.isDebugEnabled()) {
                logger.debug("Skipping instantiation of bean with name '"
                        + beanName + "'");
            }

        }
    }

    /*
     * (non-Javadoc)
     *
     * @see org.springframework.beans.factory.BeanFactoryAware#setBeanFactory(org.springframework.beans.factory.BeanFactory)
     */
    public void setBeanFactory(BeanFactory bf) throws BeansException {
        this.beanFactory = bf;
    }

    /**
     * @param beanName
     *            The beanName to set.
     */
    public void setBeanName(String beanName) {
        this.beanName = beanName;
    }

    /**
     * @param instantiate
     *            The instantiate to set.
     */
    public void setInstantiate(boolean instantiate) {
        this.instantiate = instantiate;
    }
}

En hieronder de Spring configuratie:

  <bean id="conditionalInstantiationBean" class="nl.project.util.ConditionalInstantiationBean">
    <property name="beanName" value="myMessageListenerContainer"/>
    <property name="instantiate" value="${listener.enabled}"/>
</bean>

Hierbij de volgende toelichting:

• De property beanName is een String en geen referentie naar de listener. Een referentie zou immers betekenen dat de listener bean automatisch wordt opgetuigd!
• De property instantiate kan nu met een PropertyPlaceholderConfigurer geexternaliseerd worden, bijvoorbeeld in een property file. In de property file komt dan een listener.enabled property die door een beheerclub aan-en uitgezet kan worden!
• Het lazy-init attribuut van de listener dient wel op true te worden gezet, om automatische activering van de bean te voorkomen:

  <bean id="myMessageListenerContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer" lazy-init="true">
  ...properties..
</bean>

Verbeteringen zouden nog zijn: testen of de target bean wel “lazy” geinitialiseerd wordt, aangezien anders de ConditionalInstantiationBean natuurlijk niets te doen heeft.
Ik kan me ook voorstellen dat iemand een mooie AOP oplossing voor dit issue heeft. Als dat zo is, hoor ik het graag!

Wat lastiger wordt het als je meer xml-to-object achtige configuraties wil gaan toepassen waarbij de mapping van xml naar object(en) niet altijd triviaal of 1-op-1 is. Nu biedt Apache daar een prima oplossing voor in de vorm van Commons Digester, een component die een xml configuratie, aan de hand van een set van rules, je java objecten gaat instantieren. Voor de precieze werking van Digester kan je terecht bij de betreffende Apache site.

De logica om de Digester te initializeren zie ik nog steeds vaak in de code zelf staan. In dit artikeltje gaan we de initialisatie van Digesters en het parsen van input xmls geheel aan Spring uitbesteden.

We pakken een voorbeeldje waarin vanuit een xml structuur met films een java bean genaamd FilmCollectie wordt gemaakt met daarin een lijst van Film beans. Uiteraard zou dit eenvoudige voorbeeld ook met normale Spring bean configuratie kunnen, maar gaat gaat even om het idee dat we een Digester willen gebruiken.

In code wordt vaak onderstaande structuur gebruikt om een Digester te initialiseren en xml te parsen:

InputStream is = getClass().getResourceAsStream("movies.xml");

Digester digester = new Digester();

digester.addObjectCreate("mijnFilms", FilmCollectie.class);

digester.addObjectCreate("mijnFilms/film", Film.class);

digester.addBeanPropertySetter("mijnFilms/film/titel", "titel");

digester.addSetNext("mijnFilms/film", "addFilm");

FilmCollectie mijnCollectie = (FilmCollectie) digester.parse(is.getInputStream());

Het enige wat ik als developer wil gebruiken is de uiteindelijke FilmCollectie (die op de laatste regel beschikbaar komt). We willen nu Spring verantwoordelijk maken voor het initialiseren van de Digester en het parsen van de input xml.

In het voorbeeld definieren we eerst, voor de volledigheid, een client die gebruik gaat maken van de objecttree met films:

<bean id="movieManager" class="MovieManager">
  <property name="movies" ref="movies"/>
</bean>

We willen graag zowel de Digester rules als de input van het file system trekken. De input data zou er als volgt uit kunnen zien:

<mijnFilms>

<film>

<titel>Persepolis</titel>

</film>

<film> 

<titel>American Gangster</titel>

</film>

</mijnFilms>

En de digester rules als volgt:

<digester-rules>

  <object-create-rule pattern="mijnFilms" classname="FilmCollectien"/>

  <object-create-rule pattern="mijnFilms/film" classname="Film"/>

  <property-setter-rule pattern="mijnFilms/film/titel" name="titel"/>

  <add-set-next-rule pattern="mijnFilms/film method="addFilm"/>

</digester-rules>

Nu heeft de Digester component een DigesterLoader factory aan boord die je in staat stelt met een factory method je gewenste bean plus onderliggende beans op te leveren:static Object load(URL digesterRules, ClassLoader classLoader, InputStream input)
Deze factory willen we graag gebruiken in Spring op de objecttree op te leveren.
Nu dient de Digester opgetuigd te worden. Omdat de DigesterLoader een factory is, dienen we die ook zo in Spring te configureren. Voor het gemak vullen we even een null is voor het tweede argument (de classloader).

<bean id="movies" factory-method="load" class="org.apache.commons.digester.xmlrules.DigesterLoader">
  <constructor-arg ref="...een url..."/>
  <constructor-arg><null/></constructor-arg> 
  <constructor-arg ref="...een inputStream..."/>
</bean>

Het probleem is nu: de load method verwacht een URL en een InputStream als constructor arguments van de factory method. Spring geeft je wel de mogelijkheid om Resources te definieren, die een eenduidige manier van omgaan met low-level resources implementeren.

We definieren twee resources voor de digester-rules en de xml input. De xml bestanden worden in dit voorbeeld van het classpath geladen.

<bean id="digesterRulesResource" class="org.springframework.core.io.ClassPathResource">
  <constructor-arg value="digester-rules.xml"/>
</bean>
<bean id="xmlInputResource" class="org.springframework.core.io.ClassPathResource">
  <constructor-arg value="movies.xml"/>
</bean>

We hebben nu twee Resources die de digester rules en input xml bestanden representeren. Hoe komen we nu aan een InputStream en een URL die voor de DigesterLoader nodig is?

Spring heeft een bean genaamd PropertyPathFactoryBean waarmee je een bean kan optuigen die eigenlijk een property van een andere bean is. Omdat een Resource de methods getURL() en getInputStream() heeft, kunnen we met behulp van deze Spring bean de URL en InputStream uit de Resources halen.

<bean id="xmlInputStream" class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
  <property name="targetBeanName" value="xmlInputResource"/>
<property name="propertyPath" value="inputStream"/>
</bean>
<bean id="digesterRulesURL" class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
  <property name="targetBeanName" value="digesterResource"/>
<property name="propertyPath" value="URL"/>
</bean>   

Het resultaat van bovenstaande declaratie is een bean met naam xmlInputStream van type InputStream en een bean met naam digesterURL met type URL. Deze beans kunnen nu geinjecteerd worden in de movies bean.

<bean id="movies" factory-method="load" class="org.apache.commons.digester.xmlrules.DigesterLoader">
  <constructor-arg ref="digesterRulesURL"/>
  <constructor-arg><null/></constructor-arg> 
  <constructor-arg ref="xmlInputStream"/>
</bean>

Het resultaat hiervan is een MovieManager die een property movies heeft van het type FilmCollectie. Dit object is gemaakt met behulp van de Digester zonder een letter Java code te schrijven voor het optuigen van de digester en het parsen van een input bestand. Met behulp van de PropertyPathFactoryBean kunnen we de InputStream en URL van elke willekeurige resource halen. De digester rules en input xml kunnen bijvoorbeeld ook in de applicationContext zelf worden opgenomen.

Verder zijn er natuurlijk mogelijkheden tot verkorte schrijfwijze van de PropertyFactoryBean waarvoor ik verwijs naar de Spring Appendix.