Re: Caching problem?
Ok, thanks for the heads-up, I added it to the constraint.
Nathan
On 30/06/16 17:10, Chris Poulsen wrote:
btw the modules path can be both "modules" and "modules.gz" depending
on various things.
On Thu, Jun 30, 2016 at 4:35 PM, Nathan Quirynen
mailto:nat...@pensionarchitects.be>> wrote:
Hey Chris,
Yeah, that's the only option I've found until now using following
check as you said:
if( ! (path.startsWith("/assets/") ||
path.startsWith("/modules.gz/")) ) {
// add headers
}
Hope I got everything covered by this, but it's at least an
improvement as how it was before (caching was turned off for
everything) and the problem I had with that one asset seems to be
solved (still don't really get what was happening there though).
Thanks for your thoughts!
Nathan
On 30/06/16 15:56, Chris Poulsen wrote:
check the path? (asset paths usually contains "/asset/" and
module paths
contains "/modules/")
On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
nat...@pensionarchitects.be
> wrote:
Is there any way to know in a Request filter if it is a
page request (not
a request to some asset).
I thought doing the following:
PageRenderRequestParameters parameters =
linkEncoder.decodePageRenderRequest(request);
if (parameters == null) {
// not a page request
}
But it seems that for every request to an asset it is
never null, and
parameters.getLogicalPageName() has the value "Index".
On 29/06/16 18:32, Nathan Quirynen wrote:
I have found that in one of the applications request
filters following is
added to every response:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
On 29/06/16 17:33, Nathan Quirynen wrote:
Hi,
I have a "weird" problem where this one image
won't show up. Never had
this problem before the upgrade to 5.4 and since
there have been changes
with caching, I guess it has something to do with
that.
I don't know a lot about the caching Tapestry does
(or in general), so I
hope someone can point me in the right direction
to find the problem.
After some testing the image does not load when I
use Firefox, unless I
use the reload function of Firefox that overrides
the cache.
The difference I find when using this is in the
request headers (for all
files):
Normal load (image does not show up):
Cache-Control: max-age=0
"Hard" reload (image does show up):
Cache-Control: no-cache
Pragma: no-cache
When inspecting the source code in Firefox, the
url seems correct and
then the image does show up magically.
What could be causing this one file (next to all
the other assets that
were added in the same version) to have this
behaviour? Can this be caused
by Tapestry?
I have tried clearing Firefox's cache, using a
computer that has not
opened the application before and also changing
the version of the
application with no results...
Some pointers are appreciated!
Nathan
-
To unsubscribe, e-mail:
users-unsubscr...@tapestry.apache.org
For additional commands, e-mail:
users-h...@tapestry.apache.org
-
To unsubscribe, e-mail:
users-unsubscr...@tapestry.apache.org
For additional commands, e-mail:
users-h...@tapestry.apache.org
-
To unsubscribe, e-mail:
users-unsubscr...@tapest
Re: Caching problem?
btw the modules path can be both "modules" and "modules.gz" depending on
various things.
On Thu, Jun 30, 2016 at 4:35 PM, Nathan Quirynen <
nat...@pensionarchitects.be> wrote:
> Hey Chris,
>
> Yeah, that's the only option I've found until now using following check as
> you said:
>
> if( ! (path.startsWith("/assets/") || path.startsWith("/modules.gz/")) ) {
>
> // add headers
>
> }
>
> Hope I got everything covered by this, but it's at least an improvement as
> how it was before (caching was turned off for everything) and the problem I
> had with that one asset seems to be solved (still don't really get what was
> happening there though).
>
> Thanks for your thoughts!
>
> Nathan
>
>
>
> On 30/06/16 15:56, Chris Poulsen wrote:
>
>> check the path? (asset paths usually contains "/asset/" and module paths
>> contains "/modules/")
>>
>> On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
>> nat...@pensionarchitects.be> wrote:
>>
>> Is there any way to know in a Request filter if it is a page request (not
>>> a request to some asset).
>>>
>>> I thought doing the following:
>>>
>>> PageRenderRequestParameters parameters =
>>> linkEncoder.decodePageRenderRequest(request);
>>>
>>> if (parameters == null) {
>>>
>>> // not a page request
>>>
>>> }
>>>
>>> But it seems that for every request to an asset it is never null, and
>>> parameters.getLogicalPageName() has the value "Index".
>>>
>>>
>>>
>>> On 29/06/16 18:32, Nathan Quirynen wrote:
>>>
>>> I have found that in one of the applications request filters following is
added to every response:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
On 29/06/16 17:33, Nathan Quirynen wrote:
Hi,
>
> I have a "weird" problem where this one image won't show up. Never had
> this problem before the upgrade to 5.4 and since there have been
> changes
> with caching, I guess it has something to do with that.
> I don't know a lot about the caching Tapestry does (or in general), so
> I
> hope someone can point me in the right direction to find the problem.
>
> After some testing the image does not load when I use Firefox, unless I
> use the reload function of Firefox that overrides the cache.
> The difference I find when using this is in the request headers (for
> all
> files):
>
> Normal load (image does not show up):
>
> Cache-Control: max-age=0
>
> "Hard" reload (image does show up):
>
> Cache-Control: no-cache
> Pragma: no-cache
>
>
> When inspecting the source code in Firefox, the url seems correct and
> then the image does show up magically.
>
> What could be causing this one file (next to all the other assets that
> were added in the same version) to have this behaviour? Can this be
> caused
> by Tapestry?
>
> I have tried clearing Firefox's cache, using a computer that has not
> opened the application before and also changing the version of the
> application with no results...
>
>
> Some pointers are appreciated!
>
>
> Nathan
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
>
> -
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Caching problem?
Hey Chris,
Yeah, that's the only option I've found until now using following check
as you said:
if( ! (path.startsWith("/assets/") || path.startsWith("/modules.gz/")) ) {
// add headers
}
Hope I got everything covered by this, but it's at least an improvement
as how it was before (caching was turned off for everything) and the
problem I had with that one asset seems to be solved (still don't really
get what was happening there though).
Thanks for your thoughts!
Nathan
On 30/06/16 15:56, Chris Poulsen wrote:
check the path? (asset paths usually contains "/asset/" and module paths
contains "/modules/")
On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
nat...@pensionarchitects.be> wrote:
Is there any way to know in a Request filter if it is a page request (not
a request to some asset).
I thought doing the following:
PageRenderRequestParameters parameters =
linkEncoder.decodePageRenderRequest(request);
if (parameters == null) {
// not a page request
}
But it seems that for every request to an asset it is never null, and
parameters.getLogicalPageName() has the value "Index".
On 29/06/16 18:32, Nathan Quirynen wrote:
I have found that in one of the applications request filters following is
added to every response:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
On 29/06/16 17:33, Nathan Quirynen wrote:
Hi,
I have a "weird" problem where this one image won't show up. Never had
this problem before the upgrade to 5.4 and since there have been changes
with caching, I guess it has something to do with that.
I don't know a lot about the caching Tapestry does (or in general), so I
hope someone can point me in the right direction to find the problem.
After some testing the image does not load when I use Firefox, unless I
use the reload function of Firefox that overrides the cache.
The difference I find when using this is in the request headers (for all
files):
Normal load (image does not show up):
Cache-Control: max-age=0
"Hard" reload (image does show up):
Cache-Control: no-cache
Pragma: no-cache
When inspecting the source code in Firefox, the url seems correct and
then the image does show up magically.
What could be causing this one file (next to all the other assets that
were added in the same version) to have this behaviour? Can this be caused
by Tapestry?
I have tried clearing Firefox's cache, using a computer that has not
opened the application before and also changing the version of the
application with no results...
Some pointers are appreciated!
Nathan
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Caching problem?
check the path? (asset paths usually contains "/asset/" and module paths
contains "/modules/")
On Thu, Jun 30, 2016 at 11:55 AM, Nathan Quirynen <
nat...@pensionarchitects.be> wrote:
> Is there any way to know in a Request filter if it is a page request (not
> a request to some asset).
>
> I thought doing the following:
>
> PageRenderRequestParameters parameters =
> linkEncoder.decodePageRenderRequest(request);
>
> if (parameters == null) {
>
> // not a page request
>
> }
>
> But it seems that for every request to an asset it is never null, and
> parameters.getLogicalPageName() has the value "Index".
>
>
>
> On 29/06/16 18:32, Nathan Quirynen wrote:
>
>> I have found that in one of the applications request filters following is
>> added to every response:
>>
>> Cache-Control: no-cache, no-store, must-revalidate
>>
>> Pragma: no-cache
>>
>>
>> On 29/06/16 17:33, Nathan Quirynen wrote:
>>
>>> Hi,
>>>
>>> I have a "weird" problem where this one image won't show up. Never had
>>> this problem before the upgrade to 5.4 and since there have been changes
>>> with caching, I guess it has something to do with that.
>>> I don't know a lot about the caching Tapestry does (or in general), so I
>>> hope someone can point me in the right direction to find the problem.
>>>
>>> After some testing the image does not load when I use Firefox, unless I
>>> use the reload function of Firefox that overrides the cache.
>>> The difference I find when using this is in the request headers (for all
>>> files):
>>>
>>> Normal load (image does not show up):
>>>
>>> Cache-Control: max-age=0
>>>
>>> "Hard" reload (image does show up):
>>>
>>> Cache-Control: no-cache
>>> Pragma: no-cache
>>>
>>>
>>> When inspecting the source code in Firefox, the url seems correct and
>>> then the image does show up magically.
>>>
>>> What could be causing this one file (next to all the other assets that
>>> were added in the same version) to have this behaviour? Can this be caused
>>> by Tapestry?
>>>
>>> I have tried clearing Firefox's cache, using a computer that has not
>>> opened the application before and also changing the version of the
>>> application with no results...
>>>
>>>
>>> Some pointers are appreciated!
>>>
>>>
>>> Nathan
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: Caching problem?
Is there any way to know in a Request filter if it is a page request
(not a request to some asset).
I thought doing the following:
PageRenderRequestParameters parameters =
linkEncoder.decodePageRenderRequest(request);
if (parameters == null) {
// not a page request
}
But it seems that for every request to an asset it is never null, and
parameters.getLogicalPageName() has the value "Index".
On 29/06/16 18:32, Nathan Quirynen wrote:
I have found that in one of the applications request filters following
is added to every response:
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
On 29/06/16 17:33, Nathan Quirynen wrote:
Hi,
I have a "weird" problem where this one image won't show up. Never
had this problem before the upgrade to 5.4 and since there have been
changes with caching, I guess it has something to do with that.
I don't know a lot about the caching Tapestry does (or in general),
so I hope someone can point me in the right direction to find the
problem.
After some testing the image does not load when I use Firefox, unless
I use the reload function of Firefox that overrides the cache.
The difference I find when using this is in the request headers (for
all files):
Normal load (image does not show up):
Cache-Control: max-age=0
"Hard" reload (image does show up):
Cache-Control: no-cache
Pragma: no-cache
When inspecting the source code in Firefox, the url seems correct and
then the image does show up magically.
What could be causing this one file (next to all the other assets
that were added in the same version) to have this behaviour? Can this
be caused by Tapestry?
I have tried clearing Firefox's cache, using a computer that has not
opened the application before and also changing the version of the
application with no results...
Some pointers are appreciated!
Nathan
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Caching problem?
I have found that in one of the applications request filters following is added to every response: Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache On 29/06/16 17:33, Nathan Quirynen wrote: Hi, I have a "weird" problem where this one image won't show up. Never had this problem before the upgrade to 5.4 and since there have been changes with caching, I guess it has something to do with that. I don't know a lot about the caching Tapestry does (or in general), so I hope someone can point me in the right direction to find the problem. After some testing the image does not load when I use Firefox, unless I use the reload function of Firefox that overrides the cache. The difference I find when using this is in the request headers (for all files): Normal load (image does not show up): Cache-Control: max-age=0 "Hard" reload (image does show up): Cache-Control: no-cache Pragma: no-cache When inspecting the source code in Firefox, the url seems correct and then the image does show up magically. What could be causing this one file (next to all the other assets that were added in the same version) to have this behaviour? Can this be caused by Tapestry? I have tried clearing Firefox's cache, using a computer that has not opened the application before and also changing the version of the application with no results... Some pointers are appreciated! Nathan - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Caching problem?
Hi, I have a "weird" problem where this one image won't show up. Never had this problem before the upgrade to 5.4 and since there have been changes with caching, I guess it has something to do with that. I don't know a lot about the caching Tapestry does (or in general), so I hope someone can point me in the right direction to find the problem. After some testing the image does not load when I use Firefox, unless I use the reload function of Firefox that overrides the cache. The difference I find when using this is in the request headers (for all files): Normal load (image does not show up): Cache-Control: max-age=0 "Hard" reload (image does show up): Cache-Control: no-cache Pragma: no-cache When inspecting the source code in Firefox, the url seems correct and then the image does show up magically. What could be causing this one file (next to all the other assets that were added in the same version) to have this behaviour? Can this be caused by Tapestry? I have tried clearing Firefox's cache, using a computer that has not opened the application before and also changing the version of the application with no results... Some pointers are appreciated! Nathan - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Unusual caching problem
Thanks for the reply Andy, I found the problem... it was with a service that maintains its own cache that I read and write to, but the cache was not being refreshed. Much appreciated, Peter andyhot wrote: Peter Stavrinides wrote: Hi everyone I have developed an editable table similar to an excel spreadsheet. I use Tapestry 4.1 and a little Javascript to get it to work. when you edit a cell it affects corresponding cells etc just like a spreadsheet. My problem arises when I enable caching on tomcat, it no longer seems to refresh the table and the figures in corresponding cells do not get updated when I edit a cell, whereas in development with caching disabled it works perfectly... I don't even know where to start with this one, so any ideas about what could be going on would be appreciated. Well, it could be that you're incorrectly using lots of instance fields in your component class. In dev mode (caching disabled) they're always cleared, while in prod mode (caching enable) where component instances are reused you have to either clear them yourself, or allow tapestry to manage them (by using abstract getters and setters instead) Thanks Peter -- Peter Stavrinides Albourne Partners (Cyprus) Ltd Tel: +357 22 750652 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unusual caching problem
Peter Stavrinides wrote: Hi everyone I have developed an editable table similar to an excel spreadsheet. I use Tapestry 4.1 and a little Javascript to get it to work. when you edit a cell it affects corresponding cells etc just like a spreadsheet. My problem arises when I enable caching on tomcat, it no longer seems to refresh the table and the figures in corresponding cells do not get updated when I edit a cell, whereas in development with caching disabled it works perfectly... I don't even know where to start with this one, so any ideas about what could be going on would be appreciated. Well, it could be that you're incorrectly using lots of instance fields in your component class. In dev mode (caching disabled) they're always cleared, while in prod mode (caching enable) where component instances are reused you have to either clear them yourself, or allow tapestry to manage them (by using abstract getters and setters instead) Thanks Peter -- Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unusual caching problem
Hi everyone I have developed an editable table similar to an excel spreadsheet. I use Tapestry 4.1 and a little Javascript to get it to work. when you edit a cell it affects corresponding cells etc just like a spreadsheet. My problem arises when I enable caching on tomcat, it no longer seems to refresh the table and the figures in corresponding cells do not get updated when I edit a cell, whereas in development with caching disabled it works perfectly... I don't even know where to start with this one, so any ideas about what could be going on would be appreciated. Thanks Peter -- Peter Stavrinides Albourne Partners (Cyprus) Ltd Tel: +357 22 750652 If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javascript caching problem
Did you turn on caching in Tomcat? -Dorg.apache.tapestry.disable-caching=true On 9/14/06, Peter Dawn <[EMAIL PROTECTED]> wrote: guys, does tap3 have a javascript caching problem. i have begun to notice that my changes dont reflect within my application once i compile it. but if i restart tomcat it shows up. i havent noticed this before. has anybody else experienced this problem before. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Javascript caching problem
guys, does tap3 have a javascript caching problem. i have begun to notice that my changes dont reflect within my application once i compile it. but if i restart tomcat it shows up. i havent noticed this before. has anybody else experienced this problem before. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
