Skip to main content

log4j.properties changes

5 replies [Last post]
howardteece
Offline
Joined: 2010-06-17
Points: 0

In check-in 9956 the file log4j.properties was removed from base.filelist and a specific copy added to build.xml to place the file in the target bin directory.

This means that we can't easily create jars for non-simulator targets as log4j.properties is no longer a part of ocap-rez.jar

Should I raise an IT for this?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
scottdeboy
Offline
Joined: 2009-02-02
Points: 0

It sounds like there are a few options here.

I agree, being able to override the log4j.properties location would work fine for core developers, but it would be a bit more of a hassle for folks who aren't as familiar with the RI but need to modify the log4j configuration (they still have to copy log4j.properties somewhere and then update final.properties).

Is deploying the log4j.properties we copy to $OCAPROOT/bin/$OCAPTC/env an option? I suspect it would require an extra step in your deployment script (a file copy or jar creation step) - just trying to get as much info as possible so we can make a reasonably informed decision.

There are a couple of stack code changes needed to be able to set OCAP.log4j.properties in final.properties (the code is currently only looking in base.properties, but should also look in final.properties).

howardteece
Offline
Joined: 2010-06-17
Points: 0

Using final.properties would certainly help, but the real problem is that log4j.properties needs to be manually added to the final build objects to ensure we get some log output from the stack. Remember at this point that because there's no property file, there are no appenders so we get zero trace.

I think the best thing would be:
1. Restore log4j.properties to base.filelist so it is included in ocap-rez.jar
2. Add the parsing of final.properties to allow a manual override of the location of log4j.properties when the stack starts.
3. Continue to copy the file to the env directory for sim users and then modify final.properties to point to that file, not the one found as a last resort in the base directory.

Thanks.

dhooley
Offline
Joined: 2008-04-23
Points: 0

There are no technical reasons why the change should be reverted. log4j.properties just needs to be available to the classloader - in a jar or a folder, it doesn't matter.

As Scott has pointed out, there are good reasons to leave it (it's easier for SDK users and other RI stack developers to change their configuration). There are also reasons why you may not even want to use our log4j.properties file,and putting the config file back in ocap-rez.jar makes it difficult for others to do that.

So, we feel the change is appropriate. We suggest that you modify your processes to ensure log4j.properties is available to the classloader'.

scottdeboy
Offline
Joined: 2009-02-02
Points: 0

This was an intentional change we put in place in order to make it -much- easier to change the verbosity of the Java logging in the stack.

The build process now copies log4j.properties to $OCAPROOT/bin/$OCAPTC/env (only if it does not already exist in that location), making it much easier to change the configuration (just modify the copied log4j.properties file).

This change is beneficial both to the core developer team and others developing with the RI, as they can now change Java logging verbosity without being required to rebuild or extract log4j.properties from ocap-rez.jar and add it to the classpath manually.

Are there changes you can put in place for your non-simulator deployment targets to accommodate this change?

howardteece
Offline
Joined: 2010-06-17
Points: 0

Well, no not really as the file is missing from a non-sim deployment.

Wouldn't it be easier for sim developers to modify OCAP.log4j.properties in base.properties to point to the log4j.properties that can be modified at run time?

Then everyone is happy as we get a file to deploy and they get a file they can edit.