An object's type is in fact not only its class name, but a combination of its class name and the class loader from which the class was loaded. Note that class loaders can be heirarchical, but if classloader A delegates the loading of a class to classloader B, the class is considered loaded from classloader B.
Now, the classloader chosen when you refer to a class by name is the class loader of the current class. So in
class Bar
{
public void someFunction (Object obj)
{
if (obj instanceof FooClass)
{
...
}
}
}we are comparing obj.getClass () to Bar.class.getClassLoader ().loadClass ("FooClass").
If obj was an instance of "FooClass" instantiated using the class definition from a different classloader, then this won't work.
The reason for this kind of behavior is that you can load two different versions of the same class for example (or two completely different classes of the same name) within two different classloaders without them conflicting. Also, static variables are specific only to the actual class instance, therefore if the same class has been loaded in two different classloaders, each one will have its own instances of static members.
That's why, for example, two different web apps can be loaded into tomcat with different versions of the same library and not conflict.
Now you understand why it's evil to keep your jars in two places.
Cheers,
Erik
Shapira, Yoav wrote:
Howdy,
As I didn't build the project, I am not so familiar with it and Icouldn't
avoid to put some of the classes in several places (server, common,
shared, WEB-INF of my apps....).
Don't do this, as it can lead to unpredictable classloading errors.
Keep everything you can in WEB-INF/lib, the rest in common/lib, but no
jar should be in both places. And you probably don't need to put
anything at all of yours in the server classloader directories.
Callback callback = getTheCallBackObject();the
if(callback instanceof ApplicationCallback) { ((ApplicationCallback) callback).doSomething(); }
When I debug this part, the expression 'callback instanceof
ApplicationCallback' is true, nevertheless if I step once, the code in
if block is not executed !!!
If the doSomething is not executed, how do you know if clause evaluates to true? From the debugger I suppose?
You can also try the other way around, callback.getClass().isAssignableFrom(ApplicationCallback.class), to see what would happen.
Has anybody experienced this kind of weird behaviour?
Strange. I think I've had that happen once or twice, but I can't recall
the solution ;(
Yoav Shapira
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- http://www.spectacle.ca/ The New Online Source for Live Music in Montreal .::514.286.1699::.
