Return-Path: X-Original-To: apmail-struts-dev-archive@www.apache.org Delivered-To: apmail-struts-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5797F18801 for ; Fri, 12 Feb 2016 16:13:16 +0000 (UTC) Received: (qmail 98149 invoked by uid 500); 12 Feb 2016 16:13:16 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 98113 invoked by uid 500); 12 Feb 2016 16:13:16 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 98102 invoked by uid 99); 12 Feb 2016 16:13:16 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2016 16:13:16 +0000 Received: from Renes-MBP.fritz.box (static-89-1-30-186.netcologne.de [89.1.30.186]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0D05F1A0046 for ; Fri, 12 Feb 2016 16:13:12 +0000 (UTC) Subject: Re: SMI on steroids Feature Request To: Struts Developers List References: From: Rene Gielen X-Enigmail-Draft-Status: N1110 Message-ID: <56BE0495.3030804@apache.org> Date: Fri, 12 Feb 2016 17:13:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Greg is a Struts committer and as such completely free to implement and commit on features or bugs, with or without PR. Given that, I think Greg is pretty well aware how things are run. Just in case this needs clarification, I'll put this straight with my "manager" (aka PMC member) hat on: What goes into releases is subject to silent consensus or explicit consensus if discussion is needed or wanted. While the PMC members have the final word in non-trivial or controversial decisions, all participants on the dev-list or user-list are heard and have the power to express their opinions and thus influence actual decisions. The depicted decision flow is incorrect in that we don't have one, two or whatever number of folks here that "filter" requests and then pass it to be voted upon. We rarely vote on features anyway. We prefer simple discussions among all people feeling involved, with hopefully valuable outcome. The sole purpose of this thread is to clarify on future directions of SMI/DMI. I have no clue what kind of working patch, as suggested, would help here. As for making the case for users and user impact as well as why something is useful, this is the *essence* of this thread and the referenced ticket and this is exactly what is being discussed here. - Ren� Am 12.02.16 um 14:45 schrieb Martin Gainty: > Hi Greg > since barosso got a FT job at Amazon the Struts managers that call the shots on new Struts features are Lukasz and Dave > > If they say this is a good idea that should be voted on and then implemented then perhaps our feature might be implemented > > My suggestions is to lay out the groundwork for the new feature that is: > Make the case that users like yourself would find this new feature useful > If possible submit a working patch to latest codebase and a testcase demonstrating the viability of this new feature > As you probably have guessed already i am not a manager..so this is not my call > Good Luck Greg! > Martin > ______________________________________________ > > > >> Date: Thu, 11 Feb 2016 11:02:41 +0000 >> Subject: Re: SMI on steroids >> From: gregh3269@gmail.com >> To: dev@struts.apache.org >> >> Can there be two levels on the SMI? >> >> If DMI is on and SMI is in relaxed-strict mode (false) we can leave the >> >> {1} and prefix{0}suffix in so it works. >> >> although it would be better to have some kind of regex ie >> regex:([A-Z-a-z]*) for safety plus a max length! >> >> Then if SMI is in strict mode (true) remove {1} and prefix{0}suffix so it >> will then fall back on the global/allowed-methods. >> >> Just a thought. >> >> Cheers Greg >> >> >> >> >> On 5 February 2016 at 09:23, Lukasz Lenart wrote: >> >>> 2016-02-05 10:20 GMT+01:00 Greg Huber : >>>> my lastest comment.. >>>> >>>> The entry that we don't want is {1} style >>>> >>>> PatternAllowedMethod{allowedMethodPattern=(.*), original='\{1\}'\} >>>> >>>> which is don't check anything, effectively disabling SMI. >>>> >>>> run{1}This style could be left in, as they are pretty restrictive, or is >>>> there a regex for the pattern that could be added to the globals, >>>> acknowledging there is a potential risk in your DMI? >>> >>> Yes, that true, but this approach is very strict and can affect many >>> users/projects. I would like to hear other's opinion >>> >>> >>> Regards >>> -- >>> �ukasz >>> + 48 606 323 122 http://www.lenart.org.pl/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> > > -- Ren� Gielen http://twitter.com/rgielen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org