date:20130117

[jira] [Resolved] (LOG4J2-150) Applet: AccessControlException from System.getProperty(...), Integer.getInteger, and Boolean.getBoolean

2013-01-17 Thread Ralph Goers (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-150.


   Resolution: Fixed
Fix Version/s: 2.0-beta4
 Assignee: Ralph Goers

Fixed as of revision 1434589. Please verify and close.

> Applet: AccessControlException from System.getProperty(...), 
> Integer.getInteger, and Boolean.getBoolean
> ---
>
> Key: LOG4J2-150
> URL: https://issues.apache.org/jira/browse/LOG4J2-150
> Project: Log4j 2
>  Issue Type: Bug
>  Components: API, Core
>Affects Versions: 2.0-beta4
> Environment: Firefox 18
>Reporter: Scott Severtson
>Assignee: Ralph Goers
> Fix For: 2.0-beta4
>
> Attachments: system-properties-access-control-exception-handling.patch
>
>
> When deploying Log4J2 in an applet, several API and Core classes make direct, 
> unchecked attempts to pull in system properties via System.getProperty(...), 
> Integer.getInteger, and Boolean.getBoolean. A sandboxed applet unfortunately 
> may not access arbitrary system properties. PropertiesUtil seems to handle 
> for this issue, but not all Core uses this utility, nor do a few classes in 
> the API.
> The resulting exception looks like:
> Caused by: java.security.AccessControlException: access denied 
> (java.util.PropertyPermission log4j2.status.entries read)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
> at java.lang.System.getProperty(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at java.lang.Integer.getInteger(Unknown Source)
> at org.apache.logging.log4j.status.StatusLogger.(StatusLogger.java:48)
> ... 27 more
> I've created a patch (to follow) which resolves these issues. Unfortunately, 
> some code in my patch is duplicated or very similar between the API and Core 
> -- PropertiesUtil lives in Core, and I wasn't comfortable re-locating it to 
> the API without discussion/review. Instead, I introduced a minimal version of 
> the code to the API module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Commented] (LOG4J2-146) Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext

2013-01-17 Thread Ralph Goers (JIRA)


[ 
https://issues.apache.org/jira/browse/LOG4J2-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555992#comment-13555992
 ] 

Ralph Goers commented on LOG4J2-146:


I'm not sure if this can be fixed but I will investigate it.  The Log4j 1.2 
bridge has methods on the Category such as getting the parent logger that are 
currently implemented but would have to be noops if they go to the Log4j 2 API 
only.

> Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext
> 
>
> Key: LOG4J2-146
> URL: https://issues.apache.org/jira/browse/LOG4J2-146
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta4
>Reporter: Scott Severtson
>Priority: Minor
>
> Attempting to use the Log4J 1.2 emulation API without log4j2-core results in 
> the following error and ClassCastException on startup:
> ERROR StatusLogger Unable to locate a logging implementation, using 
> SimpleLogger
> ...
>   ... 36 more
> Caused by: java.lang.ClassCastException: 
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
> org.apache.logging.log4j.core.LoggerContext
>   at org.apache.log4j.Logger.getLogger(Logger.java:43)
> ... 39 more
> The ERROR is understood, but the exception is not. Apparently, the Log4J 1.2 
> emulation is dependent on core, instead of just the SPI? I would not have 
> expected this dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Comment Edited] (LOG4J2-146) Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext

2013-01-17 Thread Ralph Goers (JIRA)


[ 
https://issues.apache.org/jira/browse/LOG4J2-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13555992#comment-13555992
 ] 

Ralph Goers edited comment on LOG4J2-146 at 1/17/13 8:55 AM:
-

I'm not sure if this can be fixed but I will investigate it.  The Log4j 1.2 
bridge has methods on the Category such as getting the parent logger that are 
currently implemented but would have to be noops if they go to the Log4j 2 API 
only. FWIW if you build the site you would now see that the Log4j 1.2 bridge 
says it needs both the API and implementation.

  was (Author: ralph.go...@dslextreme.com):
I'm not sure if this can be fixed but I will investigate it.  The Log4j 1.2 
bridge has methods on the Category such as getting the parent logger that are 
currently implemented but would have to be noops if they go to the Log4j 2 API 
only.
  
> Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext
> 
>
> Key: LOG4J2-146
> URL: https://issues.apache.org/jira/browse/LOG4J2-146
> Project: Log4j 2
>  Issue Type: Bug
>  Components: log4j 1.2 emulation
>Affects Versions: 2.0-beta4
>Reporter: Scott Severtson
>Priority: Minor
>
> Attempting to use the Log4J 1.2 emulation API without log4j2-core results in 
> the following error and ClassCastException on startup:
> ERROR StatusLogger Unable to locate a logging implementation, using 
> SimpleLogger
> ...
>   ... 36 more
> Caused by: java.lang.ClassCastException: 
> org.apache.logging.log4j.simple.SimpleLoggerContext cannot be cast to 
> org.apache.logging.log4j.core.LoggerContext
>   at org.apache.log4j.Logger.getLogger(Logger.java:43)
> ... 39 more
> The ERROR is understood, but the exception is not. Apparently, the Log4J 1.2 
> emulation is dependent on core, instead of just the SPI? I would not have 
> expected this dependency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Log4J2 and Tomcat: multiple external config files

2013-01-17 Thread Scott Severtson


Ralph,

So, based on your response, here's what we've come up with:
* Log4J2 .jars deployed to Tomcat's CATALINA_BASE/lib directory
* -Dlog4j.configurationFile=/path/to/tomcat-specific/log4j2.xml
* Log4J2 .jars *also* deployed in web applications
* web.xml context-param: 
log4jConfiguration=${log4j.application.configurationFile}

* web.xml listener Log4jContextListener
* 
-Dlog4j.application.configurationFile=/path/to/application-specific/log4j2.xml


This works, for the most part. The application-specific log events are 
sent to the appropriate application-specific appenders, and Tomcat log 
events are sent to the Tomcat-specific appenders.


However, we have one problem: Application-specific log events are *also* 
appended to the Tomcat root logger.


Do I need to add entries to the tomcat-specific configuration to 
*exclude* application specific events? I was under the impression that 
the ClassLoaderContextSelector and using Log4jContextListener would 
prevent events from being sent between the two contexts.


For what it's worth, our applications do not currently specify a 
display-name in web.xml, which according to the docs, would result in 
ServletContext.getServletContextName() returning null. Also, no 
context-param is configured for log4jContextName. However, based on my 
reading of the Log4J2 code, the context name is not actually used by 
Configurator or ConfigurationFactory, so I assumed the null name would 
not matter.


Many thanks for any hints in the right direction,
--Scott

On 01/10/2013 12:27 PM, Ralph Goers wrote:

LOG4J2-18 and LOG4J2-42 have been sitting for quite some time waiting for 
someone like yourself to come along and help come up with good approaches.

I think most of the tools are there but I'm not sure what the best way(s) 
is/are to finish it off.

First, hopefully you are aware that the default ContextSelector is the 
ClassLoaderContextSelector. If you place your Log4j 2 jars in the tomcat class 
loader then Tomcat's logging will use the Logging Context associated with 
Tomcat's class loader. That would need to use log4j2.xml or the system property 
- unless something can be added to Tomcat startup that causes it to use a 
different configuration file via the Configurator.  All the web applications 
will have their own logging contexts that is associated with their class 
loader. If you use the Log4jContextListener in the web project and can 
configure each web apps web.xml then you can cause each web app to have their 
own configuration or you can set them to all use the same one.  I suppose we 
could also modify the context listener to look for a system property to 
automatically cause all the web apps to share a configuration.

With the BasicContextSelector everything uses a single LoggerContext so that 
probably isn't what you want.

With the JNDIContextSelector each web app does a JNDI lookup to locate its 
LoggerContext. Again, you would need to configure each web app with the 
location of the configuration file.

I'm open to suggestions on how to better handle this.

Ralph


On Jan 10, 2013, at 8:56 AM, Scott Severtson wrote:


All,

We'd like to replace Tomcat's built-in logging with Log4J2, and are able to do 
so based on Tomcat's docs for using Log4J 1.x, and deploying the 
log4j-1.2-api-2.0-beta4.jar shim.

However, we're running into an issue with external configuration...

Our webapps are always deployed with external logging configuration files. 
Historically, we've used -Dlog4j.configuration=/path/to/log4j.properties (now 
-Dlog4j.configurationFile=/path/to/log4j2.xml) to point the app to the correct 
file.

Unfortunately, if we pass the app-specific config file to the Tomcat JVM, the 
Tomcat-level Log4J2 instance *also* tries to that config file.

Is there a reasonable way to support externalized configuration files both for 
the Tomcat-level Log4J2 instance, *and* app-specific external configuration 
files as well?

Many thanks,
--Scott

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org




-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Log4J2 and Tomcat: multiple external config files

2013-01-17 Thread Scott Severtson


All,

Hmmm... More experimentation has shown that this configuration does not 
have reliable results. Sometimes on startup, the application-specific 
messages end up in the Tomcat logs, but not in the application-specific 
logs. Other times, the messages are routed correctly.


Any thoughts? Is there some sort of configuration race condition going on?

--Scott

On 01/17/2013 09:33 AM, Scott Severtson wrote:

Ralph,

So, based on your response, here's what we've come up with:
* Log4J2 .jars deployed to Tomcat's CATALINA_BASE/lib directory
* -Dlog4j.configurationFile=/path/to/tomcat-specific/log4j2.xml
* Log4J2 .jars *also* deployed in web applications
* web.xml context-param: 
log4jConfiguration=${log4j.application.configurationFile}

* web.xml listener Log4jContextListener
* 
-Dlog4j.application.configurationFile=/path/to/application-specific/log4j2.xml


This works, for the most part. The application-specific log events are 
sent to the appropriate application-specific appenders, and Tomcat log 
events are sent to the Tomcat-specific appenders.


However, we have one problem: Application-specific log events are 
*also* appended to the Tomcat root logger.


Do I need to add entries to the tomcat-specific configuration to 
*exclude* application specific events? I was under the impression that 
the ClassLoaderContextSelector and using Log4jContextListener would 
prevent events from being sent between the two contexts.


For what it's worth, our applications do not currently specify a 
display-name in web.xml, which according to the docs, would result in 
ServletContext.getServletContextName() returning null. Also, no 
context-param is configured for log4jContextName. However, based on my 
reading of the Log4J2 code, the context name is not actually used by 
Configurator or ConfigurationFactory, so I assumed the null name would 
not matter.


Many thanks for any hints in the right direction,
--Scott

On 01/10/2013 12:27 PM, Ralph Goers wrote:
LOG4J2-18 and LOG4J2-42 have been sitting for quite some time waiting 
for someone like yourself to come along and help come up with good 
approaches.


I think most of the tools are there but I'm not sure what the best 
way(s) is/are to finish it off.


First, hopefully you are aware that the default ContextSelector is 
the ClassLoaderContextSelector. If you place your Log4j 2 jars in the 
tomcat class loader then Tomcat's logging will use the Logging 
Context associated with Tomcat's class loader. That would need to use 
log4j2.xml or the system property - unless something can be added to 
Tomcat startup that causes it to use a different configuration file 
via the Configurator.  All the web applications will have their own 
logging contexts that is associated with their class loader. If you 
use the Log4jContextListener in the web project and can configure 
each web apps web.xml then you can cause each web app to have their 
own configuration or you can set them to all use the same one. I 
suppose we could also modify the context listener to look for a 
system property to automatically cause all the web apps to share a 
configuration.


With the BasicContextSelector everything uses a single LoggerContext 
so that probably isn't what you want.


With the JNDIContextSelector each web app does a JNDI lookup to 
locate its LoggerContext. Again, you would need to configure each web 
app with the location of the configuration file.


I'm open to suggestions on how to better handle this.

Ralph


On Jan 10, 2013, at 8:56 AM, Scott Severtson wrote:


All,

We'd like to replace Tomcat's built-in logging with Log4J2, and are 
able to do so based on Tomcat's docs for using Log4J 1.x, and 
deploying the log4j-1.2-api-2.0-beta4.jar shim.


However, we're running into an issue with external configuration...

Our webapps are always deployed with external logging configuration 
files. Historically, we've used 
-Dlog4j.configuration=/path/to/log4j.properties (now 
-Dlog4j.configurationFile=/path/to/log4j2.xml) to point the app to 
the correct file.


Unfortunately, if we pass the app-specific config file to the Tomcat 
JVM, the Tomcat-level Log4J2 instance *also* tries to that config file.


Is there a reasonable way to support externalized configuration 
files both for the Tomcat-level Log4J2 instance, *and* app-specific 
external configuration files as well?


Many thanks,
--Scott

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org



-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org






-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.

Chainsaw v2 Log viewer

2013-01-17 Thread Stein, Jason

I'm trying to get Chainsaw up and running with our Jboss application.  We're 
currently using a JBoss log4j log which has a conversion pattern that looks 
like this:



As a result of not knowing exactly what logformat to use for this, I was 
getting a message which stated that there were no matching lines, and then it 
would show the log message that wasn't matching.

Then, in order to get Chainsaw to work, I created a separate conversion pattern 
(in a separate appender) which was detailed in your tutorial like this:



And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) - MESSAGE
Like I said, hoping to simply get something in the chainsaw-log...

All I'm getting is messages that say "no further lines to process", rather than 
any real log messages.  As a matter of fact, I don't see ANY real log messages, 
just chainsaw-logs.

What I was hoping I could do was use Chainsaw as a better log viewer - instead 
of using TextPad or Notepad++ .

Any help would be very much appreciated.

Please consider the environment before printing this email.

The information contained in this e-mail and its attachments are confidential to
the intended recipient and may be legally privileged or otherwise protected 
from 
disclosure.  If you have received this message in error,you must not print this 
email or its attachments.  Please notify the sender immediately and delete the 
message and any attachments from your computer. The unauthorized use, 
disclosure,
copying or alteration of this message is forbidden.  Emails are not secure and 
may
contain viruses. Vertex accepts no responsibility for viruses; it is your 
responsibility to scan or otherwise check this email and any attachments.

Re: Chainsaw v2 Log viewer

2013-01-17 Thread Scott Deboy

If you aren't already, I'd suggest trying the latest developer snapshot.

It has built-in support for generating a Chainsaw configuration from a
fileappender/conversionpattern:
 - File, load Chainsaw configuration menu
 - Use fileappender entries from a log4j config file (can be .properties or
.xml)
 - Select the  'open file' button and browse to your log4j configuration
file containing the fileappender entries
 - Optionally select 'always start Chainsaw with this' and probably 'Save
configuration as'

Let me know if that doesn't work.

If you are having problems, you can always use 'MESSAGE' as your logformat,
which will not parse the line at all, just write the entire line to the
'MESSAGE' field.

Scott


On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason
wrote:

>
>
>  I’m trying to get Chainsaw up and running with our Jboss application.
> We’re currently using a JBoss log4j log which has a conversion pattern
> that looks like this:
>
> ** **
>
> 
>
> ** **
>
> As a result of not knowing exactly what logformat to use for this, I was
> getting a message which stated that there were no matching lines, and then
> it would show the log message that wasn’t matching.
>
> ** **
>
> Then, in order to get Chainsaw to work, I created a separate conversion
> pattern (in a separate appender) which was detailed in your tutorial like
> this:
>
> ** **
>
> 
> 
>
> ** **
>
> And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) –
> MESSAGE 
>
> Like I said, hoping to simply get something in the chainsaw-log…
>
> ** **
>
> All I’m getting is messages that say “no further lines to process”, rather
> than any real log messages.  As a matter of fact, I don’t see ANY real
> log messages, just chainsaw-logs.
>
> ** **
>
> What I was hoping I could do was use Chainsaw as a better log viewer –
> instead of using TextPad or Notepad++ .
>
> ** **
>
> Any help would be very much appreciated.
>
> ** **
>
> ** **
>
>
> ** Please consider the environment before printing this email.
> The information contained in this e-mail and its attachments are
> confidential to the intended recipient and may be legally privileged or
> otherwise protected from disclosure. If you have received this message in
> error,you must not print this email or its attachments. Please notify the
> sender immediately and delete the message and any attachments from your
> computer. The unauthorized use, disclosure, copying or alteration of this
> message is forbidden. Emails are not secure and may contain viruses. Vertex
> accepts no responsibility for viruses; it is your responsibility to scan or
> otherwise check this email and any attachments.
>

Re: Chainsaw v2 Log viewer

2013-01-17 Thread Scott Deboy

Latest developer snapshot is available here:
http://people.apache.org/~sdeboy


On Thu, Jan 17, 2013 at 1:55 PM, Scott Deboy  wrote:

> If you aren't already, I'd suggest trying the latest developer snapshot.
>
> It has built-in support for generating a Chainsaw configuration from a
> fileappender/conversionpattern:
>  - File, load Chainsaw configuration menu
>  - Use fileappender entries from a log4j config file (can be .properties
> or .xml)
>  - Select the  'open file' button and browse to your log4j configuration
> file containing the fileappender entries
>  - Optionally select 'always start Chainsaw with this' and probably 'Save
> configuration as'
>
> Let me know if that doesn't work.
>
> If you are having problems, you can always use 'MESSAGE' as your
> logformat, which will not parse the line at all, just write the entire line
> to the 'MESSAGE' field.
>
> Scott
>
>
> On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason  > wrote:
>
>>
>>
>>  I’m trying to get Chainsaw up and running with our Jboss application.
>> We’re currently using a JBoss log4j log which has a conversion pattern
>> that looks like this:
>>
>> ** **
>>
>> 
>>
>> ** **
>>
>> As a result of not knowing exactly what logformat to use for this, I was
>> getting a message which stated that there were no matching lines, and then
>> it would show the log message that wasn’t matching.
>>
>> ** **
>>
>> Then, in order to get Chainsaw to work, I created a separate conversion
>> pattern (in a separate appender) which was detailed in your tutorial
>> like this:
>>
>> ** **
>>
>> 
>>
>> ** **
>>
>> And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) –
>> MESSAGE 
>>
>> Like I said, hoping to simply get something in the chainsaw-log…
>>
>> ** **
>>
>> All I’m getting is messages that say “no further lines to process”,
>> rather than any real log messages.  As a matter of fact, I don’t see ANY
>> real log messages, just chainsaw-logs.
>>
>> ** **
>>
>> What I was hoping I could do was use Chainsaw as a better log viewer –
>> instead of using TextPad or Notepad++ .
>>
>> ** **
>>
>> Any help would be very much appreciated.
>>
>> ** **
>>
>> ** **
>>
>>
>> ** Please consider the environment before printing this email.
>> The information contained in this e-mail and its attachments are
>> confidential to the intended recipient and may be legally privileged or
>> otherwise protected from disclosure. If you have received this message in
>> error,you must not print this email or its attachments. Please notify the
>> sender immediately and delete the message and any attachments from your
>> computer. The unauthorized use, disclosure, copying or alteration of this
>> message is forbidden. Emails are not secure and may contain viruses. Vertex
>> accepts no responsibility for viruses; it is your responsibility to scan or
>> otherwise check this email and any attachments.
>>
>
>

RE: Chainsaw v2 Log viewer

2013-01-17 Thread Stein, Jason

Thank you, Scott, that worked great.  Now my next wish is this:

Since I have about 50 Test/QA JBoss environments, to use JNLP to start Chainsaw 
and have the appropriate configurations automatically loaded for each 
environment, depending upon which jnlp link one clicks.

Is that possible?

From: Scott Deboy [mailto:scott.de...@gmail.com]
Sent: Thursday, January 17, 2013 1:55 PM
To: Log4J Developers List
Subject: Re: Chainsaw v2 Log viewer

Latest developer snapshot is available here: http://people.apache.org/~sdeboy

On Thu, Jan 17, 2013 at 1:55 PM, Scott Deboy 
mailto:scott.de...@gmail.com>> wrote:
If you aren't already, I'd suggest trying the latest developer snapshot.
It has built-in support for generating a Chainsaw configuration from a 
fileappender/conversionpattern:
 - File, load Chainsaw configuration menu
 - Use fileappender entries from a log4j config file (can be .properties or 
.xml)
 - Select the  'open file' button and browse to your log4j configuration file 
containing the fileappender entries
 - Optionally select 'always start Chainsaw with this' and probably 'Save 
configuration as'
Let me know if that doesn't work.
If you are having problems, you can always use 'MESSAGE' as your logformat, 
which will not parse the line at all, just write the entire line to the 
'MESSAGE' field.

Scott

On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason 
mailto:jason.st...@vertexgroup.com>> wrote:

I'm trying to get Chainsaw up and running with our Jboss application.  We're 
currently using a JBoss log4j log which has a conversion pattern that looks 
like this:



As a result of not knowing exactly what logformat to use for this, I was 
getting a message which stated that there were no matching lines, and then it 
would show the log message that wasn't matching.

Then, in order to get Chainsaw to work, I created a separate conversion pattern 
(in a separate appender) which was detailed in your tutorial like this:



And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) - MESSAGE
Like I said, hoping to simply get something in the chainsaw-log...

All I'm getting is messages that say "no further lines to process", rather than 
any real log messages.  As a matter of fact, I don't see ANY real log messages, 
just chainsaw-logs.

What I was hoping I could do was use Chainsaw as a better log viewer - instead 
of using TextPad or Notepad++ .

Any help would be very much appreciated.




Please consider the environment before printing this email.
The information contained in this e-mail and its attachments are confidential 
to the intended recipient and may be legally privileged or otherwise protected 
from disclosure. If you have received this message in error,you must not print 
this email or its attachments. Please notify the sender immediately and delete 
the message and any attachments from your computer. The unauthorized use, 
disclosure, copying or alteration of this message is forbidden. Emails are not 
secure and may contain viruses. Vertex accepts no responsibility for viruses; 
it is your responsibility to scan or otherwise check this email and any 
attachments.

Re: Chainsaw v2 Log viewer

2013-01-17 Thread Scott Deboy

Hi Jason,

Glad that helped - there are a lot of new features - feedback welcome.

The latest developer snapshot isn't available via webstart, but if you
pushed Chainsaw to your own web server, yes, the first arg Chainsaw accepts
is a URL to a configuration file (you can use this feature to create
different aliases in Windows etc.).

Scott


On Thu, Jan 17, 2013 at 3:00 PM, Stein, Jason
wrote:

> Thank you, Scott, that worked great.  Now my next wish is this:
>
> ** **
>
> Since I have about 50 Test/QA JBoss environments, to use JNLP to start
> Chainsaw and have the appropriate configurations automatically loaded for
> each environment, depending upon which jnlp link one clicks.
>
> ** **
>
> Is that possible?  
>
> ** **
>
> *From:* Scott Deboy [mailto:scott.de...@gmail.com]
> *Sent:* Thursday, January 17, 2013 1:55 PM
> *To:* Log4J Developers List
> *Subject:* Re: Chainsaw v2 Log viewer
>
> ** **
>
> Latest developer snapshot is available here:
> http://people.apache.org/~sdeboy
>
> ** **
>
> On Thu, Jan 17, 2013 at 1:55 PM, Scott Deboy 
> wrote:
>
> If you aren't already, I'd suggest trying the latest developer snapshot.**
> **
>
> It has built-in support for generating a Chainsaw configuration from a
> fileappender/conversionpattern:
>
>  - File, load Chainsaw configuration menu
>
>  - Use fileappender entries from a log4j config file (can be .properties
> or .xml)
>
>  - Select the  'open file' button and browse to your log4j configuration
> file containing the fileappender entries
>
>  - Optionally select 'always start Chainsaw with this' and probably 'Save
> configuration as'
>
> Let me know if that doesn't work.
>
> If you are having problems, you can always use 'MESSAGE' as your
> logformat, which will not parse the line at all, just write the entire line
> to the 'MESSAGE' field.
>
>
> Scott
>
> ** **
>
> On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason 
> wrote:
>
> ** **
>
> I’m trying to get Chainsaw up and running with our Jboss application.
> We’re currently using a JBoss log4j log which has a conversion pattern
> that looks like this:
>
>  
>
> 
>
>  
>
> As a result of not knowing exactly what logformat to use for this, I was
> getting a message which stated that there were no matching lines, and then
> it would show the log message that wasn’t matching.
>
>  
>
> Then, in order to get Chainsaw to work, I created a separate conversion
> pattern (in a separate appender) which was detailed in your tutorial like
> this:
>
>  
>
> 
> 
>
>  
>
> And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) –
> MESSAGE 
>
> Like I said, hoping to simply get something in the chainsaw-log…
>
>  
>
> All I’m getting is messages that say “no further lines to process”, rather
> than any real log messages.  As a matter of fact, I don’t see ANY real
> log messages, just chainsaw-logs.
>
>  
>
> What I was hoping I could do was use Chainsaw as a better log viewer –
> instead of using TextPad or Notepad++ .
>
>  
>
> Any help would be very much appreciated.
>
>  
>
>  
>
>
>
> Please consider the environment before printing this email.
> The information contained in this e-mail and its attachments are
> confidential to the intended recipient and may be legally privileged or
> otherwise protected from disclosure. If you have received this message in
> error,you must not print this email or its attachments. Please notify the
> sender immediately and delete the message and any attachments from your
> computer. The unauthorized use, disclosure, copying or alteration of this
> message is forbidden. Emails are not secure and may contain viruses. Vertex
> accepts no responsibility for viruses; it is your responsibility to scan or
> otherwise check this email and any attachments. 
>
> ** **
>
> ** **
>

RE: Chainsaw v2 Log viewer

2013-01-17 Thread Stein, Jason

Scott, not sure that I follow you when you say, "pushed Chainsaw to your own 
web server."  Do you mean try to create my own JNLP file?

From: Scott Deboy [mailto:scott.de...@gmail.com]
Sent: Thursday, January 17, 2013 3:06 PM
To: Log4J Developers List
Subject: Re: Chainsaw v2 Log viewer

Hi Jason,

Glad that helped - there are a lot of new features - feedback welcome.

The latest developer snapshot isn't available via webstart, but if you pushed 
Chainsaw to your own web server, yes, the first arg Chainsaw accepts is a URL 
to a configuration file (you can use this feature to create different aliases 
in Windows etc.).
Scott

On Thu, Jan 17, 2013 at 3:00 PM, Stein, Jason 
mailto:jason.st...@vertexgroup.com>> wrote:
Thank you, Scott, that worked great.  Now my next wish is this:

Since I have about 50 Test/QA JBoss environments, to use JNLP to start Chainsaw 
and have the appropriate configurations automatically loaded for each 
environment, depending upon which jnlp link one clicks.

Is that possible?

From: Scott Deboy [mailto:scott.de...@gmail.com]
Sent: Thursday, January 17, 2013 1:55 PM
To: Log4J Developers List
Subject: Re: Chainsaw v2 Log viewer

Latest developer snapshot is available here: http://people.apache.org/~sdeboy

On Thu, Jan 17, 2013 at 1:55 PM, Scott Deboy 
mailto:scott.de...@gmail.com>> wrote:
If you aren't already, I'd suggest trying the latest developer snapshot.
It has built-in support for generating a Chainsaw configuration from a 
fileappender/conversionpattern:
 - File, load Chainsaw configuration menu
 - Use fileappender entries from a log4j config file (can be .properties or 
.xml)
 - Select the  'open file' button and browse to your log4j configuration file 
containing the fileappender entries
 - Optionally select 'always start Chainsaw with this' and probably 'Save 
configuration as'
Let me know if that doesn't work.
If you are having problems, you can always use 'MESSAGE' as your logformat, 
which will not parse the line at all, just write the entire line to the 
'MESSAGE' field.

Scott

On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason 
mailto:jason.st...@vertexgroup.com>> wrote:

I'm trying to get Chainsaw up and running with our Jboss application.  We're 
currently using a JBoss log4j log which has a conversion pattern that looks 
like this:

As a result of not knowing exactly what logformat to use for this, I was 
getting a message which stated that there were no matching lines, and then it 
would show the log message that wasn't matching.

Then, in order to get Chainsaw to work, I created a separate conversion pattern 
(in a separate appender) which was detailed in your tutorial like this:

And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) - MESSAGE
Like I said, hoping to simply get something in the chainsaw-log...

All I'm getting is messages that say "no further lines to process", rather than 
any real log messages.  As a matter of fact, I don't see ANY real log messages, 
just chainsaw-logs.

What I was hoping I could do was use Chainsaw as a better log viewer - instead 
of using TextPad or Notepad++ .

Any help would be very much appreciated.

Please consider the environment before printing this email.
The information contained in this e-mail and its attachments are confidential 
to the intended recipient and may be legally privileged or otherwise protected 
from disclosure. If you have received this message in error,you must not print 
this email or its attachments. Please notify the sender immediately and delete 
the message and any attachments from your computer. The unauthorized use, 
disclosure, copying or alteration of this message is forbidden. Emails are not 
secure and may contain viruses. Vertex accepts no responsibility for viruses; 
it is your responsibility to scan or otherwise check this email and any 
attachments.

Re: Chainsaw v2 Log viewer

2013-01-17 Thread Scott Deboy

Today there aren't a lot of great options here - setting up a JNLP-enabled
web server and exposing signed versions of the developer snapshot jars and
generating multiple configuration files and multiple jnlp files pointing to
those - ugly.

Using shortcuts in your window manager or a script could be a little
better, but I think I have a better option for you.

Chainsaw and all of the network-based appenders already support 'discovery'
via multicast dns/rendezvous, so I'd try a network-based appender and this
discovery configuration.  I'd suggest either a multicastappender,
UDPappender or SocketHubAppender.

In theory, once you have the jmdns jar available in your app (alongside
log4j), you would add one line to your socket-based appender configuration:
setAdvertiseViaMulticastDNS=true
Once your app is running and you start Chainsaw (assuming the nodes are
reachable via multicast), you will see the advertised socket-based appender
in Chainsaw's 'connect to' menu.

Adding discovery for file-based appenders is an interesting idea since we
have VFSLogFilePatternReceiver.  I'll have to think about what that would
take.

Hope that helps,
Scott



On Thu, Jan 17, 2013 at 4:39 PM, Stein, Jason
wrote:

> Scott, not sure that I follow you when you say, “pushed Chainsaw to your
> own web server.”  Do you mean try to create my own JNLP file?
>
> ** **
>
> *From:* Scott Deboy [mailto:scott.de...@gmail.com]
> *Sent:* Thursday, January 17, 2013 3:06 PM
>
> *To:* Log4J Developers List
> *Subject:* Re: Chainsaw v2 Log viewer
>
> ** **
>
> Hi Jason,
>
> Glad that helped - there are a lot of new features - feedback welcome.
>
> The latest developer snapshot isn't available via webstart, but if you
> pushed Chainsaw to your own web server, yes, the first arg Chainsaw accepts
> is a URL to a configuration file (you can use this feature to create
> different aliases in Windows etc.).
>
> Scott
>
> ** **
>
> On Thu, Jan 17, 2013 at 3:00 PM, Stein, Jason 
> wrote:
>
> Thank you, Scott, that worked great.  Now my next wish is this:
>
>  
>
> Since I have about 50 Test/QA JBoss environments, to use JNLP to start
> Chainsaw and have the appropriate configurations automatically loaded for
> each environment, depending upon which jnlp link one clicks.
>
>  
>
> Is that possible?  
>
>  
>
> *From:* Scott Deboy [mailto:scott.de...@gmail.com]
> *Sent:* Thursday, January 17, 2013 1:55 PM
> *To:* Log4J Developers List
> *Subject:* Re: Chainsaw v2 Log viewer
>
>  
>
> Latest developer snapshot is available here:
> http://people.apache.org/~sdeboy
>
>  
>
> On Thu, Jan 17, 2013 at 1:55 PM, Scott Deboy 
> wrote:
>
> If you aren't already, I'd suggest trying the latest developer snapshot.**
> **
>
> It has built-in support for generating a Chainsaw configuration from a
> fileappender/conversionpattern:
>
>  - File, load Chainsaw configuration menu
>
>  - Use fileappender entries from a log4j config file (can be .properties
> or .xml)
>
>  - Select the  'open file' button and browse to your log4j configuration
> file containing the fileappender entries
>
>  - Optionally select 'always start Chainsaw with this' and probably 'Save
> configuration as'
>
> Let me know if that doesn't work.
>
> If you are having problems, you can always use 'MESSAGE' as your
> logformat, which will not parse the line at all, just write the entire line
> to the 'MESSAGE' field.
>
>
> Scott
>
>  
>
> On Thu, Jan 17, 2013 at 1:42 PM, Stein, Jason 
> wrote:
>
>  
>
> I’m trying to get Chainsaw up and running with our Jboss application.
> We’re currently using a JBoss log4j log which has a conversion pattern
> that looks like this:
>
>  
>
> 
>
>  
>
> As a result of not knowing exactly what logformat to use for this, I was
> getting a message which stated that there were no matching lines, and then
> it would show the log message that wasn’t matching.
>
>  
>
> Then, in order to get Chainsaw to work, I created a separate conversion
> pattern (in a separate appender) which was detailed in your tutorial like
> this:
>
>  
>
> 
> 
>
>  
>
> And used the logformat of TIMESTAMP LEVEL [THREAD] CLASS (FILE:LINE) –
> MESSAGE 
>
> Like I said, hoping to simply get something in the chainsaw-log…
>
>  
>
> All I’m getting is messages that say “no further lines to process”, rather
> than any real log messages.  As a matter of fact, I don’t see ANY real
> log messages, just chainsaw-logs.
>
>  
>
> What I was hoping I could do was use Chainsaw as a better log viewer –
> instead of using TextPad or Notepad++ .
>
>  
>
> Any help would be very much appreciated.
>
>  
>
>  
>
>
>
> Please consider the environment before printing this email.
> The information contained in this e-mail and its attachments are
> confidential to the intended recipient and may be legally privileged or
> otherwise prote

[jira] [Created] (LOG4J2-155) Re-add getContentType, add getFormat to Layout

2013-01-17 Thread Scott Deboy (JIRA)

Scott Deboy created LOG4J2-155:
--

 Summary: Re-add getContentType, add getFormat to Layout
 Key: LOG4J2-155
 URL: https://issues.apache.org/jira/browse/LOG4J2-155
 Project: Log4j 2
  Issue Type: Improvement
Reporter: Scott Deboy


The different Layout implementations don't expose the contentType previously 
available in log4j.  HTMLLayout has a 'dead' contentType field, but that's it.

It would be useful to expose the content type (text/plain, text/html, text/xml) 
along with a information about the format.

If the content type is text/plain, exposing the layout format as a conversion 
pattern would work fine.

If the content type is text/html or text/xml we could expose something else (or 
null).

My primary interest is adding the ability to 'discover' the file-based logging 
configurations in order to support them via Chainsaw and multicast DNS.

If all Layouts supporting text/plain content types exposed their format as a 
conversion pattern, and the file-based appenders (optionally) provided the 
ability to advertise their configuration, the files could be remotely tailed 
without the far endpoint even knowing anything about the file configuration.

For an example, see how multicast appenders are exposed via zeroconf/multicast 
dns in log4j 1.x in activateOptions - something very similar could be done with 
contenttype and format properties in a fileappender with a layout.

if (advertiseViaMulticastDNS) {
Map properties = new HashMap();
properties.put("multicastAddress", remoteHost);
zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
zeroConf.advertise();
}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-155) add getFormat to Layout

2013-01-17 Thread Scott Deboy (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Deboy updated LOG4J2-155:
---

Summary: add getFormat to Layout  (was: Re-add getContentType, add 
getFormat to Layout)

> add getFormat to Layout
> ---
>
> Key: LOG4J2-155
> URL: https://issues.apache.org/jira/browse/LOG4J2-155
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Scott Deboy
>
> The different Layout implementations don't expose the contentType previously 
> available in log4j.  HTMLLayout has a 'dead' contentType field, but that's it.
> It would be useful to expose the content type (text/plain, text/html, 
> text/xml) along with a information about the format.
> If the content type is text/plain, exposing the layout format as a conversion 
> pattern would work fine.
> If the content type is text/html or text/xml we could expose something else 
> (or null).
> My primary interest is adding the ability to 'discover' the file-based 
> logging configurations in order to support them via Chainsaw and multicast 
> DNS.
> If all Layouts supporting text/plain content types exposed their format as a 
> conversion pattern, and the file-based appenders (optionally) provided the 
> ability to advertise their configuration, the files could be remotely tailed 
> without the far endpoint even knowing anything about the file configuration.
> For an example, see how multicast appenders are exposed via 
> zeroconf/multicast dns in log4j 1.x in activateOptions - something very 
> similar could be done with contenttype and format properties in a 
> fileappender with a layout.
> if (advertiseViaMulticastDNS) {
> Map properties = new HashMap();
> properties.put("multicastAddress", remoteHost);
> zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
> zeroConf.advertise();
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Updated] (LOG4J2-155) add getFormat to Layout

2013-01-17 Thread Scott Deboy (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Deboy updated LOG4J2-155:
---

Description: 
I was looking at an old rev - getContentType is now exposed - thanks!

Now if we could add a 'getFormat':

It would be useful to expose information about a Layout's format.

If the content type is text/plain, exposing the layout format as a conversion 
pattern would work fine.

If the content type is text/html or text/xml we could expose something else (or 
null).

My primary interest is adding the ability to 'discover' the file-based logging 
configurations in order to support them via Chainsaw and multicast DNS.

If all Layouts supporting text/plain content types exposed their format as a 
conversion pattern, and the file-based appenders (optionally) provided the 
ability to advertise their configuration, the files could be remotely tailed 
without the far endpoint even knowing anything about the file configuration.

For an example, see how multicast appenders are exposed via zeroconf/multicast 
dns in log4j 1.x in activateOptions - something very similar could be done with 
contenttype and format properties in a fileappender with a layout.

if (advertiseViaMulticastDNS) {
Map properties = new HashMap();
properties.put("multicastAddress", remoteHost);
zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
zeroConf.advertise();
}


  was:
The different Layout implementations don't expose the contentType previously 
available in log4j.  HTMLLayout has a 'dead' contentType field, but that's it.

It would be useful to expose the content type (text/plain, text/html, text/xml) 
along with a information about the format.

If the content type is text/plain, exposing the layout format as a conversion 
pattern would work fine.

If the content type is text/html or text/xml we could expose something else (or 
null).

My primary interest is adding the ability to 'discover' the file-based logging 
configurations in order to support them via Chainsaw and multicast DNS.

If all Layouts supporting text/plain content types exposed their format as a 
conversion pattern, and the file-based appenders (optionally) provided the 
ability to advertise their configuration, the files could be remotely tailed 
without the far endpoint even knowing anything about the file configuration.

For an example, see how multicast appenders are exposed via zeroconf/multicast 
dns in log4j 1.x in activateOptions - something very similar could be done with 
contenttype and format properties in a fileappender with a layout.

if (advertiseViaMulticastDNS) {
Map properties = new HashMap();
properties.put("multicastAddress", remoteHost);
zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
zeroConf.advertise();
}



> add getFormat to Layout
> ---
>
> Key: LOG4J2-155
> URL: https://issues.apache.org/jira/browse/LOG4J2-155
> Project: Log4j 2
>  Issue Type: Improvement
>Reporter: Scott Deboy
>
> I was looking at an old rev - getContentType is now exposed - thanks!
> Now if we could add a 'getFormat':
> It would be useful to expose information about a Layout's format.
> If the content type is text/plain, exposing the layout format as a conversion 
> pattern would work fine.
> If the content type is text/html or text/xml we could expose something else 
> (or null).
> My primary interest is adding the ability to 'discover' the file-based 
> logging configurations in order to support them via Chainsaw and multicast 
> DNS.
> If all Layouts supporting text/plain content types exposed their format as a 
> conversion pattern, and the file-based appenders (optionally) provided the 
> ability to advertise their configuration, the files could be remotely tailed 
> without the far endpoint even knowing anything about the file configuration.
> For an example, see how multicast appenders are exposed via 
> zeroconf/multicast dns in log4j 1.x in activateOptions - something very 
> similar could be done with contenttype and format properties in a 
> fileappender with a layout.
> if (advertiseViaMulticastDNS) {
> Map properties = new HashMap();
> properties.put("multicastAddress", remoteHost);
> zeroConf = new ZeroConfSupport(ZONE, port, getName(), properties);
> zeroConf.advertise();
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

Re: Log4J2 and Tomcat: multiple external config files

2013-01-17 Thread Ralph Goers

Why do you deploy the Log4j2 jars to both the Tomcat directory and the 
application?  That will mean that any Managers that should be shared across web 
apps won't be. I'm not sure why you would get varying results.

I'll be driving tomorrow to visit my in-laws for the long weekend so I'm not 
sure how responsive I will be.

Ralph

On Jan 17, 2013, at 1:02 PM, Scott Severtson  
wrote:

> All,
> 
> Hmmm... More experimentation has shown that this configuration does not have 
> reliable results. Sometimes on startup, the application-specific messages end 
> up in the Tomcat logs, but not in the application-specific logs. Other times, 
> the messages are routed correctly.
> 
> Any thoughts? Is there some sort of configuration race condition going on?
> 
> --Scott
> 
> On 01/17/2013 09:33 AM, Scott Severtson wrote:
>> Ralph,
>> 
>> So, based on your response, here's what we've come up with:
>> * Log4J2 .jars deployed to Tomcat's CATALINA_BASE/lib directory
>> * -Dlog4j.configurationFile=/path/to/tomcat-specific/log4j2.xml
>> * Log4J2 .jars *also* deployed in web applications
>> * web.xml context-param: 
>> log4jConfiguration=${log4j.application.configurationFile}
>> * web.xml listener Log4jContextListener
>> * 
>> -Dlog4j.application.configurationFile=/path/to/application-specific/log4j2.xml
>> 
>> This works, for the most part. The application-specific log events are sent 
>> to the appropriate application-specific appenders, and Tomcat log events are 
>> sent to the Tomcat-specific appenders.
>> 
>> However, we have one problem: Application-specific log events are *also* 
>> appended to the Tomcat root logger.
>> 
>> Do I need to add entries to the tomcat-specific configuration to *exclude* 
>> application specific events? I was under the impression that the 
>> ClassLoaderContextSelector and using Log4jContextListener would prevent 
>> events from being sent between the two contexts.
>> 
>> For what it's worth, our applications do not currently specify a 
>> display-name in web.xml, which according to the docs, would result in 
>> ServletContext.getServletContextName() returning null. Also, no 
>> context-param is configured for log4jContextName. However, based on my 
>> reading of the Log4J2 code, the context name is not actually used by 
>> Configurator or ConfigurationFactory, so I assumed the null name would not 
>> matter.
>> 
>> Many thanks for any hints in the right direction,
>> --Scott
>> 
>> On 01/10/2013 12:27 PM, Ralph Goers wrote:
>>> LOG4J2-18 and LOG4J2-42 have been sitting for quite some time waiting for 
>>> someone like yourself to come along and help come up with good approaches.
>>> 
>>> I think most of the tools are there but I'm not sure what the best way(s) 
>>> is/are to finish it off.
>>> 
>>> First, hopefully you are aware that the default ContextSelector is the 
>>> ClassLoaderContextSelector. If you place your Log4j 2 jars in the tomcat 
>>> class loader then Tomcat's logging will use the Logging Context associated 
>>> with Tomcat's class loader. That would need to use log4j2.xml or the system 
>>> property - unless something can be added to Tomcat startup that causes it 
>>> to use a different configuration file via the Configurator.  All the web 
>>> applications will have their own logging contexts that is associated with 
>>> their class loader. If you use the Log4jContextListener in the web project 
>>> and can configure each web apps web.xml then you can cause each web app to 
>>> have their own configuration or you can set them to all use the same one. I 
>>> suppose we could also modify the context listener to look for a system 
>>> property to automatically cause all the web apps to share a configuration.
>>> 
>>> With the BasicContextSelector everything uses a single LoggerContext so 
>>> that probably isn't what you want.
>>> 
>>> With the JNDIContextSelector each web app does a JNDI lookup to locate its 
>>> LoggerContext. Again, you would need to configure each web app with the 
>>> location of the configuration file.
>>> 
>>> I'm open to suggestions on how to better handle this.
>>> 
>>> Ralph
>>> 
>>> 
>>> On Jan 10, 2013, at 8:56 AM, Scott Severtson wrote:
>>> 
 All,
 
 We'd like to replace Tomcat's built-in logging with Log4J2, and are able 
 to do so based on Tomcat's docs for using Log4J 1.x, and deploying the 
 log4j-1.2-api-2.0-beta4.jar shim.
 
 However, we're running into an issue with external configuration...
 
 Our webapps are always deployed with external logging configuration files. 
 Historically, we've used -Dlog4j.configuration=/path/to/log4j.properties 
 (now -Dlog4j.configurationFile=/path/to/log4j2.xml) to point the app to 
 the correct file.
 
 Unfortunately, if we pass the app-specific config file to the Tomcat JVM, 
 the Tomcat-level Log4J2 instance *also* tries to that config file.
 
 Is there a reasonable way to support externalized configuration files both 
 for the To

[jira] [Resolved] (LOG4J2-152) NullPointerException in (...)appender.rolling.helper.FileRenameAction if filePattern does not contain a parent directory

2013-01-17 Thread Ralph Goers (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ralph Goers resolved LOG4J2-152.


   Resolution: Fixed
Fix Version/s: 2.0-beta4
 Assignee: Ralph Goers

Fixed in revision 1435044. Please verify and close.

> NullPointerException in (...)appender.rolling.helper.FileRenameAction if 
> filePattern does not contain a parent directory
> 
>
> Key: LOG4J2-152
> URL: https://issues.apache.org/jira/browse/LOG4J2-152
> Project: Log4j 2
>  Issue Type: New Feature
>  Components: Appenders
>Affects Versions: 2.0-beta3
>Reporter: Remko Popma
>Assignee: Ralph Goers
> Fix For: 2.0-beta4
>
>
> ERROR StatusLogger Error in synchronous task java.lang.NullPointerException
>   at 
> org.apache.logging.log4j.core.appender.rolling.helper.FileRenameAction.execute(FileRenameAction.java:85)
>   at 
> org.apache.logging.log4j.core.appender.rolling.helper.FileRenameAction.execute(FileRenameAction.java:71)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.rollover(RollingFileManager.java:140)
>   at 
> org.apache.logging.log4j.core.appender.rolling.RollingFileManager.checkRollover(RollingFileManager.java:97)
>   at 
> atlas.infra.log.RollingRandomAccessFileAppender.append(RollingRandomAccessFileAppender.java:52)
>   at 
> org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:98)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:335)
>   at 
> org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:316)
>   at 
> org.apache.logging.log4j.core.Logger$PrivateConfig.logEvent(Logger.java:304)
> To reproduce, in log4j2.xml, specify a filePattern without a parent directory:
>   
>   filePattern="fileWithoutParentDir-%d{MM-dd-}-%i.log.gz">
> To fix, change 
> org.apache.logging.log4j.core.appender.rolling.helper.FileRenameAction#execute(File,
>  File, boolean) (line 85): add null check:
> if (parent != null && !parent.exists()) { // parent is null if not specified 
> in filePattern

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org

[jira] [Resolved] (LOG4J2-150) Applet: AccessControlException from System.getProperty(...), Integer.getInteger, and Boolean.getBoolean

[jira] [Commented] (LOG4J2-146) Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext

[jira] [Comment Edited] (LOG4J2-146) Log4J 1.2 API implementation ClassCastException with SimpleLoggerContext

Re: Log4J2 and Tomcat: multiple external config files

Re: Log4J2 and Tomcat: multiple external config files

Chainsaw v2 Log viewer

Re: Chainsaw v2 Log viewer

Re: Chainsaw v2 Log viewer

RE: Chainsaw v2 Log viewer

Re: Chainsaw v2 Log viewer

RE: Chainsaw v2 Log viewer

Re: Chainsaw v2 Log viewer

[jira] [Created] (LOG4J2-155) Re-add getContentType, add getFormat to Layout

[jira] [Updated] (LOG4J2-155) add getFormat to Layout

[jira] [Updated] (LOG4J2-155) add getFormat to Layout

Re: Log4J2 and Tomcat: multiple external config files

[jira] [Resolved] (LOG4J2-152) NullPointerException in (...)appender.rolling.helper.FileRenameAction if filePattern does not contain a parent directory

17 matches

Site Navigation

Mail list logo

Footer information