Hi Landon,
I'm not sure I understand your question, sorry. I'm not suggesting to
expose any method to access logging functionality.
I hope this makes this more clear:
What I'm suggesting is that the 330 calls to System.out currently in src
get cleaned up, replaced with appropriate log4j calls.
ie.
System.out.println("Starting OpenJUMP");
logger.info("Starting OpenJUMP");
System.out.println("Entering my private method");
logger.debug("Entering my private method");
System.out.println("Should never reach here !!!");
logger.fatal("Should never reach here !!!", exception);
Log4j then needs a configuration defined so it knows where to output the
log statements, if at all. This can be done from an xml file specified
from the JVM (which is what is currently done):
-Dlog4j.configuration=file:etc/log4j.xml
or from an xml file specified as a application argument:
import com.foo.Bar;
import org.apache.log4j.Logger;
import org.apache.log4j.DOMConfigurator;
public class MyApp {
static Logger logger = Logger.getLogger(MyApp.class);
public static void main(String[] args) {
// Configure using log4j.xml file
DOMConfigurator.configure(args[0]);
logger.info("Entering application.");
Bar bar = new Bar();
bar.doIt();
logger.info("Exiting application.");
}
}
or programmatically, hard-coded:
import com.foo.Bar;
import org.apache.log4j.Logger;
import org.apache.log4j.BasicConfigurator;
public class MyApp {
static Logger logger = Logger.getLogger(MyApp.class);
public static void main(String[] args) {
// Set up a simple configuration that logs on the console.
// (not that OJ would do this)
BasicConfigurator.configure();
logger.info("Entering application.");
Bar bar = new Bar();
bar.doIt();
logger.info("Exiting application.");
}
}
A possibility exists that OJ could accept a log_level parameter. If not
specified, the default log4j.xml file could be used outputting "info"
and above statements to a log file. If specified, a different log4j.xml
file or hard-coded root logger could be used to output trace/debug log
statements and above to a log file. This could be useful for bug
reporting. As a plugin developer, I can specify my own configuration
file that ignores all log statements except those in my own java
package, writing them to my console.
I know OJ currently uses log4j. If the OJ team wants to fully go the
log4j route, then all I'm suggesting for now is that the 330 output
statements get cleaned up.
But, Landon, I think you made an excellent point earlier ... some of
these statements should also be reported to the user
(https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=Displaying_Debug_Messages)
in addition to being logged.
Cheers,
Kevin
On 9/7/2010 8:43 AM, Sunburned Surveyor wrote:
> I'll have to take a look at log4J again. Did you imagine exposing a
> method to access the logging functionality through the plug-in
> context, or through some other mechanism?
>
> The Sunburned Surveyor
>
> On Tue, Sep 7, 2010 at 8:29 AM, Kevin Neufeld<kneuf...@refractions.net>
> wrote:
>> On 9/7/2010 7:38 AM, Sunburned Surveyor wrote:
>>> Stefan,
>>>
>>> ... I have used Log4j before,
>>> and it seemed a little complicated.
>> I find the log4j.properties variant complicated as well. But the
>> log4j.xml [1] configuration variant I find fairly straight forward [2].
>> I can include/exclude log messages from particular java packages and log
>> priorities.
>>
>>> I wonder if just having the
>>> ability to write messages to a simple plain-text log file would
>>> suffice.
>>>
>> Which is one of many output appenders available to log4j :) I agree,
>> this is what I would recommend. From user's perspective, one can submit
>> the log file when posting a bug report. We can even include a parameter
>> in the JUMP launcher that would temporarily set the log priority to
>> debug or even verbose to help with bug reports.
>>
>> My 2 cents,
>> -- Kevin
>>
>>
>> [1] http://wiki.apache.org/logging-log4j/Log4jXmlFormat
>> [2] http://wiki.apache.org/logging-log4j/Log4jXmlFormat#Example_2
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
