I think we are talking about two different aspects.
First: user perspective and in that case users can use whatever
logging layer they want, SLF4j, Log4j, etc. And using XW Logger isn't
prohibited but using it in app isn't recommended approach IMHO. They
shouldn't depend on custom logging mechanism like Logger and it
supposed to be said clearly in the docs (it isn't but it can be easily
improved ;-)
Second: framework shouldn't depend on any concrete implementation to
avoid user confusion and potential problems with many different
logging layers used inside one app. But as a author I want to have a
tool to help me debugging problems inside the framework, I don't want
to spend time on figuring out which logging library should I use - no,
there is already one simple Logger interface and I'm obligated to use
- that's it!
The current approach with tiny XW Logger facade fits in the both cases
very well and I don't want to change that. I just wanted improve this
layer to reduce boilerplate code where on four lines of code three
aren't related to method's logic.
Also Chris stepped in with his offer to donate his work to the project
- so why not to accept someone's help? That's why I pushed this
forward to get another contributor involved and something that
supposed to take two days of development was extended into two weeks
of confusion :(
Regards
Ł.
2014-05-26 15:53 GMT+02:00 Christian Grobmeier <grobme...@gmail.com>:
> On 24 May 2014, at 17:11, Dave Newton wrote:
>
>> On May 24, 2014 8:09 AM, "Christian Grobmeier" <grobme...@gmail.com>
>> 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-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
