The changes weren't very drastic. Spring reworked their xml parsing stuff - lot less xml and (better) xsd support. They simply deprecated some XML parsing classes - which were easily replaceable - updating my slightly changed parser.
What's new with this release, else than compatibility? I added 'bean by type' support to @Spring annotation. What this means is, that you don't have to define bean's name if you are aware that there is exactly one bean which satisifies class type requirement. If there are multiple such beans - which satisfy class type requirement - we use default name. What is default name - in case of the field it is filed's name, in case of method it is a simple pojo setter/getter name. Since a code tells more than words, here it is :-)
Here I would like to thank c.vidal from the forum, for initializing the whole thing - also writing much of the code / patch. This has been a long time on my todo list, just needed a little kick. ;-)private Object getObjectFromBeanFactory(Spring spring, String defaultBeanName, Class beanType) throws Exception
{
BeanFactory beanFactory = (BeanFactory) Util.lookup(spring.jndiName(), BeanFactory.class);
String beanName = spring.bean();
if (beanName != null && beanName.length() > 0)
{
return beanFactory.getBean(beanName, beanType);
}
else
{
// by type injection
if (beanFactory instanceof ListableBeanFactory)
{
ListableBeanFactory lbf = (ListableBeanFactory) beanFactory;
Map beans = lbf.getBeansOfType(beanType);
if (beans.size() > 1)
{
Object bean = beans.get(defaultBeanName);
if (bean == null)
{
throw new IllegalArgumentException("More than one bean of type: " + beanType);
}
return bean;
}
else if (beans.size() == 1)
{
return beans.values().iterator().next();
}
else
{
throw new IllegalArgumentException("No such bean by type: " + beanType);
}
}
else
{
// bean factory is not listable - use default bean name
return beanFactory.getBean(defaultBeanName, beanType);
}
}
}
Ok, we are slowly getting unnecessary definition info out of the @Spring annotation. Currently working on getting that jndiName attribute out too. Should be done something similar to EJB3 PersistenceContext default unit name - when there is just one persistence context in your deployment, you don't need to supply unit name.
As JBoss Microcontainer is getting more and more momentum - with new JBoss5 and its deployers - work in progress also involves rewriting SpringDeployer to new deployers concept - see JIRA JBMICROCONT-26.
Just like to invite everybody to my JBossWorld Berlin presentation - Microcontainer and contextual injection.
Have fun using compatible SpringDeployer :-).
ps: if somebody needs some examples redone / fixed - just let me know on the forum (didn't have time to test them ... but did test Deployer with my current job project - it works :-)