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 3B40AF96C for ; Mon, 26 May 2014 13:54:02 +0000 (UTC) Received: (qmail 65621 invoked by uid 500); 26 May 2014 13:54:01 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 65575 invoked by uid 500); 26 May 2014 13:54:01 -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 65567 invoked by uid 99); 26 May 2014 13:54:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 May 2014 13:54:01 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grobmeier@gmail.com designates 209.85.212.173 as permitted sender) Received: from [209.85.212.173] (HELO mail-wi0-f173.google.com) (209.85.212.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 May 2014 13:53:57 +0000 Received: by mail-wi0-f173.google.com with SMTP id bs8so15503wib.6 for ; Mon, 26 May 2014 06:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-type; bh=6D+mPL9NgdGPqySbVOiQdg2INJfGZth9l4Ur95X0LjM=; b=AwNfxFUP+9BMP2l0hgL7zfKUkHJsVkn4UZ1E0bozmRABEz9GkPNizsKGVCfzA2IIAL 02B8iINis8DXUvMbq23Etzort/gRv3cjDV/wW51UuS2/Q8ulzD+fO4RFsst9Qzb5Glcu mIctdRhuj/70gYw3cZ9bIoMTQT//fEwRBdX/Eo0odb3bpX4lJatqP+RyxvFAC+NJzjf3 bd8nicY+uC8OjnsiHtvpNqBtAfMvPbPyxoSKRlsoJMfoL9CU4R+901B6V9upHcnprIJ0 wrNNdQEioPWeEOvq6llOG3bCRNynTYwQpA/Qfi1CizG9C7WIs4HcNa+hulqxyeQmCDbx jzHw== X-Received: by 10.180.211.36 with SMTP id mz4mr28463219wic.20.1401112413813; Mon, 26 May 2014 06:53:33 -0700 (PDT) Received: from [192.168.56.1] (p579D5ED5.dip0.t-ipconnect.de. [87.157.94.213]) by mx.google.com with ESMTPSA id br5sm27067526wjc.9.2014.05.26.06.53.32 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 May 2014 06:53:32 -0700 (PDT) From: "Christian Grobmeier" To: "Struts Developers List" Subject: Re: Less boilerplate in code Date: Mon, 26 May 2014 15:53:21 +0200 Message-ID: <8279E44A-B03C-4904-95D8-62D01B677AFA@gmail.com> In-Reply-To: References: <6EE2F746-0DB2-4FBF-860E-2A29B29AA62B@gmail.com> <2DF35C18-5BBC-4B3A-98D0-3964C2BD38AA@gmail.com> <19157518-807D-4900-8267-C7FC95B18EDF@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4214) X-Virus-Checked: Checked by ClamAV on apache.org On 24 May 2014, at 17:11, Dave Newton wrote: > On May 24, 2014 8:09 AM, "Christian Grobmeier" > wrote: >> I didn't know this: {0.enrollmentDate,date,yyyy-MM-dd} would call > SimpleDateFormat. > > I find it reasonably obvious this is formatting a date. My point is you have to learn about it. There is no code completion to help you. Maybe you can imagine this is formatting a date because there is some format given, but I can't tell whats the "date" parameter for. I would have to read the docs. I don't want to force our users reading docs except our own. You could argue slf4j needs some doc reading itself, but many developers may have done so already. Its more widespread and probably a better investment of time. > I also don't see anything confusing about the call itself. I prefer > code > to be distilled to its essence. In this case, logging, I'd rather > focus on > what I'm logging than the mechanics of Java. A giant chunk of code in > the > middle of what I'm *really* doing is distracting and takes the focus > away > from the problem being solved. If there is a lot of code hidden from you, then there is a lot code which might be buggy. Nobody prevents you to use that framework if you like it that much, but that is nothing which a framework like Struts should dictate. Instead I believe Struts should stick to common sense wherever possible, and logging is one of these cases. > This is true of Java in general, but I don't want to be overwhelmed by > secondary concerns while reading code, whenever possible. > > While I don't necessarily advocate this as the *only* solution, I > wouldn't > mind introducing some minor syntax in format strings. I do wonder if > it > should fit in better with an existing EL rather than introducing yet > another, though. When it comes to logging i am a purist. People already complain because there are too many logging solutions around today, I don't think it would make any sense to have something special for Struts. There is some stuff people can use, why are we not using what everybody else uses? In regards to Onyx, I have a few more reasons why I would like to avoid its introduction. In example: - maintained by a single person - who fixes the bugs, when there are some? See OGNL. - in 2013 only two commits were made - no very active - haven't seen the package on maven central repos - not wide spread, 18 downloads for each version - small version number tells me there is not yet trust in stability For technical reasons I don't like it's syntax and think it's way to much reflection for solving a simple problem. To be honest (and sorry, Chris, I really think it was lot of work and you are quite talented) I would prefer to the custom logging we have and know instead of using a pretty unknown, exotic logging wrapper. That's my two cents, and now I will shut up for a few days on the matter to give others space to breath. Thanks! Christian > > Dave --- http://www.grobmeier.de The Zen Programmer: http://bit.ly/12lC6DL @grobmeier GPG: 0xA5CC90DB --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org