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

Reply via email to