Seam Spring 3.1.0.Alpha1 released

Congrats !

From what I understood, using 'Implicit Spring context bootstrapping' avoids the need to add @Veto to each Spring bean class (life saviour !).

Can I specify the Spring WebApplicationContext in 'Implicit Spring context bootstrapping' ?

For instance something like (the sample's ugly but you get the idea) :

default=spring*:ContextLoaderListener

This would enable us to use Spring's classic ContextLoaderListener to load Spring files

    <listener>
        <listener-class>
            org.springframework.web.context.ContextLoaderListener
        </listener-class>
    </listener>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/contacts.xml, /WEB-INF/resources.xml</param-value>
    </context-param>

Using ContextLoaderListener (http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/context/ContextLoader.html) would allow the following features :

1. such as parentContextKey, locatorFactorySelector
2. or sharing it with another non Spring / Seam component calling ContextLoader.getCurrentWebApplicationContext()).

Also not sure if we don't have this feature about how we would inject Spring context in Spring Security Filter (http://static.springsource.org/spring-security/site/docs/3.0.x/reference/springsecurity-single.html#delegating-filter-proxy) :

<filter>
    <filter-name>myFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>myFilter</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>

Thanks once more for this Spring Module !

Hey gonzalad,

I'm glad you like it, please feel free to add suggestions as JIRA items! It's easier to keep tabs on me that way:). The web context is available via

@Produces @Web @SpringContext ApplicationContext applicationContext;

although auto-vetoing is not supported indeed (as an alternative, you can use bean scanning suppression - AFAICT each CDI implementation supports it, Weld surely does, albeit in a proprietary format, but will be standard in CDI 1.1).

I am afraid that what you suggested wrt accessing web context via extension is not possible. The main problem here is CDI lifecycle - CDI deployment (and extension execution) happens before web container startup, so that web artifacts can be CDI-injected. This means that the ContextLoaderListener runs after the extension, which in turn cannot have access to the the Spring context created by the listener.

Regarding security, there is an item on the roadmap regarding Spring security integration, I am sure that we can add this as a feature there.

Thanks Marius for your responsiveness.

CDI deployment (and extension execution) happens before web container startup, so that web artifacts can be CDI-injected.

Youps forgot about that (sniff !) ;)

The feature facilities to import CDI beans an Spring beans should be left for the Spring team :)