> On Nov 4, 2015, at 9:13 AM, Jan Sindberg <[email protected]> wrote: > > I was thinking of centralizing the permissions. For instance as a > Public class Permission_Letters { > static final String name = "LETTERS"; > static final Permission EDIT_DAMAGE_LETTERS = new Permission(name, > "EDIT_DAMAGE_LETTERS"); > ... > ... > } > > Where there must be a check the code can refer to this permission without > making a new Permission and without copying strings all over the source. > ... > If (accessMgr.checkAccess(session, Permission_Letters. EDIT_DAMAGE_LETTERS)) { > // Do stuff > } > ... > In friendly code that is all fine and good, but one could "accidentally" > rename the object and operation through the public setters on any permission, > completely changing the meaning. > If I want to secure my code, instead of static fields I need to do static > methods which return a new Permission object each time. > It's probably not too expensive to create a new object each time there should > be a permission-check, but I would still like to suggest dedicated > constructors and no setters, or at least package scoped setters where > possible. What do you think?
Jan, Still trying to understand your requirements here. What is the rationale of wrapping a fortress Permission instance with another class like Permission_Letters? What does this buy us - convenience, security, flexibility, enhanced capability? I’ll need to understand this before I can comment further on what I think about the idea or how to implement it. Thanks Shawn
