Well how does subject get its securityManager / realm. That may throw some
light onto whether the realm needs to be injected elsewhere too.

- Animesh

On Mon, Sep 8, 2008 at 1:46 AM, 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to