That would work for me. Sent from my iPhone
On Jan 27, 2012, at 0:52, Mark Struberg <[email protected]> wrote: > What if we move this to an own i18n module together with the Message factory > stuff? > Just an idea, I bet there are better options out there. > > LieGrue, > strub > > > > ----- Original Message ----- >> From: "Lincoln Baxter, III" <[email protected]> >> To: [email protected] >> Cc: >> Sent: Friday, January 27, 2012 5:07 AM >> Subject: Re: [DISCUSS] Logging >> >> T he only reason why I -1 typesafe logging is because I don't think we >> really need it for internal development. I don't think we should rule out >> providing it as a feature - if that makes any sense. I think it adds >> complexity that we probably don't really need. I guess I don't have a >> very >> strong opinion though, so I could change that to a +0 for typesafe logging. >> >> ~Lincoln >> >> On Wed, Jan 25, 2012 at 7:03 AM, Pete Muir <[email protected]> wrote: >> >>> 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 ;) >>>> >>>> >>>> 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. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Pete Muir <[email protected]> >>>>> To: [email protected] >>>>> Cc: >>>>> Sent: Wednesday, January 25, 2012 12:23 PM >>>>> Subject: Re: [DISCUSS] Logging >>>>> >>>>> >>>>> >>>>> Also, >>>>> >>>>> On 25 Jan 2012, at 09:25, Gerhard Petracek wrote: >>>>> >>>>>> 1) -1 for i18n logging (i think we agree on it already) >>>>> >>>>> I know our product managers are after i8ln for log messages - at >> least >>> INFO >>>>> (IIRC) and above should be l10n'd. I'll try to share the >> why when >>>>> I've chatted to them. >>>>> >>>>> So, I'm +0 right now. >>>>> >>>>>> 2) +1 for fast internal logging >>>>> >>>>> +10 >>>>> >>>>>> 3) +1 for avoiding dependencies (or shade them in - if >> it's really >>>>> 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. >>>>> >>>>> +10 >>>>> >>>>>> 4) +0.5 for a >thin< abstraction layer + jul as default >> (>at >>>>> least< to get >>>>>> a more concise api) >>>>> >>>>> I would be +1 here, we've seen this work well in JBoss AS 7, >> and it >>> seems >>>>> much neater than the previous log4j stuff we had. However this >> might >>> just be a >>>>> better thin layer ;-) >>>>> >>>>>> 5) +1 for supporting type-safe logging for applications, >>> if< we keep >>>>> it in >>>>>> an own module >>>>> >>>>> +1 >>>>> >>>>>> 6) -1 for using type-safe logging >within< deltaspike >> (imo we >>>>> don't need it >>>>>> internally) >>>>> >>>>> +1 >>>>> >>>>>> 7) +1 for error-codes >>>>> >>>>> +1 - we would really appreciate this at JBoss, when it comes time >> to >>> provide >>>>> support to our customers for Deltaspike. >>>>> >>>>>> 8) +1 for talking about concrete prototype/s (via [1]) and >> resolve this >>>>>> topic in v0.2 >>>>>> >>>>>> regards, >>>>>> gerhard >>>>>> >>>>>> [1] >>>>>> >>>>> >>> >> https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows#SuggestedGitWorkflows-Discussionworkflow(optional)<https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows#SuggestedGitWorkflows-Discussionworkflow%28optional%29> >>>>>> >>>>>> >>>>>> >>>>>> 2012/1/25 Gerhard Petracek <[email protected]> >>>>>> >>>>>>> +1! >>>>>>> >>>>>>> regards, >>>>>>> gerhard >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/1/25 Mark Struberg <[email protected]> >>>>>>> >>>>>>>>>> -1 to i18n and typesafe logging for version >> one. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Lincoln, why you hatin' on type-safe logging? >> Brother, hook >>>>> me up with >>>>>>>> a +1 >>>>>>>>> :) >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>> >>>>>>>> Hehe, that's the nice thing here at Apache. >>>>>>>> Since we only discuss those things on strictly >> technical levels we >>>>> are >>>>>>>> still all brothers, even if we get some -1 sometimes >> :) >>>>>>>> >>>>>>>> Don't worry Dan, if there are diverse opinions, >> then we have >>>>> passed the >>>>>>>> test for the first lesson: free thinking :) >>>>>>>> >>>>>>>> Having some +1 and -1 in an early discussion phase >> only means one >>>>> thing: >>>>>>>> we need more arguments. >>>>>>>> >>>>>>>> Lincoln, most of the times (at least if you see that a >> few people >>>>> already >>>>>>>> casted +1 for some idea) it's very helpful if you >> underline >>>>> your -1 with >>>>>>>> technical arguments means "_why_ you don't >> like type-safe >>>>> logging" and/or >>>>>>>> the requirements you would have for such a feature to >> be >>>>> successful. >>>>>>>> >>>>>>>> Most votes here are majority votes [1], but I've >> seen it many >>>>> times that >>>>>>>> (even after there are already lots of +1 on the table) >> a single >>>>> person >>>>>>>> outlined a problem and did cast -1. And if the >> argument is valid, >>>>> it's >>>>>>>> pretty often the case that the others recall their +1 >> and change it >>>>> to -1 >>>>>>>> as well. >>>>>>>> >>>>>>>> It's really all about the arguments. >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> [1] http://www.apache.org/foundation/voting.html >>>>>>>> >>>>>>> >>>>>>> >>>>> >>> >>> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.com >> http://scrumshark.com >> "Keep it Simple" >>
