+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
They can already do the same thing with loggers right?
Scott
On Jan 25, 2014 10:19 PM, "Ralph Goers" wrote:
> A malicious app could do
>
> for (int i=0; i < 10; ++i) {
> new Level(“Level” + i, 1000 + i){};
> }
>
> Sure idiots can do lots of bad things but I don’t think Levels should be
> q
It was a lot harder when each custom extension was an enum implementing an
interface. There was no way to do a new on it.
Ralph
> On Jan 25, 2014, at 10:33 PM, Remko Popma wrote:
>
> Hm...
> Doesn't it become nearly impossible to protect against malicious intent, the
> moment we make it exten
Hm...
Doesn't it become nearly impossible to protect against malicious intent, the
moment we make it extensible?
On Sunday, January 26, 2014, Ralph Goers wrote:
> A malicious app could do
>
> for (int i=0; i < 10; ++i) {
> new Level(“Level” + i, 1000 + i){};
> }
>
> Sure idiots can do lots
A malicious app could do
for (int i=0; i < 10; ++i) {
new Level(“Level” + i, 1000 + i){};
}
Sure idiots can do lots of bad things but I don’t think Levels should be quite
that flexible.
Ralph
On Jan 25, 2014, at 9:39 PM, Remko Popma wrote:
> I don't think client code can do new Level(
I wanted to have my cake and eat it too. I want the standard levels to be part
of an enumeration so I can use switch. The way the code was written I couldn’t
do that. I’ve figured out another way. I have a StdLevel enum embedded in the
Level class.
Ralph
On Jan 25, 2014, at 9:39 PM, Remko
Apologies for thinking out loud and not being clear. Code generation can
probably be made to work with either "real" enums or the extensible enums
approach. The mechanism may differ but either should be possible. So from
that point of view, no preference either way. Again apologies for the
confusio
*static Map in the extensible enum class
On Sun, Jan 26, 2014 at 2:56 PM, Remko Popma wrote:
> After thinking about it some more, the code generation could just access
> the static Map in the extensible enums class and find out what instances
> are registered. That would work but assumes that t
After thinking about it some more, the code generation could just access
the static Map in the extensible enums class and find out what instances
are registered. That would work but assumes that the configuration (or at
least the initialization of the static Map in Levels) is complete before
code g
Did you mean that a custom Level implementation cannot extend StdLevel?
So a custom Level implementation would need to include the levels defined
in StdLevel (DEBUG, INFO, ...) in addition to the custom levels.
I think I see now.
How much of a problem is this though? Or, do we need to start thinki
I don't think client code can do new Level(){} as the constructor requires
String and int arguments.
By the way, I am unclear on what went wrong with the enum approach you
originally took.
You said:
StdLevel isn’t a Level because it can’t extend it if it is an enum, so
I can’t initialize the l
Out of curiosity, what exactly is the benefit of declaring the class abstract
when it has a protected constructor? It seems like all you are accomplishing
is making the instantiation syntax uglier. It also bothers me that open code
can just do a new Level(){} - which will do nothing but cause p
Yeah, I missed the {} as I modified the class before I tried to compile it.
You can’t just use an AtomicInteger because you might be adding a duplicate to
the map, in which case you have incorrectly incremented the ordinal. I used
simple synchronization.
Unfortunately, because the extended lev
Ralph,
I copied Nick's code _as is_ and had no compile errors.
The class is abstract, but instances are defined in the static block as:
OFF = new Level("OFF", 0) {}; // note the {}: this creates an anonymous
concrete subclass
I agree that read access needs to be synchronized as well, not just writ
Ralph, if you're getting compile errors with that code, A) there's a
copy-paste/transposition error, or B) there's something wrong with your
(non-standard?) compiler. Given:
abstract class A { ... }
This is perfectly legal in Java 5+:
A a = new A() { };
That's an anonymous inner class extendi
That was what I was originally thinking. I suspect that what the result of what
we are thinking would be to just be able to dynamically generate the wrapper
based on the custom Level(s).
Ralph
On Jan 25, 2014, at 8:43 PM, Gary Gregory wrote:
> My idea was _not_ to add byte codes to the Logger
As I am working on this I just want to point out a number of issues with the
code below:
1. The class is abstract. The static block is doing a bunch of new Level()
invocations which obviously generate compile errors on an abstract class. I
had to make it be a non-abstract class.
2. As I pointe
My idea was _not_ to add byte codes to the Logger interface, it was to add code
to a user's class that wraps a logger.
G
Original message
From: Remko Popma
Date:01/25/2014 21:51 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Enums and Custom Levels
I've started to
Yeah, I took another 5 minutes and thought about it. A proxy isn’t the full
answer as somehow we need to create the method signatures for compile time.
I’ve done that before from database data to generate an interface but this is a
little different.
Ralph
On Jan 25, 2014, at 7:07 PM, Remko Po
I mean, not sure whether to use Proxy or generate code or something else,
but hopefully get really close to the ease-of-use of the current Logger
interface...
On Sun, Jan 26, 2014 at 12:06 PM, Remko Popma wrote:
> I'm not sure how close we can get to what we have now, but yes, that was
> what I
I'm not sure how close we can get to what we have now, but yes, that was
what I had in mind...
On Sun, Jan 26, 2014 at 12:00 PM, Ralph Goers wrote:
> Wow - I had never thought about using a Java Proxy to implement all those
> methods before. That would be a piece of cake.
>
> Ralph
>
> On Jan 2
[
https://issues.apache.org/jira/browse/LOG4J2-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882158#comment-13882158
]
Remko Popma commented on LOG4J2-513:
That would be great! Just speaking for myself, I
Wow - I had never thought about using a Java Proxy to implement all those
methods before. That would be a piece of cake.
Ralph
On Jan 25, 2014, at 6:51 PM, Remko Popma wrote:
> I've started to think about how to implement Gary's idea to use these custom
> levels to generate code that would a
Great! That plus support for defining custom levels from the config (with
no custom class required) would mean we would have found a solution that I
believe resolves everyone's issues.
Scott
On Jan 25, 2014 6:52 PM, "Remko Popma" wrote:
> I've started to think about how to implement Gary's idea
I've started to think about how to implement Gary's idea to use these
custom levels to generate code that would add methods to the Logger
interface, but I think I'll wait a little to see what form the custom
levels take.
On Sun, Jan 26, 2014 at 11:45 AM, Remko Popma wrote:
> These are the switc
These are the switches I found:
* log4j-1.2-api: org.apache.log4j.Category - just FYI, it looks like this
switch is missing the FATAL level... is this a bug?
* log4j-api: org.apache.logging.log4j.status.StatusLogger
* log4j-core: org.apache.logging.log4j.core.net.Severity
* log4j-core: org.apache.l
I am not sure what you mean by this. I have already succeeded in adding custom
level names to the configuration and making them be valid. I am just trying to
clean it up a bit based on what Nick is suggesting.
Ralph
On Jan 25, 2014, at 6:30 PM, Scott Deboy wrote:
> There's no way to add sup
Actually, we can use switch in all the places it is currently being used. They
are all places where we are converting between our levels to a Level or
Severity from some other framework. I handled that by first mapping custom
levels to the closest standard level and then using the switch state
There's no way to add support for users to define level entries (name and
value pairs as a new element in the config) and have us do the work to make
those valid? That would get get rid of my request for additional levels,
right?
On Jan 25, 2014 6:15 PM, "Ralph Goers" wrote:
> The class is needed
You can't "switch" anymore because custom levels means you're dealing with
an unknown quantity of levels. You'll have to look them up in a
registry/map. That's the trade off of an extensible system.
On Jan 25, 2014 8:13 PM, "Ralph Goers" wrote:
> Rats. StdLevel isn’t a Level because it can’t ext
The class is needed because it is a name and a value (two items) that has to be
represented as a single parameter to Logger methods. Using raw int or String
is not a good alternative.
Ralph
On Jan 25, 2014, at 4:54 PM, Scott Deboy wrote:
> If levels are just a name and a value why require a
Rats. StdLevel isn’t a Level because it can’t extend it if it is an enum, so I
can’t initialize the levels using that. So no switch statements if we go this
way. I’ll keep looking at it but that makes this solution less appealing to me.
Ralph
On Jan 25, 2014, at 6:05 PM, Ralph Goers wrote:
Sure, I can take a look at doing it that way. But it is going to have many of
the same problems to implement as to what I just finished doing - except that I
won’t need the Levels class or Levels interface. The one downside to this
approach is that there are 4 or 5 places where Level is used in
Nick, I think because your solution is considered "old style" enums. I
don't know anyone making those kind of enums anymore since JDK 1.5 gave us
an official "enum" keyword. Using that and interfaces is preferred, I think.
On Sat, Jan 25, 2014 at 7:32 PM, Nicholas Williams <
nicho...@nicholaswill
Matt Sicker created LOG4J2-513:
--
Summary: Use more OSGi-friendly class loading mechanisms.
Key: LOG4J2-513
URL: https://issues.apache.org/jira/browse/LOG4J2-513
Project: Log4j 2
Issue Type: Sub-
I actually do object I think. It sounds like a significantly more convoluted
approach than the extensible enum. With the extensible enum, new levels are
immediately discovered, serialization works automatically, and extenders don't
have to do any extra work in the constructor. Why are we making
[
https://issues.apache.org/jira/browse/LOG4J2-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882132#comment-13882132
]
Matt Sicker commented on LOG4J2-373:
Shouldn't you be loading core as a bundle too?
>
In any event, I'd like to thank the entire Log4J Developer community here
for hearing out my interface idea without biting my head off -- after all,
it's a "big" change near a GA release :-) It was also nice knowing there
exists a place where a serious technical debate can remain cordial. Kudos.
An
[
https://issues.apache.org/jira/browse/LOG4J2-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-346:
---
Attachment: 0001-Add-SLF4J-related-bundles.patch
Here's a better patch. I've added two submodules to
If levels are just a name and a value why require a class at all? What
about just having it defined in the configuration.
On Jan 25, 2014 4:37 PM, "Ralph Goers" wrote:
> Because we don't know the class name that the Level belongs to. It is
> referenced in the configuration just as "DIAG", not
>
Because we don’t know the class name that the Level belongs to. It is
referenced in the configuration just as “DIAG”, not
“org.apache.logging.test.ExtendedLevel.DIAG”.
In any case I fixed it. I just annotated the new Level as a Plugin and then
look up all the Level plugins in BaseConfiguratio
Would it be an option to require that the custom level class package is
mentioned in the Configuration packages="..." attribute?
On Sun, Jan 26, 2014 at 9:26 AM, Paul Benedict wrote:
> If you made it a requirement for the constructor to register, why not just
> instantiate each level as you enc
If you made it a requirement for the constructor to register, why not just
instantiate each level as you encounter it in the config?
On Sat, Jan 25, 2014 at 6:06 PM, Ralph Goers wrote:
> Hmm. It seems I am going to have to do something to force the registration
> as the custom level class hasn’t
Hmm. It seems I am going to have to do something to force the registration as
the custom level class hasn’t been constructed before the levels are referenced
in the configuration.
Ralph
On Jan 25, 2014, at 3:43 PM, Ralph Goers wrote:
> In the constructor each of them calls Levels.addLevel(t
In the constructor each of them calls Levels.addLevel(this).
Ralph
On Jan 25, 2014, at 2:21 PM, Remko Popma wrote:
> Interesting! So, users would add custom levels by creating a new enum that
> implements the Level interface? How does the new enum get registered? In
> config or in code?
>
>
Interesting! So, users would add custom levels by creating a new enum that
implements the Level interface? How does the new enum get registered? In
config or in code?
Just trying to understand how it works...
(With Nick's class I understood how that would work: users would extend the
Level class
That sounds like a pretty good idea.
Matt Sicker
> On Jan 25, 2014, at 15:18, Ralph Goers wrote:
>
> Here is what I am implementing:
>
> 1. Level is now an Interface. This allows the vast amount of code to
> continue to work.
> 2. The current Level enum has been renamed to StdLevel. It impl
Here is what I am implementing:
1. Level is now an Interface. This allows the vast amount of code to continue
to work.
2. The current Level enum has been renamed to StdLevel. It implements the Level
interface.
3. A new class named Levels is in the spi package of the API. It contains a
Concurr
No, of course, everyone seems to agree that custom levels should be permitted.
But I never heard agreement on whether we were going the extensible enum route
or the Level-as-interface route. The camp still seemed to disagree on that.
Nick
Sent from my iPhone, so please forgive brief replies and
Hi folks,
I would like to remind you ApacheCon is happening in April 2014.
If you would like to submit your talk, now is the chance.
I think it would be great to have somebody presenting our Logging frameworks.
I will not be there unfortunately.
Regards,
Christian
---
http://www.grobmeier.de
Th
I have not heard anyone disagree with allowing custom Levels. The disagreement
I am hearing is over adding new pre-defined levels.
Ralph
On Jan 25, 2014, at 7:29 AM, Nick Williams
wrote:
> I may have missed something. Did we decide on an approach? Last I heard, the
> camp was still split: S
I may have missed something. Did we decide on an approach? Last I heard, the
camp was still split: Some wanted to go with my extensible enum, others wanted
to change Level to an interface and make a Levels enum.
So I'm a bit confused. Which implementation are you working on?
Nick
On Jan 25, 20
I am working on the implementation of custom levels now. I should have it done
today.
Ralph
On Jan 24, 2014, at 7:07 PM, Remko Popma wrote:
> What is the best way to make progress on the custom levels implementation?
>
> Do we re-open LOG4J-41 or start a fresh Jira ticket? For implementation
Chandra Sekhar Kakarla created LOG4J2-512:
-
Summary: Log4j2 need to support Asynchronous Servlets/ Servlet 3.0
while automatically starting, and configurable to initialize and
de-initialize loggers from the code
Key: LO
On Sat, Jan 25, 2014 at 5:10 AM, Christian Grobmeier wrote:
> Thanks a lot Gary for the great response. Now I understand you better.
Thank you Christian. I created the branch
https://svn.apache.org/repos/asf/logging/log4j/log4j2/branches/new-levelsfor
those who want to a have easy look.
Gary
[
https://issues.apache.org/jira/browse/LOG4J2-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881854#comment-13881854
]
Gary Gregory commented on LOG4J2-316:
-
Imo if there is any text it should only be "Log
[
https://issues.apache.org/jira/browse/LOG4J2-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881743#comment-13881743
]
Alireza Fattahi edited comment on LOG4J2-316 at 1/25/14 10:11 AM:
--
Thanks a lot Gary for the great response. Now I understand you better.
On 25 Jan 2014, at 2:00, Ralph Goers wrote:
I have the same problem with your use of NOTICE as I did with CONFIG.
If I want to see startup and shutdown log events I MUST also get
warning messages, which isn’t necessarily wh
58 matches
Mail list logo
