<snip>
> >
> > My mistake the other day does show one
> > area where WeakHashtable will fail -- if a custom
> > subclass of LogFactory were deployed in
> WEB-INF/lib
> > but commons-logging.jar were on the server
> classpath.
> > But I expect that's a pretty small use case.
>
> i suspect this extends to pretty much anyone who
> uses a custom
> LogFactory implementation where commons-logging is
> in a parent
> classloader and the implementation is deployed in
> the child.
>
Yep.
> custom LogFactory implementations are not very
> useful at the moment and
> so i'd be happy just to live with a note in the
> documentation about
> this limitation.
>
Sounds good. I'll put some thought to a good note,
although it might be a few days. Were you thinking in
the Javadoc, or somewhere else?
> in addition, this use case will be addressed very
> well by the bytecode
> stuff. (the idea is that instead of discovering a
> log factory at
> runtime, all the calls will be rewired when the
> classes are enhanced.)
> if you're deploying a stand alone web-app with a
> definite need to use a
> particular LogFactory, it's more reliable to dope
> all the jar's than to
> rely on discovery.
>
> i'll look forward to see your patch (either i've
> missed it, i'm
> confused or it was stripped this time...)
>
Don't know what happened. Late night gremlins. When
I get home (prob 8 hours from now) I'll attach it to
Bugzilla.
> i'll leave my tidy up for a few days (give you a
> chance to get patching
> without me treading on your toes). once everyone's
> happy with the
> class, i plan to start pushing towards a 1.0.5
> release. it'll probably
> be release from a branch so that the release
> candidate for long enough.
>
Great. Thanks for everything.
Brian
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
