DO NOT REPLY [Bug 25879] - directory generator caching bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879

directory generator caching bug





--- Additional Comments From [EMAIL PROTECTED]  2004-01-04 04:28 ---
If you've added a file to the directory, directory's modification time should
change and this should invalidate cache entry. Can you verify that directory
generator's validity includes modification time of the directories?

[Bug?] absolute redirection in flow appears not to be proxy safe

[Stefano Mazzocchi]

I came across a very weird problem today. I had two cocoon applications 
that were once running in different JVM instances, both mapped to / and 
I moved them into a single Jetty instance mapped on /A and /B (for 
simplicity).

Then I modified the ProxyPass settings and used the jetty web.xml trick 
to change the cookie path.

Now, the interesting thing was that while /A performed just like 
before, /B had a wierd problem: "redirects" were absolute to the 
"webapp server", not to the "web server".

Both apps had the same exact version of cocoon (compiled this morning).

After careful examination and extensive protocol dump, I was able to 
understand that while /A used

 cocoon.redirectTo(../../index);

/B used

 cocoon.redirectTo(/index);

and both turn up to the in the same position, but while the first 
actually works (the redirect is "remapped" to the original Proxy URL, 
not to the appserver one which is obviously firewalled), the second 
doesn't do remapping and the web application fails because it tries to 
connect to the webapp directly

[actually it's even worse, because it tries to connect to the ProxyPass 
setting, which are http://localhost:8000/ in my case, so it tries to 
connect to *your* machine!]

The interesting thing is that this worked perfectly in the past, when 
both were mapped to /, but I can't tell what broke since I moved them 
*and* change the version of cocoon at the same time.

Did anybody experience a similar behavior?

--
Stefano.

DO NOT REPLY [Bug 25879] New: - directory generator caching bug

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25879

directory generator caching bug

   Summary: directory generator caching bug
   Product: Cocoon 2
   Version: 2.1.2
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: sitemap components
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Cache validation of DirectoryGenerator seems not to check if there are any new
files in the directory.
If you add new file to directory DirectoryGenerator [with caching] would never
noticed that, as if there wouldn't be any new files.

Re: Saxon as the default XSLT procesor

[J.Pietschmann]

Nicola Ken Barozzi wrote:
document() calls in the style sheet,
There are. I'm gonna remove them soon, nut for now they are there, and 
will the possibility to use them will remain some time for backward compat.

because at least in the Cocoon releases I used it gets passed
null as Source quite often for no obvious reason.
Wierd...

I think it's a Cocoon bug. The first invocation of the pipeline is ok,
but in followup incovations the XSLT processor often gets a null
SourceResolver (not Source, sorry). Xalan uses its own URIResolver in
this case, while Saxon (6.x series) takes it literally. That's one
of the dark corners of the TrAX spec, I couldn't find any regulations
guiding the behaviour.
The null is not a MT problem, it happens even for low load. I think
it has something to do with incorrect re-initialization of the pipeline
after the SourceResolver has been recycled and the reference had been
nulled.
Given the added problem that document() referenced stuff doesn't influence
cache validity, I switched to aggregation. If the document() gets the
URI from source XML, this can be painful (XSLT to an XInclude source,
then Xinclude, the the final XSLT instead of just one XSLT). The worst
thing is that you can't easily test the XSLT any longer with command
line tools, even though none of the dynamic features (like cocoon: URIS)
are used. If you've to ftp the damn sources to the app server, this really
slows down development :-/ .
J.Pietschmann

Re: Saxon as the default XSLT procesor

[Nicola Ken Barozzi]

J.Pietschmann wrote:
Nicola Ken Barozzi wrote:

But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(
That's not unusual. Did you use the most recent Cocoon?
Almost. It's some quite recent dev version.

I suppose there are no document() calls in the style sheet,
There are. I'm gonna remove them soon, nut for now they are there, and 
will the possibility to use them will remain some time for backward compat.

because at least in the Cocoon releases I used it gets passed
null as Source quite often for no obvious reason. Xalan tends
to ignore this, while Saxon barfs.
Wierd...

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-

Re: Saxon as the default XSLT procesor

[J.Pietschmann]

Nicola Ken Barozzi wrote:
But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(
That's not unusual. Did you use the most recent Cocoon?

I suppose there are no document() calls in the style sheet,
because at least in the Cocoon releases I used it gets passed
null as Source quite often for no obvious reason. Xalan tends
to ignore this, while Saxon barfs.
J.Pietschmann

Re: Saxon as the default XSLT procesor

[Nicola Ken Barozzi]

Stefano Mazzocchi wrote:
...
I've done some tests on my machine using the XSLTBench and here is what 
I got:

Saxon 6.5.3 -> 49.52
XalanJ 2.5.2 > 19.89
couldn't test XSLTC

So, +1 to change to Saxon.
I'm +1 to change to anything compatible that is faster than Xalan.

But... I swapped Xalan with Saxon 6.5.3 in Forrest and I get a NPE :-(

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-