On 12/21/05, Ceki Gülcü <[EMAIL PROTECTED]> wrote: > At 09:16 PM 12/20/2005, robert burrell donkin wrote: > >On 12/20/05, Ceki Gülcü <[EMAIL PROTECTED]> wrote: > > > > > how credible are the claims that the problems have been > > > fixed? > > > ><sigh> > > > >please: let's not get personal > > Robert, > > My intention was not to offend you. I am sorry if that was the case.
i'm not offended (just a little tired) the word credible can be interpreted in various ways: JCL is difficult requires eyes to prevent mistakes and i'm touchy about criticism since we've had quite a bit of developer burnout. > > > Would you care to expand on the fixes, alternatively point us > > > to a document describing them? > > > >IIRC brian and simon went through most of them last year whilst you > >were still lurking on list > > According to my understanding, the root causes of the bugs have not > been fixed but their symptoms. More concretely, instead of throwing an > exception, JCL now catches them and defaults to java.util.logging. a primary motivation for not fixing the known problems previously was that it may just be fixing the symptoms. one of the points in spending all those hours analysing the various classloader specifications and calculating the expected behaviour of the possible permutations was to be sure which were symptoms and which were limitations of the dynamic binding design approach. JCL should now be working as well as the limitations of this kind of design can work. some of the expected behaviour is unintuitive but we think is correct as per specification. (if you do have the cycles to spare, i'd be happy for you to check this analysis.) IMO it's very important to distinguish between bugs and limitations imposed by the specifications on dynamic loading. bugs can be fixed. the other kind of limitation can not. by maintaining that a particular behaviour is a bug you imply that some other, better coders could fix it rather than a limitation of the dynamic loading design that can only be fixed by moving to a different design. (as you know) the classloading magick was originally coded by some of the most famous and knowledgable servlet specification gurus on the basis of the revised java 2 classloading recommendations. a design decision was taken that expections would be thrown for various corner cases which should not occur in compliant servlet containers. the major advantage in dynamic binding is that it's possible (with correct configuration) to have the jar in the top level classloader and still achieve the correct classloader isolation. there was a theory that correct isolation for commerical hosting of servlets required exceptions to be thrown for some scenarios to prevent theoretical attacks by servlets upon their hosts. not only is commercial servlet hosting relatively rare but also there are much better ways to execute these attacks then using JCL given a weak sandbox. JCL now adopts a more pragmatic approach. the problems started with the various later J2EE specifications which proposed weak classloading models which are not consistent with the Java 2 recommendations. these conspire to prevent effect reuse of libraries with certain desirable characteristics inside and outside a J2EE container. IMO the inability to simply reuse code inside and outside a J2EE container is a primary weakness of the specification. (those of a cynical disposition may ask whether this is to the advantage of J2EE container vendors.) in particular, singletons are very difficult to reuse correctly in a J2EE environment. craig's per-context-classloader-singleton works well for pure servlet containers but leaks memory when hot re-deployed in a J2EE container. simon's analysis indicates that the J2EE specification does not allow a solution and asked the JCP to consider fixing the J2EE specification to allow better reuse of libraries but there seems little chance of that being adopt nor of the broken classloading specification being fixed. there are consequences for libraries from this understanding and from the understanding of deep java libraries gained bitterly in the commons over the last few years. this has consequences for the way deep libraries should approach logging. deep libraries should really either adopt the policy of not logging or should adopt an IoC logging policy (since IoC is the one of the few patterns which can be safely reused inside and outside a J2EE container). - robert
