Return-Path: X-Original-To: apmail-logging-log4j-dev-archive@www.apache.org Delivered-To: apmail-logging-log4j-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 74CC51112B for ; Mon, 2 Jun 2014 14:22:50 +0000 (UTC) Received: (qmail 47206 invoked by uid 500); 2 Jun 2014 14:22:50 -0000 Delivered-To: apmail-logging-log4j-dev-archive@logging.apache.org Received: (qmail 47152 invoked by uid 500); 2 Jun 2014 14:22:50 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 47142 invoked by uid 99); 2 Jun 2014 14:22:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2014 14:22:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of garydgregory@gmail.com designates 209.85.160.49 as permitted sender) Received: from [209.85.160.49] (HELO mail-pb0-f49.google.com) (209.85.160.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Jun 2014 14:22:47 +0000 Received: by mail-pb0-f49.google.com with SMTP id jt11so4262244pbb.22 for ; Mon, 02 Jun 2014 07:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MUfxtqn1JgBy4mH/F5AfvhKmIrjxR7nczs9bE5VX+Ms=; b=KKMnAQ7r8UrlWzFIgxCwC74DRWIKJM57UHdiX9Zalwem4Nt4aPxa6ffgwHGzsNaCIw 1Jz7HikbR1N5bLOACxe/Skp96OPZ66n4lH44Min9NiC+8UJ2GHJcQycIcQD+V8BCTMrZ +04CbckQL5NgNckGf1mm+79oQaPgYAhicyjHpUk1Mi6W3S9R7u1n1zVSfFJTDWzTLBGj MdfFB+3bDjELU2cFo5tKHemf/3XyoKzY5lTzCvrPpmpyy20xJbT/xiZ9vn2zBP7SzhOZ Q/eTaOk1exI8JdV5hig2Y3xdaNCsU8NWzs1SBxpebElatC4SiXV1BuWdWpUmjn9NxNZ9 JXEw== MIME-Version: 1.0 X-Received: by 10.68.173.65 with SMTP id bi1mr41243864pbc.130.1401718942646; Mon, 02 Jun 2014 07:22:22 -0700 (PDT) Received: by 10.70.127.196 with HTTP; Mon, 2 Jun 2014 07:22:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Jun 2014 10:22:22 -0400 Message-ID: Subject: Re: PluginAttribute choice From: Gary Gregory To: Log4J Developers List Content-Type: multipart/alternative; boundary=047d7b3a99d8a6c84c04fadb1f0f X-Virus-Checked: Checked by ClamAV on apache.org --047d7b3a99d8a6c84c04fadb1f0f Content-Type: text/plain; charset=UTF-8 If we support typed attributes as we do now, you can still use Strings everywhere, it's up to the plugin author. I really did not like seeing the same String to foo type conversion code in each plugin. The less boiler plate code the better. There is less room for error when you declare your param as an int or other (primitive or not) type. It's a nice separation of concerns. Gary On Mon, Jun 2, 2014 at 9:56 AM, Paul Benedict wrote: > I go back and forth with the need to have plugin attributes be strongly > typed. First, I am not a fan of it because annotations don't support > multiple types well (as Ralph said) and string expressions can be pretty > powerful if you want to allow script expressions (as Ralph said). That is > my real opinion of the matter. But I don't mind being a team player to help > other designs... :-) If you all do decide to go with strongly typed > annotations, definitely go with multiple annotation types (as I proposed a > few days back). > > Yet I don't think you guys should worry too much about strongly typed data > here because annotation processing is all about validating the metadata -- > no matter what you choose. There isn't any tangible gain on making this > feature strongly typed. I would simply treat the default value as an > expression and call it a day. That will remove the added complexity of > needing other annotations. > > > > Cheers, > Paul > > > On Mon, Jun 2, 2014 at 8:48 AM, Matt Sicker wrote: > >> Jackson is how we handle YAML and JSON configs anyways. It might be worth >> looking into for 2.1. >> >> >> On 2 June 2014 08:19, Gary Gregory wrote: >> >>> I'm not trying to handle all cases under the sun. But... we've chosen >>> NOT to use an XML Schema based XML IO framework (like JAXB or Jackson), >>> instead we've invented our own. I know we do JSON as well, but so does >>> Jackson and it likely also has a plugin for YAML. So now, every time I'm >>> looking for some minor improvement, it means tweaking our custom framework >>> or adding boilerplate code to plugins. It's a pain, but that's where we are >>> today. At least now, with the new type converters, I get the type >>> conversion from to int for free :-) >>> >>> In this case, I meant, you can only use attribute A or B. >>> >>> It is probably worth stepping back and looking at the big picture and >>> whether we want to invest in improving the current config IO framework or >>> at least consider if Jackson would be a better fit. Likely not for 2.0 ;-) >>> >>> Gary >>> >>> >>> On Mon, Jun 2, 2014 at 4:03 AM, Ralph Goers wrote: >>> >>>> Are you looking for annotations to handle every kind of thing you might >>>> like to do instead of just putting a couple lines of code in the factory >>>> method? I would have handled this by saying foo and bar both need to be >>>> Integer and then adding a line do code that insures exactly one, or at most >>>> one, is present ( depending on what you want ). >>>> >>>> I really have no idea what it means for an attribute or element to be >>>> in a "choice". Does it mean at most one is specified or exactly one? What >>>> if I want exactly one in some cases and at most one in others? >>>> >>>> Ralph >>>> >>>> On Jun 1, 2014, at 11:53 PM, Gary Gregory >>>> wrote: >>>> >>>> How do I tell my plugin that it can have attribute1 or 2, but not both? >>>> IOW I want the config framework to do the validation for me. >>>> >>>> How about: >>>> >>>> >>>> @PluginAttribute(choice="group1") int foo, >>>> >>>> >>>> >>>> >>>> @PluginAttribute(choice="group1") int bar >>>> >>>> Same thing for elements. >>>> >>>> Thoughts? >>>> >>>> Gary >>>> >>>> -- >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org >>>> Java Persistence with Hibernate, Second Edition >>>> >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>>> >>>> >>> >>> >>> -- >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org >>> Java Persistence with Hibernate, Second Edition >>> >>> JUnit in Action, Second Edition >>> Spring Batch in Action >>> Blog: http://garygregory.wordpress.com >>> Home: http://garygregory.com/ >>> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >> -- >> Matt Sicker >> > > -- E-Mail: garydgregory@gmail.com | ggregory@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory --047d7b3a99d8a6c84c04fadb1f0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we support typed attributes as we d= o now, you can still use Strings everywhere, it's up to the plugin auth= or.

I really did not like seeing the same String to foo type c= onversion code in each plugin. The less boiler plate code the better.

There is less room for error when you declare your param as= an int or other (primitive or not) type. It's a nice separation of con= cerns.

Gary


On Mon, Jun 2, 2014 at 9:56 AM, Paul Benedict <pbenedict@apache.org= > wrote:
I go back and forth with the need to have plugin attribute= s be strongly typed. First, I am not a fan of it because annotations don= 9;t support multiple types well (as Ralph said) and string expressions can = be pretty powerful if you want to allow script expressions (as Ralph said).= That is my real opinion of the matter. But I don't mind being a team p= layer to help other designs... :-) If you all do decide to go with strongly= typed annotations, definitely go with multiple annotation types (as I prop= osed a few days back).

Yet I don't think you guys should worry too much about strongly typ= ed data here because annotation processing is all about validating the meta= data -- no matter what you choose. There isn't any tangible gain on mak= ing this feature strongly typed. I would simply treat the default value as = an expression and call it a day. That will remove the added complexity of n= eeding other annotations.



Cheers,
Paul


On Mon, Jun 2, 2014 at 8:48 AM, Matt Sic= ker <boards@gmail.com> wrote:
Jackson is how we handle YAML and JSON configs anyways. It= might be worth looking into for 2.1.

<= br>
On 2 June 2014 08:19, Gary Gregory <ga= rydgregory@gmail.com> wrote:
I'm not trying to = handle all cases under the sun. But... we've chosen NOT to use an XML S= chema based XML IO framework (like JAXB or Jackson), instead we've inve= nted our own. I know we do JSON as well, but so does Jackson and it likely = also has a plugin for YAML. So now, every time I'm looking for some min= or improvement, it means tweaking our custom framework or adding boilerplat= e code to plugins. It's a pain, but that's where we are today. At l= east now, with the new type converters, I get the type conversion from to i= nt for free :-)

In this case, I meant, you can only use attribute A or B.
It is probably worth stepping back and looking at the big p= icture and whether we want to invest in improving the current config IO fra= mework or at least consider if Jackson would be a better fit. Likely not fo= r 2.0 ;-)

Gary


On Mon, Jun 2, 2014 at 4:03 AM, Ralph Goers <rgoers@apach= e.org> wrote:
Are you looking for a= nnotations to handle every kind of thing you might like to do instead of ju= st putting a couple lines of code in the factory method? I would have handl= ed this by saying foo and bar both need to be Integer and then adding a lin= e do code that insures exactly one, or at most one, is present ( depending = on what you want ).=C2=A0

I really have no idea what it means for an attribute or= element to be in a "choice". Does it mean at most one is specifi= ed or exactly one? What if I want exactly one in some cases and at most one= in others?

Ralph

On Jun 1, 2014, at 11:53 PM= , Gary Gregory <garydgregory@gmail.com> wrote:

How do I tell my plugin that it can have attribu= te1 or 2, but not both? IOW I want the config framework to do the validatio= n for me.

How about:

@PluginAttribute(choice=3D&qu=
ot;group1") int foo,





@PluginAttribute(choice=3D"group1") int bar

Sam=
e thing for elements.

Thoughts?
Gary



--
=


--
Matt Sicker <boards@gmail.com>




--
--047d7b3a99d8a6c84c04fadb1f0f--