+1 Johannes
################################################# web: http://www.jgeppert.com twitter: http://twitter.com/jogep 2015-09-28 9:50 GMT+02:00 Lukasz Lenart <lukaszlen...@apache.org>: > If there be no objections I would like to merge this PR and push a new > BETA today > > 2015-09-26 9:57 GMT+02:00 Lukasz Lenart <lukaszlen...@apache.org>: > > 2015-09-25 16:04 GMT+02:00 Christoph Nenning < > christoph.nenn...@lex-com.net>: > >> Well, I don't think it is necessary to check parent packages at all. > >> Because strictDMI is a primitive boolean and cannot be null. So each > >> package has it explicitly configured, inheriting it is not required. > >> PackageConfig.isStrictMethodInvocation() should just return that value. > > > > Not exactly, as Boolean.parseBoolean will return "false" if there was > > null and null means there is no "strict-method-invocation" attribute > > configured. That's why I have changed the logic to treat missing > > "strict-method-invocation" attribute as "true" and evaluate parent > > packages. > > > >> 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. > > > > * 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). > > > > > > 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 > >
