Is there any quick and easy way to add debug logging to a Java service running under Unix rather than implementing log4j or an equivalent.

thanks

Tony

If it is only for the purpose of debugging and in dev/test environment, you can use System.out.println and the output would be on the nohup (if you ahve started the server with that) or on the console on which you have started the server
Another way is to write a public methods in the shared service tab. This method should do a doInvoke() to pub.flow:DebugLog. Now in the java service you can invoke this method passing in the message as input

Regards,
Pradeep

You could use either of the following:

1. System.out.println to write to the server log – but works only reliably when running IS from a console

2. Use FileOutputStream and keep a reference to the open stream in a public static variable in your shared code

3. You might use the internal AuditLogManager class but that is unsupported and I am not even sure whether it is documented.

Option 1 would be the next best thing after Log4J. And I would still prefer Log4J…

Good luck!

Chris

thanks log4j seems the best approach having looked at the options

You can also use the same facilities that the debugLog service uses and get the automatic log rolling, etc. without introducing another logging facility (for some reason, I object to adding log4j to IS–it seems redundant).

ServerAPI.getLogStream will return an open stream that can be used for logging. You can do some simple management to have one or more app log streams available.

getLogStream - Wrapper service for ServerAPI.getLogStream. Given an input logfile parm, opens a log file in the server’s default log directory. The returned stream is intended to remain open for the life of the JVM. The service maintains a static hashtable of log streams keyed by the logfile parameter (a filename) on the shared code tab.

writeLogStream - Accepts a stream returned by getLogStream and a message to write. Writes date/time first, followed by the message and then by line.separator.

closeLogStream - Given a logfile, closes the stream associated with it (if any) and removes the stream from the list of open streams. This is primarily a convenience method useful during development.

With these base helper services in place, then you can write app/integration specific service like “logMessage” that calls getLogStream and writeLogStream for a specific logfile name. For example:

writeFooLog(message)
–getLogStream(“foo.log”) → stream
–writeLogStream(stream, message)

log4j certainly provides additional flexibility. The question becomes do you need that flexibility or is just on/off logging sufficient?

Just another option to consider.