On Fri, 2005-01-28 at 20:15, Richard Sitze wrote: hi richard
(apologies for the delay: machine problems) > I'd like to begin to identify the ClassLoader problems with the > current JCL discovery mechanism. If you are aware of additional > issues, please respond and let's get them all out on the table. setting aside bugs and environments where discovery is not going to work (for example, untrusted applets), i think your analysis has captured everything. > I believe the following two scenarios summarize the specific issues, > as well as more general problems. > > A. Parent / Child ClassLoaders, General <snip> > B. Parent / Child ClassLoaders, Child does not defer to Parent first. <snip> > C. Host / Sub <snip> > SUMMARY of PROBLEM: > > There are ONE general problem at work here: > - Disrespect for proper ISOLATION as defined by ClassLoaders > > The fundamental problem is dealing with the thread context classloader > in [common] situations where it represents an "isolated" or > "isolating" mechanism. For scenario A, we are simply loading > when we should be. For scenario B, by setting "child first" > search behavior, we are granting the child a degree of independence. > For scenario C, by creating a Sub that isn't related to the > "parent" at all. > > In both cases, JCL behavior incorrectly *assumes* that a more > traditional "Parent/Child" relationship exists with the thread context > classloader. > > While the current mechanism *is* generally useful, I'm realizing > that we've only addressed one corner case, and have broken other > *very* reasonable classloader configurations. +1 > WHAT CAN BE DONE: > > - For A.1, For auto configuration of for predefined wrapper impls, > any "impl" class should be located using the ClassLoader of the > wrapper, never the thread context class loader. +1 > Detect "independent" thread context class loaders and respect the > boundries. By independent, I mean any classloader that gives > preference to it's own "internal" classes. > > - The trivial case is a thread context class loader that doesn't > include the current ClassLoader [used to load 'this' class, i.e. > LogFactory] in it's hierarchy. In this case, the discovery > mechanism simply has *NO* business crossing the boundry, it should > revert back to using the ClassLoader used to load the [currently > executing] LogFactory. This should cover scenario C. > > - Scenario B is a bit more difficult to resolve. > > For B.1, the child "resource manager" [LogFactory] is in > control. We can presume during discovery that we should NOT > look any higher up the hierarchy than the level at which our > interface [Log or LogFactory] was discovered for configuration > or implementation resources. [various games can be played > to determine which loader in a hierarchy was used to obtain > any particular resource]. > > For B.2, the parent "resouce manager" [LogFactory] is in > control. We can "check" by requesting our base interface [Log or > LogFactory] from the thread context class loader. If the class > returned is not the same as what we have in the Parent, then > we should treat this as the trivial case: use the LogFactory > classloader and do not cross that boundry. i think that this last paragraph is the key: the acid test for compatibility is whether the Log class loaded by the context class loader is the same as the Log class loaded by the LogFactory loader. when this test fails, it is appropriate to use the classloader used to load LogFactory. i can't think of any use cases which work now which would be broken by changing the code to respect the classloader boundaries in this fashion. can anyone else? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
