Your DataSource is probably being instantiated long before any request is made (note the bootstrap thread name in your log - [localhost-startStop-1]). So there is actually no SESSION which can be used by Spring to satisfy the SESSION scope.
You need to implement session-scoping manually (via RequestContextHolder) or have the components loosly coupled (e.g. via ApplicationContext#getBean).
What we have done on several projects is to implement TenantContext as ThreadLocal variable (similar to Spring Security's SecurityContext), which is being set and unset by a special servlet Filter. That is by far the best approach as no component will rely on the fact that there is actually an active HTTP request.
you would be better off without any session scoped bean
Sidenote: If you are using Hibernate, then be aware that there is already a support for multi-tenancy. Other frameworks might support it as well.
Thank you for your answer. One question: If the DataSource is being instantiated before any request is made that means it won't be possible to use a custom DataSource with setConnectionInitSqls. Right? Or simply haven't been executed the getConnection, so it's still possible to.
The ThreadLocal variable should be in a singleton bean?
DataSource is being instantiated before any request is made, however it is not used (i.e. getConnection is not called). You can still use setConnectionInitSqls. Regarding ThreadLocal - you can even place it as a static variable in some utility class (check Spring's RequestContextHolder or LocaleContextHolder).
One last question. Since all my multi-tenancy stuff is related to the logged in user, should I store the tenant information in the Authentication.getDetails() like this question says it's possible?. Do you see problems if I do it this way? (hope I'm not asking a fool's question)
That is a very good question. I always tend to keep tenant context logic independent. But you can definitely use security context to store tenant information. You only need to think about the situation when you don't have any user available (e.g. during authentication)... but that can be solved via docs.spring.io/spring-security/site/docs/3.0.x/reference/ (e.g. by creating temporary tenant specific anonymous authentication).