[logback-dev] I don't understand ClassPackagingDataCalculator :p

[Joern Huxhorn]

Ceki Gulcu wrote:
> Thorbjørn Ravn Andersen wrote:
>   
>> Ceki Gulcu skrev:
>>     
>>> classloaders. Sun's internal API is used to determine with *certainty* the class 
>>> which corresponds to the class in the stack frame.
>>>   
>>>       
>> If you use Sun internal API's it most likely does not work on non-Sun 
>> JVM's.   That might not be what you want to do.
>>     
>
> Good point. However, I tested with IBM's JDK and BEA's jrockit. It seems to work 
> fine.
>
>   
Ah, ok. I think I see...

It's because otherwise Class.forName, called from inside the Logger,
would use the Loggers ClassLoader to load the class in question. And
since the Logger class might be loaded by a container this could result
in wrong version information, right?

Did this problem actually happen or is this a precaution? Shouldn't e.g.
web-applications always execute in an isolated manner?
That's my experience, at least, because otherwise a logback
configuration in one webapp would overwrite that of another one,
wouldn't it?

Concerning the use of the internal class, it's really quite unfortunate
that functionality like this isn't somehow accessible.
Similar functionality is available in
private static native Class[] ResourceBundle.getClassContext()
so that method, in combination with setAccessible(true), could be used
as an alternative to
public static native Class Reflection.getCallerClass(int i);
but it's just choosing between two evils.

The most secure solution would probably be to first try to call
sun.reflect.Reflection.getCallerClass
using reflection so it's possible to catch Exception if the class or
method isn't available (anymore).

If that doesn't work you could try, again using reflection, to retrieve
the ResourceBundle and make that method accessible. This can fail
because of security exception or if the internals of ResourceBundle change.
In that case it just isn't possible to resolve really correct ClassLoader.

All this reflection would only need to be done once statically in
ClassPackagingDataCalculator so the performance impact should be nearly
zero.

I guess that the method in Reflection is maybe faster since it only
returns a single class instead of an array containing all classes in the
call stack so I would keep using that as long as it's possible.

Regards, Joern.