Grzegorz Kossakowski schrieb:
No, you don't necessarily see the exception, in the end you get an empty
response and this gives a new exception, the well-known "Premature end
of file". Any exception in the called block must be passed through,
otherwise you never see what you were doing wrong in your "backend"
sitemap. Had a lot of problems with that when exceptions were swallowed
in the first blocks-fw implementation.
I don't agree with this one. AFAIK, in servlet-service-fw implementation
exception are passed back to the calling sitemap. It was you who
provided a patch: https://issues.apache.org/jira/browse/COCOON-1954 :-)
Yes, but the exception gets lost in isValid() and in my case it is not
re-generated or something, the result is just an empty response.
I have seen you tried to fix the getValidity() method like this:
public SourceValidity getValidity() {
- return this.validity;
+ try {
+ connect();
+ } catch (Exception e) {
+ if (logger.isDebugEnabled())
+ logger.debug("Exception occured while making servlet
request", e);
+ return null;
+ }
+ return servletConnection.getLastModified() > 0 ? this.validity
: null;
}
This cannot work, since you cannot call connect() before you have the value
for If-Modified-Since which is only available in isValid(SourceValidity)
when both validities are available! I was first thinking about the same
solution but then understood why your original code with the connect inside
isValid is right!
Alex
--
Alexander Klimetschek
http://www.mindquarry.com