rails-devel

[Rails-devel] Log4j logging

[Erik V. <eri...@hc...>]

I have implemented log4j logging throughout.
Most System.out.println() statements have been replaced by log.debug().

There are two "appenders" (i.e. log message destinations):
the console and a daily rolling log file.

The log file logs everything and includes time stamps and other details.
The console does not get "debug"-level messages and has less detail.

To avoid confusion, I have renamed the Log Window to Report Window,
because it holds what can best be described as the game report
(I would like to add Print and Save buttons to this window).
The lines added to this window are also logged (level INFO), 
as well as all messages sent to the UI.

There is a new properties file called "my.properties",
which is intended to hold the user's local preferences
(in so far these are not configurable by some screen).
Currently this file only holds the SVG/GIF tile preference,
and the log4j properties.
One of the log4j properties is the log file path; the
default is log/18xx.log. 

The new class util.Config reads my.properties into a Properties map.
Any class can retrieve any property with the Config.get() method.
Other property files can easily be added.

I have changed ImageLoader to use the GIF/SVG preference.
If the preferred type (SVG is default) is not found, the
other type is looked for. This class was also changed
to consistently use Util.getStreamForFile(). 
This method looks first at the file system and, if a tile 
(or whatever else - it is also used to find XML files)
is not found there, into the Rails jar (incl. version number).

Jar file log4j-1.2.14.jar has been added to the lib directory
and must be added to the project's build path.

Comments welcome, as usual.

Erik Vos

Re: [Rails-devel] Log4j logging

[brett l. <wak...@gm...>]

On 1/12/07, Erik Vos <eri...@hc...> wrote:
> I have implemented log4j logging throughout.
> Most System.out.println() statements have been replaced by log.debug().

Excellent!

> There is a new properties file called "my.properties",
> which is intended to hold the user's local preferences
> (in so far these are not configurable by some screen).
> Currently this file only holds the SVG/GIF tile preference,
> and the log4j properties.
> One of the log4j properties is the log file path; the
> default is log/18xx.log.
>

We should include a "remember my choices" style of checkbox or button
and save more of the UI fields into the properties file. This should
be in the Options UI and one of the drop-downs so the user can do it
both before starting a game and during a game.


---Brett.

Re: [Rails-devel] Log4j logging

[Erik V. <eri...@hc...>]

> > There is a new properties file called "my.properties",
> > which is intended to hold the user's local preferences
> > (in so far these are not configurable by some screen).
> > Currently this file only holds the SVG/GIF tile preference,
> > and the log4j properties.
> > One of the log4j properties is the log file path; the
> > default is log/18xx.log.
> >
> 
> We should include a "remember my choices" style of checkbox or button
> and save more of the UI fields into the properties file. This should
> be in the Options UI and one of the drop-downs so the user can do it
> both before starting a game and during a game.

Do we already have any choice items like that?
I don't think so, but once we have such items, 
we should find a place to store these.

I don't know how such storage is realised in other systems.
If it's a properties file, I would suggest to create 
another one for that purpose: one that can be overwritten
by the program after any change.
my.properties would then be reserved for properties 
that are not (or not yet) maintainable via the UI.

However, I don't have any strong feelings about this.

BTW by default log4j expects a configuration file named
log4j.properties, but I have changed this into my.properties
by setting a system property in the main() method.
This property is checked by log4j. It can also be provided 
on the command line, but I don't check that yet.
This property setting should always be the first statement to execute
in any new main program that we might develop in the future. 

Erik.

Re: [Rails-devel] Log4j logging

[brett l. <wak...@gm...>]

>
> Do we already have any choice items like that?
> I don't think so, but once we have such items,
> we should find a place to store these.
>


I thought we might, but perhaps we don't.


> I don't know how such storage is realised in other systems.
> If it's a properties file, I would suggest to create
> another one for that purpose: one that can be overwritten
> by the program after any change.
> my.properties would then be reserved for properties
> that are not (or not yet) maintainable via the UI.
>

I'd prefer to not have too many configuration files running around.
Ideally, all preferences should be set in the UI, so the user doesn't
have to manually edit the configuration file.


---Brett

Re: [Rails-devel] Log4j logging

[Erik V. <eri...@hc...>]

> I'd prefer to not have too many configuration files running around.
> Ideally, all preferences should be set in the UI, so the user doesn't
> have to manually edit the configuration file.

Not sure if it is feasible and worthwhile for log4j logging.

Speaking about that, the version of my.properties that I have checked in
may not be the most user-friendly one, as it creates an indefinite 
amount of logfiles.

Logging options ("appenders") that don't are:
- the RollingFileAppender, which rolls over at a certain size, 
whereby a maximum number of old logs can be set.
- the FileAppender in overwrite mode, which creates a new log
in each run (i.e. game). No backups with this one.

Any suggestions about the way to go?
In theory we could develop out own appender, which might
do whatever we want, but I have already found that
grasping the inner workings of log4j is not easy.


In addition, we should distinguish between the my.properties
version in CVS, which should be a sensible default version,
and the version that we really use ourselves.

Could we give a different name to the CVS version,
and tell the user to change the name to get it working?

Erik.

Re: [Rails-devel] Log4j logging

[brett l. <wak...@gm...>]

On 1/13/07, Erik Vos <eri...@hc...> wrote:
> Speaking about that, the version of my.properties that I have checked in
> may not be the most user-friendly one, as it creates an indefinite
> amount of logfiles.
>

Yeah, that's not good.

> Logging options ("appenders") that don't are:
> - the RollingFileAppender, which rolls over at a certain size,
> whereby a maximum number of old logs can be set.
> - the FileAppender in overwrite mode, which creates a new log
> in each run (i.e. game). No backups with this one.
>
> Any suggestions about the way to go?
> In theory we could develop out own appender, which might
> do whatever we want, but I have already found that
> grasping the inner workings of log4j is not easy.
>

I think we don't really need more than one log file just yet.

I definitely don't want to clutter up a user's drive unnecessarily.

It looks like we should use the FileAppender.


>
> Could we give a different name to the CVS version,
> and tell the user to change the name to get it working?
>

I don't like that option.  I'd like to make things as easy as possible
for users. Most people want their software to "just work" without much
setup.

So, we should provide a properties file with sensible defaults. Some
will want to change them, most will just use what we give them.


---Brett

Re: [Rails-devel] Log4j logging

[Erik V. <eri...@hc...>]

> I think we don't really need more than one log file just yet.
> 
> I definitely don't want to clutter up a user's drive unnecessarily.
> 
> It looks like we should use the FileAppender.


OK, I have reduced the log4j options in my.properties to 
just a simple log file that is overwritten for each new game.
I have removed the ConsoleAppender.

I have also removed the prefix log/ to the log file name
to avoid errors if there is no log directory.

My own version of my.properties is now named my_my.properties.
It is invoked by specifying -Dconfigfile=my_my.properties 
on the command line (in Eclipse by adding this option as a "VM argument").

GameTest picks up this argument. If absent, the default name
my.properties is used.

Only my.properties will exist in CVS.
So, if you want to save my original version (or your own version)
of this file, please rename it before you synchronise!

Erik.

Re: [Rails-devel] Log4j logging

[brett l. <wak...@gm...>]

On 1/15/07, Erik Vos <eri...@hc...> wrote:
> > I think we don't really need more than one log file just yet.
> >
> > I definitely don't want to clutter up a user's drive unnecessarily.
> >
> > It looks like we should use the FileAppender.
>
>
> OK, I have reduced the log4j options in my.properties to
> just a simple log file that is overwritten for each new game.
> I have removed the ConsoleAppender.
>
> I have also removed the prefix log/ to the log file name
> to avoid errors if there is no log directory.
>


Perfect. :-)


> My own version of my.properties is now named my_my.properties.
> It is invoked by specifying -Dconfigfile=my_my.properties
> on the command line (in Eclipse by adding this option as a "VM argument").
>
> GameTest picks up this argument. If absent, the default name
> my.properties is used.
>


We should capture this somewhere. Perhaps we should make use of
SourceForge's documentation tools?


> Only my.properties will exist in CVS.
> So, if you want to save my original version (or your own version)
> of this file, please rename it before you synchronise!
>

Will do.

Re: [Rails-devel] Log4j logging

[Erik V. <eri...@hc...>]

> > My own version of my.properties is now named my_my.properties.
> > It is invoked by specifying -Dconfigfile=my_my.properties
> > on the command line (in Eclipse by adding this option as a 
> "VM argument").
> >
> > GameTest picks up this argument. If absent, the default name
> > my.properties is used.
> >
> 
> 
> We should capture this somewhere. Perhaps we should make use of
> SourceForge's documentation tools?

I'm not familiar with those but it sounds good.

The -D feature is mainly interesting for developers; other users
will not likely have a need for two different properties files.

For all users we will need to document the contents of the properties file.
Both my.properties and GameTest.java already include comments
that could serve as a start for such document(s).

Erik.