On Mon, Feb 21, 2005 at 11:21:01AM -0800, Oleg wrote: : Well regarding #1 from what I understand the class in webapp web-inf : will take priority, however, I can see how #2 can be a problem, but, : does it only work one way? Meaning a class in sared/classes will not : see webapp/web-inf/classes, so down the hierarchy, however, it will : work just fine going up, so class in webapp will see classes in : shared?
Correct -- the per-webapp classloader is the child of the shared/lib classloader. (This is an oversimplification but please bear with me.) Really, there are more than two classloaders involved, forming several parent/child relationships in a hierarchy... Try to think of it as the GoF Chain of Responsiblity pattern: when the per-webapp classloader can't find a class, it delegates (passes the request) to its parent. This keeps going until you hit a classloader that can successfully load the class, or until the innermost classloader -- which doesn't delegate to anyone else -- gives up and says there's no such class. Going the other way thus isn't possible: that innermost (parent) classloader can't see what its children see, and so on. If a class under shared/lib needs access to (depends on) a class in a child classloader, it will never find it, and the system throws a NoClassDefFoundError. It's for a similar reason one webapp can't see another webapp's classes: they only have a relationship with their parent classloader, and not that of their siblings. -QM --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
