Looks like your suggestion does work for one servlet. Not sure whether its scalable enough of a solution for me though. The root cause of the problem is that tapestry doesn't deal with the outside servlets and gives up its processing pipeline. Its more of a design issue on my side now of how to fix it. One way I am trying to do it is to create my own Servlet 3.0 filter and get the configuration cleanly from that filter, maybe that will alleviate the need to call servlets from tapestry filters directly.
Thanks a lot for your help, you steered me in the right direction. On Sep 8, 2011, at 2:11 PM, Thiago H. de Paula Figueiredo wrote: > On Thu, 08 Sep 2011 14:17:59 -0300, Lenny Primak <lpri...@hope.nyc.ny.us> > wrote: > >> This relates to my battle with securing servlets with tap-security / shiro. >> I found out that because tapestry 'ignores' my outside servlets >> (REST/WebServices) security information isn't getting propagated. >> If I could just let tapestry handle the stuff it doesn't know about, it >> would be fine. > > This looks like a tapestry-security or Shiro issue, not a Tapestry one here. > I don't know what pipeline it uses (HttpServletRequestHandler or > RequestHandler). > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and > instructor > Owner, Ars Machina Tecnologia da Informação Ltda. > http://www.arsmachina.com.br > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
