cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: svn commit: r312968 - in /cocoon/branches/BRANCH_2_1_X: ./ src/java/org/apache/cocoon/components/source/impl/validity/ src/java/org/apache/cocoon/i18n/ src/java/org/apache/cocoon/transformation/ src/webapp/WEB-INF/ src/webapp/samples/i18n/translations/
Date Mon, 24 Oct 2005 18:19:15 GMT
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>> Vadim Gritsenko wrote:
>>>> - Bad formed XML files and other serious exceptions are 
>>>> semi-silently ignored. By semi-silently, I mean they're just logged 
>>>> and don't bubble up higher in the call stack, thus giving the false 
>>>> impression that the system works.
>>> Such exceptions must not bubble up upstream: if exception is let 
>>> through, your whole site goes down simply due to single bug in i18n 
>>> catalogue. With existing exception handling, i18n (and your whole 
>>> site) continues functioning with older version of the catalogue, but 
>>> reports an error into the log file (that's what you've got 
>>> monitoring for). That's the i18n behaviour as it was originally 
>>> designed. See "Keep existing loaded values" comment.
>> Ok. So you mean that i18n allows broken message files to exist?
> Exactly.

Wow. I really dislike that.

>> This is contradictory with *all* other hot-reload behaviours in 
>> Cocoon: if an XSLT, a template or sitemap are modified and are 
>> malformed, an error is raised and bubbles up (yes, potentially 
>> breaking the whole system). We don't use the cached version of the 
>> file if reload fails.
>> That's why I find the way i18n handles this very strange. Or does it 
>> mean message dictionaries are not considered on an equal stand with 
>> other application files, and are allowed to be buggy and changed live 
>> on the production server without testing beforehand? This really 
>> doesn't sound good to me...
> I guess it takes some getting used to it.

C'mon! What does it mean "getting used to it"? If it's broken, let's fix 
it!! It's too late for 2.1.8, but I'd like this subject to be discussed, 
as it really seems a bad thing to me.


> More general note - ignored exceptions is the single most frustrating 
> experience you can have with Cocoon in particular and Java in general. 
> Hence I'm proponent of having the ability to see exception if so desired.

Me too, but in this particular case, most exceptions will just say that 
the source doesn't exists.

>> SNFE is used here as a substitute for source.exist(), probably 
>> because two implementations don't have a proper implementation for 
>> it. Better fix the implementations or log the exception only if 
>> source.exists() returns true rather than fill the logs with 
>> meaningless exceptions.
> Won't argue with that. OTOH, there might be broken sources out there 
> where even if source.exists() it can still throw SNFE.
> You also have to take into an account a situation where source WAS 
> existing at the moment of .exists(), but was removed before you tried 
> to .getInputStream() it. So, SNFE handling still has to be present.

Ok, so what about :

catch (SNFE snfe) {
    if (!source.exists()) {"bundle " + source.getURI() + " doesn't exist");
    } else {"bundle " + source.getURI() + " is said to exist 
but could not be loaded", sfne);

That way, we avoid logging an exception that just says that the source 
doesn't exist, but still log it whenever there is an inconsistency 
between exists() and getInputStream(), whatever its cause.



Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message