[jira] [Created] (LOG4J2-580) Log4j 2 on Weblogic server

Vinay Srivastav Kasarla created LOG4J2-580: -- Summary: Log4j 2 on Weblogic server Key: LOG4J2-580 URL: https://issues.apache.org/jira/browse/LOG4J2-580 Project: Log4j 2 Issue Type: Bu

[jira] [Closed] (LOG4J2-580) Log4j 2 on Weblogic server

[ https://issues.apache.org/jira/browse/LOG4J2-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed LOG4J2-580. --- Resolution: Invalid > Log4j 2 on Weblogic server > -- > > Key

[jira] [Commented] (LOG4J2-580) Log4j 2 on Weblogic server

[ https://issues.apache.org/jira/browse/LOG4J2-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946333#comment-13946333 ] Gary Gregory commented on LOG4J2-580: - Jira is not a support forum, please post your q

Re: Would like to change a bit of the SimpleLogger API. Feedback requested.

Yeah, sorry, I thought you were discussing the other streaming api.  Gary Original message From: Matt Sicker Date:03/24/2014 23:46 (GMT-05:00) To: Log4J Developers List Subject: Re: Would like to change a bit of the SimpleLogger API. Feedback requested. Wait which stre

org.apache.log4j.net.XMLSocketReceiver from v1

Hi All: Our server uses v1's org.apache.log4j.net.XMLSocketReceiver. I do not see a v2 equivalent. Thoughts? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition

Re: Why org.apache.logging.log4j.Level.valueOf(Class, String)?

I'm not convinced we need it, but it was put there to make Level as close to a real enum as possible. Every enum provides that static method (by way of extending Enum). N On Mar 25, 2014, at 7:28 AM, Gary Gregory wrote: > Why do we have this API in org.apache.logging.log4j.Level: > > publ

Why org.apache.logging.log4j.Level.valueOf(Class, String)?

Why do we have this API in org.apache.logging.log4j.Level: public static > T valueOf(Class enumType, String name) { return Enum.valueOf(enumType, name); } ? -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

AbstractConfigurationTest is a confusing name. It is not abstract and it is not subclassed. Better name? Gary On Sun, Mar 23, 2014 at 9:19 PM, Matt Sicker wrote: > Interesting. There's already an AbstractConfigurationTest that's an > abstract ConfigurationTest, but there's also a BaseConfigura

Re: org.apache.log4j.net.XMLSocketReceiver from v1

We need to add receivers to log4j2 :) Dcott On Mar 25, 2014 5:19 AM, "Gary Gregory" wrote: > Hi All: > > Our server uses v1's org.apache.log4j.net.XMLSocketReceiver. > > I do not see a v2 equivalent. > > Thoughts? > > Gary > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Pers

Re: Why org.apache.logging.log4j.Level.valueOf(Class, String)?

Well, some Javadocs would help. Gary On Tue, Mar 25, 2014 at 8:31 AM, Nick Williams < nicho...@nicholaswilliams.net> wrote: > I'm not convinced we need it, but it was put there to make Level as close > to a real enum as possible. Every enum provides that static method (by way > of extending Enu

[jira] [Updated] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-579: Summary: Rework Level comparison APIs (was: Rename Level.lessOrEqual() to isLessOrEqual()) > Rewo

[jira] [Reopened] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened LOG4J2-579: - Reopening for further discussion. > Rework Level comparison APIs > > >

[jira] [Updated] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-579: Description: Rename Level.lessOrEqual() to isLessOrEqual(). Propose new API names. was:Rename L

[jira] [Updated] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated LOG4J2-579: Attachment: log4j2-579.diff > Rework Level comparison APIs > > >

[jira] [Commented] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946631#comment-13946631 ] Gary Gregory commented on LOG4J2-579: - Please see {{log4j2-579.diff}} for a proposed n

[jira] [Commented] (LOG4J2-346) Cyclic dependency in OSGi-context. Apache Log4j SLF4J Binding <-> slf4j-api

[ https://issues.apache.org/jira/browse/LOG4J2-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946588#comment-13946588 ] Stefan Klaus commented on LOG4J2-346: - Is the Patch already committed to the trunk. I

Re: Level.isGreaterOrEqual: svn commit: r1581082 - /logging/log4j/log4j2/trunk/log4j-api/src/main/java/org/apache/logging/log4j/Level.java

Please see {{log4j2-579.diff}} for a proposed new API set ( https://issues.apache.org/jira/secure/attachment/12636707/log4j2-579.diff). I removed the int APIs since it feels like it is leaking encapsulation: the user should not care that ints are used internally. Thank you Gary On Mon, Mar 24,

Re: Level.isGreaterOrEqual: svn commit: r1581082 - /logging/log4j/log4j2/trunk/log4j-api/src/main/java/org/apache/logging/log4j/Level.java

This looks fine to me. There is some leakage that needs to happen. The intLevel() method returns the int value and that is used by Logger in core to make the level evaluation as fast as possible. Ralph On Mar 25, 2014, at 7:51 AM, Gary Gregory wrote: > Please see {{log4j2-579.diff}} for a p

Re: org.apache.log4j.net.XMLSocketReceiver from v1

We have JMS receivers and a SocketServer. I would expect that the XMLSocketReceiver is expecting log events in XML format? If so, it would seem that extending SocketServer to do that wouldn’t be very hard. Ralph On Mar 25, 2014, at 6:51 AM, Scott Deboy wrote: > We need to add receivers to

Re: Level.isGreaterOrEqual: svn commit: r1581082 - /logging/log4j/log4j2/trunk/log4j-api/src/main/java/org/apache/logging/log4j/Level.java

On Tue, Mar 25, 2014 at 11:26 AM, Ralph Goers wrote: > This looks fine to me. There is some leakage that needs to happen. The > intLevel() method returns the int value and that is used by Logger in core > to make the level evaluation as fast as possible. > Thank you for the review. Committed to

Re: Level.isGreaterOrEqual: svn commit: r1581082 - /logging/log4j/log4j2/trunk/log4j-api/src/main/java/org/apache/logging/log4j/Level.java

No, i don’t think so. On Mar 25, 2014, at 8:32 AM, Gary Gregory wrote: > On Tue, Mar 25, 2014 at 11:26 AM, Ralph Goers > wrote: > This looks fine to me. There is some leakage that needs to happen. The > intLevel() method returns the int value and that is used by Logger in core to > mak

Re: Level.isGreaterOrEqual: svn commit: r1581082 - /logging/log4j/log4j2/trunk/log4j-api/src/main/java/org/apache/logging/log4j/Level.java

On Tue, Mar 25, 2014 at 1:20 PM, Ralph Goers wrote: > No, i don’t think so. > OK, I've marked the issue as resolved then. Gary > > > > On Mar 25, 2014, at 8:32 AM, Gary Gregory wrote: > > On Tue, Mar 25, 2014 at 11:26 AM, Ralph Goers > wrote: > >> This looks fine to me. There is some leaka

[jira] [Resolved] (LOG4J2-579) Rework Level comparison APIs

[ https://issues.apache.org/jira/browse/LOG4J2-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved LOG4J2-579. - Resolution: Fixed > Rework Level comparison APIs > > >

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

Well, the old AbstractConfigurationTest was deleted. I merged that with the XMLConfigurationTest (and the JSON and YAML ones that extended the old AbstractConfigurationTest) into a new test that uses the parameterized runner instead (they all tested the same thing, just different config file format

Re: org.apache.log4j.net.XMLSocketReceiver from v1

I've been reading up on Camel lately. Maybe we could adopt some conventions from there? On 25 March 2014 10:29, Ralph Goers wrote: > We have JMS receivers and a SocketServer. I would expect that the > XMLSocketReceiver is expecting log events in XML format? If so, it would > seem that extendi

Re: log4j2 rc1 bug

Now that you mention it, I usually see the socket server tests fail on my computer, but the tests themselves still pass for some reason. It's actually rather confusing sometimes whether or not the tests succeed based on the output (except for when an informative message is part of the stack trace l

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

On Tue, Mar 25, 2014 at 9:36 PM, Matt Sicker wrote: > Well, the old AbstractConfigurationTest was deleted. I merged that with > the XMLConfigurationTest (and the JSON and YAML ones that extended the old > AbstractConfigurationTest) into a new test that uses the parameterized > runner instead (the

Re: org.apache.log4j.net.XMLSocketReceiver from v1

On Tue, Mar 25, 2014 at 9:38 PM, Matt Sicker wrote: > I've been reading up on Camel lately. Maybe we could adopt some > conventions from there? > Please explain. Gary > > > On 25 March 2014 10:29, Ralph Goers wrote: > >> We have JMS receivers and a SocketServer. I would expect that the >> X

Re: org.apache.log4j.net.XMLSocketReceiver from v1

Using routes, consumers, producers, processors, endpoints, etc. All enterprise integration pattern sort of things. Somewhat similar to how Flume works, really. On 25 March 2014 21:14, Gary Gregory wrote: > On Tue, Mar 25, 2014 at 9:38 PM, Matt Sicker wrote: > >> I've been reading up on Camel l

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

Not prefixed with Abstract at least. There's no need for an abstract test class in this scenario as it is more efficiently dealt with using a @Parameters method. See: https://github.com/apache/logging-log4j2/blob/trunk/log4j-core/src/test/java/org/apache/logging/log4j/core/config/AbstractConfigura

Re: org.apache.log4j.net.XMLSocketReceiver from v1

OK, I think Camel is higher level than our low-level net bits. Gary On Tue, Mar 25, 2014 at 10:20 PM, Matt Sicker wrote: > Using routes, consumers, producers, processors, endpoints, etc. All > enterprise integration pattern sort of things. Somewhat similar to how > Flume works, really. > > > O

Re: svn commit: r1580614 - /logging/log4j/log4j2/trunk/log4j-core/src/main/java/org/apache/logging/log4j/core/config/BaseConfiguration.java

On Tue, Mar 25, 2014 at 10:24 PM, Matt Sicker wrote: > Not prefixed with Abstract at least. There's no need for an abstract test > class in this scenario as it is more efficiently dealt with using a > @Parameters method. See: > > > https://github.com/apache/logging-log4j2/blob/trunk/log4j-core/sr

[jira] [Updated] (LOG4J2-547) Update LoggerStream API

[ https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Brouwer updated LOG4J2-547: - Attachment: log4j2-547-remove-streams.patch Perhaps we can agree to at least remove the streaming

Re: org.apache.log4j.net.XMLSocketReceiver from v1

I don't mean using it. I mean borrowing the patterns it uses architecturally. Though I might be thinking a bit too high level here to be really useful. So basically, we've got Appenders, Filters, Layouts (and patterns), StrLookups, and ContextSelectors. Using Camel/EIP vocab, that gives us message

[jira] [Assigned] (LOG4J2-497) Create Log4j config JUnit rule.

[ https://issues.apache.org/jira/browse/LOG4J2-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reassigned LOG4J2-497: -- Assignee: Matt Sicker > Create Log4j config JUnit rule. > --- > >

[jira] [Resolved] (LOG4J2-497) Create Log4j config JUnit rule.

[ https://issues.apache.org/jira/browse/LOG4J2-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker resolved LOG4J2-497. Resolution: Implemented Fix Version/s: 2.0-rc2 Just added as {{InitialLoggerContext}}. It co

[jira] [Closed] (LOG4J2-497) Create Log4j config JUnit rule.

[ https://issues.apache.org/jira/browse/LOG4J2-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-497. -- > Create Log4j config JUnit rule. > --- > > Key: LOG4J2-497 >

[jira] [Assigned] (LOG4J2-498) Update unit tests to use Log4jConfig rule.

[ https://issues.apache.org/jira/browse/LOG4J2-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker reassigned LOG4J2-498: -- Assignee: Matt Sicker > Update unit tests to use Log4jConfig rule. > --

[jira] [Commented] (LOG4J2-498) Update unit tests to use Log4jConfig rule.

[ https://issues.apache.org/jira/browse/LOG4J2-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947551#comment-13947551 ] Matt Sicker commented on LOG4J2-498: I've updated one unit test so far as well as adde

Re: org.apache.log4j.net.XMLSocketReceiver from v1

On Tue, Mar 25, 2014 at 10:41 PM, Matt Sicker wrote: > I don't mean using it. I mean borrowing the patterns it uses > architecturally. Though I might be thinking a bit too high level here to be > really useful. > > So basically, we've got Appenders, Filters, Layouts (and patterns), > StrLookups,