You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Alex Orlov <oo...@mail.ru> on 2020/11/08 09:47:44 UTC
Re[2]: Some questions about Shiro API
Hi Lenny,
I have casts, you have casts, Bob and Mike also have casts. It doesn’t matter how many casts
you have, you mustn’t have any.
In modern SO development approach we use only API and shouldn’t know anything about implementations
classes. I’m sure that you know about OSGI, JPMS etc. The main idea of such systems is to completely hide
implementation classes. You event don’t see those implementation classes, so, you just CAN’T use them!
So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
or API is not flexible enough.
So, I can’t accept your advice because it is simply unacceptable.
--
Best regards, Alex Orlov
>Суббота, 7 ноября 2020, 23:37 +03:00 от Lenny Primak <lp...@hope.nyc.ny.us>:
>
>Oh and I have very few “casts” that are necessary to accomplish any of this
>
>> On Nov 7, 2020, at 12:50 AM, Alex Orlov < ooo_saturn7@mail.ru > wrote:
>>
>> Hi all,
>>
>> Trying to I get the list of all logged in subjects I found this 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, using SecurityUtils we can get SecurityManager, however,
>> SecurityManager doesn’t let get SessionManager, SessionDAO etc.
>> So, we can’t do
>> SecurityUtils.getSecurityManager().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
>>
>> So, we can configure them statically, but not dynamically. At least, we must be able to get them
>> at runtime. Maybe it is necessary to change API to make it more flexible?
>>
>> 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?
>>
>>
>> --
>> Best regards, Alex Orlov
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Again, it’s not as black and white as you think.
Not everything is perfect, nothing is, and nothing ever will be.
Yes, Shiro APIs are a bit old-fashioned, but they work perfectly, understandable
and productive.
Trust me, as you rework your problems “in terms of Shiro design” your desire for casts will largely disappear.
I believe you are trying to use objects in your code that you are mostly do not need to.
> On Nov 8, 2020, at 4:24 AM, Alex Orlov <oo...@mail.ru> wrote:
>
> Hi Andreas,
>
> I am just a Shiro user and this is Shiro user mailing list. I fulfilled my duties — opened an issue and gave explanations.
> I develop my projects, Shiro developers develop Shiro. I just can’t develop any library I use in my projects ( > 30) — because
> to do it I must give up my projects.
>
> The idea of my message wasn’t "Change the API because anyway you have nothing to do". The idea of my message
> was — "Don’t call a wrong thing a right thing".
>
>
> --
> Best regards, Alex Orlov
>
>
> Воскресенье, 8 ноября 2020, 12:54 +03:00 от Andreas Reichel <an...@manticore-projects.com>:
>
> Dear Alex.
>
>
> On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
>> So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
>> or API is not flexible enough.
>
>
> Sometimes it may mean: it works perfectly fine as it is and the people have more relevant stuff to do.
> Look at Hurd: perfect in theory, unusable in practise. Look at the Linux kernel. Far away from being perfect or clean, but runs impressively well and reliable.
>
> That said: your best argument might be a pull request, which demonstrates the improvement you have in mind. I am sure, the Shiro developpers would merge it when the advantage of the refactoring is obvious.
>
> Best regards
> Andreas
>
Re[4]: Some questions about Shiro API
Posted by Alex Orlov <oo...@mail.ru>.
Hi Andreas,
I am just a Shiro user and this is Shiro user mailing list. I fulfilled my duties — opened an issue and gave explanations.
I develop my projects, Shiro developers develop Shiro. I just can’t develop any library I use in my projects ( > 30) — because
to do it I must give up my projects.
The idea of my message wasn’t "Change the API because anyway you have nothing to do". The idea of my message
was — "Don’t call a wrong thing a right thing".
--
Best regards, Alex Orlov
>Воскресенье, 8 ноября 2020, 12:54 +03:00 от Andreas Reichel <an...@manticore-projects.com>:
>
>Dear Alex.
>
>
>On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
>>So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
>>or API is not flexible enough.
>
>Sometimes it may mean: it works perfectly fine as it is and the people have more relevant stuff to do.
>Look at Hurd: perfect in theory, unusable in practise. Look at the Linux kernel. Far away from being perfect or clean, but runs impressively well and reliable.
>
>That said: your best argument might be a pull request, which demonstrates the improvement you have in mind. I am sure, the Shiro developpers would merge it when the advantage of the refactoring is obvious.
>
>Best regards
>Andreas
Re: Re[2]: Some questions about Shiro API
Posted by Andreas Reichel <an...@manticore-projects.com>.
Dear Alex.
On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
> So, when you do FooImpl impl = (FooImpl) foo; it means that either
> you are doing something wrong,
> or API is not flexible enough.
Sometimes it may mean: it works perfectly fine as it is and the people
have more relevant stuff to do.
Look at Hurd: perfect in theory, unusable in practise. Look at the
Linux kernel. Far away from being perfect or clean, but runs
impressively well and reliable.
That said: your best argument might be a pull request, which
demonstrates the improvement you have in mind. I am sure, the Shiro
developpers would merge it when the advantage of the refactoring is
obvious.
Best regards
Andreas
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
“simply unacceptable” is so black&white :)
The reality is that people used Shiro for decades, and it was acceptable for all of those people and all this time.
Simple fact is that no one is going to redesign Shiro APIs for you.
Either you need to do a PR, and convince the maintainers it’s useful, or,
use Shiro, or, or don’t use it.
That is a fact.
> On Nov 8, 2020, at 3:47 AM, Alex Orlov <oo...@mail.ru> wrote:
>
> Hi Lenny,
>
> I have casts, you have casts, Bob and Mike also have casts. It doesn’t matter how many casts
> you have, you mustn’t have any.
>
> In modern SO development approach we use only API and shouldn’t know anything about implementations
> classes. I’m sure that you know about OSGI, JPMS etc. The main idea of such systems is to completely hide
> implementation classes. You event don’t see those implementation classes, so, you just CAN’T use them!
>
> So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
> or API is not flexible enough.
>
> So, I can’t accept your advice because it is simply unacceptable.
>
>
> --
> Best regards, Alex Orlov
>
>
> Суббота, 7 ноября 2020, 23:37 +03:00 от Lenny Primak <lp...@hope.nyc.ny.us>:
>
> Oh and I have very few “casts” that are necessary to accomplish any of this
>
> > On Nov 7, 2020, at 12:50 AM, Alex Orlov <ooo_saturn7@mail.ru <x-...@mail.ru>> wrote:
> >
> > Hi all,
> >
> > Trying to I get the list of all logged in subjects I found this 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, using SecurityUtils we can get SecurityManager, however,
> > SecurityManager doesn’t let get SessionManager, SessionDAO etc.
> > So, we can’t do
> > SecurityUtils.getSecurityManager().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
> >
> > So, we can configure them statically, but not dynamically. At least, we must be able to get them
> > at runtime. Maybe it is necessary to change API to make it more flexible?
> >
> > 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?
> >
> >
> > --
> > Best regards, Alex Orlov
>