On Fri, Feb 11, 2022 at 10:47 AM Michael Osipov <micha...@apache.org> wrote: > > Rémy, > > really, I don't understand your work attitude. Carsten contacted us on > the mailing list before providing the PR. Then he provided the PR. It > was open for EIGHT months. We discussed this in and out, with you and > Mark. Everyone expressed the conditions he is willing to accept the PR. > I have even asked Carsten to break up the PR to please you. The purpose > of RTC/PR is to express your opinion BEFORE it gets merged to avoid > post-mortem discussions like this. You expressed your conditions and now > you object? This is absolutely not fair and unprofessional.
I apologized for this already. I am really sorry about this but background thinking led to different conclusions over time. > I cannot share your further explanations as well. The Realm *is* already > an object store. Principal name and roles are attributes on that object, > so is password. Without this possibility you have the following problems: That statement is just weird. The realm stores credentials associated with a principal name, as well as a list of roles (other names) associated with that name. That's it. An object store can store objects (like if there is a get/setAttribute that deals with Object - and that's my problem now, as it turns out ...). > * You cannot abstract from the persistence layer in your application > code, at worst you need to double code for retrieval > * You double access time since you need to query the principal store > again. A performance penalty in a stateless application, e.g. APIs > * You maybe even not have access to the realm. Consider the identity > provider gives you some form of token containing the attributes which > you CANNOT retreive yourself. How to solve? You can't. I don't believe the penalty exists for a DataSource backend. Most likely for LDAP. Either way, the application is now non portable. Given that the benefit for DataSource does not seem large, this simply sounds bad in that case. For LDAP, it sounds like a tradeoff. > No one is aiming here for an ORM layer. One of my points is that this is really far from obvious in the API, so it needs a round of javadoc tightening up. Rémy > > > Mark, > > you have even assisted on how to backport to previous versions and > object somewhat as well? I don't understand that. > > > From my PoV Carsten did everything we requested over a very long period > of time. > > M --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
