Java – way to give persistenceUnitName for Spring’s LocalContainerEntityManagerFactoryBean without persistence.xml

There's some kind of magic here, but at the end, everything is a deterministic program.

The DelegatingFilterProxy is a Filter as it was explained above, whose goal is "delegating to a Spring-managed bean that implements the Filter interface", that is, it finds a bean ("target bean" or "delegate") in your Spring application context and invokes it. How is it possible? Because this bean implements javax.servlet.Filter, its doFilter method is called.

Which bean is called? the DelegatingFilterProxy "Supports a "targetBeanName" [...], specifying the name of the target bean in the Spring application context."

As you saw in your web.xml that the bean's name is "springSecurityFilterChain".

So, in the context of a web application, a Filter instantiates a bean called "springSecurityFilterChain" in your application context and then delegate to it via the doFilter() method.

Remember, your application context is defined with ALL THE APPLICATION-CONTEXT (XML) files. For instance: applicationContext.xml AND applicationContext-security.xml.

So try to find a bean called "springSecurityFilterChain" in the latter...

...and probably you can't (for instance if you followed a tutorial or if you configured the security using Roo)

Here is the magic: there's a new element for configuring the security, something like

<http auto-config="true" use-expressions="true"> 

as it is allowed by http://www.springframework.org/schema/security/spring-security-3.0.xsd, will do the trick.

When Spring loads the application context using XML files, if it finds a element, it will try to set up the HTTP security, that is, a filter stack and protected URLs and to register the FilterChainProxy named "springSecurityFilterChain".

Alternatively, you can define the bean in the classic way, that is:

<beans:bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">

But it's less recommended, since you need to do a lot of configuration (all the filters that you're going to use. And there are more than a dozen of them)

I came across the same issue but in a different scenario. The EntityManagerFactoryRegistry produces the same HHH000436 warning, when executing multiple tests in the same run (i.e. the same JVM) started from my IDE.

The problem can surface in case there are at least two test classes using the SpringJUnit4ClassRunner to load different Spring test application contexts each containing an EntityManagerFactory.

The root cause is that Hibernate maintains a static registry of EntityManagerFactory instances, where the creation of the second instance may cause the collision the log message is about. So why isn't the first instance deregistered after the first test finished executing? It normally would when the app context containing that EntityManagerFactory instance gets destroyed. The reason it doesn't happen during test execution is that the Spring test context framework caches all loaded contexts in order to avoid re-loading the exact same context potentially needed by multiple tests. As a result, beans in these contexts doesn't get destroyed until after the last test finished executing, and Hibernate will just collect all the EntityManagerFactory instances ever created.

It's really a non-issue, but if someone is really annoyed by the warning message, there are a few possible ways to avoid seeing it:

1. Make sure the EntityManagerFactory instances get a different name (they are keyed by name in the registry). Chek the constructor of EntityManagerFactoryImpl on how the name is derived.
2. Use @DirtiesContext on the test class to cause the SpringJUnit4ClassRunner to close the context and remove it from its context cache immediately after executing the test class.
3. Simply set the logging level of EntityManagerFactoryRegistry to error...

Hope this helps someone.