You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Sergio Vieira Rolanski <se...@strategos.com.br> on 2013/04/08 21:17:07 UTC
Tomcat form auth not using filters
Hello,
Using Java 6, Apache Tomcat 7.0.34, Mojarra 2.1.19 and PrimeFaces 3.5
I set up my application to use forms auth and it is working, but I have a problem when the session expires.
I'm not sure what Tomcat does when the session expires to render (or redirect) the login page instead of the request page.
I get an Hibernate exception as root cause saying that there is no session open, that means the request is ignoring my HibernateFilter (among other important filters) which opens the session and transaction for the current request resulting in an error.
Any ideas how do I fix this?
Thanks,
Sergio
Re: Tomcat form auth not using filters
Posted by Sergio Vieira Rolanski <se...@strategos.com.br>.
Problem solved. I will keep an eye open for that possible hibernate/request problem.
Thank you for the help.
Sergio
----- Mensagem original -----
De: "Sergio Vieira Rolanski" <se...@strategos.com.br>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviadas: Terça-feira, 9 de Abril de 2013 8:18:26
Assunto: Re: Tomcat form auth not using filters
Hi,
Thank you, I will test this later.
I'm using a threadlocal to open session/transaction,
does that forwarded request happens in the same thread as the original request?
Sergio
----- Mensagem original -----
De: "Christopher Schultz" <ch...@christopherschultz.net>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviadas: Segunda-feira, 8 de Abril de 2013 18:19:11
Assunto: Re: Tomcat form auth not using filters
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 4/8/13 4:58 PM, Konstantin Kolinko wrote:
> 2013/4/9 Sergio Vieira Rolanski <se...@strategos.com.br>:
>> Thansk for the reply,
>>
>> Let me try to be clear on this matter:
>>
>> I try open the address "http://localhost:8084/MyApplication" (or
>> any other protected address/page) and I'm not logged in (I have
>> never logged in or the session is expired) Tomcat should show me
>> the login page (controleAcesso/Login.xhtml, that is "access
>> control" in portuguese), but instead I get an error (the
>> stacktrace is below)
>>
>> Now if I try to open
>> "http://localhost:8084/MyApplication/controleAcesso/Login.xhtml"
>> directly, it works just fine and I can see the login page, do the
>> login and navigate the application.
>>
>> I know hibernate and servlet session are different things, what I
>> meant was that each request is intercepted by HibernateFilter
>> (implements javax.servlet.Filter) so it opens a session and a
>> transaction for that request. If you look the stacktrace, my
>> HibernateFilter is not called at all.
>>
>> I made a request for lets say
>> "http://localhost:8084/MyApplication/billing/BillingHistory.xhtml"
>> and I'm not logged in, tomcat should show me the login page,
>> right? But it seems that to get the appropriate response for the
>> request (the login page instead of the BillingHistory.xhtml)
>> tomcat/servlet/whatever is taking another path and ignoring my
>> servlet filters thus not opening the hibernate session and giving
>> me exception instead of the login page.
>>
>>
>
> OK, I am understanding you problem now.
>
> The important part of your stacktrace:
>
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
>
>
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:425)
> at
> org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
>
>
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
>
> That is how "forwardToLoginPage" is implemented.
>
> If you want a Filter to be called during
> javax.servlet.RequestDispatcher.forward(), it has to be mapped
> with
>
> <filter-mapping> <dispatcher>FORWARD</dispatcher>
> </filter-mapping>
I would warn the OP that blindly mapping the Filter to FORWARD
dispatch might result in multiple connections/Hibernate-sessions being
allocated for a single client request if the Filter is not written
carefully. Be sure to check to make sure the Filter will work properly
when involved multiple times for a single request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRYzROAAoJEBzwKT+lPKRYxw8QAMvtHoUD75+uEFVD/dywjW4d
HTVxwJ622S6dhAHJNISt4S1MeJT7JB8DOevJfKAP96ZNd1/jhJjFxxRcuA9/aIf7
ezfBjEpnQ/WmO2h3gWbm0fv4VcVsIif5MDEmVSesjLtot1qsGuJ3iA5OoVQWksr8
uJAoxU+l+Voqor2XSu/OH6y6IRq2CfriPsMphM7nOVAmLvbvKNHER1ov8D/6iWKq
gTzR9BBJf+/U0X1czwwOMXShicZa41pp+N/Z9v++XL8XDQzMz37yapo8HwvMLeOe
DLBTgrgOsjlJ5+M2e6+bZW9Ntn0xFJZXrW4rieQxRhGJLXNhxiZfLjyxe9eR1SDU
uAUY3lGzqluulfu+I7854gE0FjofEXdFC7Lo0oiuUPft2QffjbheyAjkuvjxCK1o
byRHx2efTVRlfM5RPCJ5qEh5o05Anjt/FEurywWB2DkvtdXYSCVv4IZh1l9SIf9J
TZVQsHgXOl3/9d25X286XH7XDitPnFuzHOpLkhSWHuMgsoCfV0DAiIS45DJXN8ds
0gYYWnU6gpdaGr7MJ2o5fQFZS0JZHHplxi1e+N/VDcXH19Whds/BJaz2q4fPgaur
2s0goJPEc32ZxIJ7FiovHK9oj4FNtSa252Dz6ekNv1Y2fu4rj0P2V4rcPmTkKiA5
V3PIlHZJbYcoVVohC0Ty
=WHt0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat form auth not using filters
Posted by Sergio Vieira Rolanski <se...@strategos.com.br>.
Hi,
Thank you, I will test this later.
I'm using a threadlocal to open session/transaction,
does that forwarded request happens in the same thread as the original request?
Sergio
----- Mensagem original -----
De: "Christopher Schultz" <ch...@christopherschultz.net>
Para: "Tomcat Users List" <us...@tomcat.apache.org>
Enviadas: Segunda-feira, 8 de Abril de 2013 18:19:11
Assunto: Re: Tomcat form auth not using filters
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 4/8/13 4:58 PM, Konstantin Kolinko wrote:
> 2013/4/9 Sergio Vieira Rolanski <se...@strategos.com.br>:
>> Thansk for the reply,
>>
>> Let me try to be clear on this matter:
>>
>> I try open the address "http://localhost:8084/MyApplication" (or
>> any other protected address/page) and I'm not logged in (I have
>> never logged in or the session is expired) Tomcat should show me
>> the login page (controleAcesso/Login.xhtml, that is "access
>> control" in portuguese), but instead I get an error (the
>> stacktrace is below)
>>
>> Now if I try to open
>> "http://localhost:8084/MyApplication/controleAcesso/Login.xhtml"
>> directly, it works just fine and I can see the login page, do the
>> login and navigate the application.
>>
>> I know hibernate and servlet session are different things, what I
>> meant was that each request is intercepted by HibernateFilter
>> (implements javax.servlet.Filter) so it opens a session and a
>> transaction for that request. If you look the stacktrace, my
>> HibernateFilter is not called at all.
>>
>> I made a request for lets say
>> "http://localhost:8084/MyApplication/billing/BillingHistory.xhtml"
>> and I'm not logged in, tomcat should show me the login page,
>> right? But it seems that to get the appropriate response for the
>> request (the login page instead of the BillingHistory.xhtml)
>> tomcat/servlet/whatever is taking another path and ignoring my
>> servlet filters thus not opening the hibernate session and giving
>> me exception instead of the login page.
>>
>>
>
> OK, I am understanding you problem now.
>
> The important part of your stacktrace:
>
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
>
>
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:425)
> at
> org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
>
>
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
>
> That is how "forwardToLoginPage" is implemented.
>
> If you want a Filter to be called during
> javax.servlet.RequestDispatcher.forward(), it has to be mapped
> with
>
> <filter-mapping> <dispatcher>FORWARD</dispatcher>
> </filter-mapping>
I would warn the OP that blindly mapping the Filter to FORWARD
dispatch might result in multiple connections/Hibernate-sessions being
allocated for a single client request if the Filter is not written
carefully. Be sure to check to make sure the Filter will work properly
when involved multiple times for a single request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRYzROAAoJEBzwKT+lPKRYxw8QAMvtHoUD75+uEFVD/dywjW4d
HTVxwJ622S6dhAHJNISt4S1MeJT7JB8DOevJfKAP96ZNd1/jhJjFxxRcuA9/aIf7
ezfBjEpnQ/WmO2h3gWbm0fv4VcVsIif5MDEmVSesjLtot1qsGuJ3iA5OoVQWksr8
uJAoxU+l+Voqor2XSu/OH6y6IRq2CfriPsMphM7nOVAmLvbvKNHER1ov8D/6iWKq
gTzR9BBJf+/U0X1czwwOMXShicZa41pp+N/Z9v++XL8XDQzMz37yapo8HwvMLeOe
DLBTgrgOsjlJ5+M2e6+bZW9Ntn0xFJZXrW4rieQxRhGJLXNhxiZfLjyxe9eR1SDU
uAUY3lGzqluulfu+I7854gE0FjofEXdFC7Lo0oiuUPft2QffjbheyAjkuvjxCK1o
byRHx2efTVRlfM5RPCJ5qEh5o05Anjt/FEurywWB2DkvtdXYSCVv4IZh1l9SIf9J
TZVQsHgXOl3/9d25X286XH7XDitPnFuzHOpLkhSWHuMgsoCfV0DAiIS45DJXN8ds
0gYYWnU6gpdaGr7MJ2o5fQFZS0JZHHplxi1e+N/VDcXH19Whds/BJaz2q4fPgaur
2s0goJPEc32ZxIJ7FiovHK9oj4FNtSa252Dz6ekNv1Y2fu4rj0P2V4rcPmTkKiA5
V3PIlHZJbYcoVVohC0Ty
=WHt0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat form auth not using filters
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Konstantin,
On 4/8/13 4:58 PM, Konstantin Kolinko wrote:
> 2013/4/9 Sergio Vieira Rolanski <se...@strategos.com.br>:
>> Thansk for the reply,
>>
>> Let me try to be clear on this matter:
>>
>> I try open the address "http://localhost:8084/MyApplication" (or
>> any other protected address/page) and I'm not logged in (I have
>> never logged in or the session is expired) Tomcat should show me
>> the login page (controleAcesso/Login.xhtml, that is "access
>> control" in portuguese), but instead I get an error (the
>> stacktrace is below)
>>
>> Now if I try to open
>> "http://localhost:8084/MyApplication/controleAcesso/Login.xhtml"
>> directly, it works just fine and I can see the login page, do the
>> login and navigate the application.
>>
>> I know hibernate and servlet session are different things, what I
>> meant was that each request is intercepted by HibernateFilter
>> (implements javax.servlet.Filter) so it opens a session and a
>> transaction for that request. If you look the stacktrace, my
>> HibernateFilter is not called at all.
>>
>> I made a request for lets say
>> "http://localhost:8084/MyApplication/billing/BillingHistory.xhtml"
>> and I'm not logged in, tomcat should show me the login page,
>> right? But it seems that to get the appropriate response for the
>> request (the login page instead of the BillingHistory.xhtml)
>> tomcat/servlet/whatever is taking another path and ignoring my
>> servlet filters thus not opening the hibernate session and giving
>> me exception instead of the login page.
>>
>>
>
> OK, I am understanding you problem now.
>
> The important part of your stacktrace:
>
> at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
>
>
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:425)
> at
> org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
>
>
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
>
> That is how "forwardToLoginPage" is implemented.
>
> If you want a Filter to be called during
> javax.servlet.RequestDispatcher.forward(), it has to be mapped
> with
>
> <filter-mapping> <dispatcher>FORWARD</dispatcher>
> </filter-mapping>
I would warn the OP that blindly mapping the Filter to FORWARD
dispatch might result in multiple connections/Hibernate-sessions being
allocated for a single client request if the Filter is not written
carefully. Be sure to check to make sure the Filter will work properly
when involved multiple times for a single request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRYzROAAoJEBzwKT+lPKRYxw8QAMvtHoUD75+uEFVD/dywjW4d
HTVxwJ622S6dhAHJNISt4S1MeJT7JB8DOevJfKAP96ZNd1/jhJjFxxRcuA9/aIf7
ezfBjEpnQ/WmO2h3gWbm0fv4VcVsIif5MDEmVSesjLtot1qsGuJ3iA5OoVQWksr8
uJAoxU+l+Voqor2XSu/OH6y6IRq2CfriPsMphM7nOVAmLvbvKNHER1ov8D/6iWKq
gTzR9BBJf+/U0X1czwwOMXShicZa41pp+N/Z9v++XL8XDQzMz37yapo8HwvMLeOe
DLBTgrgOsjlJ5+M2e6+bZW9Ntn0xFJZXrW4rieQxRhGJLXNhxiZfLjyxe9eR1SDU
uAUY3lGzqluulfu+I7854gE0FjofEXdFC7Lo0oiuUPft2QffjbheyAjkuvjxCK1o
byRHx2efTVRlfM5RPCJ5qEh5o05Anjt/FEurywWB2DkvtdXYSCVv4IZh1l9SIf9J
TZVQsHgXOl3/9d25X286XH7XDitPnFuzHOpLkhSWHuMgsoCfV0DAiIS45DJXN8ds
0gYYWnU6gpdaGr7MJ2o5fQFZS0JZHHplxi1e+N/VDcXH19Whds/BJaz2q4fPgaur
2s0goJPEc32ZxIJ7FiovHK9oj4FNtSa252Dz6ekNv1Y2fu4rj0P2V4rcPmTkKiA5
V3PIlHZJbYcoVVohC0Ty
=WHt0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat form auth not using filters
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/9 Sergio Vieira Rolanski <se...@strategos.com.br>:
> Thansk for the reply,
>
> Let me try to be clear on this matter:
>
> I try open the address "http://localhost:8084/MyApplication" (or any other protected address/page) and I'm not logged in (I have never logged in or the session is expired) Tomcat should show me the login page (controleAcesso/Login.xhtml, that is "access control" in portuguese), but instead I get an error (the stacktrace is below)
>
> Now if I try to open "http://localhost:8084/MyApplication/controleAcesso/Login.xhtml" directly, it works just fine and I can see the login page, do the login and navigate the application.
>
> I know hibernate and servlet session are different things, what I meant was that each request is intercepted by HibernateFilter (implements javax.servlet.Filter) so it opens a session and a transaction for that request. If you look the stacktrace, my HibernateFilter is not called at all.
>
> I made a request for lets say "http://localhost:8084/MyApplication/billing/BillingHistory.xhtml" and I'm not logged in, tomcat should show me the login page, right? But it seems that to get the appropriate response for the request (the login page instead of the BillingHistory.xhtml) tomcat/servlet/whatever is taking another path and ignoring my servlet filters thus not opening the hibernate session and giving me exception instead of the login page.
>
>
OK, I am understanding you problem now.
The important part of your stacktrace:
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:425)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
That is how "forwardToLoginPage" is implemented.
If you want a Filter to be called during
javax.servlet.RequestDispatcher.forward(), it has to be mapped with
<filter-mapping>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
for URL "/controleAcesso/Login.xhtml".
See the Servlet specification ch. 6.2.5 for more details on filter mapping.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat form auth not using filters
Posted by Sergio Vieira Rolanski <se...@strategos.com.br>.
Thansk for the reply,
Let me try to be clear on this matter:
I try open the address "http://localhost:8084/MyApplication" (or any other protected address/page) and I'm not logged in (I have never logged in or the session is expired) Tomcat should show me the login page (controleAcesso/Login.xhtml, that is "access control" in portuguese), but instead I get an error (the stacktrace is below)
Now if I try to open "http://localhost:8084/MyApplication/controleAcesso/Login.xhtml" directly, it works just fine and I can see the login page, do the login and navigate the application.
I know hibernate and servlet session are different things, what I meant was that each request is intercepted by HibernateFilter (implements javax.servlet.Filter) so it opens a session and a transaction for that request. If you look the stacktrace, my HibernateFilter is not called at all.
I made a request for lets say "http://localhost:8084/MyApplication/billing/BillingHistory.xhtml" and I'm not logged in, tomcat should show me the login page, right? But it seems that to get the appropriate response for the request (the login page instead of the BillingHistory.xhtml) tomcat/servlet/whatever is taking another path and ignoring my servlet filters thus not opening the hibernate session and giving me exception instead of the login page.
javax.faces.view.facelets.TagAttributeException: /popups/BuscaUsuario.xhtml @14,80 <f:loadBundle basename="#{bwBuscaUsuario.properties}"> /popups/BuscaUsuario.xhtml @14,80 basename="#{bwBuscaUsuario.properties}" Um erro ocorreu ao realizar a injeção de recurso no bean gerenciado bwBuscaUsuario
at com.sun.faces.facelets.tag.jsf.core.LoadBundleHandler.apply(LoadBundleHandler.java:231)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:166)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:178)
at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:166)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:155)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:320)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:379)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:358)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:187)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:188)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:164)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:902)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:487)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:412)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:339)
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:425)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:1822)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.faces.view.facelets.TagAttributeException: /popups/BuscaUsuario.xhtml @14,80 basename="#{bwBuscaUsuario.properties}" Um erro ocorreu ao realizar a injeção de recurso no bean gerenciado bwBuscaUsuario
at com.sun.faces.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:331)
at com.sun.faces.facelets.tag.TagAttributeImpl.getValue(TagAttributeImpl.java:295)
at com.sun.faces.facelets.tag.jsf.core.LoadBundleHandler.apply(LoadBundleHandler.java:222)
... 100 more
Caused by: com.sun.faces.mgbean.ManagedBeanCreationException: Um erro ocorreu ao realizar a injeção de recurso no bean gerenciado bwBuscaUsuario
at com.sun.faces.mgbean.BeanBuilder.invokePostConstruct(BeanBuilder.java:229)
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:105)
at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:408)
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:268)
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:244)
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109)
at com.sun.faces.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:329)
... 102 more
Caused by: com.sun.faces.spi.InjectionProviderException
at com.sun.faces.vendor.WebContainerInjectionProvider.invokeAnnotatedMethod(WebContainerInjectionProvider.java:115)
at com.sun.faces.vendor.WebContainerInjectionProvider.invokePostConstruct(WebContainerInjectionProvider.java:95)
at com.sun.faces.mgbean.BeanBuilder.invokePostConstruct(BeanBuilder.java:223)
... 114 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.faces.vendor.WebContainerInjectionProvider.invokeAnnotatedMethod(WebContainerInjectionProvider.java:113)
... 116 more
Caused by: org.hibernate.HibernateException: createCriteria is not valid without active transaction
at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:341)
at com.sun.proxy.$Proxy48.createCriteria(Unknown Source)
at strategos.baseweb.hibernate.AbstractEntity.createCriteria(AbstractEntity.java:179)
at strategos.baseweb.hibernate.AbstractEntity.findAll(AbstractEntity.java:170)
at strategos.baseweb.forms.buscas.BuscaUsuario.pageLoad(BuscaUsuario.java:68)
... 121 more
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat form auth not using filters
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/4/8 Sergio Vieira Rolanski <se...@strategos.com.br>:
> Hello,
>
> Using Java 6, Apache Tomcat 7.0.34, Mojarra 2.1.19 and PrimeFaces 3.5
>
> I set up my application to use forms auth and it is working, but I have a problem when the session expires.
> I'm not sure what Tomcat does when the session expires to render (or redirect) the login page instead of the request page.
The same as for a new request that has no session at all. A valve
(Authenticator) will intercept the request before it reaches your
application and will display a login form.
> I get an Hibernate exception as root cause saying that there is no session open, that means the request is ignoring my HibernateFilter (among other important filters) which opens the session and transaction for the current request resulting in an error.
A hibernate session and a servlet session are two different entities.
There is no relation between them.
> Any ideas how do I fix this?
No. We do not have your source code nor you stacktrace.
I would first find out how I got there. What is stacktrace of the call
when this issue happens and what is requested URL.
All filters are mentioned in stacktrace (full stacktrace is written to
the logs). It is easy to see whether your filter is there.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org