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