Ard Schrijvers wrote:
> This is actually almost the same "hack" we used, but instead of a transformer
> a selector, and if some value set in flowscript, an action to set headers.
> Because we are outsourcing/other parties using our "best practices", and I
> did not want them to have to think a
Rice Yeh wrote:
Hi,
I am studing the cocoon-rcl-webapp-wrapper. An instance of
URLClassLoader with loading path setting from
/WEB-INF/cocoon/rclwrapper.urlcl.conf (mostly is from local repository)
is passed to as the parent of ReloadingClassLoader constructor in
ReloadingClassloaderManager.
Daniel Fagerstrom napisał(a):
You don't get that part, which show that there is a problem with my
design. I probably mounted the dispatcher servlet at "/*" while
developing the stuff :/ Thinking a little bit more about it, it would
probably better to let the servlet path of the dispatcher servl
Ard Schrijvers wrote:
>
> is there any best practice to have cforms in urls you do not know on
> beforehand, with continuations?
>
Continuation is just randomly generated token, unique to each user
interaction (like as session Id). Even if it is cached, even if GET is used
as a form method, ne
Grzegorz Kossakowski skrev:
Daniel Fagerstrom napisał(a):
Daniel Fagerstrom skrev:
Grzegorz Kossakowski wrote:
Hello,
I'm hacking now ajax and forms block to get them use of
servlet-services
and came across a bug. When you put ${cocoon.request.contextPath} into
JX template it w
Hello,
I asked this page on the cocoon users list, but haven't received an
answer, so am bringing it to the dev list (it is relevant to dev).
The doc page for Web Services Proxy,
http://cocoon.apache.org/2.1/userdocs/wsproxy-generator.html, says
"If the remote site requires authentication,
Server is slightly overloaded (80% CPU average, Robot is crawling Internet,
addind >5 of new products daily), but HTTPD works fine...
www.tokenizer.org
please do not reload it;)
I'll check it from behind-corporate-proxy today.
Also I need to test that cache is not shared (still...) between work
Sometimes (only sometimes!) HTTPD forwards requests "If-Modified-Since" from
Internet Explorer to Cocoon. Without 304 we will never have cache!
When I say "sometimes" I mean that few different caches exists at HTTPD,
per-process. We may have 32 processes, 128 threads each, total: 32 caches
with m
Hi,
I created simple class (additionally to existing HttpCacheAction.
I am using also simple JavaScript which generates 304 (don't know Cocoon
in-depth yet...)
The rest: HTTPD uses _few_ multithreaded processes (worker model), and few
per-process instances of cache (It was true with v.2.0.44, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 27 Jan 2007, Jorg Heymans wrote:
Date: Sat, 27 Jan 2007 15:39:02 +0100
From: Jorg Heymans <[EMAIL PROTECTED]>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: Hardcoded artifact versions (was Re: Multiple local snapshot
On 1/29/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
>... https://issues.apache.org/jira/browse/COCOON-1619 also plays a role in
> this, as headers set by internal pipelines are ignored.
Yes, this is kind of a bummer indeed, which I already knew, but do you regard
it as a bug (aah reading the
Hello Bertrand,
>
> > For high-traffic sites, we obviously want to use mod_cache,
> but, at the same time,
> > mod_cache shouldn't cache pages with a continuation in it
>
> The problem is making the HTTP cache headers variable according to
> which pipeline is executed.
>
> But, in principl
Daniel Fagerstrom napisał(a):
> Daniel Fagerstrom skrev:
>> Grzegorz Kossakowski wrote:
>>> Hello,
>>>
>>> I'm hacking now ajax and forms block to get them use of
>>> servlet-services
>>> and came across a bug. When you put ${cocoon.request.contextPath} into
>>> JX template it will always return nu
On 1/29/07, Ard Schrijvers <[EMAIL PROTECTED]> wrote:
For high-traffic sites, we obviously want to use mod_cache, but, at the same
time,
mod_cache shouldn't cache pages with a continuation in it
The problem is making the HTTP cache headers variable according to
which pipeline is executed.
[
https://issues.apache.org/jira/browse/COCOON-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468210
]
Grzegorz Kossakowski (aka g[R]eK) commented on COCOON-1990:
---
I couldn't reproduce this iss
Daniel Fagerstrom skrev:
Grzegorz Kossakowski wrote:
Hello,
I'm hacking now ajax and forms block to get them use of servlet-services
and came across a bug. When you put ${cocoon.request.contextPath} into
JX template it will always return null (at least while using servlet
dispatcher). However,
Hello,
now we are talking about httpd mod_cache already, is there any best practice to
have cforms in urls you do not know on beforehand, with continuations? For
high-traffic sites, we obviously want to use mod_cache, but, at the same time,
mod_cache shouldn't cache pages with a continuation in
17 matches
Mail list logo
