axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Problems with commons-logging - Very interesting
Date Wed, 21 Dec 2005 10:28:02 GMT
On 12/21/05, Ceki Gülcü <> wrote:
> At 09:16 PM 12/20/2005, robert burrell donkin wrote:
> >On 12/20/05, Ceki Gülcü <> 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

View raw message