Re: Less boilerplate in code

[Johannes Geppert <jo...@apache.org>]

Hi all,

I can understand Lukasz to avoid a maybe not necessary dependency.
But on the other hand why reinvent this logging facade if there already
exists a good and widely used solution within the ASF which is flexible
enough?
I think we should not care about base stuff like logging, better
concentrate on struts features, I mean what has logging to do with struts
or xwork?

@grobmeier
Is it possible to use Log4j2 as facade and the user can choose Slf4j with
log4j1?
Or better is there any limitation for the user if we decide to use Log4j2
as the logging facade?

This onyx stuff looks like a advantage and may some developer likes it and
some not.
For me it looks like a maybe usefully feature for the users but may not on
the web framework site.
May this should better donated as a log4j2 plugin.


Best Regards

Johannes

#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep



2014-05-27 7:51 GMT+02:00 Lukasz Lenart <lu...@apache.org>:

> 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 <gr...@gmail.com>:
> > On 24 May 2014, at 17:11, Dave Newton wrote:
> >
> >> On May 24, 2014 8:09 AM, "Christian Grobmeier" <gr...@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-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Less boilerplate in code

[Gabriel Guerreiro <Ga...@maisis.pt>]

Hi,

The Onyx idea is great. Some benchmarks would help, though.
Like Slf4J, it adds pattern matching interpretation that can have 
undetected human errors.

For some applications, log performance is really important.
But for a lot of users, the chore of changing log frameworks and 
managing dependencies is what they really care.

Instead of using it inside of Struts, why not donating it to a yet 
established log framework?
Some of the already too many log frameworks should really come together 
and provide compatible user APIs.
Users should be able to change a dependency and the imports and have 
everything working without changing every log statement.

It is not an advantage of an open source web framework to have an 
internal logging wrapper.
Just adds nedded configuration and a need to understand it when 
debugging inside the Struts code.

Best Regards,

Gabriel

Em 06-06-2014 09:06, Johannes Geppert escreveu:
> Hi all,
>
> I can understand Lukasz to avoid a maybe not necessary dependency.
> But on the other hand why reinvent this logging facade if there already
> exists a good and widely used solution within the ASF which is flexible
> enough?
> I think we should not care about base stuff like logging, better
> concentrate on struts features, I mean what has logging to do with struts
> or xwork?
>
> @grobmeier
> Is it possible to use Log4j2 as facade and the user can choose Slf4j with
> log4j1?
> Or better is there any limitation for the user if we decide to use Log4j2
> as the logging facade?
>
> This onyx stuff looks like a advantage and may some developer likes it and
> some not.
> For me it looks like a maybe usefully feature for the users but may not on
> the web framework site.
> May this should better donated as a log4j2 plugin.
>
>
> Best Regards
>
> Johannes
>
> #################################################
> web: http://www.jgeppert.com
> twitter: http://twitter.com/jogep
>
>
>
> 2014-05-27 7:51 GMT+02:00 Lukasz Lenart <lu...@apache.org>:
>
>> 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 <gr...@gmail.com>:
>>> On 24 May 2014, at 17:11, Dave Newton wrote:
>>>
>>>> On May 24, 2014 8:09 AM, "Christian Grobmeier" <gr...@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-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Less boilerplate in code

[Lukasz Lenart <lu...@apache.org>]

2014-06-06 10:52 GMT+02:00 Johannes Geppert <jo...@gmail.com>:
>>I think that's the main case in this whole discussion - it isn't about
>>users and what kind of logging library they are using. That aspect
>>must stay as is, users cannot notice any change.
> Exact the user should be able to use any logging framework he want to
> choose.
> But if Log4j2 facade provides this feature why not use it?

Because it's a huge and boring task - you must rewrite each and every
logging statement to match Log4j2/SLF4j - XWork logger is using #0,
#1,... for params substitution, where Log4j2 is using #{} and SLF4j {}

> Logging itself is not our business or am I wrong?

It's not but we should provide the best possible integration.


If someone want to step in and replace the whole logging layer with
Log4j2/SLF4j I don't see objections. The same with Onyx, I'm not going
to block any contributors' activity.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Less boilerplate in code

[Johannes Geppert <jo...@gmail.com>]

>I think that's the main case in this whole discussion - it isn't about
>users and what kind of logging library they are using. That aspect
>must stay as is, users cannot notice any change.
Exact the user should be able to use any logging framework he want to
choose.
But if Log4j2 facade provides this feature why not use it?

Logging itself is not our business or am I wrong?



#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep


2014-06-06 10:21 GMT+02:00 Lukasz Lenart <lu...@apache.org>:

> 2014-06-06 10:12 GMT+02:00 Christoph Nenning <
> Christoph.Nenning@lex-com.net>:
> >>
> >> This onyx stuff looks like a advantage and may some developer likes it
> > and
> >> some not.
> >> For me it looks like a maybe usefully feature for the users but may not
> > on
> >> the web framework site.
> >
> >
> > Please keep in mind that users are not affected by onyx. Applications can
> > still choose their own logging facade. Onyx would just be visible to
> > struts committers and contributers.
>
> I think that's the main case in this whole discussion - it isn't about
> users and what kind of logging library they are using. That aspect
> must stay as is, users cannot notice any change.
>
> Onyx will be used only internally, inside Struts and it will depend on
> whatever users has chosen as a logging library, so it must adjust
> itself to users' choice (the same as it's now)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Re: Less boilerplate in code

[Lukasz Lenart <lu...@apache.org>]

2014-06-06 10:12 GMT+02:00 Christoph Nenning <Ch...@lex-com.net>:
>>
>> This onyx stuff looks like a advantage and may some developer likes it
> and
>> some not.
>> For me it looks like a maybe usefully feature for the users but may not
> on
>> the web framework site.
>
>
> Please keep in mind that users are not affected by onyx. Applications can
> still choose their own logging facade. Onyx would just be visible to
> struts committers and contributers.

I think that's the main case in this whole discussion - it isn't about
users and what kind of logging library they are using. That aspect
must stay as is, users cannot notice any change.

Onyx will be used only internally, inside Struts and it will depend on
whatever users has chosen as a logging library, so it must adjust
itself to users' choice (the same as it's now)


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Less boilerplate in code

[Christoph Nenning <Ch...@lex-com.net>]

> 
> This onyx stuff looks like a advantage and may some developer likes it 
and
> some not.
> For me it looks like a maybe usefully feature for the users but may not 
on
> the web framework site.


Please keep in mind that users are not affected by onyx. Applications can 
still choose their own logging facade. Onyx would just be visible to 
struts committers and contributers.


Regards,
Christoph

This Email was scanned by Sophos Anti Virus