Re[6]: How to get all logged in Subjects

[Alex Orlov <oo...@mail.ru>]

Hi Brian,
 
Thank you for your answer. On basis of your answer I think there are some design problems in Shiro.
 
1) As I understand "It's possible to set them in an INI file because that operates on bean properties (getters/setters)."
just means, that yes, SessionManager HAS SessionDAO what we see in INI and when configuration is be loaded
getters/setters are used. However, I say — what we have in INI we must have mirrored in API. However, 
it is not mirrored in API. → that is the reason of this question.
 
2) Inheritance is heavily used not only in Shiro, but in OOP. The question is that is very strance when
one type has two types of relations (has and is) with quite different type. For example, consider the
following code:
 
class Car implements Engine {
    private Engine engine;
}
 
I am not a guru, but I find such API strange.
 
3) What about casting — yes, it is possible to make casting and this is what I began to do. But after
some time I stopped and said to myself — "You are doing a stupid thing. The problem is in API"
 
 
 
--
Best regards, Alex Orlov
 
  
>Суббота, 7 ноября 2020, 16:57 +03:00 от Brian Demers <br...@gmail.com>:
> 
>Hey Alex,
> 
>Sorry about giving you wrong info before, I forgot about that method.
> 
>1.) From the API point of view the SessionDAO is an implementation detail, and getting access to those details would require some casting.
> 
>They are not part of the main API because not all SessionManagers would use a DAO, it's possible they are stored some other way.
> 
>It's possible to set them in an INI file because that operates on bean properties (getters/setters).
> 
>2.) Many of Shiro's implementations make heavy use of Inheritance.  The is more obvious if you look at a Realm implementation  
>On Fri, Nov 6, 2020 at 5:24 AM Alex Orlov < ooo_saturn7@mail.ru > wrote:
>>I found this wonderful method :
>> 
>>SessionDAO#Collection<Session> getActiveSessions()
>> 
>>and want to use it. And I have two questions:
>> 
>>1) Why does API hide top level objects for which we have interfaces?
>>For example, there is no API SecurityManager.getSessionManager().getSessionDAO()?
>>It seems to be unusual for me. Besides it is possible to set them via ini:
>> 
>> 
>>sessionManager = com.foo.my.SessionManagerImplementation
>>securityManager.sessionManager = $sessionManage
>> 
>>sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager
>>securityManager.sessionManager = $sessionManager  # Configure a SessionDAO and then set it: securityManager.sessionManager.sessionDAO = $sessionDAO
>> 
>>Maybe it is necessary to change API?
>> 
>>2) Why does SecurityManager extend SessionManager?
>>As I understand SecurityManager has a SessionManager, but not is a SessionManager:
>> 
>>public interface SecurityManager extends Authenticator, Authorizer, SessionManager
>> 
>>Could anyone explain?
>> 
>>