james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JSieve] Sporadic Mysterious Exceptions
Date Sat, 11 Aug 2007 07:59:40 GMT
On 8/10/07, Steve Brewin <sbrewin@synsys.com> wrote:
> Hi Guys

hi steve

> +1 to using DI, -1 to static initializers for anything other than types
> without dependencies, for example, primitives and Strings.

in general, i agree

in this case, though, the possibility of a 0.2 release needs to be considered

> To be fair, the lunatic (me) that originally wrote this stuff did say (in a
> post or jira, I can't remember which) that this was a proof of concept which
> should be refactored to use injection and was at best alpha. To be honest,
> I'm astounded that it has stood up as well as it has.
> As to the synchronization issues, the lazy initialization pattern (that
> Stefano so loves) is not an accident. The intent is that in deployments
> where synchronization is required, you subclass to add synchronization,
> normally just on the getter method. In single threaded or per thread
> environments, the vanilla code is just fine. I hate synchronization being
> imposed when it is not required. Similairly, if you want to avoid lazy
> initialisation with this pattern, you just invoke the getter earlier, such
> as in the constructor of the using class. Just please not in a static
> initialiser which is invoked when the class is loaded, which occurs who
> knows when!

mostly in agreement

> I can't claim I applied these rules in the initial drop of jSieve. I never
> explored the areas requiring synchronization. Good luck with this :)
> Anyway, thanks to all of you for taking this on and cleaning it up.
> Unfortunately, I've way too many other commitments to get involved beyond
> the occasional (worthless?) post.

it's always good to hear from you :-)

i'd like to be able to cut a 0.2 release sometime soon.

though static initialisers worry me too, creating a ThreadLocal
instance is relatively low risk. if i were to refactoring the code
base to introduce IoC, there's a definite risk that i'll break
something. i would prefer to release a patched up version of the
current code base (including the static initialiser i introduced to
fix the null pointer bug) and then refactor trunk towards IoC.

i agree that this needs to be fixed properly before a 1.0 release, though.

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message