into the source code of method 'dodaj'. I would like to have the source of my method 'dodaj' like that:

public int dodaj(float p1, float p2){return (int)(p1 + p2);}

And I would like to write in my 'myLoggingConfigFilePath' write something:

.level=ALL

or .level=ENTRYor .level=RETURN

But I don't know what should I put in my config file exactly and where. I can't deduce from the documentation if it possible to enable logging method and parameters method and returned results by the config file (properties).

You can see that sorter.Generator.generate(int) is invoked. And please notice that there is no single line in the source code with Logger, or log() apart from config files.

As far as I can understand logging mechanisms is embedded in JDK so I only need to enable it and configure. Of course I can put log() statements in the soruce code if I wish. But I can get some information about execution without any additional instruction put into my source code. Please notice, that this is the FINER level and you can read in documentation that entering() and exiting() also log information at FINER level (as I remember). So if I configure to log ALL actions why I cannot enable also logging method invocation with parameter values without additional instrumentation of my source code.

Sorry to say, but look at the logging statements. They are all logged by sun classes. Look at the documentation, and learn how to read the log. The statement:2004-08-10 11:12:53 sun.rmi.server.UnicastRef invokeFINER: main: method: public abstract java.util.Vector sorter.Generator.generate(int) throws java.rmi.RemoteException

Is logged by the class sun.rmi.server.UnicastRef. I.e. sun has logging statements in their code, and that is what you have turned on. So your code hasn't written, or caused anything to be written to the log.

I'm pretty sure that you can't log without adding logging to your code (which an aspect can do)/Kaj

I am just looking around the matter since I am not familiar with logging facility (I have been just learning it since Sunday) - I try log4j but it seems not so powerful as JDK 1.4 logging (by the way it looks as JDK incorporated main concepts from log4j).

It helps me a lot since it means that I need to write a proxy object and instrument code at the proxy level or it means that I should instrument the rmi stubs in order to log parameters or returned values.

Currently I am reading and exercising the AspectJ as you suggested. However, I am not pretty sure if I can use it for RMI applications since AspectJ uses its own compiler. Do you know anything if RMI works fine with AspectJ?

I am just looking around the matter since I am not familiar with logging facility (I have been justlearning it since Sunday) -

Then you still have a lot to learn.

I try log4j but it seems not so powerful as JDK 1.4 logging (by the way itlooks as JDK incorporated main concepts from log4j).

Yes, indeed, log4j is older, and the JDK for logging did borrow liberally from log4j. (Some folks would take offence at your statement that log4j isn't as powerful. They'd argue that the JDK logging facility watered down log4j.)

It helps me a lot since it means that I need to writea proxy object and instrument code at the proxy levelor it means that I should instrument the rmi stubs inorder to log parameters or returned values.

If the Sun classes are putting out logging info, then Sun put the logging statements in there to do it. You can see them at any time by looking at the source code you downloaded with your JDK.

Currently I am reading and exercising the AspectJ asyou suggested. However, I am not pretty sure if I canuse it for RMI applications since AspectJ uses its owncompiler. Do you know anything if RMI works fine withAspectJ?

Since you're writing the RMI classes, I'd say that it'd be easy for you to add logging to your stuff. I'd be surprised if you needed more than that.

My advice would be to learn logging without AspectJ for now. Aspects might be very important someday, but you can solve your fundamental logging problem without it today.

would be if you were concatenating some strings to create a logging message. This can be an expensive operation, especially if your code is peppered with them. Surrounding those cases with this IF test gives the Hotspot compiler a chance to eliminate the operation.

'duffymo': Yes, I can do that but I need as Kaj and you say first to log something i.e. put lines with logger.entering() and logger.exiting(). And I would like not to instrument the source code and I would like to have a log. It means that:

1. I should have an instrumented JVM (but it would be probably much more slower). However, I should do it on my own.

2. I should put log instructions somewhere (to stubs, source code, or proxies, etc.) and then use logging facility supported by JDK 1.4.

As Kaj has said: it is not possible to log without logging.

Concerning log4j, I think that I will be politically correct if I say that log4j is so good that it has been incorporated into official JDK 1.4 release. Make peace not war.

Thanks again Guys. I reward Kaj since (s)he was first who interested in this subject.

'duffymo': Yes, I can do that but I need as Kaj andyou say first to log something i.e. put lines withlogger.entering() and logger.exiting(). And I wouldlike not to instrument the source code and I wouldlike to have a log. It means that:

You have no choice. You have to instrument the source code. Can't have logging without it. Even AspectJ isn't magic that way. You have to tell the JVM where to do it somewhere. All AspectJ does is move it out of your code and into deployment descriptors.

Rod Johnson says that writing a class means instrumenting it for logging. I take that advice to heart. That's what I do from now on.

1. I should have an instrumented JVM (but it would beprobably much more slower). However, I should do iton my own.

But you don't.

2. I should put log instructions somewhere (to stubs,source code, or proxies, etc.) and then use loggingfacility supported by JDK 1.4.

Right.

As Kaj has said: it is not possible to log without logging.

Indeed.

Concerning log4j, I think that I will be politicallycorrect if I say that log4j is so good that it hasbeen incorporated into official JDK 1.4 release. Makepeace not war.

Fine with me. I'm not one of those folks who's upset about log4j. They all work at IBM. ;) I'm just pointing out the history.