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 <[email protected]> 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? > > >
