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 depe
2014-06-06 10:52 GMT+02:00 Johannes Geppert :
>>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
>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 t
2014-06-06 10:12 GMT+02:00 Christoph Nenning :
>>
>> 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 affe
>
> 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 lo
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
concen
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 mechanis
I will also be quiet in hopes of getting some discussion from other
members. The only clarification I wanted to make is that the format is
based on java.text.MessageFormat, with the addition of dot-notation. So I
don't know how much training will truly be necessary. Most developers have
probably
On 24 May 2014, at 17:11, Dave Newton wrote:
On May 24, 2014 8:09 AM, "Christian Grobmeier"
wrote:
I didn't know this: {0.enrollmentDate,date,-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
On May 24, 2014 8:09 AM, "Christian Grobmeier" wrote:
> I didn't know this: {0.enrollmentDate,date,-MM-dd} would call
SimpleDateFormat.
I find it reasonably obvious this is formatting a date.
I also don't see anything confusing about the call itself. I prefer code
to be distilled to its ess
On 24 May 2014, at 0:43, Chris Pratt wrote:
log.debug("Loading Student [{0.number}] {0.name} Enrolled:
{0.enrollmentDate,date,-MM-dd}",student);
This makes logging complicated.
I actually find it a lot less complicated than the equivalent:
if(log.isDebugEnabled()) {
log.debug("Loading S
>
> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
> {0.enrollmentDate,date,-MM-dd}",student);
This makes logging complicated.
I actually find it a lot less complicated than the equivalent:
if(log.isDebugEnabled()) {
log.debug("Loading Student [{}] {} Enrolled:
{}",student.get
On 23 May 2014, at 22:04, Chris Pratt wrote:
Sorry, I should have included the link -
https://code.google.com/p/anodyzed/
It isn't a replacement for async loggers, it works on the other end of
the
problem, building the log message when it isn't necessary.
you can disable logging in other f
Sorry, I should have included the link - https://code.google.com/p/anodyzed/
It isn't a replacement for async loggers, it works on the other end of the
problem, building the log message when it isn't necessary.
I would actually recommend SLF4j for two reasons. One, it is the front
runner, almost
On 23 May 2014, at 18:22, Chris Pratt wrote:
I'm preparing to start working on the logging for Struts 3.0, so we
need to
come to some consensus. As I see it, the leading options are:
1. Don't do anything
2. Switch to SLF4j (or Log4j2)
3. Use Onyx as is
4. Use Onyx as an Object Aware Facad
I'm preparing to start working on the logging for Struts 3.0, so we need to
come to some consensus. As I see it, the leading options are:
1. Don't do anything
2. Switch to SLF4j (or Log4j2)
3. Use Onyx as is
4. Use Onyx as an Object Aware Facade directly to SLF4j (or Log4j2)
My prefe
Just my $0.02:
I'd prefer to see stuff that other people implement and have more eyes on
take precedence over framework code.
Similar to how XW has/had string utils duped by commons, etc, it just
doesn't make sense to maintain that kind of boilerplate when it's already
implemented, and implemente
On 23 May 2014, at 11:58, Lukasz Lenart wrote:
Yes, we can break everything in 3.x but ... do we want to start from
scratch?
It's not from scratch, is removing something from our codebase and use
something which already exists.
And what's wrong in tiny logging facade? I've said it already, I
Yes, we can break everything in 3.x but ... do we want to start from scratch?
And what's wrong in tiny logging facade? I've said it already, I will
say it again: not all ppl are using Log4j or SLF4j or jul - it's the
worst thing if you must handle configuration of two or three different
logging li
Hi all,
with Struts 3.x we are allowed to "break things" and it is expected that
we do major steps.
Personally I would like to remove any custom made logging layer
and move on to a more standard one. Performance is not an issue, when
logging
is done right:
http://www.grobmeier.de/log4j-2-per
You are correct, it delegates the actual logging to a logging engine,
currently either Log4j, Logback, java.util.logging or to SLF4j.
(*Chris*)
On Wed, May 21, 2014 at 10:10 PM, Lukasz Lenart wrote:
> @Chris
> Do I get it right - Onyx is just logging facade not the full-blow
> logging library?
@Chris
Do I get it right - Onyx is just logging facade not the full-blow
logging library?
2014-05-17 8:52 GMT+02:00 Lukasz Lenart :
> Some were already addressed, another thing is that across the
> framework we are using different semantic inside logging messages, ie:
> "Value [#0] was excluded by
Some were already addressed, another thing is that across the
framework we are using different semantic inside logging messages, ie:
"Value [#0] was excluded by pattern [#1]" and re-writing all these
doesn't make sense. Right now XWork logging facade is very thin - one
class implementing Logger int
Sorry, I don't get your point about java.util.logging? You're saying using
a specific logging engine (java.util.logging) is as portable and useful as
using a logging api designed for the purpose? I understand that commons
logging had several problems, but that's why SLF4j was designed to work
aro
Agreed.
(*Chris*)
On May 16, 2014 5:14 PM, "Paul Benedict" wrote:
> Christoph, I don't think the problem is in using SLF4J in itself. The
> problem is it's not appropriate to switch logging frameworks in a patch
> release. Adding a dependency is going to cause major upgrade headaches --
> espec
Christoph, I don't think the problem is in using SLF4J in itself. The
problem is it's not appropriate to switch logging frameworks in a patch
release. Adding a dependency is going to cause major upgrade headaches --
especially logging dependencies. If anything is done, this will be on the
2.5 or 3.
I should be able to add the dot syntax to the existing xwork logger (I'll
have to research further to be sure). One other change I would suggest is
changing the order of the logging engine discovery. If you test for log4j
before you test for slf4j, then there's no way to use slf4j as the api with
> -Original Message-
> From: Chris Pratt
> Sent: Wednesday, May 14, 2014 15:52
>
> Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
> probably more stable and definitely more supported. So I'd probably
> recommend that we extract the SLF4j support object and use it
I don't get why we wouldn't use slf4j.
On Thursday, May 15, 2014, Lukasz Lenart wrote:
> 2014-05-14 21:51 GMT+02:00 Chris Pratt
> >:
> > Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
> > probably more stable and definitely more supported. So I'd probably
> > recommend th
> > Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
> > probably more stable and definitely more supported. So I'd probably
> > recommend that we extract the SLF4j support object and use it directly
(or
> > at least make it the default). If it's something that you're
intere
What is your reluctance to using SLF4j. It seems like the right technology
for the problem.
(*Chris*)
P.S. ICLA on the way
On Wed, May 14, 2014 at 11:16 PM, Lukasz Lenart wrote:
> 2014-05-14 21:51 GMT+02:00 Chris Pratt :
> > Yes, we could use Onyx's interface mechanism, but I think SLF4j's
2014-05-15 3:40 GMT+02:00 Chris Pratt :
> Then you still have to use code like:
>
> if(LOG.isDebugEnabled()) {
> LOG.debug("Action name is [#0]",action.getName());
> }
>
> Any time that the value isn't in an available primitive. With Onyx you
> could just write:
>
> LOG.debug("Action name is {0.
2014-05-14 19:33 GMT+02:00 Chris Pratt :
> If you want a really powerful version of what they did, check out my onyx
> project (https://code.google.com/p/anodyzed/). It's kind of been
> languishing since I haven't found too many people that really care about
> logging efficiency, but I'd be totall
Updated https://cwiki.apache.org/confluence/display/WW/Struts+Next
2014-05-14 21:26 GMT+02:00 Lukasz Lenart :
> 2014-05-14 19:33 GMT+02:00 Chris Pratt :
>> If you want a really powerful version of what they did, check out my onyx
>> project (https://code.google.com/p/anodyzed/). It's kind of been
Then you still have to use code like:
if(LOG.isDebugEnabled()) {
LOG.debug("Action name is [#0]",action.getName());
}
Any time that the value isn't in an available primitive. With Onyx you
could just write:
LOG.debug("Action name is {0.name}",action);
Which is much more readable and just as
Hi,
What do you think about that idea [1]?
Basically instead of doing this:
if (LOG.isDebugEnable()) {
LOG.debug("Action name is [#0]', actionName);
}
it will be possible to do this:
LOG.debug("Action name is [#0]', actionName);
with implementation in eg. JdkLogger like this:
public voi
2014-05-14 21:51 GMT+02:00 Chris Pratt :
> Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
> probably more stable and definitely more supported. So I'd probably
> recommend that we extract the SLF4j support object and use it directly (or
> at least make it the default). If it
Yes, we could use Onyx's interface mechanism, but I think SLF4j's is
probably more stable and definitely more supported. So I'd probably
recommend that we extract the SLF4j support object and use it directly (or
at least make it the default). If it's something that you're interested
in, I'd have
If you want a really powerful version of what they did, check out my onyx
project (https://code.google.com/p/anodyzed/). It's kind of been
languishing since I haven't found too many people that really care about
logging efficiency, but I'd be totally willing to donate the code to
Struts2 (and do s
I went through how SLF4J is implemented and they did exactly what I
want to do :-)
I need some regex Ninja to remove if statement around LOG's calls
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2014-05-12 13:17 GMT+02:00 Dave Newton :
> I think the issue is only when the params
I think the issue is only when the params are more than just strings, e.g.,
"long"-running methods.
I'd like to ditch the XW facade, though; I think whenever possible we
should strip out XW/S2 functionality when it exists in libraries we already
use (like those older XW string utils).
d.
On Sun
I prefer to switch slf4j instead of an own xwork logging facade.
Regards
Johannes
#
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
2014-05-10 9:43 GMT+02:00 Lukasz Lenart :
> Hi,
>
> What do you think about that idea [1]?
>
> B
42 matches
Mail list logo
