Ah, this helps greatly. In a web app, the best thing to do is configure JSecurity in web.xml via the ini format. The JSecurityFilter will acquire the SecurityManager and enable SecurityUtils automatically, as long as there is a Configuration class that can be used.
For example, in Spring-based webapps, we have a SpringIniWebConfiguration implementation to support this ( http://jsecurity.svn.sourceforge.net/viewvc/jsecurity/trunk/support/spring/src/org/jsecurity/spring/SpringIniWebConfiguration.java?revision=868&view=markup ). The best thing to do would be to create a GuiceIniWebConfiguration that does the same thing and then use it in web.xml: <filter> <filter-name>JSecurityFilter</filter-name> <filter-class>org.jsecurity.web.servlet.JSecurityFilter</filter-class> <init-param> <param-name>configClassName</param-name> <param-value>com.domain.my.package.GuiceIniWebConfiguration</param-value> </init-param> <init-param> <param-name>config</param-name> <param-value> # config as specified in the JSecurityFilter JavaDoc ( http://jsecurity.org/api/org/jsecurity/web/servlet/JSecurityFilter.html) </param-value> </init-param> </filter> ... filter-mapping here. Then you can use SecurityUtils.getSubject() anywhere in your code and not worry about anything else. If you create this GuiceIniWebConfiguration class, please contribute it back to the project - we'll be happy to maintain it! Thanks, Les On Sun, Sep 7, 2008 at 4:16 PM, Animesh Jain <[EMAIL PROTECTED]> wrote: > Yup this is a web-app. I'm using Guice for dependency injection so you can > think of that as a replacement for Spring. I could send you the whole app > too so you'd see what I see. I'm pretty sure there's nothing wrong with the > dependency injection here. Because as I said after the login action I'm able > to obtain an instance of the subject in a separate action class by calling > > Subject subject = getSecurityManager().getSubject() > > Here getSecurityManager() gets me an injected SecurityManager correctly > with my realm properly configured and all. Right after this line if I call > > subject.hasRole("XYZ") > > the error gets thrown up. > > - Animesh > > > > On Mon, Sep 8, 2008 at 1:38 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > >> Is this a web app? I.e. is there a web.xml file somewhere? >> >> Also, is this a spring application? >> >> >> On Sun, Sep 7, 2008 at 3:44 PM, Animesh Jain <[EMAIL PROTECTED]>wrote: >> >>> Ok here's the deal.. >>> >>> I'm injecting a DefaultWebSecurityManager into my action classes, which >>> has my HibernateSecurityRealm set correctly. So calling >>> >>> Subject subject = getSecurityManager().getSubject(); >>> >>> is giving me the correct currently logged in user. But strangely when I >>> debug the subject instance after getting it, the securityManager it shows is >>> not the same - it has a real called >>> org.jsecurity.realm.text.PropertiesRealm. Now how is that possible? >>> >>> I was not using the SecurityUtils class and had not explicitly set a >>> SecurityManager using SecurityUtils.setSecurityManager(). Is that required. >>> Anyway I now added it too but that has had no effect. Still the same error. >>> >>> So where's the subject instance getting the different implementation from >>> >>> Animesh >>> >>> >>> On Mon, Sep 8, 2008 at 12:52 AM, Les Hazlewood <[EMAIL PROTECTED]>wrote: >>> >>>> The SimpleAccountRealm is a fallback/failsafe realm that is used if you >>>> haven't correctly configured a realm yourself. What does your JSecurity >>>> configuration look like? >>>> >>>> >>>> On Sun, Sep 7, 2008 at 3:04 PM, Animesh Jain <[EMAIL PROTECTED]>wrote: >>>> >>>>> Les, >>>>> >>>>> On second thoughts.. I'm still not sure. Why is it that there's >>>>> SimpleAccountRealm.java in the stacktrace and no HibernateSecurityRealm >>>>> (the >>>>> one I implemented). >>>>> >>>>> Any thoughts. >>>>> >>>>> Animesh >>>>> >>>>> >>>>> On Mon, Sep 8, 2008 at 12:24 AM, Animesh Jain <[EMAIL PROTECTED]>wrote: >>>>> >>>>>> Oops! I should have looked at the stacktrace closer. This is unrelated >>>>>> to Jsecurity. I've been working on an integration of Stripes+Guice+Warp >>>>>> persist+Jsecurity. Jsecurity is the last remaining thing and when I got >>>>>> the >>>>>> error I assumed it was because of that :P. So I'll close it here.. maybe >>>>>> I'll drop you an email if I feel I need your help. >>>>>> >>>>>> Stacktrace: >>>>>> >>>>>> exception >>>>>> >>>>>> net.sourceforge.stripes.exception.StripesServletException: Unhandled >>>>>> exception in exception handler. >>>>>> >>>>>> net.sourceforge.stripes.exception.DefaultExceptionHandler.handle(DefaultExceptionHandler.java:158) >>>>>> >>>>>> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:249) >>>>>> >>>>>> org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) >>>>>> >>>>>> org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) >>>>>> >>>>>> com.wideplay.warp.hibernate.SessionPerRequestFilter.doFilter(SessionPerRequestFilter.java:53) >>>>>> >>>>>> root cause >>>>>> >>>>>> java.util.NoSuchElementException >>>>>> java.util.Collections$EmptySet$1.next(Collections.java:2910) >>>>>> >>>>>> java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010) >>>>>> >>>>>> org.jsecurity.realm.SimpleAccountRealm.getAuthorizationCacheKey(SimpleAccountRealm.java:157) >>>>>> >>>>>> org.jsecurity.realm.AuthorizingRealm.getAuthorizationInfo(AuthorizingRealm.java:265) >>>>>> >>>>>> org.jsecurity.realm.AuthorizingRealm.hasRole(AuthorizingRealm.java:500) >>>>>> >>>>>> org.jsecurity.authz.ModularRealmAuthorizer.hasRole(ModularRealmAuthorizer.java:178) >>>>>> >>>>>> org.jsecurity.mgt.AuthorizingSecurityManager.hasRole(AuthorizingSecurityManager.java:213) >>>>>> >>>>>> org.jsecurity.subject.DelegatingSubject.hasRole(DelegatingSubject.java:211) >>>>>> bookmark.web.action.HomeAction.preAction(HomeAction.java:14) >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>>>>> >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>>>>> java.lang.reflect.Method.invoke(Method.java:585) >>>>>> >>>>>> net.sourceforge.stripes.controller.DispatcherHelper$6.intercept(DispatcherHelper.java:442) >>>>>> >>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:158) >>>>>> >>>>>> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) >>>>>> >>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) >>>>>> >>>>>> net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor.intercept(BeforeAfterMethodInterceptor.java:113) >>>>>> >>>>>> net.sourceforge.stripes.controller.ExecutionContext.proceed(ExecutionContext.java:155) >>>>>> >>>>>> net.sourceforge.stripes.controller.ExecutionContext.wrap(ExecutionContext.java:74) >>>>>> >>>>>> net.sourceforge.stripes.controller.DispatcherHelper.invokeEventHandler(DispatcherHelper.java:440) >>>>>> >>>>>> net.sourceforge.stripes.controller.DispatcherServlet.invokeEventHandler(DispatcherServlet.java:285) >>>>>> >>>>>> net.sourceforge.stripes.controller.DispatcherServlet.doPost(DispatcherServlet.java:167) >>>>>> >>>>>> net.sourceforge.stripes.controller.DispatcherServlet.doGet(DispatcherServlet.java:67) >>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:689) >>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:802) >>>>>> >>>>>> net.sourceforge.stripes.controller.StripesFilter.doFilter(StripesFilter.java:246) >>>>>> >>>>>> org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) >>>>>> >>>>>> org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) >>>>>> >>>>>> com.wideplay.warp.hibernate.SessionPerRequestFilter.doFilter(SessionPerRequestFilter.java:53) >>>>>> >>>>>> >>>>>> On Mon, Sep 8, 2008 at 12:13 AM, Les Hazlewood <[EMAIL PROTECTED] >>>>>> > wrote: >>>>>> >>>>>>> Hi Animesh, >>>>>>> >>>>>>> Your realm implementation looks fine. But, JSecurity doesn't throw a >>>>>>> NoSuchElementException anywhere in its code. I'm assuming this has to >>>>>>> do >>>>>>> with how a collection is being used, either iterated by JSecurity, or >>>>>>> something happening in your DAO layer. >>>>>>> >>>>>>> Please include the stacktrace - it is very hard to debug without it >>>>>>> ;) >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Les >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
