On Wednesday, January 29, 2014, Nick Williams nicho...@nicholaswilliams.net
wrote:
On Jan 28, 2014, at 5:43 PM, Remko Popma wrote:
I would really like everyone's feedback on this. I have two questions:
1. Does this fulfill everyone's requirements?
Another way of asking this is: would you
Annotation processing is beyond over-engineered, yet it still lacks some of
the neat features from runtime annotation processing. I've been meaning
to look more into it as it might be useful for injecting Loggers using
annotations.
On 29 January 2014 07:46, Remko Popma remko.po...@gmail.com
I would like to propose not doing anything on this subject until there is a
request from the community. It's probably way too easy to over-engineer and
devise solutions to problems that a small percentage (or zero?) of the
users will need. I am all for ingenuity and passion, but after GA occurs
I agree.
Nick
On Jan 29, 2014, at 5:09 PM, Paul Benedict wrote:
I would like to propose not doing anything on this subject until there is a
request from the community. It's probably way too easy to over-engineer and
devise solutions to problems that a small percentage (or zero?) of the
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user
I would really like everyone's feedback on this. I have two questions:
1. Does this fulfill everyone's requirements?
Another way of asking this is: would you use this in your own projects? (If
not, why not?)
2. What do you think of this approach?
Obviously code generation has drawbacks. For one
I plan on catching up on all this tomorrow night.
Gary
On Tue, Jan 28, 2014 at 6:43 PM, Remko Popma remko.po...@gmail.com wrote:
I would really like everyone's feedback on this. I have two questions:
1. Does this fulfill everyone's requirements?
Another way of asking this is: would you use
On Jan 28, 2014, at 5:43 PM, Remko Popma wrote:
I would really like everyone's feedback on this. I have two questions:
1. Does this fulfill everyone's requirements?
Another way of asking this is: would you use this in your own projects? (If
not, why not?)
Personally, no. I don't like the
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user passes it the fully qualified name of the
interface, and a list of NAME=INTLEVEL custom log levels.
The generated source code
specific applications.
For medical devices for example I could only have critical, warning,
advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about
-dev@logging.apache.org
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger interface.
To invoke the tool the user passes it the fully qualified name
for domain specific applications.
For medical devices for example I could only have critical, warning,
advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
, warning,
advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates
message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool
applications. For
medical devices for example I could only have critical, warning, advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about
(GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user passes it the fully
On Jan 27, 2014, at 11:15 AM, Nick Williams nicho...@nicholaswilliams.net
wrote:
However, what I WOULD be okay with is creating a SimpleLogger interface
for things like log(Level, ...), etc. and having Logger extend SimpleLogger
to provide info(), warn(), and so on. This would be backwards
Okay, I see now. I got confused by what Gary said:
That's brilliant! The Logger interface contains methods like log(Level, ...)
and StandardLogger extends Logger to provide info(), warn() and so on.
This let's me create a custom Logger (DEFCON example) AND an extension to
StandardLogger
I would like to see SimpleLogger be where custom interfaces are extended.
Now you can't forget that if we provide a default implementation class,
that will already implement Logger. So it's very easy to cast directly to
Logger if necessary to access your standard methods.
On Mon, Jan 27, 2014 at
09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user passes it the fully
Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very simple at first?
We provide a tool that generates the source code for a custom logger
interface.
To invoke the tool the user passes it the fully qualified name of the
interface
.
For medical devices for example I could only have critical, warning,
advisory.
Original message
From: Remko Popma
Date:01/27/2014 09:15 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Using Custom Levels with a Custom/Wrapper Interface
How about starting with something very
Here's a split-off thread for discussing how we can make using custom levels
easier. Some on the team have expressed a desire to make it even easier. Given
hypothetical custom levels DIAG and NOTE, the following would be nice to have:
logger.note(message);
logger.diag(message);
etc.
We're to
If there is a way to support this strictly through configuration that would
be ideal.
I'm trying to find a way to remove my request for additional built in
levels but through configuration instead of adding them ourselves.
Scott
Scott
On Jan 26, 2014 7:38 PM, Nick Williams
It would not be possible to do this strictly through configuration because the
user needs a compiled interface to code against. Where is that compiled
interface to come from?
Nick
On Jan 26, 2014, at 9:40 PM, Scott Deboy wrote:
If there is a way to support this strictly through configuration
The JPA criteria API manages to generate a Foo_ class for the entity class
Foo, and that seems to work out fine.
On 26 January 2014 21:45, Nick Williams nicho...@nicholaswilliams.netwrote:
It would not be possible to do this strictly through configuration because
the user needs a compiled
I am going to have to echo what Nick said. If you can think of a way to make
logger.log(SomeClass.SomeLevel, “hello world”);
work without actually creating SomeClass then please share!
Ralph
On Jan 26, 2014, at 7:45 PM, Nick Williams nicho...@nicholaswilliams.net
wrote:
It would not be
I actually thought that Nick's idea was the answer to that: users create a
custom interface, something like this:
public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
}
They get an instance of this interface by
Scott would like users to add a level definition to the logging configuration
and have everything else happen auto-magically. That would happen at run-time
which is a bit late since the methods need to be available at compile time.
I believe Scott said he would be fine if users had to do
Yes, I would like to declare in the config:
Level: NOTICE, value: 232
And in Java code be able to use logger.notice(some message).
But I think that'd require invokedynamic..which would probably
require..javassist/ASM?
I'd be ok with anything that's really close to that :)
Scott
On 1/26/14,
Sure, but what's wrong with the idea?
The user provide their own interface, so that interface exists at compile
time.
The interface uses annotations, so it does not need to explicitly refer to
a custom Level instance. Only the /implementation/ needs to know about the
custom Level instances, and
In addition to the above, we could provide a tool to generate a MyLogger
interface with 14 method signatures for each custom Level name. This would
be an offline tool that users would use only once.
But this tool is optional...
On Monday, January 27, 2014, Remko Popma remko.po...@gmail.com wrote:
Nick, I thought that you meant that users would provide their own
interface, like this:
public interface MyLogger extends Logger {
@LoggingLevel(name=DIAG)
void diag(String message);
// optional other methods
}
That way, this interface exists at compile time.
On Monday, January 27,
Could we leverage Rhino? :)
Scott
On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
Scott, invokedynamic and javassist...those are all /runtime/ things. The
user needs Logger#notice to be available at compile time. Those are not
compatible.
Nick
Sent from my iPhone, so
Of course, they'd have to use rhino, or something else...which doesn't
help. Where's duck typing when you need it :)
On 1/26/14, Scott Deboy scott.de...@gmail.com wrote:
Could we leverage Rhino? :)
Scott
On 1/26/14, Nicholas Williams nicho...@nicholaswilliams.net wrote:
Scott,
Yes, I was saying that. But, unless I'm misunderstanding, Scott doesn't want
the user to even have to write the interface. He wants them to just configure
it and the interface become available magically. I was pointing out that
there's a disconnect between when the configuration is used
If we go the run-once tool route, then you might as well use annotation
processing. I think it would support everything necessary to generate the
appropriate custom logger class.
On 26 January 2014 23:00, Scott Deboy scott.de...@gmail.com wrote:
Of course, they'd have to use rhino, or
38 matches
Mail list logo
