2015-09-28 13:11 GMT+02:00 Christoph Nenning <christoph.nenn...@lex-com.net>: >> > What does the current implementation do? >> > if strictDMI is set to false it returns false. >> > if it is set to true parent packages are checked. if it is true in one >> > parent true is returned. >> > otherwise true is returned in anycase. >> > >> > IMHO it can be just a simple getter. >> >> You are right :) But I have some doubts, what if someone has a large >> application with multiple packages? Right now it will have to disable >> Stritc DMI in each one, Strict DMI isn't inhertited so it can be done >> in parent package (his own, not from Struts). But from other side we >> want to have SMI* is enabled by default. >> > > > That means if SMI is false it could mean 2 things: > - was explicitly set to false > - was not set and parent package should be checked > > If it is true it was explicitly configured and parent packages don't need > to be checked.
If it was not set, the assumption is to use the default value which is "true" > I would turn it into a Boolean that can be null. So it is more clear what > the state in xml is and whether it is necessary to check parent packages. I thought about the same ... >> * SMI -> Stritc Method Invocation - it comes to me that DMI is >> something different than SMI so we should use different abbrevation. >> SMI works independly from DMI, SMI performs checks inside application >> (tax police), and DMI does the same but on user input (border police). > > That means when methods are configured as own actions they must be > additionally configured as allowed-methods? Nope, methods configured as actions (used with "method" attribute or marked as @Action) are automatically added as allowed-methods >> If there be no objections I would like to merge this PR and >> push a new BETA today > > +1 > > More changes can be made in master ;) > And we might get feedback if users have issues with SMI. Thanks for review and all you comments! Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
