Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of pmuir@redhat.com designates
 209.132.183.28 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
Subject: Re: [DISCUSS] Logging
From: Pete Muir <pmuir@redhat.com>
In-Reply-To: <1327492649.24561.YahooMailNeo@web171520.mail.ir2.yahoo.com>
Date: Wed, 25 Jan 2012 12:03:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <433F6747-AF71-4116-8C2F-60DEA18AAACA@redhat.com>
References: 
 <CAKeeVe4ZkQ=c2r0wL20jrEiUVFG2A7U+y8W2OYNgV4hdF55-Xg@mail.gmail.com>
 <CAOqetn909iJ-ZT7sxMq2h4NbFrRutd6D26WA7g6-9QHGqw1-qA@mail.gmail.com>
 <CAEXeC6wS+cJzqnsk+VsmUgNFsMN64cxY2RgGg3urQ3WQcRhT0w@mail.gmail.com>
 <CAEp_U4He=ZFot0xQv4+TyV1w44_BaRo53R_7NCkvQQqcq7TeRw@mail.gmail.com>
 <CAKeHnO5XhbHyzyezqo-ceh+mN_tzNYu_BpA_rCYDS3cN1_z1_Q@mail.gmail.com>
 <1327478621.82455.YahooMailNeo@web171519.mail.ir2.yahoo.com>
 <CAGJtJfFJi3GyRts56FcsA4bgbpZZSPQie7tE6odJaOZYOErAwQ@mail.gmail.com>
 <CAGJtJfHFuDFNOHw4TMSDJFfDzq29zJ+OY2mBpYX+=AupFZ5iiA@mail.gmail.com>
 <01024DB2-E329-48B3-B210-5F664466A25C@redhat.com>
 <1327492649.24561.YahooMailNeo@web171520.mail.ir2.yahoo.com>
To: deltaspike-dev@incubator.apache.org, Mark Struberg <struberg@yahoo.de>

I don't think internationalized error messages don't make sense from a =
technical perspective. All the arguments I've seen against them are =
social (we can't as easily answer their questions as we can't understand =
the error message). If there are technical reasons, I would be =
interested to hear them.

PS at Red Hat, the roles are a bit different. Engineers come up with the =
ideas, and Product Managers filter whether they make sense for the =
business to sell or not.

On 25 Jan 2012, at 11:57, Mark Struberg wrote:

> Product Managers often likes to have stuff - and also often they =
cannot argument WHY they like to have them ;)
>=20
>=20
> That's part of the job of a Product Manager - to come up with new =
ideas. Some of them are good, others are not.
> Our job as technician is to filter out the ones who make no sense from =
a technological perspective.
>=20
> LieGrue,
> strub
>=20
>=20
>=20
> ----- Original Message -----
>> From: Pete Muir <pmuir@redhat.com>
>> To: deltaspike-dev@incubator.apache.org
>> Cc:=20
>> Sent: Wednesday, January 25, 2012 12:23 PM
>> Subject: Re: [DISCUSS] Logging
>>=20
>>=20
>>=20
>> Also,
>>=20
>> On 25 Jan 2012, at 09:25, Gerhard Petracek wrote:
>>=20
>>> 1) -1 for i18n logging (i think we agree on it already)
>>=20
>> I know our product managers are after i8ln for log messages - at =
least INFO=20
>> (IIRC) and above should be l10n'd. I'll try to share the why when=20
>> I've chatted to them.
>>=20
>> So, I'm +0 right now.
>>=20
>>> 2) +1 for fast internal logging
>>=20
>> +10
>>=20
>>> 3) +1 for avoiding dependencies (or shade them in - if it's really=20=

>> needed
>>> and we are allowed to do it).
>>>     it would be nice if all of our modules which are directly =
related to
>>> java-ee specs. can be used without additional dependencies for =
applications
>>> which get deployed to a java-ee6+ application-server.
>>=20
>> +10
>>=20
>>> 4) +0.5 for a >thin< abstraction layer + jul as default (>at=20
>> least< to get
>>> a more concise api)
>>=20
>> I would be +1 here, we've seen this work well in JBoss AS 7, and it =
seems=20
>> much neater than the previous log4j stuff we had. However this might =
just be a=20
>> better thin layer ;-)
>>=20
>>> 5) +1 for supporting type-safe logging for applications, >if< we =
keep=20
>> it in
>>> an own module
>>=20
>> +1
>>=20
>>> 6) -1 for using type-safe logging >within< deltaspike (imo we=20
>> don't need it
>>> internally)
>>=20
>> +1
>>=20
>>> 7) +1 for error-codes
>>=20
>> +1 - we would really appreciate this at JBoss, when it comes time to =
provide=20
>> support to our customers for Deltaspike.
>>=20
>>> 8) +1 for talking about concrete prototype/s (via [1]) and resolve =
this
>>> topic in v0.2
>>>=20
>>> regards,
>>> gerhard
>>>=20
>>> [1]
>>>=20
>> =
https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workf=
lows#SuggestedGitWorkflows-Discussionworkflow(optional)
>>>=20
>>>=20
>>>=20
>>> 2012/1/25 Gerhard Petracek <gerhard.petracek@gmail.com>
>>>=20
>>>> +1!
>>>>=20
>>>> regards,
>>>> gerhard
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> 2012/1/25 Mark Struberg <struberg@yahoo.de>
>>>>=20
>>>>>>> -1 to i18n and typesafe logging for version one.
>>>>>>>=20
>>>>>>=20
>>>>>> Lincoln, why you hatin' on type-safe logging? Brother, hook=20
>> me up with
>>>>> a +1
>>>>>> :)
>>>>>>=20
>>>>>> -Dan
>>>>>>=20
>>>>>=20
>>>>> Hehe, that's the nice thing here at Apache.
>>>>> Since we only discuss those things on strictly technical levels we=20=

>> are
>>>>> still all brothers, even if we get some -1 sometimes :)
>>>>>=20
>>>>> Don't worry Dan, if there are diverse opinions, then we have=20
>> passed the
>>>>> test for the first lesson: free thinking :)
>>>>>=20
>>>>> Having some +1 and -1 in an early discussion phase only means one=20=

>> thing:
>>>>> we need more arguments.
>>>>>=20
>>>>> Lincoln, most of the times (at least if you see that a few people=20=

>> already
>>>>> casted +1 for some idea) it's very helpful if you underline=20
>> your -1 with
>>>>> technical arguments means "_why_ you don't like type-safe=20
>> logging" and/or
>>>>> the requirements you would have for such a feature to be=20
>> successful.
>>>>>=20
>>>>> Most votes here are majority votes [1], but I've seen it many=20
>> times that
>>>>> (even after there are already lots of +1 on the table) a single=20
>> person
>>>>> outlined a problem and did cast -1. And if the argument is valid,=20=

>> it's
>>>>> pretty often the case that the others recall their +1 and change =
it=20
>> to -1
>>>>> as well.
>>>>>=20
>>>>> It's really all about the arguments.
>>>>>=20
>>>>> LieGrue,
>>>>> strub
>>>>>=20
>>>>> [1] http://www.apache.org/foundation/voting.html
>>>>>=20
>>>>=20
>>>>=20
>>=20