Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
<snip/>
- 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.
<snip/>
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()) {
getLogger.info("bundle " + source.getURI() + " doesn't exist");
} else {
getLogger.info("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.
Deal?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
