Declaring Spring Bean no contexto pai versus contexto filho
Eu tenho um objeto spring bean (dao) que eu instanciao no meu ServletContext por meio do seguinte xml:
<bean id="userDao" class="com.company.dao.impl.UserDaoImpl">
<property name="sessionFactory" ref="sessionFactory" />
</bean>
Este bean é declarado dentro do meu arquivo webapp-servlet.xml e é usado pelo meu aplicativo no ServletContex
Também estou usando o SpringSecurity. Entendo que isso seja executado em um contexto diferente (o SecurityContext).
aplicativo @My possui um webapp-security.xml no qual instanciamos um provedor de autenticação personalizado. Gostaria de usar o meu dao usado no meu aplicativo para também fazer a pesquisa do usuário no meu contexto de segurança, mas quando executo:
<bean id="userAuthenticationProvider" class="com.company.security.UserAuthenticationProvider">
<property name="userDao" ref="userDao" />
</bean>
Eu recebo erros dizendo que não existe esse bean "userDao". O bean é conectado automaticamente nos beans declarados no meu outro contexto, mas não dentro do meu contexto de segurança. De acordo com o Spring Docs, acredito que ambos os contextos separados são necessários no web.xml
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<listener>
<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>
Então, minha pergunta é: como posso acessar o meu DAO que mora no meu ServletContext dentro do meu SecurityContext? Existe um modificador de escopo para o meu dao ou eu poderia, de alguma forma, obter o ServletContext em tempo de execução no meu provedor de autenticação? Para referência, é assim que eu quero usá-lo dentro do meu provedor de autenticação:
public class UserAuthenticationProvider extends
AbstractUserDetailsAuthenticationProvider {
@Override
protected UserDetails retrieveUser(String userName,
UsernamePasswordAuthenticationToken authenticationToken)
throws AuthenticationException {
// use dao here
obrigado por explicar isso para mim
ATUALIZAR
Continuando minha investigação, parece que o DispatcherServlet onde estou usando meus daos é um contexto filho, e o contexto de segurança está em algum lugar mais alto. Consequentemente, os beans no meu DispatcherServlet não podem ser vistos pelos contextos pai. Eu acho que a resposta é mover minhas declarações de bean para o contexto do aplicativo pai de alguma forma, mas não tenho certeza de como fazer isso. Aqui está o meu web.xml
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/spring-*.xml
</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>myapp</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
...
Mudei toda a minha criação de dao para um spring-dao.xml, e no meu spring-security.xml agora estou fazendo um:
<import resource="spring-dao.xml" />
O daos ainda permanece visível para o contexto DispatcherServlet e invisível para meu SecurityContex
RESPONDIDAS
Tudo bem, eu descobri. Aqui estão alguns links úteis:
http: //static.springsource.org/spring-security/site/faq.html#faq-method-security-in-web-contex
O problema era que precisamos garantir que o dao exista no ApplicationContext (contêiner de mola superior). Para garantir que isso aconteceu, mudei meu web.xml para:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/spring-dao.xml WEB-INF/spring-security.xml
</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
<listener>
<listener-class>
org.springframework.security.web.session.HttpSessionEventPublisher
</listener-class>
</listener>
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy
</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>webapp</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>listings</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
Eu pensei que isso garantiria que o primeiro carregador de contexto que iniciar fosse ler minha configuração dao (e criar meus dao beans) e, em seguida, minha configuração de segurança. Como os beans dao estão sendo criados dessa maneira, removi a instrução "import resource =" spring-dao.xml "" anterior no security.xml porque não será mais necessária.
Logo após essa configuração context-param, criei o ContextLoaderListener. Este é um contêiner de mola de nível superior ao DispatcherServlet, então imaginei que colocar esse primeiro seria o primeiro a ler essas configurações, arquivos eel criaria os beans. Então, qualquer contexto filho teria acesso a eles. Pode não ser assim que funciona, pois o DispatcherServlet pode nem ler o contextConfigLocation, mas mesmo assim, imaginei que, nesse ponto, os beans já seriam declarados, que pena, o contexto pai os possui.
Agora, por outro truque ... para obter meu DAO, eu poderianãAutomatizado. Eu tive que injetar manualmente via XML:
<bean id="userAuthenticationProvider" class="com.company.app.security.UserAuthenticationProvider">
<property name="userDao" ref="userDao" />
</bean>
Claro, eu fiz os métodos getter e setter no meu dao, e pronto! Não sei por que o @Autowired não funciona aqui. Presumo que seja por design. Talvez isso seja específico do SecurityContext (não será extraído de outros contextos) ou talvez @Autowired in generals puxa do contexto atual, ou talvez porque eu criei o bean via XML, eu também precise definir propriedades via xml e não através de anotações? (as anotações estão ativadas e funcionando no meu namespace de aplicativo de nível superior).
De qualquer forma ... ainda não entendo muito, mas o ponto importante é que finalmente está funcionand