Grzegorz Kossakowski schrieb:
Why not earlier? This way I'd be able to help with this issues. Now it is not
possible because I cannot reproduce most of your problems.
Sorry, I understand, but it's kinda difficult to strip down those sitemaps
and set them up in a new context like the servlet-service-samples.
1) Last-Modified header set to -1 instead of skipping it (my last mail)
Couldn't reproduce. I also think that this should not harm even though it's not
valid to set Last-Modified header to -1. What kind of
problem this behavior causes for you?
As described in my last mails: having a last-modified of -1 and comparing it
with a if-modified-since of -1 (aka both are unknown, no caching should be
tried at all) you get a not-modified result because of the following line in
HttpEnvironment.isResponseModified():
return (if_modified_since / 1000 < lastModified / 1000);
which results in -1/1000 == -1/1000 => response is *not* modified. This is
wrong, since two -1 values mean that there is nothing known about
modification timestamps, so it should retrieve the full content.
2) Equal URIs in different blocks make the first request return an empty
response. Looks like the resource is in cache because of the same URI
but cannot be retrieved, thus empty response. On second attempt the
cache is filled with data. (I haven't been able to debug that
specifically, so maybe I am not correct here)
Yes, I agree that this can be a problem and should be fixed ASAP.
I fixed it by introducing servlet:<bean-name>:/foo/bar globally unique URLs,
at least when a local servlet call is made (ie. servlet:/foo/bar).
servlet:super:/ and servlet:something:/ stay unmodified (maybe these have to
be tweaked as well to solve my last unresolved exception).
3) When introducing globally unique URIs in ServletSource.getURI() with
a non-resolvable scheme (eg.
servlet:com.mycompany.myservlet-bean-id:/foobar) this will make any
relative resolving of resources fail. Eg. XSLT <include> or <import>
statements work by taking Source.getURI() as base path for the relative
path and then resolve this new included source in a normal way. Thus
things returned by Source.getURI() *must* be resolvable!
I see. It sounds reasonable. We'll have to think how to implement this (should
not be that hard).
I implemented this in ServletServiceContext.getNamedContext() by looking up
servlet:<bean-name>: as well via Spring's application context. So the URLs
in 2) become actually resolvable.
4) ServletSource.ServletValidity.isValid(SourceValidity) swallows
exceptions thrown in connect, thus any ProcessingExceptions in the
called block. It simply returns UNKNOWN validity status and one gets an
empty response without knowing that an exception was a reason for this.
Thanks for spotting it. I committed logging of this exceptions.
However, I cannot understand how you get empty response. If validity is unknown
the resource should be retrieved from original source.
Second request should occur and if exception still occurs it would be passed
down the processing instead of being swallowed.
What I'm lacking?
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 have fixes for all of this, unfortunately I still get an exception via
4) that I cannot explain. It's the same old
"org.xml.sax.SAXParseException: Premature end of file" because of an
empty response. :-(
I suspect that all this problems are caused by one (or two) obscure bugs that
make parts going crazy.
Yes, but still looking for it. My cocoon code is now full of
System.out.println() statements ;-)
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
