Re: ChecksumPath exception on unexistent assets
Hi Ben, thank you for the commit. Cheers, Bob Roberto Marotta D.B.M. Srl Via Enrico Noe, 23 20133 Milano Tel. 02.26.60.05.21 - Original Message - From: "Ben Weidig" To: "Tapestry users" Sent: Monday, 9 May, 2022 5:56:47 PM Subject: Re: ChecksumPath exception on unexistent assets Hi Bob, thanks for the patch! I've changed it to an early return to don't check for -1 again, and added some tests. https://github.com/apache/tapestry-5/commit/b01906961a456656404fc2bc9d85ea2aeff10c53 Cheers, Ben On Mon, May 9, 2022 at 3:57 PM Roberto wrote: > Hi Ben, > > a possible solution for TAP5-2713 (ChecksumPath: > java.lang.StringIndexOutOfBoundsException) ticket could be this: > > In 'ChecksumPath' method only check 'slashx' variable and if it is -1 > return NON_EXISTING_RESOURCE, otherwise it executes the normal code. > > The patch is in attached. > > Regards, > Bob > > Roberto Marotta > D.B.M. Srl > Via Enrico Noe, 23 > 20133 Milano > Tel. 02.26.60.05.21 > > > -- > *From: *"Ben Weidig" > *To: *"Tapestry users" > *Sent: *Monday, 28 March, 2022 4:30:28 PM > *Subject: *Re: ChecksumPath exception on unexistent assets > > Hi Bob, > > thanks for informing us about the exception on non-existant resources, > I've created an issue: https://issues.apache.org/jira/browse/TAP5-2713 and > will take a look. > > Cheers, > Ben > > > On Mon, Mar 28, 2022 at 4:15 PM Roberto wrote: > > > > > > > Hi, > > > > It appears that the > > "org.apache.tapestry5.internal.services.assets.ChecksumPath" class throws > > exception > > like "String index out of range: -1" when trying to apply substring > > function on unexistent resource path. > > Maybe throwing an exception like "404 code error and resource not found" > > would be more convenient. > > > > kind regards > > bob > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ChecksumPath exception on unexistent assets
Hi Bob, thanks for the patch! I've changed it to an early return to don't check for -1 again, and added some tests. https://github.com/apache/tapestry-5/commit/b01906961a456656404fc2bc9d85ea2aeff10c53 Cheers, Ben On Mon, May 9, 2022 at 3:57 PM Roberto wrote: > Hi Ben, > > a possible solution for TAP5-2713 (ChecksumPath: > java.lang.StringIndexOutOfBoundsException) ticket could be this: > > In 'ChecksumPath' method only check 'slashx' variable and if it is -1 > return NON_EXISTING_RESOURCE, otherwise it executes the normal code. > > The patch is in attached. > > Regards, > Bob > > Roberto Marotta > D.B.M. Srl > Via Enrico Noe, 23 > 20133 Milano > Tel. 02.26.60.05.21 > > > -- > *From: *"Ben Weidig" > *To: *"Tapestry users" > *Sent: *Monday, 28 March, 2022 4:30:28 PM > *Subject: *Re: ChecksumPath exception on unexistent assets > > Hi Bob, > > thanks for informing us about the exception on non-existant resources, > I've created an issue: https://issues.apache.org/jira/browse/TAP5-2713 and > will take a look. > > Cheers, > Ben > > > On Mon, Mar 28, 2022 at 4:15 PM Roberto wrote: > > > > > > > Hi, > > > > It appears that the > > "org.apache.tapestry5.internal.services.assets.ChecksumPath" class throws > > exception > > like "String index out of range: -1" when trying to apply substring > > function on unexistent resource path. > > Maybe throwing an exception like "404 code error and resource not found" > > would be more convenient. > > > > kind regards > > bob > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ChecksumPath exception on unexistent assets
Hi Ben,
a possible solution for TAP5-2713 (ChecksumPath:
java.lang.StringIndexOutOfBoundsException) ticket could be this:
In 'ChecksumPath' method only check 'slashx' variable and if it is -1 return
NON_EXISTING_RESOURCE, otherwise it executes the normal code.
The patch is in attached.
Regards,
Bob
Roberto Marotta
D.B.M. Srl
Via Enrico Noe, 23
20133 Milano
Tel. 02.26.60.05.21
- Original Message -
From: "Ben Weidig"
To: "Tapestry users"
Sent: Monday, 28 March, 2022 4:30:28 PM
Subject: Re: ChecksumPath exception on unexistent assets
Hi Bob,
thanks for informing us about the exception on non-existant resources,
I've created an issue: https://issues.apache.org/jira/browse/TAP5-2713 and
will take a look.
Cheers,
Ben
On Mon, Mar 28, 2022 at 4:15 PM Roberto wrote:
>
>
> Hi,
>
> It appears that the
> "org.apache.tapestry5.internal.services.assets.ChecksumPath" class throws
> exception
> like "String index out of range: -1" when trying to apply substring
> function on unexistent resource path.
> Maybe throwing an exception like "404 code error and resource not found"
> would be more convenient.
>
> kind regards
> bob
>
>
>
From 398421cb4692e3c9501e7cf58bf1632e120843d6 Mon Sep 17 00:00:00 2001
From: roberto
Date: Fri, 15 Apr 2022 11:56:37 +0200
Subject: [PATCH] TAP5-2713: ChecksumPath:
java.lang.StringIndexOutOfBoundsException
Detection slash might throw an StringIndexOutOfBounds Exception,
this mean that resource doesn't exist and it must respond with a
404 error status code
---
.../services/assets/ChecksumPath.java | 45 +++
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/assets/ChecksumPath.java b/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/assets/ChecksumPath.java
index 95e907eae..d89933bc2 100644
--- a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/assets/ChecksumPath.java
+++ b/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/assets/ChecksumPath.java
@@ -40,27 +40,34 @@ public class ChecksumPath
this.streamer = streamer;
int slashx = extraPath.indexOf('/');
-checksum = extraPath.substring(0, slashx);
-
-String morePath = extraPath.substring(slashx + 1);
-
-// Slashes at the end of the path should be dropped because
-// they don't make sense. TAP5-2663
-while (morePath.endsWith("/"))
+// Prevent an StringIndexOutOfBoundsException in the case of resource not found. TAP5-2713
+checksum = (slashx != -1) ? extraPath.substring(0, slashx) : "";
+if (slashx != -1)
{
-morePath = morePath.substring(0, morePath.length() - 1);
-}
+ String morePath = extraPath.substring(slashx + 1);
-if (!isBlank(morePath))
-{
-resourcePath = baseFolder == null
-? morePath
-: baseFolder + "/" + morePath;
+ // Slashes at the end of the path should be dropped because
+ // they don't make sense. TAP5-2663
+ while (morePath.endsWith("/"))
+ {
+ morePath = morePath.substring(0, morePath.length() - 1);
+ }
+
+ if (!isBlank(morePath))
+ {
+ resourcePath = baseFolder == null
+ ? morePath
+ : baseFolder + "/" + morePath;
+ }
+ else {
+ // When we only have something which looks like a checksum but no actual path.
+ // For example, /assets/META-INF/
+ resourcePath = NON_EXISTING_RESOURCE;
+ }
}
-else {
-// When we only have something which looks like a checksum but no actual path.
-// For example, /assets/META-INF/
-resourcePath = NON_EXISTING_RESOURCE;
+else
+{
+ resourcePath = NON_EXISTING_RESOURCE;
}
}
@@ -83,7 +90,7 @@ public class ChecksumPath
return streamer.streamResource(resource, checksum, ResourceStreamer.DEFAULT_OPTIONS);
}
-
+
/**
* Copied from StringUtils since it's the only method we want from it.
*/
--
2.24.4
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: ChecksumPath exception on unexistent assets
Hi Bob, thanks for informing us about the exception on non-existant resources, I've created an issue: https://issues.apache.org/jira/browse/TAP5-2713 and will take a look. Cheers, Ben On Mon, Mar 28, 2022 at 4:15 PM Roberto wrote: > > > Hi, > > It appears that the > "org.apache.tapestry5.internal.services.assets.ChecksumPath" class throws > exception > like "String index out of range: -1" when trying to apply substring > function on unexistent resource path. > Maybe throwing an exception like "404 code error and resource not found" > would be more convenient. > > kind regards > bob > > >
ChecksumPath exception on unexistent assets
Hi, It appears that the "org.apache.tapestry5.internal.services.assets.ChecksumPath" class throws exception like "String index out of range: -1" when trying to apply substring function on unexistent resource path. Maybe throwing an exception like "404 code error and resource not found" would be more convenient. kind regards bob
Re: Tapestry exposes the list of css/js files in assets
On Thu, Jan 16, 2020 at 6:22 AM Nicolas Bouillon wrote: > Hi all, > Hello! Thanks for posting your findings. It should be noted that Tapestry considers anything under /WEB-INF/assets are public files. In other words, files which are intended to be seen. So, while it's not ideal to have file listings, I wouldn't consider something problematic. > > Following a pen-test of our application, it has been raised that the > list of assets if visible as a directory listing. > > For example, we have a javascript file available at this location > /assets/meta/z58f7f3d4/javascript/library.js but when we access > /assets/meta/z58f7f3d4/javascript/ the web server lists all files > available in META-INF.assets.javascript directory of the project. > > Do you know how to prevent this listing? > > Looks like to me it's happening in > > org.apache.tapestry5.internal.services.assets.ClasspathAssetRequestHandler#handleAssetRequest > and then in > org.apache.tapestry5.internal.services.ResourceStreamerImpl#streamResource(org.apache.tapestry5.ioc.Resource, > org.apache.tapestry5.services.assets.StreamableResource, > java.lang.String, > > java.util.Set) > > Thank you, > Nicolas. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Thiago
Re: Tapestry exposes the list of css/js files in assets
I believe Dmitry's solution will only work for assets on the classpath
(under src/main/resources/META-INF/assets), because it is a
ClasspathAssetProtectionRule. However, the same directory listing problem
seems to exist for context asset directories (subdirectories under
src/main/webapp), so a different solution is needed there.
ContextAssetRequestHandler is an internal Tapestry service, but it's a very
small class that one could maybe override by contributing a new
AssetRequestHandler implementation for the RequestConstants.CONTEXT_FOLDER
folder. I haven't tried, though.
On Fri, Jan 17, 2020, 4:40 AM Dmitry Gusev wrote:
> My previous rule didn't work for JAR resources, here's an improved version
> of regex pattern rule:
>
> import org.apache.tapestry5.SymbolConstants;
> import org.apache.tapestry5.ioc.annotations.Symbol;
> import org.apache.tapestry5.services.ClasspathAssetProtectionRule;
>
> import java.util.regex.Matcher;
> import java.util.regex.Pattern;
>
> public class DirectoryListingAssetProtectionRule implements
> ClasspathAssetProtectionRule
> {
> public static final Pattern LAST_SEGMENT_PATTERN =
> Pattern.compile("[^/]+$");
>
> private final String modulePathPrefixGZ;
>
> public DirectoryListingAssetProtectionRule(
> @Symbol(SymbolConstants.MODULE_PATH_PREFIX) String
> modulePathPrefix)
> {
> this.modulePathPrefixGZ = modulePathPrefix.toLowerCase() + ".gz";
> }
>
> @Override
> public boolean block(String path)
> {
> final Matcher matcher = LAST_SEGMENT_PATTERN.matcher(path);
>
> if (!matcher.find())
> {
> // Empty last segment?
> return true;
> }
>
> final String match = matcher.group().toLowerCase();
>
> return match.equals(modulePathPrefixGZ) || !match.contains(".");
> }
> }
>
>
> On Thu, Jan 16, 2020 at 1:35 PM Dmitry Gusev
> wrote:
>
> > Looking a bit further, it does make sense to me to block all directory
> > requests in ClasspathAssetRequestHandler by default,
> > as directory listing is not something you'd expect to receive via HTTP.
> >
> > That workaround won't work if you have folder with dot in the name
> though,
> > so something more type-safe may be required.
> >
> > At first glance I couldn't find any existing API that would expose
> > underlying File object from an instance of Resource, but for
> > ClasspathResource (and maybe some other resources, like FileResource,
> > ContextResource, etc.) this implementation could probably work better
> (not
> > tested):
> >
> > @Contribute(ClasspathAssetProtectionRule.class)
> > public static void contributeClasspathAssetProtectionRule(
> > OrderedConfiguration configuration,
> > AssetSource assetSource)
> > {
> > configuration.add("DirectoryListing", path ->
> > {
> > Resource resource = assetSource.resourceForPath(path);
> >
> > if (resource == null)
> > {
> > // Nothing to serve
> > return true;
> > }
> >
> > URL resourceUrl = resource.toURL();
> >
> > if (resourceUrl != null)
> > {
> > try
> > {
> > return
> Path.of(resourceUrl.toURI()).toFile().isDirectory();
> > }
> > catch (URISyntaxException e)
> > {
> > throw new RuntimeException(e);
> > }
> > }
> >
> > return false;
> > });
> > }
> >
> >
> > On Thu, Jan 16, 2020 at 1:19 PM Nicolas Bouillon
> > wrote:
> >
> >> Hi,
> >> Thank you for the quick reply, I've added the following rule in my
> >> AppModule.
> >>
> >> @Contribute(ClasspathAssetProtectionRule.class)
> >> public static void contributeClasspathAssetProtectionRule(
> >> OrderedConfiguration
> configuration)
> >> {
> >> ClasspathAssetProtectionRule fileWithDot = (s) ->
> >> !s.toLowerCase().matches(".*\\.[^/]+");
> >> configuration.add("DirectoryListing", fileWithDot);
> >> }
> >>
> >> Note that the directory listing is displayed even without any ending
> >> forwarding slash. Then I've forced the requested file name to end with
> >> a . followed by some chars (anything but a forward slash).
> >>
> >> I wonder if that
Re: Tapestry exposes the list of css/js files in assets
My previous rule didn't work for JAR resources, here's an improved version
of regex pattern rule:
import org.apache.tapestry5.SymbolConstants;
import org.apache.tapestry5.ioc.annotations.Symbol;
import org.apache.tapestry5.services.ClasspathAssetProtectionRule;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class DirectoryListingAssetProtectionRule implements
ClasspathAssetProtectionRule
{
public static final Pattern LAST_SEGMENT_PATTERN =
Pattern.compile("[^/]+$");
private final String modulePathPrefixGZ;
public DirectoryListingAssetProtectionRule(
@Symbol(SymbolConstants.MODULE_PATH_PREFIX) String modulePathPrefix)
{
this.modulePathPrefixGZ = modulePathPrefix.toLowerCase() + ".gz";
}
@Override
public boolean block(String path)
{
final Matcher matcher = LAST_SEGMENT_PATTERN.matcher(path);
if (!matcher.find())
{
// Empty last segment?
return true;
}
final String match = matcher.group().toLowerCase();
return match.equals(modulePathPrefixGZ) || !match.contains(".");
}
}
On Thu, Jan 16, 2020 at 1:35 PM Dmitry Gusev wrote:
> Looking a bit further, it does make sense to me to block all directory
> requests in ClasspathAssetRequestHandler by default,
> as directory listing is not something you'd expect to receive via HTTP.
>
> That workaround won't work if you have folder with dot in the name though,
> so something more type-safe may be required.
>
> At first glance I couldn't find any existing API that would expose
> underlying File object from an instance of Resource, but for
> ClasspathResource (and maybe some other resources, like FileResource,
> ContextResource, etc.) this implementation could probably work better (not
> tested):
>
> @Contribute(ClasspathAssetProtectionRule.class)
> public static void contributeClasspathAssetProtectionRule(
> OrderedConfiguration configuration,
> AssetSource assetSource)
> {
> configuration.add("DirectoryListing", path ->
> {
> Resource resource = assetSource.resourceForPath(path);
>
> if (resource == null)
> {
> // Nothing to serve
> return true;
> }
>
> URL resourceUrl = resource.toURL();
>
> if (resourceUrl != null)
> {
> try
> {
> return Path.of(resourceUrl.toURI()).toFile().isDirectory();
> }
> catch (URISyntaxException e)
> {
> throw new RuntimeException(e);
> }
> }
>
> return false;
> });
> }
>
>
> On Thu, Jan 16, 2020 at 1:19 PM Nicolas Bouillon
> wrote:
>
>> Hi,
>> Thank you for the quick reply, I've added the following rule in my
>> AppModule.
>>
>> @Contribute(ClasspathAssetProtectionRule.class)
>> public static void contributeClasspathAssetProtectionRule(
>> OrderedConfiguration configuration)
>> {
>> ClasspathAssetProtectionRule fileWithDot = (s) ->
>> !s.toLowerCase().matches(".*\\.[^/]+");
>> configuration.add("DirectoryListing", fileWithDot);
>> }
>>
>> Note that the directory listing is displayed even without any ending
>> forwarding slash. Then I've forced the requested file name to end with
>> a . followed by some chars (anything but a forward slash).
>>
>> I wonder if that configuration should be put by default, or activable
>> using a configuration switch described in
>> https://tapestry.apache.org/security.html
>>
>> Thank you again.
>> Nicolas.
>>
>> Le jeu. 16 janv. 2020 à 10:43, Dmitry Gusev a
>> écrit :
>> >
>> > Hi,
>> >
>> > I wasn't aware of it, thanks for bringing it up.
>> >
>> > From what I found in code, AssetsModule contributes three asset
>> protection
>> > rules: for .xml, .class, and .properties files:
>> >
>> > public static void contributeClasspathAssetProtectionRule(
>> > OrderedConfiguration
>> configuration)
>> > {
>> > ClasspathAssetProtectionRule classFileRule = (s) ->
>> > s.toLowerCase().endsWith(".class");
>> > configuration.add("ClassFile", classFileRule);
>> > ClasspathAssetProtectionRule propertiesFileRule = (s) ->
>> > s.toLowerCase().endsWith(".properties");
>> > configuration.add("PropertiesFile", propertiesFileRule);
>> > ClasspathAssetProtectionRule xmlFileRu
Re: Tapestry exposes the list of css/js files in assets
Looking a bit further, it does make sense to me to block all directory
requests in ClasspathAssetRequestHandler by default,
as directory listing is not something you'd expect to receive via HTTP.
That workaround won't work if you have folder with dot in the name though,
so something more type-safe may be required.
At first glance I couldn't find any existing API that would expose
underlying File object from an instance of Resource, but for
ClasspathResource (and maybe some other resources, like FileResource,
ContextResource, etc.) this implementation could probably work better (not
tested):
@Contribute(ClasspathAssetProtectionRule.class)
public static void contributeClasspathAssetProtectionRule(
OrderedConfiguration configuration,
AssetSource assetSource)
{
configuration.add("DirectoryListing", path ->
{
Resource resource = assetSource.resourceForPath(path);
if (resource == null)
{
// Nothing to serve
return true;
}
URL resourceUrl = resource.toURL();
if (resourceUrl != null)
{
try
{
return Path.of(resourceUrl.toURI()).toFile().isDirectory();
}
catch (URISyntaxException e)
{
throw new RuntimeException(e);
}
}
return false;
});
}
On Thu, Jan 16, 2020 at 1:19 PM Nicolas Bouillon
wrote:
> Hi,
> Thank you for the quick reply, I've added the following rule in my
> AppModule.
>
> @Contribute(ClasspathAssetProtectionRule.class)
> public static void contributeClasspathAssetProtectionRule(
> OrderedConfiguration configuration)
> {
> ClasspathAssetProtectionRule fileWithDot = (s) ->
> !s.toLowerCase().matches(".*\\.[^/]+");
> configuration.add("DirectoryListing", fileWithDot);
> }
>
> Note that the directory listing is displayed even without any ending
> forwarding slash. Then I've forced the requested file name to end with
> a . followed by some chars (anything but a forward slash).
>
> I wonder if that configuration should be put by default, or activable
> using a configuration switch described in
> https://tapestry.apache.org/security.html
>
> Thank you again.
> Nicolas.
>
> Le jeu. 16 janv. 2020 à 10:43, Dmitry Gusev a
> écrit :
> >
> > Hi,
> >
> > I wasn't aware of it, thanks for bringing it up.
> >
> > From what I found in code, AssetsModule contributes three asset
> protection
> > rules: for .xml, .class, and .properties files:
> >
> > public static void contributeClasspathAssetProtectionRule(
> > OrderedConfiguration configuration)
> > {
> > ClasspathAssetProtectionRule classFileRule = (s) ->
> > s.toLowerCase().endsWith(".class");
> > configuration.add("ClassFile", classFileRule);
> > ClasspathAssetProtectionRule propertiesFileRule = (s) ->
> > s.toLowerCase().endsWith(".properties");
> > configuration.add("PropertiesFile", propertiesFileRule);
> > ClasspathAssetProtectionRule xmlFileRule = (s) ->
> > s.toLowerCase().endsWith(".xml");
> > configuration.add("XMLFile", xmlFileRule);
> > }
> >
> > So as a possible workaround you could contribute another rule that vetoes
> > asset requests that have no file extension (or end with forward slash),
> > which should cover directory entries.
> >
> > On Thu, Jan 16, 2020 at 12:22 PM Nicolas Bouillon
> > wrote:
> >
> > > Hi all,
> > >
> > > Following a pen-test of our application, it has been raised that the
> > > list of assets if visible as a directory listing.
> > >
> > > For example, we have a javascript file available at this location
> > > /assets/meta/z58f7f3d4/javascript/library.js but when we access
> > > /assets/meta/z58f7f3d4/javascript/ the web server lists all files
> > > available in META-INF.assets.javascript directory of the project.
> > >
> > > Do you know how to prevent this listing?
> > >
> > > Looks like to me it's happening in
> > >
> > >
> org.apache.tapestry5.internal.services.assets.ClasspathAssetRequestHandler#handleAssetRequest
> > > and then in
> > >
> org.apache.tapestry5.internal.services.ResourceStreamerImpl#streamResource(org.apache.tapestry5.ioc.Resource,
> > > org.apache.tapestry5.services.assets.StreamableResource,
> > > java.lang.String,
> > >
> > >
> java.util.Set)
> > >
> > > Thank you,
> > > Nicolas.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > > For additional commands, e-mail: users-h...@tapestry.apache.org
> > >
> > >
> >
> > --
> > Dmitry Gusev
> >
> > AnjLab Team
> > http://anjlab.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Re: Tapestry exposes the list of css/js files in assets
Hi,
Thank you for the quick reply, I've added the following rule in my AppModule.
@Contribute(ClasspathAssetProtectionRule.class)
public static void contributeClasspathAssetProtectionRule(
OrderedConfiguration configuration)
{
ClasspathAssetProtectionRule fileWithDot = (s) ->
!s.toLowerCase().matches(".*\\.[^/]+");
configuration.add("DirectoryListing", fileWithDot);
}
Note that the directory listing is displayed even without any ending
forwarding slash. Then I've forced the requested file name to end with
a . followed by some chars (anything but a forward slash).
I wonder if that configuration should be put by default, or activable
using a configuration switch described in
https://tapestry.apache.org/security.html
Thank you again.
Nicolas.
Le jeu. 16 janv. 2020 à 10:43, Dmitry Gusev a écrit :
>
> Hi,
>
> I wasn't aware of it, thanks for bringing it up.
>
> From what I found in code, AssetsModule contributes three asset protection
> rules: for .xml, .class, and .properties files:
>
> public static void contributeClasspathAssetProtectionRule(
> OrderedConfiguration configuration)
> {
> ClasspathAssetProtectionRule classFileRule = (s) ->
> s.toLowerCase().endsWith(".class");
> configuration.add("ClassFile", classFileRule);
> ClasspathAssetProtectionRule propertiesFileRule = (s) ->
> s.toLowerCase().endsWith(".properties");
> configuration.add("PropertiesFile", propertiesFileRule);
> ClasspathAssetProtectionRule xmlFileRule = (s) ->
> s.toLowerCase().endsWith(".xml");
> configuration.add("XMLFile", xmlFileRule);
> }
>
> So as a possible workaround you could contribute another rule that vetoes
> asset requests that have no file extension (or end with forward slash),
> which should cover directory entries.
>
> On Thu, Jan 16, 2020 at 12:22 PM Nicolas Bouillon
> wrote:
>
> > Hi all,
> >
> > Following a pen-test of our application, it has been raised that the
> > list of assets if visible as a directory listing.
> >
> > For example, we have a javascript file available at this location
> > /assets/meta/z58f7f3d4/javascript/library.js but when we access
> > /assets/meta/z58f7f3d4/javascript/ the web server lists all files
> > available in META-INF.assets.javascript directory of the project.
> >
> > Do you know how to prevent this listing?
> >
> > Looks like to me it's happening in
> >
> > org.apache.tapestry5.internal.services.assets.ClasspathAssetRequestHandler#handleAssetRequest
> > and then in
> > org.apache.tapestry5.internal.services.ResourceStreamerImpl#streamResource(org.apache.tapestry5.ioc.Resource,
> > org.apache.tapestry5.services.assets.StreamableResource,
> > java.lang.String,
> >
> > java.util.Set)
> >
> > Thank you,
> > Nicolas.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
> >
> >
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Tapestry exposes the list of css/js files in assets
Hi,
I wasn't aware of it, thanks for bringing it up.
>From what I found in code, AssetsModule contributes three asset protection
rules: for .xml, .class, and .properties files:
public static void contributeClasspathAssetProtectionRule(
OrderedConfiguration configuration)
{
ClasspathAssetProtectionRule classFileRule = (s) ->
s.toLowerCase().endsWith(".class");
configuration.add("ClassFile", classFileRule);
ClasspathAssetProtectionRule propertiesFileRule = (s) ->
s.toLowerCase().endsWith(".properties");
configuration.add("PropertiesFile", propertiesFileRule);
ClasspathAssetProtectionRule xmlFileRule = (s) ->
s.toLowerCase().endsWith(".xml");
configuration.add("XMLFile", xmlFileRule);
}
So as a possible workaround you could contribute another rule that vetoes
asset requests that have no file extension (or end with forward slash),
which should cover directory entries.
On Thu, Jan 16, 2020 at 12:22 PM Nicolas Bouillon
wrote:
> Hi all,
>
> Following a pen-test of our application, it has been raised that the
> list of assets if visible as a directory listing.
>
> For example, we have a javascript file available at this location
> /assets/meta/z58f7f3d4/javascript/library.js but when we access
> /assets/meta/z58f7f3d4/javascript/ the web server lists all files
> available in META-INF.assets.javascript directory of the project.
>
> Do you know how to prevent this listing?
>
> Looks like to me it's happening in
>
> org.apache.tapestry5.internal.services.assets.ClasspathAssetRequestHandler#handleAssetRequest
> and then in
> org.apache.tapestry5.internal.services.ResourceStreamerImpl#streamResource(org.apache.tapestry5.ioc.Resource,
> org.apache.tapestry5.services.assets.StreamableResource,
> java.lang.String,
>
> java.util.Set)
>
> Thank you,
> Nicolas.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
Tapestry exposes the list of css/js files in assets
Hi all, Following a pen-test of our application, it has been raised that the list of assets if visible as a directory listing. For example, we have a javascript file available at this location /assets/meta/z58f7f3d4/javascript/library.js but when we access /assets/meta/z58f7f3d4/javascript/ the web server lists all files available in META-INF.assets.javascript directory of the project. Do you know how to prevent this listing? Looks like to me it's happening in org.apache.tapestry5.internal.services.assets.ClasspathAssetRequestHandler#handleAssetRequest and then in org.apache.tapestry5.internal.services.ResourceStreamerImpl#streamResource(org.apache.tapestry5.ioc.Resource, org.apache.tapestry5.services.assets.StreamableResource, java.lang.String, java.util.Set) Thank you, Nicolas. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Location of assets
Hi Christian,
I am sorry for a very late response.
The absolute path does not work actually.
If I use e.g.
background-image: url('/images/myimage.png');
in a css file, the image is not displayed.
The image location in my directory structure is
src/main/webapp/images/myimage.png
and Tapestry provides it on URL like
/assets/ctx/7d7f78bd/images/myimage.png
Especially, the generated path element (which is new in Tapestry 5.4) makes
referencing in css imposible.
Anyway, I will move all images to location like
src/main/resources/META-INF/assets/images
so that it can be referenced relatively.
This seems to be the way to go.
Thanks for your help.
Cheers
Jarda
2017-02-24 23:03 GMT+01:00 Christian Riedel :
> Hi Jarda,
>
> you just use the path relative to your servlet context.
>
> > background-image: url('/images/myimage.png');
>
>
> this could work. If your app is not deployed under the root context but
> under /foo-bar/ then I guess this should work:
>
> background-image: url('/foo-bar/images/myimage.png‘);
>
> If both, your images and your css files are stored in src/main/webapp you
> can also use relative paths:
>
> background-image: url('../images/myimage.png‘);
>
> That being said, I prefer to have all assets in META-INF/images and
> META-INF/css for example. Relative paths have the advantage that Tapestry
> will give you an error if any image isn’t where it should be if you
> reference it via relative paths. That check does not apply for absolute
> paths (starting with a slash).
>
> Cheers,
> Christian
>
>
>
> > Am 24.02.2017 um 12:59 schrieb Jaroslav Ciml :
> >
> > Hi,
> >
> > I am trying to figure out what is the correct location of assets with
> Tapestry 5.4 and Maven directory structure.
> >
> > I will explain how do I understand it. Correct what is wrong please.
> >
> > From logical point of view, I can think of two types of assets - global
> and comopnent specific.
> >
> > A global asset is e.g. a PNG image that is used as a background in
> various places in the application, i.e. it is referenced in many Tapestry
> components. Such global assets are called "context assets" in Tapestry.
> >
> > A component specific asset is say a CSS file that defines style just for
> the HTML markup generated by one specific Tapestry component. Such
> component specific assets are called "class path assets" in Tapestry.
> >
> > Suppose that I have some Tapestry component with CSS file and a global
> PNG image.
> >
> > The tml and java files for the component are located in:
> > src/main/java/com/somecompany/myapp/view/components/MyComponent.java
> > src/main/resources/com/somecompany/myapp/view/components/MyComponent.tml
> >
> > And this is the appropriate configuration in web.xml:
> >
> > tapestry.app-package
> > com.somecompany.myapp.view
> >
> >
> > The global PNG file is located in:
> > src/main/webapp/images/myimage.png
> >
> > The CSS file that is related just to MyComponent is located in:
> > src/main/resources/META-INF/assets/MyComponent.css
> >
> > and the CSS is imported in MyComponent.java:
> > @Import(stylesheet = "MyComponent.css")
> >
> > Do these locations make sense please?
> >
> > If so, is it possible to reference the global PNG from the component
> specific CSS?
> > ul.my-component-menu {
> > background-image: url('what_should_be_here/myimage.png');
> > }
> >
> > Thanks.
> > Jarda
> > -
> > 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: Location of assets
Hi Jarda,
you just use the path relative to your servlet context.
> background-image: url('/images/myimage.png');
this could work. If your app is not deployed under the root context but under
/foo-bar/ then I guess this should work:
background-image: url('/foo-bar/images/myimage.png‘);
If both, your images and your css files are stored in src/main/webapp you can
also use relative paths:
background-image: url('../images/myimage.png‘);
That being said, I prefer to have all assets in META-INF/images and
META-INF/css for example. Relative paths have the advantage that Tapestry will
give you an error if any image isn’t where it should be if you reference it via
relative paths. That check does not apply for absolute paths (starting with a
slash).
Cheers,
Christian
> Am 24.02.2017 um 12:59 schrieb Jaroslav Ciml :
>
> Hi,
>
> I am trying to figure out what is the correct location of assets with
> Tapestry 5.4 and Maven directory structure.
>
> I will explain how do I understand it. Correct what is wrong please.
>
> From logical point of view, I can think of two types of assets - global and
> comopnent specific.
>
> A global asset is e.g. a PNG image that is used as a background in various
> places in the application, i.e. it is referenced in many Tapestry components.
> Such global assets are called "context assets" in Tapestry.
>
> A component specific asset is say a CSS file that defines style just for the
> HTML markup generated by one specific Tapestry component. Such component
> specific assets are called "class path assets" in Tapestry.
>
> Suppose that I have some Tapestry component with CSS file and a global PNG
> image.
>
> The tml and java files for the component are located in:
> src/main/java/com/somecompany/myapp/view/components/MyComponent.java
> src/main/resources/com/somecompany/myapp/view/components/MyComponent.tml
>
> And this is the appropriate configuration in web.xml:
>
> tapestry.app-package
> com.somecompany.myapp.view
>
>
> The global PNG file is located in:
> src/main/webapp/images/myimage.png
>
> The CSS file that is related just to MyComponent is located in:
> src/main/resources/META-INF/assets/MyComponent.css
>
> and the CSS is imported in MyComponent.java:
> @Import(stylesheet = "MyComponent.css")
>
> Do these locations make sense please?
>
> If so, is it possible to reference the global PNG from the component specific
> CSS?
> ul.my-component-menu {
> background-image: url('what_should_be_here/myimage.png');
> }
>
> Thanks.
> Jarda
> -
> 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
Location of assets
Hi,
I am trying to figure out what is the correct location of assets with Tapestry
5.4 and Maven directory structure.
I will explain how do I understand it. Correct what is wrong please.
From logical point of view, I can think of two types of assets - global and
comopnent specific.
A global asset is e.g. a PNG image that is used as a background in various
places in the application, i.e. it is referenced in many Tapestry components.
Such global assets are called "context assets" in Tapestry.
A component specific asset is say a CSS file that defines style just for the
HTML markup generated by one specific Tapestry component. Such component
specific assets are called "class path assets" in Tapestry.
Suppose that I have some Tapestry component with CSS file and a global PNG
image.
The tml and java files for the component are located in:
src/main/java/com/somecompany/myapp/view/components/MyComponent.java
src/main/resources/com/somecompany/myapp/view/components/MyComponent.tml
And this is the appropriate configuration in web.xml:
tapestry.app-package
com.somecompany.myapp.view
The global PNG file is located in:
src/main/webapp/images/myimage.png
The CSS file that is related just to MyComponent is located in:
src/main/resources/META-INF/assets/MyComponent.css
and the CSS is imported in MyComponent.java:
@Import(stylesheet = "MyComponent.css")
Do these locations make sense please?
If so, is it possible to reference the global PNG from the component specific
CSS?
ul.my-component-menu {
background-image: url('what_should_be_here/myimage.png');
}
Thanks.
Jarda
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: problem accessing assets after migration to 5.4
assets are usually in a specific path (resources/META-INF/assets/...) -
Could it be that your file is not an asset and that it should be loaded
using normal methods (classloader.getResourceAsStream or similar)
--
Chris
On Thu, Jun 30, 2016 at 8:23 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Thu, 30 Jun 2016 13:13:23 -0300, Qbyte Consulting <
> qbyteconsult...@gmail.com> wrote:
>
> Hi,
>>
>
> Hi!
>
> I've changed my project deps to T5.4. After fixing some depricated page
>> link methods my app compiles. However when I run I get exceptions from a
>> menu loading service:
>>
>> is = assetSource.getClasspathAsset("menu.properties").getResource()
>> .openStream();
>> } catch (RuntimeException e) {
>>
>
> Try "/menu.properties" instead of "menu.properties", please.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: problem accessing assets after migration to 5.4
On Thu, 30 Jun 2016 13:13:23 -0300, Qbyte Consulting
wrote:
Hi,
Hi!
I've changed my project deps to T5.4. After fixing some depricated page
link methods my app compiles. However when I run I get exceptions from a
menu loading service:
is = assetSource.getClasspathAsset("menu.properties").getResource()
.openStream();
} catch (RuntimeException e) {
Try "/menu.properties" instead of "menu.properties", please.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
problem accessing assets after migration to 5.4
Hi,
I've changed my project deps to T5.4. After fixing some depricated page
link methods my app compiles. However when I run I get exceptions from a
menu loading service:
is = assetSource.getClasspathAsset("menu.properties").getResource()
.openStream();
} catch (RuntimeException e) {
final String msg = "The menu.properties asset can not be found";
java.lang.RuntimeException: Exception constructing service 'MenuService':
Error
invoking constructor public
epulse.audit.manager.services.impl.MenuServiceImpl(o
rg.apache.tapestry5.services.AssetSource,org.slf4j.Logger) throws
java.io.IOExce
ption: The menu.properties asset can not be found
at
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.ob
tainObjectFromCreator(JustInTimeObjectCreator.java:76)
at
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.cr
eateObject(JustInTimeObjectCreator.java:55)
at
org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.ea
gerLoadService(JustInTimeObjectCreator.java:88)
at
org.apache.tapestry5.ioc.internal.RegistryImpl.performRegistryStartup
(RegistryImpl.java:357)
This reads in a properties file. It worked before, the files are under
resources in the maven project. Even copying them to the same source
package as the class doesn't resolve the issue, any idea?
John
Re: Far Future Expiration Headers of Assets
Howard, just a thought. It appears as if the files with the 60 sec cache are mostly Tapestry core files. Since we are unable to put a checksum in the URI, would it be possible to put a version in the filename? Example, bootstrap3.xx.css etc. I would think we could then use a far future expiration on the modules, it would also make it easy for us to keep track of what library version we are running too. The downside might just be the library maintenance during upgrades. I'm only pushing on this topic do to the fact a websites speed is one of the few known ranking factors of Google's algorithm. A website that scores high for speed will move up the page rank as Google believes the users will have a much better experience. Currently Google's scoring tool is scoring me in the low 70's for mobile which is primarily do to browser caching and render blocking css and js which we spoke about this before for future releases. I also think if we get this figured out it would help to reduce some of the hosting cost associated with the cloud. On Tue, Jan 27, 2015 at 3:10 PM, George Christman wrote: > In production mode Google / yslow have both been complaining about > assets missing expiration dates as well as the modules being too > short. You can see an example here. > > https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cardaddy.com%2F > > Now do to my lack of Tapestry knowledge on the proper way to handle > expiration for asset headers, I ended up setting the expiration date > for 1 year within apache httpd with the assumption the checksum would > change. > > So as of right now it just appears google is complaining about the > modules short expiration date "90", I'm not familiar with etag, but > would that help to resolve my issues. > > On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship wrote: >> Further, for both modules and normal assets, there's etag support ... so >> most requsts for a module get a 304 and the browser can use its local cache. >> >> On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship >> wrote: >> >>> Modules can't have a far-future expires header, because we can't put a >>> fingerprint (asset checksum) into a module URI. >>> >>> All other assets have a checksum in the URI and get the far future expires >>> header. >>> >>> The handling of this is different between development mode and production >>> mode. Short or no expires headers in development. >>> >>> The naming may be a bit wonky, but the Javadoc should explain the >>> reasoning. Basically, this is the cache control header for when the >>> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is >>> not passed, we get the far-future expires header. >>> >>> >>> On Tue, Jan 27, 2015 at 6:41 AM, George Christman >> > wrote: >>> >>>> So I figured out how to change the 60sec, >>>> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER, >>>> "max-age= >>>> 2419200,must-revalidate"); >>>> >>>> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove >>>> the expiration dates. >>>> >>>> Now I just need to figure out how to ad expiration dates to the other >>>> core css style sheets >>>> >>>> (no expires) >>>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css >>>> (no expires) >>>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css >>>> (no expires) >>>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css >>>> (no expires) >>>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css >>>> >>>> Any thoughts? >>>> >>>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman >>>> wrote: >>>> > Hi Guys, I'm back on this topic again. Does anybody know how to bump >>>> > up the default 60 second time to something further in the future? >>>> > >>>> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou >>>> wrote: >>>> >> Hi George, >>>> >> >>>> >> It does sound like the same issue. >>>> >> >>>> >> Regarding the "leverage browser caching" warning, I did not "solve" >>>> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i) >>>> >> if one keeps the Chrome developer panel up and cli
Re: Far Future Expiration Headers of Assets
In production mode Google / yslow have both been complaining about
assets missing expiration dates as well as the modules being too
short. You can see an example here.
https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fwww.cardaddy.com%2F
Now do to my lack of Tapestry knowledge on the proper way to handle
expiration for asset headers, I ended up setting the expiration date
for 1 year within apache httpd with the assumption the checksum would
change.
So as of right now it just appears google is complaining about the
modules short expiration date "90", I'm not familiar with etag, but
would that help to resolve my issues.
On Tue, Jan 27, 2015 at 1:56 PM, Howard Lewis Ship wrote:
> Further, for both modules and normal assets, there's etag support ... so
> most requsts for a module get a 304 and the browser can use its local cache.
>
> On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship
> wrote:
>
>> Modules can't have a far-future expires header, because we can't put a
>> fingerprint (asset checksum) into a module URI.
>>
>> All other assets have a checksum in the URI and get the far future expires
>> header.
>>
>> The handling of this is different between development mode and production
>> mode. Short or no expires headers in development.
>>
>> The naming may be a bit wonky, but the Javadoc should explain the
>> reasoning. Basically, this is the cache control header for when the
>> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
>> not passed, we get the far-future expires header.
>>
>>
>> On Tue, Jan 27, 2015 at 6:41 AM, George Christman > > wrote:
>>
>>> So I figured out how to change the 60sec,
>>> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER,
>>> "max-age=
>>> 2419200,must-revalidate");
>>>
>>> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove
>>> the expiration dates.
>>>
>>> Now I just need to figure out how to ad expiration dates to the other
>>> core css style sheets
>>>
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
>>> (no expires)
>>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>>>
>>> Any thoughts?
>>>
>>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
>>> wrote:
>>> > Hi Guys, I'm back on this topic again. Does anybody know how to bump
>>> > up the default 60 second time to something further in the future?
>>> >
>>> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou
>>> wrote:
>>> >> Hi George,
>>> >>
>>> >> It does sound like the same issue.
>>> >>
>>> >> Regarding the "leverage browser caching" warning, I did not "solve"
>>> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
>>> >> if one keeps the Chrome developer panel up and click around in a
>>> >> Tapestry webapp, one should see that the assets are indeed cached
>>> >> after the initial round of full requests ("200 from cache" will be
>>> >> shown for cached assets). No requests for these assets will actually
>>> >> be sent to server unless the user clicks the refresh button or run an
>>> >> audit with page reload from Chrome PageSpeed. The latter case is
>>> >> where PageSpeed will complain about the assets, because although it
>>> >> sees the 10-year-in-the-future headers in the responses, which Chrome
>>> >> does honor and will cache accordingly, PageSpeed will, however, want
>>> >> to see a "Cache-Control" header in responses. It is likely a
>>> >> non-issue because during ordinary browsing client caching is
>>> >> leveraged.
>>> >>
>>> >> The 60 seconds for modules are discussed here:
>>> >> http://tapestry.apache.org/javascript-modules.html
>>> >>
>>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>>> >> you won't see module requests on every page load. This is configurable
>>> >> and you may want a much higher value in production. If you are rapidly
&
Re: Far Future Expiration Headers of Assets
Further, for both modules and normal assets, there's etag support ... so
most requsts for a module get a 304 and the browser can use its local cache.
On Tue, Jan 27, 2015 at 10:55 AM, Howard Lewis Ship
wrote:
> Modules can't have a far-future expires header, because we can't put a
> fingerprint (asset checksum) into a module URI.
>
> All other assets have a checksum in the URI and get the far future expires
> header.
>
> The handling of this is different between development mode and production
> mode. Short or no expires headers in development.
>
> The naming may be a bit wonky, but the Javadoc should explain the
> reasoning. Basically, this is the cache control header for when the
> OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
> not passed, we get the far-future expires header.
>
>
> On Tue, Jan 27, 2015 at 6:41 AM, George Christman > wrote:
>
>> So I figured out how to change the 60sec,
>> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER,
>> "max-age=
>> 2419200,must-revalidate");
>>
>> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove
>> the expiration dates.
>>
>> Now I just need to figure out how to ad expiration dates to the other
>> core css style sheets
>>
>> (no expires)
>> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
>> (no expires)
>> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>>
>> Any thoughts?
>>
>> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
>> wrote:
>> > Hi Guys, I'm back on this topic again. Does anybody know how to bump
>> > up the default 60 second time to something further in the future?
>> >
>> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou
>> wrote:
>> >> Hi George,
>> >>
>> >> It does sound like the same issue.
>> >>
>> >> Regarding the "leverage browser caching" warning, I did not "solve"
>> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
>> >> if one keeps the Chrome developer panel up and click around in a
>> >> Tapestry webapp, one should see that the assets are indeed cached
>> >> after the initial round of full requests ("200 from cache" will be
>> >> shown for cached assets). No requests for these assets will actually
>> >> be sent to server unless the user clicks the refresh button or run an
>> >> audit with page reload from Chrome PageSpeed. The latter case is
>> >> where PageSpeed will complain about the assets, because although it
>> >> sees the 10-year-in-the-future headers in the responses, which Chrome
>> >> does honor and will cache accordingly, PageSpeed will, however, want
>> >> to see a "Cache-Control" header in responses. It is likely a
>> >> non-issue because during ordinary browsing client caching is
>> >> leveraged.
>> >>
>> >> The 60 seconds for modules are discussed here:
>> >> http://tapestry.apache.org/javascript-modules.html
>> >>
>> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>> >> you won't see module requests on every page load. This is configurable
>> >> and you may want a much higher value in production. If you are rapidly
>> >> iterating on the source of a module, you may need to force the browser
>> >> to reload after clearing local cache. Chrome has an option to disable
>> >> the client-side cache when its developer tools are open."
>> >>
>> >> The page lists solutions as well.
>> >>
>> >> Harry
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>> >> wrote:
>> >>> I'm having this same issue which I posted up a couple weeks ago
>> >>> without any response.
>> >>>
>> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
>> >>>
>> >>> So my first question is what did you do to resolve the issue?
>> >>>
>> >>> Secondly I am running in production mode,
Re: Far Future Expiration Headers of Assets
Modules can't have a far-future expires header, because we can't put a
fingerprint (asset checksum) into a module URI.
All other assets have a checksum in the URI and get the far future expires
header.
The handling of this is different between development mode and production
mode. Short or no expires headers in development.
The naming may be a bit wonky, but the Javadoc should explain the
reasoning. Basically, this is the cache control header for when the
OMIT_EXPIRATION flag is passed to the relevant service. When the flag is
not passed, we get the far-future expires header.
On Tue, Jan 27, 2015 at 6:41 AM, George Christman
wrote:
> So I figured out how to change the 60sec,
> configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER,
> "max-age=
> 2419200,must-revalidate");
>
> OMIT_EXPIRATION is a bit misleading as I thought it meant to remove
> the expiration dates.
>
> Now I just need to figure out how to ad expiration dates to the other
> core css style sheets
>
> (no expires)
> http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
> (no expires)
> http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
> (no expires)
> http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
> (no expires)
> http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
>
> Any thoughts?
>
> On Tue, Jan 27, 2015 at 8:48 AM, George Christman
> wrote:
> > Hi Guys, I'm back on this topic again. Does anybody know how to bump
> > up the default 60 second time to something further in the future?
> >
> > On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou
> wrote:
> >> Hi George,
> >>
> >> It does sound like the same issue.
> >>
> >> Regarding the "leverage browser caching" warning, I did not "solve"
> >> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
> >> if one keeps the Chrome developer panel up and click around in a
> >> Tapestry webapp, one should see that the assets are indeed cached
> >> after the initial round of full requests ("200 from cache" will be
> >> shown for cached assets). No requests for these assets will actually
> >> be sent to server unless the user clicks the refresh button or run an
> >> audit with page reload from Chrome PageSpeed. The latter case is
> >> where PageSpeed will complain about the assets, because although it
> >> sees the 10-year-in-the-future headers in the responses, which Chrome
> >> does honor and will cache accordingly, PageSpeed will, however, want
> >> to see a "Cache-Control" header in responses. It is likely a
> >> non-issue because during ordinary browsing client caching is
> >> leveraged.
> >>
> >> The 60 seconds for modules are discussed here:
> >> http://tapestry.apache.org/javascript-modules.html
> >>
> >> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
> >> you won't see module requests on every page load. This is configurable
> >> and you may want a much higher value in production. If you are rapidly
> >> iterating on the source of a module, you may need to force the browser
> >> to reload after clearing local cache. Chrome has an option to disable
> >> the client-side cache when its developer tools are open."
> >>
> >> The page lists solutions as well.
> >>
> >> Harry
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
> >> wrote:
> >>> I'm having this same issue which I posted up a couple weeks ago
> >>> without any response.
> >>>
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
> >>>
> >>> So my first question is what did you do to resolve the issue?
> >>>
> >>> Secondly I am running in production mode, so I'm not sure what the
> >>> cause could be. I'll have to check the cdn, but this is what google is
> >>> complaining about. The images are being called from a sprite map in
> >>> css where the context binding prefix can't be used.
> >>>
> >>> Leverage browser caching
> >>>
> >>> Setting an expiry date or a maximum age in the HTTP headers for static
> >>> resources instructs the browser to load previously downloaded
> >>> resources from local disk rather than over the network.
> >
Re: Far Future Expiration Headers of Assets
So I figured out how to change the 60sec,
configuration.add(SymbolConstants.OMIT_EXPIRATION_CACHE_CONTROL_HEADER,
"max-age=
2419200,must-revalidate");
OMIT_EXPIRATION is a bit misleading as I thought it meant to remove
the expiration dates.
Now I just need to figure out how to ad expiration dates to the other
core css style sheets
(no expires)
http://localhost:8080/etss/assets/meta/z64038ad2/tapestry5/tapestry.css
(no expires)
http://localhost:8080/etss/assets/meta/ze8a5779c/tapestry5/exception-frame.css
(no expires)
http://localhost:8080/etss/assets/meta/zceffa0e4/tapestry5/tapestry-console.css
(no expires) http://localhost:8080/etss/assets/meta/z57b9a823/tapestry5/tree.css
Any thoughts?
On Tue, Jan 27, 2015 at 8:48 AM, George Christman
wrote:
> Hi Guys, I'm back on this topic again. Does anybody know how to bump
> up the default 60 second time to something further in the future?
>
> On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou wrote:
>> Hi George,
>>
>> It does sound like the same issue.
>>
>> Regarding the "leverage browser caching" warning, I did not "solve"
>> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
>> if one keeps the Chrome developer panel up and click around in a
>> Tapestry webapp, one should see that the assets are indeed cached
>> after the initial round of full requests ("200 from cache" will be
>> shown for cached assets). No requests for these assets will actually
>> be sent to server unless the user clicks the refresh button or run an
>> audit with page reload from Chrome PageSpeed. The latter case is
>> where PageSpeed will complain about the assets, because although it
>> sees the 10-year-in-the-future headers in the responses, which Chrome
>> does honor and will cache accordingly, PageSpeed will, however, want
>> to see a "Cache-Control" header in responses. It is likely a
>> non-issue because during ordinary browsing client caching is
>> leveraged.
>>
>> The 60 seconds for modules are discussed here:
>> http://tapestry.apache.org/javascript-modules.html
>>
>> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
>> you won't see module requests on every page load. This is configurable
>> and you may want a much higher value in production. If you are rapidly
>> iterating on the source of a module, you may need to force the browser
>> to reload after clearing local cache. Chrome has an option to disable
>> the client-side cache when its developer tools are open."
>>
>> The page lists solutions as well.
>>
>> Harry
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
>> wrote:
>>> I'm having this same issue which I posted up a couple weeks ago
>>> without any response.
>>> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
>>>
>>> So my first question is what did you do to resolve the issue?
>>>
>>> Secondly I am running in production mode, so I'm not sure what the
>>> cause could be. I'll have to check the cdn, but this is what google is
>>> complaining about. The images are being called from a sprite map in
>>> css where the context binding prefix can't be used.
>>>
>>> Leverage browser caching
>>>
>>> Setting an expiry date or a maximum age in the HTTP headers for static
>>> resources instructs the browser to load previously downloaded
>>> resources from local disk rather than over the network.
>>> Leverage browser caching for the following cacheable resources:
>>>
>>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
>>> not specified)
>>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
>>> not specified)
>>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>>> https://www.cardaddy.com/modules.gz/t
Re: Far Future Expiration Headers of Assets
Hi Guys, I'm back on this topic again. Does anybody know how to bump
up the default 60 second time to something further in the future?
On Mon, Dec 22, 2014 at 4:01 PM, Harry Zhou wrote:
> Hi George,
>
> It does sound like the same issue.
>
> Regarding the "leverage browser caching" warning, I did not "solve"
> the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
> if one keeps the Chrome developer panel up and click around in a
> Tapestry webapp, one should see that the assets are indeed cached
> after the initial round of full requests ("200 from cache" will be
> shown for cached assets). No requests for these assets will actually
> be sent to server unless the user clicks the refresh button or run an
> audit with page reload from Chrome PageSpeed. The latter case is
> where PageSpeed will complain about the assets, because although it
> sees the 10-year-in-the-future headers in the responses, which Chrome
> does honor and will cache accordingly, PageSpeed will, however, want
> to see a "Cache-Control" header in responses. It is likely a
> non-issue because during ordinary browsing client caching is
> leveraged.
>
> The 60 seconds for modules are discussed here:
> http://tapestry.apache.org/javascript-modules.html
>
> "By default, Tapestry sets a max age of 60 (seconds) on modules, so
> you won't see module requests on every page load. This is configurable
> and you may want a much higher value in production. If you are rapidly
> iterating on the source of a module, you may need to force the browser
> to reload after clearing local cache. Chrome has an option to disable
> the client-side cache when its developer tools are open."
>
> The page lists solutions as well.
>
> Harry
>
>
>
>
>
>
>
> On Mon, Dec 22, 2014 at 12:44 PM, George Christman
> wrote:
>> I'm having this same issue which I posted up a couple weeks ago
>> without any response.
>> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
>>
>> So my first question is what did you do to resolve the issue?
>>
>> Secondly I am running in production mode, so I'm not sure what the
>> cause could be. I'll have to check the cdn, but this is what google is
>> complaining about. The images are being called from a sprite map in
>> css where the context binding prefix can't be used.
>>
>> Leverage browser caching
>>
>> Setting an expiry date or a maximum age in the HTTP headers for static
>> resources instructs the browser to load previously downloaded
>> resources from local disk rather than over the network.
>> Leverage browser caching for the following cacheable resources:
>>
>> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
>> not specified)
>> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
>> not specified)
>> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
>> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>>
>> Any thoughts?
>>
>> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote:
>>> Hi Bob and Thiago, thank you for pointing me to the right direction!
>>> Problem solved.
>>>
>>> It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to
>>> ignore Tapestry's 10-year-in-the-future "Expires" response header.
>>> But during actual browsing the assets are actually cached (seeing "200
>>> from cache").
>>>
>>> Google seems to take the position that "Expires" response headers are
>>> "superseded." While Chrome honors "Expires" during browsing, it will
>>> also look for a "Cache-Control" in response headers. See
>>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>>
>>>
>>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>&g
Re: Far Future Expiration Headers of Assets
Hi George,
It does sound like the same issue.
Regarding the "leverage browser caching" warning, I did not "solve"
the problem -- it appears to be a false alarm by Chrome PageSpeed: (i)
if one keeps the Chrome developer panel up and click around in a
Tapestry webapp, one should see that the assets are indeed cached
after the initial round of full requests ("200 from cache" will be
shown for cached assets). No requests for these assets will actually
be sent to server unless the user clicks the refresh button or run an
audit with page reload from Chrome PageSpeed. The latter case is
where PageSpeed will complain about the assets, because although it
sees the 10-year-in-the-future headers in the responses, which Chrome
does honor and will cache accordingly, PageSpeed will, however, want
to see a "Cache-Control" header in responses. It is likely a
non-issue because during ordinary browsing client caching is
leveraged.
The 60 seconds for modules are discussed here:
http://tapestry.apache.org/javascript-modules.html
"By default, Tapestry sets a max age of 60 (seconds) on modules, so
you won't see module requests on every page load. This is configurable
and you may want a much higher value in production. If you are rapidly
iterating on the source of a module, you may need to force the browser
to reload after clearing local cache. Chrome has an option to disable
the client-side cache when its developer tools are open."
The page lists solutions as well.
Harry
On Mon, Dec 22, 2014 at 12:44 PM, George Christman
wrote:
> I'm having this same issue which I posted up a couple weeks ago
> without any response.
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html
>
> So my first question is what did you do to resolve the issue?
>
> Secondly I am running in production mode, so I'm not sure what the
> cause could be. I'll have to check the cdn, but this is what google is
> complaining about. The images are being called from a sprite map in
> css where the context binding prefix can't be used.
>
> Leverage browser caching
>
> Setting an expiry date or a maximum age in the HTTP headers for static
> resources instructs the browser to load previously downloaded
> resources from local disk rather than over the network.
> Leverage browser caching for the following cacheable resources:
>
> https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration
> not specified)
> https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration
> not specified)
> https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds)
> https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds)
> https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds)
>
> Any thoughts?
>
> On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote:
>> Hi Bob and Thiago, thank you for pointing me to the right direction!
>> Problem solved.
>>
>> It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to
>> ignore Tapestry's 10-year-in-the-future "Expires" response header.
>> But during actual browsing the assets are actually cached (seeing "200
>> from cache").
>>
>> Google seems to take the position that "Expires" response headers are
>> "superseded." While Chrome honors "Expires" during browsing, it will
>> also look for a "Cache-Control" in response headers. See
>> https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control
>>
>>
>> On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo
>> wrote:
>>> Another thing to check: production mode is off?
>>>
>>>
>>> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote:
>>>
>>>> Be sure production mode is on and that your links to the asset are using
>>>> the asset: or context: binding prefix.
>>>>
>>>> Can you give us a typical asset URL (as seen by the browser)? That might
>>>> give us some hints.
>>>>
>>>> Also be sure the expires headers aren't being removed by a proxy or CDN.
>>>>
Re: Far Future Expiration Headers of Assets
The cdn should handle the expire headers. Tapestry only tells the client where to get the files. As for the modules I've never had a look at their expiration time, but a simple test app in production mode also reposts 60secs here. - Guess that could be something to dig into. -- Chris On Mon, Dec 22, 2014 at 6:44 PM, George Christman wrote: > I'm having this same issue which I posted up a couple weeks ago > without any response. > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html > > So my first question is what did you do to resolve the issue? > > Secondly I am running in production mode, so I'm not sure what the > cause could be. I'll have to check the cdn, but this is what google is > complaining about. The images are being called from a sprite map in > css where the context binding prefix can't be used. > > Leverage browser caching > > Setting an expiry date or a maximum age in the HTTP headers for static > resources instructs the browser to load previously downloaded > resources from local disk rather than over the network. > Leverage browser caching for the following cacheable resources: > > https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration > not specified) > https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration > not specified) > https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) > https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) > https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) > > Any thoughts? > > On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: > > Hi Bob and Thiago, thank you for pointing me to the right direction! > > Problem solved. > > > > It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to > > ignore Tapestry's 10-year-in-the-future "Expires" response header. > > But during actual browsing the assets are actually cached (seeing "200 > > from cache"). > > > > Google seems to take the position that "Expires" response headers are > > "superseded." While Chrome honors "Expires" during browsing, it will > > also look for a "Cache-Control" in response headers. See > > > https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control > > > > > > On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo > > wrote: > >> Another thing to check: production mode is off? > >> > >> > >> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner > wrote: > >> > >>> Be sure production mode is on and that your links to the asset are > using > >>> the asset: or context: binding prefix. > >>> > >>> Can you give us a typical asset URL (as seen by the browser)? That > might > >>> give us some hints. > >>> > >>> Also be sure the expires headers aren't being removed by a proxy or > CDN. > >>> Hint: doest the issue happen on your desktop with local host, or only > when > >>> running on a server? > >>> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > >>> > >>>> Hi! > >>>> > >>>> About my T5.4 site, Google is complaining that "resources are missing > >>>> a cache expiration. Resources that do not specify an expiration may > >>>> not be cached by browsers . . . " > >>>> > >>>> I read that "assets get a far-future expires header" and will be > >>>> "client browsers will aggressively cache downloaded assets." So I am > >>>> not sure why responses for my assets all come with > >>>> "Cache-Control:no-cache" and "Pragma:no-cache". > >>>> > >>>> Any help would be appreciated. Thanks! > >>>> > >>>> Best Regards > >>>> Harry > >>>> > >>>> - >
Re: Far Future Expiration Headers of Assets
I'm having this same issue which I posted up a couple weeks ago without any response. http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/5-4-asset-expire-header-td5729478.html So my first question is what did you do to resolve the issue? Secondly I am running in production mode, so I'm not sure what the cause could be. I'll have to check the cdn, but this is what google is complaining about. The images are being called from a sprite map in css where the context binding prefix can't be used. Leverage browser caching Setting an expiry date or a maximum age in the HTTP headers for static resources instructs the browser to load previously downloaded resources from local disk rather than over the network. Leverage browser caching for the following cacheable resources: https://d39chrhoz7kxwa.cloudfront.net/1f1a90de-ed5_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/29fb2b34-55d_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/3902d130-3b1_300.jpg (expiration not specified) https://d39chrhoz7kxwa.cloudfront.net/75713aa2-bec_300.jpg (expiration not specified) https://www.cardaddy.com/modules.gz/autocomplete-custom.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/collapse.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/dropdown.js (60 seconds) https://www.cardaddy.com/modules.gz/bootstrap/transition.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/messages/en_US.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/select.js (60 seconds) https://www.cardaddy.com/modules.gz/t5/core/zone.js (60 seconds) Any thoughts? On Sun, Dec 21, 2014 at 5:14 PM, Harry Zhou wrote: > Hi Bob and Thiago, thank you for pointing me to the right direction! > Problem solved. > > It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to > ignore Tapestry's 10-year-in-the-future "Expires" response header. > But during actual browsing the assets are actually cached (seeing "200 > from cache"). > > Google seems to take the position that "Expires" response headers are > "superseded." While Chrome honors "Expires" during browsing, it will > also look for a "Cache-Control" in response headers. See > https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control > > > On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo > wrote: >> Another thing to check: production mode is off? >> >> >> On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: >> >>> Be sure production mode is on and that your links to the asset are using >>> the asset: or context: binding prefix. >>> >>> Can you give us a typical asset URL (as seen by the browser)? That might >>> give us some hints. >>> >>> Also be sure the expires headers aren't being removed by a proxy or CDN. >>> Hint: doest the issue happen on your desktop with local host, or only when >>> running on a server? >>> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: >>> >>>> Hi! >>>> >>>> About my T5.4 site, Google is complaining that "resources are missing >>>> a cache expiration. Resources that do not specify an expiration may >>>> not be cached by browsers . . . " >>>> >>>> I read that "assets get a far-future expires header" and will be >>>> "client browsers will aggressively cache downloaded assets." So I am >>>> not sure why responses for my assets all come with >>>> "Cache-Control:no-cache" and "Pragma:no-cache". >>>> >>>> Any help would be appreciated. Thanks! >>>> >>>> Best Regards >>>> Harry >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >> >> >> -- >> Thiago H. de Paula Figueiredo >> Tapestry, Java and Hibernate consultant and developer >> http://machina.com.br >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Best Regards > Harry Zhou > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- George Christman CEO www.CarDaddy.com P.O. Box 735 Johnstown, New York - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Hi Bob and Thiago, thank you for pointing me to the right direction! Problem solved. It is NOT Tapestry related: Chrome's PageSpeed audit tool chooses to ignore Tapestry's 10-year-in-the-future "Expires" response header. But during actual browsing the assets are actually cached (seeing "200 from cache"). Google seems to take the position that "Expires" response headers are "superseded." While Chrome honors "Expires" during browsing, it will also look for a "Cache-Control" in response headers. See https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#cache-control On Sun, Dec 21, 2014 at 2:54 PM, Thiago H de Paula Figueiredo wrote: > Another thing to check: production mode is off? > > > On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: > >> Be sure production mode is on and that your links to the asset are using >> the asset: or context: binding prefix. >> >> Can you give us a typical asset URL (as seen by the browser)? That might >> give us some hints. >> >> Also be sure the expires headers aren't being removed by a proxy or CDN. >> Hint: doest the issue happen on your desktop with local host, or only when >> running on a server? >> On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: >> >>> Hi! >>> >>> About my T5.4 site, Google is complaining that "resources are missing >>> a cache expiration. Resources that do not specify an expiration may >>> not be cached by browsers . . . " >>> >>> I read that "assets get a far-future expires header" and will be >>> "client browsers will aggressively cache downloaded assets." So I am >>> not sure why responses for my assets all come with >>> "Cache-Control:no-cache" and "Pragma:no-cache". >>> >>> Any help would be appreciated. Thanks! >>> >>> Best Regards >>> Harry >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Best Regards Harry Zhou - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Another thing to check: production mode is off? On Sun, 21 Dec 2014 17:34:39 -0200, Bob Harner wrote: Be sure production mode is on and that your links to the asset are using the asset: or context: binding prefix. Can you give us a typical asset URL (as seen by the browser)? That might give us some hints. Also be sure the expires headers aren't being removed by a proxy or CDN. Hint: doest the issue happen on your desktop with local host, or only when running on a server? On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: Hi! About my T5.4 site, Google is complaining that "resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers . . . " I read that "assets get a far-future expires header" and will be "client browsers will aggressively cache downloaded assets." So I am not sure why responses for my assets all come with "Cache-Control:no-cache" and "Pragma:no-cache". Any help would be appreciated. Thanks! Best Regards Harry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Far Future Expiration Headers of Assets
Be sure production mode is on and that your links to the asset are using the asset: or context: binding prefix. Can you give us a typical asset URL (as seen by the browser)? That might give us some hints. Also be sure the expires headers aren't being removed by a proxy or CDN. Hint: doest the issue happen on your desktop with local host, or only when running on a server? On Dec 21, 2014 11:55 AM, "Harry Zhou" wrote: > Hi! > > About my T5.4 site, Google is complaining that "resources are missing > a cache expiration. Resources that do not specify an expiration may > not be cached by browsers . . . " > > I read that "assets get a far-future expires header" and will be > "client browsers will aggressively cache downloaded assets." So I am > not sure why responses for my assets all come with > "Cache-Control:no-cache" and "Pragma:no-cache". > > Any help would be appreciated. Thanks! > > Best Regards > Harry > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Far Future Expiration Headers of Assets
Hi! About my T5.4 site, Google is complaining that "resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers . . . " I read that "assets get a far-future expires header" and will be "client browsers will aggressively cache downloaded assets." So I am not sure why responses for my assets all come with "Cache-Control:no-cache" and "Pragma:no-cache". Any help would be appreciated. Thanks! Best Regards Harry - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: "assets" folder vulnerability
See http://jumpstart.doublenegative.com.au/jumpstart/examples/infrastructure/protectingassets . On Tuesday, 8 July 2014, Михаил Ярв wrote: > 5.3.7 > > > Mon, 07 Jul 2014 11:14:59 -0300 от "Thiago H de Paula Figueiredo" < > thiag...@gmail.com >: > >On Mon, 07 Jul 2014 10:30:42 -0300, Михаил Ярв < mixa_poi...@mail.ru > > wrote: > > > >> At present it is possible to view structure of application classes. All > >> you need is to follow "/assets/1.0.0-DEV/app/" url in Tapestry > >> application. > > > >What Tapestry version are you using? > > > >-- > >Thiago H. de Paula Figueiredo > >Tapestry, Java and Hibernate consultant and developer > >http://machina.com.br > > > >- > >To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
Re[2]: "assets" folder vulnerability
5.3.7 Mon, 07 Jul 2014 11:14:59 -0300 от "Thiago H de Paula Figueiredo" : >On Mon, 07 Jul 2014 10:30:42 -0300, Михаил Ярв < mixa_poi...@mail.ru > wrote: > >> At present it is possible to view structure of application classes. All >> you need is to follow "/assets/1.0.0-DEV/app/" url in Tapestry >> application. > >What Tapestry version are you using? > >-- >Thiago H. de Paula Figueiredo >Tapestry, Java and Hibernate consultant and developer >http://machina.com.br > >- >To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: "assets" folder vulnerability
On Mon, 07 Jul 2014 10:30:42 -0300, Михаил Ярв wrote: At present it is possible to view structure of application classes. All you need is to follow "/assets/1.0.0-DEV/app/" url in Tapestry application. What Tapestry version are you using? -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
"assets" folder vulnerability
At present it is possible to view structure of application classes. All you need is to follow "/assets/1.0.0-DEV/app/" url in Tapestry application.
Re: [t5.4-beta-10] Unable to locate asset, It should be located at META-INF/assets
The new location protects the assets and allows Tapestry to serve them up
however it wishes, eg. gzipped, renamed with checksum in name, etc.
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/META-INF-assets-in-5-4-td5714677.html
On 8 Jun 2014, at 4:41 pm, Muhammad Gelbana wrote:
> Is there a logical reason for that ? If there is, it will be easier for me
> to remember.
>
> *-*
> *Muhammad Gelbana*
> http://www.linkedin.com/in/mgelbana
>
>
> On Sun, Jun 8, 2014 at 4:08 AM, Geoff Callender <
> geoff.callender.jumpst...@gmail.com> wrote:
>
>> Not src/main/webapp/META-INF/ - use src/main/resources/META-INF/, eg.
>>
>>
>> http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript
>>
>> They will end up in your WAR's /WEB-INF/classes/META-INF/.
>>
>> Cheers,
>>
>> Geoff
>>
>> On 8 Jun 2014, at 8:14 am, Muhammad Gelbana wrote:
>>
>>> That's how I included my JS and CSS files
>>>
>>> @Import(library = { "js/jquery-1.10.2.js",
>>> "js/bootstrap.min.js",
>>> "js/plugins/metisMenu/jquery.metisMenu.js",
>>> "js/plugins/morris/raphael-2.1.0.min.js",
>>> "js/plugins/morris/morris.js",
>>> "js/sb-admin.js",
>>> "js/demo/dashboard-demo.js" },
>>>
>>> stylesheet = { "css/bootstrap.min.css",
>>> "font-awesome/css/font-awesome.css",
>>> "css/plugins/morris/morris-0.4.3.min.css",
>>> "css/plugins/timeline/timeline.css", "css/sb-admin.css" })
>>>
>>> *-*
>>> *Muhammad Gelbana*
>>> http://www.linkedin.com/in/mgelbana
>>>
>>>
>>> On Sun, Jun 8, 2014 at 1:06 AM, Muhammad Gelbana
>>> wrote:
>>>
>>>> Unable to locate ass
>>>>
>>>> et 'js/jquery-1.10.2.js' for component Index:layout. It should be
>> located
>>>> at META-IN
>>>>
>>>> F/assets/js/jquery-1.10.2.js
>>>>
>>>>
>>>> I've already placed this file in the specified location under the webapp
>>>> folder (i.e. src/main/webapp) and put the mentioned files under *js*
>>>> folder.
>>>>
>>>> The file's path on the disk is exactly
>>>> *
>>>>
>> t5-basic-bootstrap/src/main/webapp/META-INF/assets/js/jquery-1.10.2.js
>>>> *
>>>>
>>>> Where else should I place my META-INF directory if not next to the
>>>> WEB-INF ?
>>>>
>>>> *-*
>>>> *Muhammad Gel bana*
>>>> http://www.linkedin.com/in/mgelbana
>>>>
>>>>
>>>>
>>
>>
>> -
>> 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: [t5.4-beta-10] Unable to locate asset, It should be located at META-INF/assets
Is there a logical reason for that ? If there is, it will be easier for me
to remember.
*-*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Sun, Jun 8, 2014 at 4:08 AM, Geoff Callender <
geoff.callender.jumpst...@gmail.com> wrote:
> Not src/main/webapp/META-INF/ - use src/main/resources/META-INF/, eg.
>
>
> http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript
>
> They will end up in your WAR's /WEB-INF/classes/META-INF/.
>
> Cheers,
>
> Geoff
>
> On 8 Jun 2014, at 8:14 am, Muhammad Gelbana wrote:
>
> > That's how I included my JS and CSS files
> >
> > @Import(library = { "js/jquery-1.10.2.js",
> > "js/bootstrap.min.js",
> > "js/plugins/metisMenu/jquery.metisMenu.js",
> > "js/plugins/morris/raphael-2.1.0.min.js",
> > "js/plugins/morris/morris.js",
> > "js/sb-admin.js",
> > "js/demo/dashboard-demo.js" },
> >
> > stylesheet = { "css/bootstrap.min.css",
> > "font-awesome/css/font-awesome.css",
> > "css/plugins/morris/morris-0.4.3.min.css",
> > "css/plugins/timeline/timeline.css", "css/sb-admin.css" })
> >
> > *-*
> > *Muhammad Gelbana*
> > http://www.linkedin.com/in/mgelbana
> >
> >
> > On Sun, Jun 8, 2014 at 1:06 AM, Muhammad Gelbana
> > wrote:
> >
> >> Unable to locate ass
> >>
> >> et 'js/jquery-1.10.2.js' for component Index:layout. It should be
> located
> >> at META-IN
> >>
> >> F/assets/js/jquery-1.10.2.js
> >>
> >>
> >> I've already placed this file in the specified location under the webapp
> >> folder (i.e. src/main/webapp) and put the mentioned files under *js*
> >> folder.
> >>
> >> The file's path on the disk is exactly
> >> *
> >>
> t5-basic-bootstrap/src/main/webapp/META-INF/assets/js/jquery-1.10.2.js
> >> *
> >>
> >> Where else should I place my META-INF directory if not next to the
> >> WEB-INF ?
> >>
> >> *-*
> >> *Muhammad Gel bana*
> >> http://www.linkedin.com/in/mgelbana
> >>
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
Re: [t5.4-beta-10] Unable to locate asset, It should be located at META-INF/assets
Not src/main/webapp/META-INF/ - use src/main/resources/META-INF/, eg.
http://jumpstart.doublenegative.com.au/jumpstart7/examples/javascript/javascript
They will end up in your WAR's /WEB-INF/classes/META-INF/.
Cheers,
Geoff
On 8 Jun 2014, at 8:14 am, Muhammad Gelbana wrote:
> That's how I included my JS and CSS files
>
> @Import(library = { "js/jquery-1.10.2.js",
> "js/bootstrap.min.js",
> "js/plugins/metisMenu/jquery.metisMenu.js",
> "js/plugins/morris/raphael-2.1.0.min.js",
> "js/plugins/morris/morris.js",
> "js/sb-admin.js",
> "js/demo/dashboard-demo.js" },
>
> stylesheet = { "css/bootstrap.min.css",
> "font-awesome/css/font-awesome.css",
> "css/plugins/morris/morris-0.4.3.min.css",
> "css/plugins/timeline/timeline.css", "css/sb-admin.css" })
>
> *-*
> *Muhammad Gelbana*
> http://www.linkedin.com/in/mgelbana
>
>
> On Sun, Jun 8, 2014 at 1:06 AM, Muhammad Gelbana
> wrote:
>
>> Unable to locate ass
>>
>> et 'js/jquery-1.10.2.js' for component Index:layout. It should be located
>> at META-IN
>>
>> F/assets/js/jquery-1.10.2.js
>>
>>
>> I've already placed this file in the specified location under the webapp
>> folder (i.e. src/main/webapp) and put the mentioned files under *js*
>> folder.
>>
>> The file's path on the disk is exactly
>> *
>> t5-basic-bootstrap/src/main/webapp/META-INF/assets/js/jquery-1.10.2.js
>> *
>>
>> Where else should I place my META-INF directory if not next to the
>> WEB-INF ?
>>
>> *-*
>> *Muhammad Gel bana*
>> http://www.linkedin.com/in/mgelbana
>>
>>
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [t5.4-beta-10] Unable to locate asset, It should be located at META-INF/assets
That's how I included my JS and CSS files
@Import(library = { "js/jquery-1.10.2.js",
"js/bootstrap.min.js",
"js/plugins/metisMenu/jquery.metisMenu.js",
"js/plugins/morris/raphael-2.1.0.min.js",
"js/plugins/morris/morris.js",
"js/sb-admin.js",
"js/demo/dashboard-demo.js" },
stylesheet = { "css/bootstrap.min.css",
"font-awesome/css/font-awesome.css",
"css/plugins/morris/morris-0.4.3.min.css",
"css/plugins/timeline/timeline.css", "css/sb-admin.css" })
*-*
*Muhammad Gelbana*
http://www.linkedin.com/in/mgelbana
On Sun, Jun 8, 2014 at 1:06 AM, Muhammad Gelbana
wrote:
> Unable to locate ass
>
> et 'js/jquery-1.10.2.js' for component Index:layout. It should be located
> at META-IN
>
> F/assets/js/jquery-1.10.2.js
>
>
> I've already placed this file in the specified location under the webapp
> folder (i.e. src/main/webapp) and put the mentioned files under *js*
> folder.
>
> The file's path on the disk is exactly
> *
> t5-basic-bootstrap/src/main/webapp/META-INF/assets/js/jquery-1.10.2.js
> *
>
> Where else should I place my META-INF directory if not next to the
> WEB-INF ?
>
> *-*
> *Muhammad Gel bana*
> http://www.linkedin.com/in/mgelbana
>
>
>
[t5.4-beta-10] Unable to locate asset, It should be located at META-INF/assets
Unable to locate ass et 'js/jquery-1.10.2.js' for component Index:layout. It should be located at META-IN F/assets/js/jquery-1.10.2.js I've already placed this file in the specified location under the webapp folder (i.e. src/main/webapp) and put the mentioned files under *js* folder. The file's path on the disk is exactly *t5-basic-bootstrap/src/main/webapp/META-INF/assets/js/jquery-1.10.2.js* Where else should I place my META-INF directory if not next to the WEB-INF ? *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana
Assets t5.4
Hi everyone, I'm getting the following error,
(AssetSourceImpl.java:188) - Packaging of classpath assets has changed in
release 5.4; Assets should no longer be on the main classpath, but should
be moved to 'META-INF/assets/' or a sub-folder. Future releases of Tapestry
may no longer support assets on the main classpath.
I've read the following post,
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/META-INF-assets-in-5-4-td5714677.html
I'm still not sure what I'm suppose to be doing. Do I create a css folder
in META-INF/css and place my css there? If so, how do I call it?
@Import(stylesheet = {"context:t5-assets/css/layout.css"})?
Thanks,
George
Re: Assets in component library
Note that this will work differently, and more simply, in 5.4, where it's just a matter of putting them into the correct sub-folder of META-INF/assets. On Fri, Mar 28, 2014 at 2:09 PM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Fri, 28 Mar 2014 04:55:17 -0300, Nathan Quirynen < > nat...@pensionarchitects.be> wrote: > > Hey Thiago, >> > > Hi! > > > >> > > Please try /> (notice the lack of slash before assets). > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Assets in component library
On Fri, 28 Mar 2014 04:55:17 -0300, Nathan Quirynen
wrote:
Hey Thiago,
Hi!
Please try src="${classpath:assets/components/languageselector/nl.png}" /> (notice
the lack of slash before assets).
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Assets in component library
I got it working with the following:
public String getImagePath() {
return
assetSource.getClasspathAsset("classpath:com/company/tapestrylib/assets/components/languageselector/"
+ loopLocale.getLanguage() + ".png").toClientURL();
}
+
+
Files located in:
src/main/resources/com/company/tapestrylib/assets/components/languageselector/
Is this the right way then?
On 28/03/14 08:55, Nathan Quirynen wrote:
> Hey Thiago,
>
> Thanks for the reply. I indeed use the maven structure and that's
> actually something I have tried, with the following error as result:
>
> Could not convert 'classpath:/assets/components/languageselector/nl.png'
> into a component parameter binding: Error parsing property expression
> 'classpath:/assets/components/languageselector/nl.png': Unable to parse
> input at character position 11.
>
> - What I did:
>
>
>
> - Location of the file:
>
> src/main/resources/assets/components/languageselector/nl.png
>
>
> Am I forgetting something?
>
> -
>
> Also if I want to get it from inside a property getter, as the images
> are rendered in a loop, how do I get the right path?
>
> - I tried the following:
>
> return
> assetSource.getClasspathAsset("assets/components/languageselector/" +
> loopLocale.getLanguage() + ".png").toClientURL();
>
> - With following error as result:
>
> Unable to create a client URL for classpath resource
> assets/components/languageselector/en.png: The resource path was not
> within an aliased path.
>
> So yea, I'm still stuck here.
>
>
> On 27/03/14 18:14, Thiago H de Paula Figueiredo wrote:
>> On Thu, 27 Mar 2014 12:19:41 -0300, Nathan Quirynen
>> wrote:
>>
>>> Hi,
>> Hi!
>>
>>> I'm moving my components to a Tapestry component library. But I'm not
>>> sure how to handle images used in those components.
>>> Before I just put them in *src/main/webapp/images/* and then used *>> src="${context:/images/something.png" />*
>>>
>>> But what's the right way of handling images in a Tapestry library. I've
>>> been trying different things without success.
>>>
>>> 1) Where do I put my images
>> In the classpath. If you're using the Maven source folder structure,
>> and it seems you do, /src/main/resources is the place.
>>
>>> 2) How can I get the url to these images, also how if I need to get them
>>> dynamically (use of AssetSource?)
>> ${classpath:/images/something.png}
>>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Assets in component library
Hey Thiago,
Thanks for the reply. I indeed use the maven structure and that's
actually something I have tried, with the following error as result:
Could not convert 'classpath:/assets/components/languageselector/nl.png'
into a component parameter binding: Error parsing property expression
'classpath:/assets/components/languageselector/nl.png': Unable to parse
input at character position 11.
- What I did:
- Location of the file:
src/main/resources/assets/components/languageselector/nl.png
Am I forgetting something?
-
Also if I want to get it from inside a property getter, as the images
are rendered in a loop, how do I get the right path?
- I tried the following:
return
assetSource.getClasspathAsset("assets/components/languageselector/" +
loopLocale.getLanguage() + ".png").toClientURL();
- With following error as result:
Unable to create a client URL for classpath resource
assets/components/languageselector/en.png: The resource path was not
within an aliased path.
So yea, I'm still stuck here.
On 27/03/14 18:14, Thiago H de Paula Figueiredo wrote:
> On Thu, 27 Mar 2014 12:19:41 -0300, Nathan Quirynen
> wrote:
>
>> Hi,
>
> Hi!
>
>> I'm moving my components to a Tapestry component library. But I'm not
>> sure how to handle images used in those components.
>> Before I just put them in *src/main/webapp/images/* and then used *> src="${context:/images/something.png" />*
>>
>> But what's the right way of handling images in a Tapestry library. I've
>> been trying different things without success.
>>
>> 1) Where do I put my images
>
> In the classpath. If you're using the Maven source folder structure,
> and it seems you do, /src/main/resources is the place.
>
>> 2) How can I get the url to these images, also how if I need to get them
>> dynamically (use of AssetSource?)
>
> ${classpath:/images/something.png}
>
Re: Assets in component library
On Thu, 27 Mar 2014 12:19:41 -0300, Nathan Quirynen
wrote:
Hi,
Hi!
I'm moving my components to a Tapestry component library. But I'm not
sure how to handle images used in those components.
Before I just put them in *src/main/webapp/images/* and then used **
But what's the right way of handling images in a Tapestry library. I've
been trying different things without success.
1) Where do I put my images
In the classpath. If you're using the Maven source folder structure, and
it seems you do, /src/main/resources is the place.
2) How can I get the url to these images, also how if I need to get them
dynamically (use of AssetSource?)
${classpath:/images/something.png}
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Assets in component library
Hi, I'm moving my components to a Tapestry component library. But I'm not sure how to handle images used in those components. Before I just put them in *src/main/webapp/images/* and then used ** But what's the right way of handling images in a Tapestry library. I've been trying different things without success. 1) Where do I put my images 2) How can I get the url to these images, also how if I need to get them dynamically (use of AssetSource?) Thanks
Re: 5.4 ckeditor requirejs / assets
Figured it out, I found Thiago's example with the requestfilter. That seems
to have resolved my issue.
On Sat, Mar 22, 2014 at 8:07 PM, George Christman
wrote:
> now I'm getting a 200 response however it just redirects me to my home
> page.
>
>
> http://localhost:8080/auto/modules.gz/vendor/ckeditor/skins/bootstrapck/editor_gecko.css?t=E1PE
>
>
> On Sat, Mar 22, 2014 at 7:52 PM, George Christman > wrote:
>
>> Hi guys, I've been struggling to get a newer version of ckeditor working
>> with 5.4 with limited success. I'm using requirejs and have successfully
>> got my js working, however I'm running into a brick wall when it comes to
>> the css and images. It looks as if the css and images are being called
>> directly from ckeditors js files, however 404 errors for those files. My
>> assumption is it has something to do with tapestry's assets, however I'm
>> not certain. Can anybody shine some light on this for me?
>>
>> ckeditor-config module
>>
>> requirejs.config({
>> shim: {
>> 'ckeditor-jquery': ['jquery', 'ckeditor-core']
>> },
>> paths: {
>> 'ckeditor-core': 'vendor/ckeditor/ckeditor',
>> 'ckeditor-jquery': 'vendor/ckeditor/adapters/jquery'
>> }
>> });
>> define(["jquery"], function($) {
>>
>> init = function(spec) {
>> $('#' + spec.id).ckeditor();
>> };
>>
>> return init;
>> });
>>
>>
>>
>
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
>
--
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
Re: 5.4 ckeditor requirejs / assets
now I'm getting a 200 response however it just redirects me to my home
page.
http://localhost:8080/auto/modules.gz/vendor/ckeditor/skins/bootstrapck/editor_gecko.css?t=E1PE
On Sat, Mar 22, 2014 at 7:52 PM, George Christman
wrote:
> Hi guys, I've been struggling to get a newer version of ckeditor working
> with 5.4 with limited success. I'm using requirejs and have successfully
> got my js working, however I'm running into a brick wall when it comes to
> the css and images. It looks as if the css and images are being called
> directly from ckeditors js files, however 404 errors for those files. My
> assumption is it has something to do with tapestry's assets, however I'm
> not certain. Can anybody shine some light on this for me?
>
> ckeditor-config module
>
> requirejs.config({
> shim: {
> 'ckeditor-jquery': ['jquery', 'ckeditor-core']
> },
> paths: {
> 'ckeditor-core': 'vendor/ckeditor/ckeditor',
> 'ckeditor-jquery': 'vendor/ckeditor/adapters/jquery'
> }
> });
> define(["jquery"], function($) {
>
> init = function(spec) {
> $('#' + spec.id).ckeditor();
> };
>
> return init;
> });
>
>
>
--
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
5.4 ckeditor requirejs / assets
Hi guys, I've been struggling to get a newer version of ckeditor working
with 5.4 with limited success. I'm using requirejs and have successfully
got my js working, however I'm running into a brick wall when it comes to
the css and images. It looks as if the css and images are being called
directly from ckeditors js files, however 404 errors for those files. My
assumption is it has something to do with tapestry's assets, however I'm
not certain. Can anybody shine some light on this for me?
ckeditor-config module
requirejs.config({
shim: {
'ckeditor-jquery': ['jquery', 'ckeditor-core']
},
paths: {
'ckeditor-core': 'vendor/ckeditor/ckeditor',
'ckeditor-jquery': 'vendor/ckeditor/adapters/jquery'
}
});
define(["jquery"], function($) {
init = function(spec) {
$('#' + spec.id).ckeditor();
};
return init;
});
Re: Caching of assets (js libraries, css etc.)
OK, thanks for this. Seems like we're probably safe. Thanks, Luke On Fri, Mar 14, 2014 at 5:32 PM, Howard Lewis Ship wrote: > For normal assets, the URL directly includes a content hash value. This > covers stylesheets, images, fonts, and JavaScript libraries. In addition, > assets provide both far-future expires headers and ETags, to assist with > caching in the client or intermediate servers. > > Modules are a bit different because they can't include the content hash, as > the content hash would then be part of the name of the module. So no > content hash in module URLs, and no far-future expires header (since an > upgrade of the app may change the module). However, there's still ETags > support, so most module requests are quickly responded to with a 304 status > code. > > > On Fri, Mar 14, 2014 at 9:35 AM, Luke Wilson-Mawer < > lukewilsonma...@gmail.com> wrote: > > > In previous version the asset URLs contained the version, so they would > > change each time the version changed. In 5.4 this doesn't seem to be the > > case. > > > > Am I mistaken? If not, is this by design? And what's to stop assets being > > cached between releases of different versions of the software? > > > > Kind regards, > > > > Luke > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com >
Re: Caching of assets (js libraries, css etc.)
For normal assets, the URL directly includes a content hash value. This covers stylesheets, images, fonts, and JavaScript libraries. In addition, assets provide both far-future expires headers and ETags, to assist with caching in the client or intermediate servers. Modules are a bit different because they can't include the content hash, as the content hash would then be part of the name of the module. So no content hash in module URLs, and no far-future expires header (since an upgrade of the app may change the module). However, there's still ETags support, so most module requests are quickly responded to with a 304 status code. On Fri, Mar 14, 2014 at 9:35 AM, Luke Wilson-Mawer < lukewilsonma...@gmail.com> wrote: > In previous version the asset URLs contained the version, so they would > change each time the version changed. In 5.4 this doesn't seem to be the > case. > > Am I mistaken? If not, is this by design? And what's to stop assets being > cached between releases of different versions of the software? > > Kind regards, > > Luke > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Caching of assets (js libraries, css etc.)
In previous version the asset URLs contained the version, so they would change each time the version changed. In 5.4 this doesn't seem to be the case. Am I mistaken? If not, is this by design? And what's to stop assets being cached between releases of different versions of the software? Kind regards, Luke
[5.4.22] Serious issue with assets and checksums - different for same file
Hi everybody. Today we've launched a website based on 5.4. We're very exited about the upcoming release(5.4) and I'll post separately about our experiences (mostly great). Post release we've identified a potential serious issue related to assets and their checksums. What we see is that a handful of the assets generate different hashes for the same file. *=Example: bootstrap.css=* Server 1: /asset.gz/meta/92ffb14a/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 2: /asset.gz/meta/5787e482/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 3: /asset.gz/meta/f5e7c535/tapestry5/bootstrap_3_0_0/css/bootstrap.css Server 3 - restart: /asset.gz/meta/219ee41e/tapestry5/bootstrap_3_0_0/css/bootstrap.css We also see the same behaviour for the non gzip version of bootstrap.css. It is not only for /meta/ *=JCarouselWrapper.css=* /asset/app/f59da774/mixins/ui/JCarouselWrapper.css /asset/app/6ddc92ee/mixins/ui/JCarouselWrapper.css As you can see - we're load balanced with app served from several nodes. Normally I'd serve these through CloudFront on a cookieless domain (with tapestry as origin), but it's not possible as load balanced assets could hit 'wrong' server and get the 404 instead. So for now they are served through website domain with sticky sessions - and pray that it don't cause us problems... :) All are served with same web container: Apache Tomcat/7.0.39 JDK 1.7.0_11 Anyone got an idea of what's going on - and/or can verify? Have created JIRA - https://issues.apache.org/jira/browse/TAP5-2201 many thanks in advance Magnus
Re: [T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
JIRAs created:
https://issues.apache.org/jira/browse/TAP5-2167
https://issues.apache.org/jira/browse/TAP5-2168
On Sep 5, 2013, at 9:30 PM, Howard Lewis Ship wrote:
> You can leave the asset in the old location, and Tapestry will find it,
> with a warning.
>
> Or you can move it to the new location; /assets/LIB-NAME/path.js ... the
> LIB-NAME is determined from the library containing the component.
>
>
> The error message only reports the 5.3 location; it should be updated to be
> the 5.4 location (under META-INF/assets) and perhaps the 5.3 location as
> well (until 5.5, when 5.3 locations will not be supported).
>
> JIRA issue would be welcome.
>
>
>
> On Thu, Sep 5, 2013 at 5:14 PM, Lenny Primak wrote:
>
>> Now I understand how I could get so confused:
>> The error message is this:
>> targetException
>> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
>> asset 'classpath:com/flowlogix/web/mixins/js/DateFieldParserPatch.js' (the
>> file does not exist).
>>
>> But, I have to put the asset here:
>> META-INF/assets/flowlogix/js/DateFieldParserPatch.js
>>
>> Notice the lack of the com/flowlogix/web/... etc. The path in the error
>> message is wrong. This is why I got so confused on where to put these
>> assets.
>>
>> Should I file a JIRA?
>>
>> On Sep 5, 2013, at 7:56 PM, Lenny Primak wrote:
>>
>>> (answering my own question)
>>> Looks like the semantics have changed. Used to be that assets were
>> looked up relative to class package name,
>>> now they are just looked up relative to root.
>>>
>>> On Sep 5, 2013, at 6:37 PM, Lenny Primak wrote:
>>>
>>>> I am trying to migrate FlowLogix library to T5.4...
>>>> There are a whole bunch of mixins there, that use JavaScript
>> @Import(library="xxx.js").
>>>> I used to have those .js in the classpath in the same package.
>>>> Now, with the new packaging scheme, I moved them to
>> META-INF/assets/flowlogix.
>>>> After this, none of the imports work with the following exception:
>>>>
>>>> Example:
>>>> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
>> asset 'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file
>> does not exist).
>>>>
>>>> If i change the code to use
>> JavaScriptSupport.importJavaScriptLibrary("xxx.js") it starts working.
>>>> Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
>>>>
>>>> Using alpha-17
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
Will port JIRA shortly...
the 5.3 location warning is actually an error, and it should be made into a
warning though
It's really annoying because it appears SEVERE red in the logs
thanks!
On Sep 5, 2013, at 9:30 PM, Howard Lewis Ship wrote:
> You can leave the asset in the old location, and Tapestry will find it,
> with a warning.
>
> Or you can move it to the new location; /assets/LIB-NAME/path.js ... the
> LIB-NAME is determined from the library containing the component.
>
>
> The error message only reports the 5.3 location; it should be updated to be
> the 5.4 location (under META-INF/assets) and perhaps the 5.3 location as
> well (until 5.5, when 5.3 locations will not be supported).
>
> JIRA issue would be welcome.
>
>
>
> On Thu, Sep 5, 2013 at 5:14 PM, Lenny Primak wrote:
>
>> Now I understand how I could get so confused:
>> The error message is this:
>> targetException
>> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
>> asset 'classpath:com/flowlogix/web/mixins/js/DateFieldParserPatch.js' (the
>> file does not exist).
>>
>> But, I have to put the asset here:
>> META-INF/assets/flowlogix/js/DateFieldParserPatch.js
>>
>> Notice the lack of the com/flowlogix/web/... etc. The path in the error
>> message is wrong. This is why I got so confused on where to put these
>> assets.
>>
>> Should I file a JIRA?
>>
>> On Sep 5, 2013, at 7:56 PM, Lenny Primak wrote:
>>
>>> (answering my own question)
>>> Looks like the semantics have changed. Used to be that assets were
>> looked up relative to class package name,
>>> now they are just looked up relative to root.
>>>
>>> On Sep 5, 2013, at 6:37 PM, Lenny Primak wrote:
>>>
>>>> I am trying to migrate FlowLogix library to T5.4...
>>>> There are a whole bunch of mixins there, that use JavaScript
>> @Import(library="xxx.js").
>>>> I used to have those .js in the classpath in the same package.
>>>> Now, with the new packaging scheme, I moved them to
>> META-INF/assets/flowlogix.
>>>> After this, none of the imports work with the following exception:
>>>>
>>>> Example:
>>>> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
>> asset 'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file
>> does not exist).
>>>>
>>>> If i change the code to use
>> JavaScriptSupport.importJavaScriptLibrary("xxx.js") it starts working.
>>>> Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
>>>>
>>>> Using alpha-17
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
You can leave the asset in the old location, and Tapestry will find it,
with a warning.
Or you can move it to the new location; /assets/LIB-NAME/path.js ... the
LIB-NAME is determined from the library containing the component.
The error message only reports the 5.3 location; it should be updated to be
the 5.4 location (under META-INF/assets) and perhaps the 5.3 location as
well (until 5.5, when 5.3 locations will not be supported).
JIRA issue would be welcome.
On Thu, Sep 5, 2013 at 5:14 PM, Lenny Primak wrote:
> Now I understand how I could get so confused:
> The error message is this:
> targetException
> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
> asset 'classpath:com/flowlogix/web/mixins/js/DateFieldParserPatch.js' (the
> file does not exist).
>
> But, I have to put the asset here:
> META-INF/assets/flowlogix/js/DateFieldParserPatch.js
>
> Notice the lack of the com/flowlogix/web/... etc. The path in the error
> message is wrong. This is why I got so confused on where to put these
> assets.
>
> Should I file a JIRA?
>
> On Sep 5, 2013, at 7:56 PM, Lenny Primak wrote:
>
> > (answering my own question)
> > Looks like the semantics have changed. Used to be that assets were
> looked up relative to class package name,
> > now they are just looked up relative to root.
> >
> > On Sep 5, 2013, at 6:37 PM, Lenny Primak wrote:
> >
> >> I am trying to migrate FlowLogix library to T5.4...
> >> There are a whole bunch of mixins there, that use JavaScript
> @Import(library="xxx.js").
> >> I used to have those .js in the classpath in the same package.
> >> Now, with the new packaging scheme, I moved them to
> META-INF/assets/flowlogix.
> >> After this, none of the imports work with the following exception:
> >>
> >> Example:
> >> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate
> asset 'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file
> does not exist).
> >>
> >> If i change the code to use
> JavaScriptSupport.importJavaScriptLibrary("xxx.js") it starts working.
> >> Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
> >>
> >> Using alpha-17
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
Now I understand how I could get so confused:
The error message is this:
targetException
org.apache.tapestry5.ioc.internal.OperationException: Unable to locate asset
'classpath:com/flowlogix/web/mixins/js/DateFieldParserPatch.js' (the file does
not exist).
But, I have to put the asset here:
META-INF/assets/flowlogix/js/DateFieldParserPatch.js
Notice the lack of the com/flowlogix/web/... etc. The path in the error
message is wrong. This is why I got so confused on where to put these assets.
Should I file a JIRA?
On Sep 5, 2013, at 7:56 PM, Lenny Primak wrote:
> (answering my own question)
> Looks like the semantics have changed. Used to be that assets were looked up
> relative to class package name,
> now they are just looked up relative to root.
>
> On Sep 5, 2013, at 6:37 PM, Lenny Primak wrote:
>
>> I am trying to migrate FlowLogix library to T5.4...
>> There are a whole bunch of mixins there, that use JavaScript
>> @Import(library="xxx.js").
>> I used to have those .js in the classpath in the same package.
>> Now, with the new packaging scheme, I moved them to
>> META-INF/assets/flowlogix.
>> After this, none of the imports work with the following exception:
>>
>> Example:
>> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate asset
>> 'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file does not
>> exist).
>>
>> If i change the code to use
>> JavaScriptSupport.importJavaScriptLibrary("xxx.js") it starts working.
>> Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
>>
>> Using alpha-17
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
(answering my own question)
Looks like the semantics have changed. Used to be that assets were looked up
relative to class package name,
now they are just looked up relative to root.
On Sep 5, 2013, at 6:37 PM, Lenny Primak wrote:
> I am trying to migrate FlowLogix library to T5.4...
> There are a whole bunch of mixins there, that use JavaScript
> @Import(library="xxx.js").
> I used to have those .js in the classpath in the same package.
> Now, with the new packaging scheme, I moved them to META-INF/assets/flowlogix.
> After this, none of the imports work with the following exception:
>
> Example:
> org.apache.tapestry5.ioc.internal.OperationException: Unable to locate asset
> 'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file does not
> exist).
>
> If i change the code to use
> JavaScriptSupport.importJavaScriptLibrary("xxx.js") it starts working.
> Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
>
> Using alpha-17
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
[T5.4] @Import(library=xxx) doesn't work for META-INF/assset/xxx assets from library
I am trying to migrate FlowLogix library to T5.4...
There are a whole bunch of mixins there, that use JavaScript
@Import(library="xxx.js").
I used to have those .js in the classpath in the same package.
Now, with the new packaging scheme, I moved them to META-INF/assets/flowlogix.
After this, none of the imports work with the following exception:
Example:
org.apache.tapestry5.ioc.internal.OperationException: Unable to locate asset
'classpath:com/flowlogix/web/mixins/PeriodicUpdater.js' (the file does not
exist).
If i change the code to use JavaScriptSupport.importJavaScriptLibrary("xxx.js")
it starts working.
Assuming this is a bug, should I file a JIRA? Seems pretty bad to me.
Using alpha-17
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: load all assets in folder
Oh, i thought there is some trick for that in Tapestry (as usually :)). So for completeness i'm sending my raw solution... Thank you for advise.@Injectprivate Context context;@Injectprivate PersistentLocale persistentLocale;@Injectprivate AssetSource assetSource;File resource = context.getRealFile("/images/backgrounds/");String[] list = resource.list();if (list != null){ Random r = new Random(); int index = r.nextInt(list.length); Asset result = assetSource.getContextAsset( "context:/images/backgrounds/" + list[index], persistentLocale.get()); return result;}return null;BR,JanOn Sat, 11 May 2013 23:49:50 +0200, Thiago H de Paula Figueiredo wrote:On Sat, 11 May 2013 17:42:34 -0300, Jan Fryblik wrote:Hi guys,Hi!i just created simple slider component. Now i'm wondering, is somehow possible to load all images from context path? I mean, i have for instance folder /webapp/images/slider and i need to get all images in the directory without knowing image names. Thanks for answer.Just do what you'd do in a Servlet environment without Tapestry. See first answer to http://stackoverflow.com/questions/11195532/in-java-is-it-possible-to-get-a-directory-file-listing-inside-a-war-classpath-us.-- Thiago H. de Paula Figueiredo
Re: load all assets in folder
On Sat, 11 May 2013 17:42:34 -0300, Jan Fryblik wrote:Hi guys,Hi!i just created simple slider component. Now i'm wondering, is somehow possible to load all images from context path? I mean, i have for instance folder /webapp/images/slider and i need to get all images in the directory without knowing image names. Thanks for answer.Just do what you'd do in a Servlet environment without Tapestry. See first answer to http://stackoverflow.com/questions/11195532/in-java-is-it-possible-to-get-a-directory-file-listing-inside-a-war-classpath-us.-- Thiago H. de Paula Figueiredo
load all assets in folder
Hi guys,i just created simple slider component. Now i'm wondering, is somehow possible to load all images from context path? I mean, i have for instance folder /webapp/images/slider and i need to get all images in the directory without knowing image names. Thanks for answer.BR,Jan
Re: Switching assets based on something different than language
Tapestry 5.3 introduces the idea of skinning: its broken up into a couple of parts. One part is looking at the request to determine the "axes" (plural of axis) of customization. In your case, one axis would be locale (which is built into Tapestry). The other axis would be based on tenant, which you should be able to determine from the request, based on the host name in the request. Once you have that, you can define rules for mapping a base Resource to a skinned version of a Resource; the built-in Tapestry code for this adds suffixes to the base file name to identify the locale. I would typically use a sub-folder based on (in your example tenant, then use the standard localization there (since that's built directly into the Resource API). http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/pageload/ComponentResourceSelector.html http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/services/pageload/ComponentRequestSelectorAnalyzer.html On Wed, Dec 19, 2012 at 9:05 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, 19 Dec 2012 14:33:55 -0200, nquirynen > wrote: > > Maybe you can make an implementation of AssetSource >> > > Better yet, an AssetFactory. Take a look in the Tapestry sources of > ClasspathAssetFactory and ContextAssetFactory. > > -- > Thiago H. de Paula Figueiredo > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
Re: Switching assets based on something different than language
On Wed, 19 Dec 2012 14:33:55 -0200, nquirynen wrote: Maybe you can make an implementation of AssetSource Better yet, an AssetFactory. Take a look in the Tapestry sources of ClasspathAssetFactory and ContextAssetFactory. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Switching assets based on something different than language
Maybe you can make an implementation of AssetSource -- View this message in context: http://tapestry.1045711.n5.nabble.com/Switching-assets-based-on-something-different-than-language-tp5718854p5718856.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Switching assets based on something different than language
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tapestry has a great mechanism to switch assets based on the user's language. Now I would like to have something like that based not on language but the user's tenant (the system is multi-tenanted). So - what is the preferred approach to switch assets (images, js and css) based on data other than the user's language? Thanks - - Arno -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDR5BUACgkQbmZsMyUPuXRKwwCeOmtqeQ0wE2StbIykiyveFzCc 2+IAn0zCc7hEcCq4CBJuGSQ6+dDiqSye =8rx8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic Assets
Yes as I said, AssetSource is the service. AssetSourceImpl is the
implementation.
You inject the service.
Cheers,
Dragan Sahpaski
On Sun, Oct 28, 2012 at 11:35 PM, sommeralex wrote:
> works now with
>
> @Inject
> private AssetSource assetSource;
>
> assetSource.getExpandedAsset("context:/img/icon/star/starScore00.png").toClientURL();
>
> thx
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354p5717361.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> -
> 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: Dynamic Assets
works now with
@Inject
private AssetSource assetSource;
assetSource.getExpandedAsset("context:/img/icon/star/starScore00.png").toClientURL();
thx
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354p5717361.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic Assets
Hi!
Thx for your answer.
I tried to
@Inject
private AssetSourceImpl assetSource;
but it keeps saying that
No service implements the interface
org.apache.tapestry5.internal.services.AssetSourceImpl.
i thought AssetSourceIMPL is the implementation???!
2012/10/28 Dragan Sahpaski [via Tapestry] <
ml-node+s1045711n5717359...@n5.nabble.com>
> See the AssetSource service [1]. I use AssetSource.getExpandedAsset alot.
> Ex: assetSource.getExpandedAsset("classpath:/com/mycompany/logo.png");
>
>
> [1] AssetSource:
>
> http://tapestry.apache.org/5.3.5/apidocs/org/apache/tapestry5/services/AssetSource.html
>
> Cheers,
> Dragan Sahpaski
>
>
> On Sun, Oct 28, 2012 at 8:55 PM, sommeralex <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5717359&i=0>>
> wrote:
>
> > Hello,
> >
> > Which is the best way for using dynamic assets?
> >
> > In one of my classes, i have too much asset declarations now..
> >
> > @Inject
> > @Path("context:/img/icon/star/starScore20.png")
> > private Asset star20Asset;
> >
> > What i would prefer is a method which directly is generating the asset
> > (dynamically) - because it happens that many of the defined assets and
> dont
> > need.
> >
> > e.g:
> >
> > if (rating == 0){
> > Asset asset = new Asset("context:/img/icon/star/starScore20.png")
> > return asset.toClientURL();
> > } else if (rating <= 0.5) { ... }
> >
> > ..but fore sure, new Asset(...) does not exist.
> >
> > any ideas?
> > thx
> > alex
> >
> >
> >
> > --
> > View this message in context:
> http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354.html
> > Sent from the Tapestry - User mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=5717359&i=1>
> > For additional commands, e-mail: [hidden
> > email]<http://user/SendEmail.jtp?type=node&node=5717359&i=2>
> >
>
> -----
> To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5717359&i=3>
> For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5717359&i=4>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354p5717359.html
> To unsubscribe from Dynamic Assets, click
> here<http://tapestry.1045711.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5717354&code=YWxleGFuZGVyLnNvbW1lckBnbWFpbC5jb218NTcxNzM1NHwxMDUzMzQxMzM4>
> .
> NAML<http://tapestry.1045711.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354p5717360.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
Dynamic Assets
Hello,
Which is the best way for using dynamic assets?
In one of my classes, i have too much asset declarations now..
@Inject
@Path("context:/img/icon/star/starScore20.png")
private Asset star20Asset;
What i would prefer is a method which directly is generating the asset
(dynamically) - because it happens that many of the defined assets and dont
need.
e.g:
if (rating == 0){
Asset asset = new Asset("context:/img/icon/star/starScore20.png")
return asset.toClientURL();
} else if (rating <= 0.5) { ... }
..but fore sure, new Asset(...) does not exist.
any ideas?
thx
alex
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Dynamic-Assets-tp5717354.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: PerThread Scope and Assets
Thanks Howard :) On Fri, Jul 27, 2012 at 6:10 PM, Howard Lewis Ship wrote: > I wouldn't worry about it; there's a lot of caching going on inside > AssetSourceImpl. > > Don't prematurely optimize ... but plan to do real performance testing > if you are expecting your application to be regurlarily saturated. > Otherwise, keep your eyes on your database queries and let the rest > shake out. > > On Fri, Jul 27, 2012 at 1:13 PM, Juan E. Maya wrote: >> Hello, >> >> first of all i am very glad to go back to work with T5 :) I was >> missing the mailing list. :) >> >> I know the PerThread scope service are created per request, but i >> don't want the object to be created for every asset that is loaded, i >> only needed for the PageRender cycle. >> Is there a way to avoid the extra instantiations ? >> >> Thank you >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > - > 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: PerThread Scope and Assets
I wouldn't worry about it; there's a lot of caching going on inside AssetSourceImpl. Don't prematurely optimize ... but plan to do real performance testing if you are expecting your application to be regurlarily saturated. Otherwise, keep your eyes on your database queries and let the rest shake out. On Fri, Jul 27, 2012 at 1:13 PM, Juan E. Maya wrote: > Hello, > > first of all i am very glad to go back to work with T5 :) I was > missing the mailing list. :) > > I know the PerThread scope service are created per request, but i > don't want the object to be created for every asset that is loaded, i > only needed for the PageRender cycle. > Is there a way to avoid the extra instantiations ? > > Thank you > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
PerThread Scope and Assets
Hello, first of all i am very glad to go back to work with T5 :) I was missing the mailing list. :) I know the PerThread scope service are created per request, but i don't want the object to be created for every asset that is loaded, i only needed for the PageRender cycle. Is there a way to avoid the extra instantiations ? Thank you - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
And what an awesome module it is! On Apr 25, 2012, at 8:01 AM, Cezary Biernacki wrote: > On Wed, Apr 25, 2012 at 1:09 AM, yazdog8 wrote: > >> If you're using Less CSS (or maybe sass possibly), you can set some basic >> variables at the top of your file that can be used as a cache buster in >> your >> paths. >> >> http://lesscss.org/#-variables >> > > And you can even directly integrate LessCSS with Tapestry using my > t5conduit library: > https://github.com/cezary-biernacki/t5conduit > > Best regards, > Cezary - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
For practical reasons, I hold all css and image files, directly on server. And I reference full path from application. Its easier for designer to do changes directly on the server, and to not handle with any IDE that we use. They mostly use Dreamweaver for editing css. Bojan -- View this message in context: http://tapestry.1045711.n5.nabble.com/Recommended-method-to-reference-assets-in-css-file-tp5663514p5664720.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
On Wed, Apr 25, 2012 at 1:09 AM, yazdog8 wrote: > If you're using Less CSS (or maybe sass possibly), you can set some basic > variables at the top of your file that can be used as a cache buster in > your > paths. > > http://lesscss.org/#-variables > And you can even directly integrate LessCSS with Tapestry using my t5conduit library: https://github.com/cezary-biernacki/t5conduit Best regards, Cezary
Re: Recommended method to reference assets in .css file?
I put all that kind of css in my layout.tml file and I have an environmental object that lets me add to that from pages/components. Usually there is not a lot of it and it let's me easily move all the images to a CDN. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Recommended-method-to-reference-assets-in-css-file-tp5663514p5664625.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
On Tue, Apr 24, 2012 at 4:04 PM, Chris Mylonas wrote:
> Good question - I don't know about from within a CSS file.
> ...
> Looking into the tapestry source, specifically
> src/main/resources/org/apache/tapestry5/tapestry-console.css
> it uses relative links to the pics in
> src/main/resources/org/apache/tapestry5/silk/ [error.png|cancel.png|]
> ...
> In the same src/main/resources/org/apache/tapestry5/ - there is the
> default.css class.
> Here is a snippet
> IMG.t-autoloader-icon {
> margin-left: 4px;
> width: 16px;
> height: 16px;
> background: url(ajax-loader.gif);
> }
Duh, thanks for the hint. :)
With my images under src/main/webapp/images, I was using
../../../images/ when all I need to do is use
../ctx/images/.
Problem solved, thanks!
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
If you're using Less CSS (or maybe sass possibly), you can set some basic variables at the top of your file that can be used as a cache buster in your paths. http://lesscss.org/#-variables -- View this message in context: http://tapestry.1045711.n5.nabble.com/Recommended-method-to-reference-assets-in-css-file-tp5663514p5663546.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Recommended method to reference assets in .css file?
Hi Dave,
Good question - I don't know about from within a CSS file.
However within a template it offers this:
from this page: https://tapestry.apache.org/assets.html
image/tapestry_banner.gif lives in src/main/webapp/images/tapestry_banner.gif
Looking into the tapestry source, specifically
src/main/resources/org/apache/tapestry5/tapestry-console.css
it uses relative links to the pics in
src/main/resources/org/apache/tapestry5/silk/ [error.png|cancel.png|]
In the same src/main/resources/org/apache/tapestry5/ - there is the
default.css class.
Here is a snippet
IMG.t-autoloader-icon {
margin-left: 4px;
width: 16px;
height: 16px;
background: url(ajax-loader.gif);
}
and ajax-loader.gif is in src/main/resources/org/apache/tapestry5
If that is anything to go by
*shrug*
Cheers
Chris
On 25/04/2012, at 8:47 AM, David Rees wrote:
> What's the recommended method to reference assets in a .css file - for
> example background images?
>
> Currently I use a hard-coded relative URL, but this has the drawback
> of causing the browser to cache the resource after it's changed
> leading to browsers caching old resources unless I change the name of
> the resource.
>
> I've seen one suggestion to pull that particular css out of the css
> file and add it as part of a layout so it's included on each page and
> a ${asset} reference can be used, but that kind of defeats the purpose
> of using an external css file.
>
> What are people generally doing here?
>
> -Dave
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
Recommended method to reference assets in .css file?
What's the recommended method to reference assets in a .css file - for
example background images?
Currently I use a hard-coded relative URL, but this has the drawback
of causing the browser to cache the resource after it's changed
leading to browsers caching old resources unless I change the name of
the resource.
I've seen one suggestion to pull that particular css out of the css
file and add it as part of a layout so it's included on each page and
a ${asset} reference can be used, but that kind of defeats the purpose
of using an external css file.
What are people generally doing here?
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: RequestFilter running after serving assets
On Wed, 04 Apr 2012 21:08:10 -0300, Manuel Sugawara wrote: Yeah, I guess that will work. So, let me rephrase, When is appropriate to use a dispatcher and when a filter? Dispatchers are meant to provide a response to a request. Request filters are better suited for applying logic which is cross-page. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: RequestFilter running after serving assets
On Wed, Apr 4, 2012 at 6:48 PM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > On Wed, 04 Apr 2012 19:47:48 -0300, Manuel Sugawara < > manuel.sugaw...@gmail.com> wrote: > > Hi all, >> > > Hi! > > > I have a RequestFilter that serves some content from the database and I >> would like that it run after the assets dispatcher in order to avoid the >> creation of the service that access the database. Is this possible?. >> > > Why don't you write it as a Dispatcher instead? Yeah, I guess that will work. So, let me rephrase, When is appropriate to use a dispatcher and when a filter? Thanks. Regards, Manuel.
Re: RequestFilter running after serving assets
On Wed, 04 Apr 2012 19:47:48 -0300, Manuel Sugawara wrote: Hi all, Hi! I have a RequestFilter that serves some content from the database and I would like that it run after the assets dispatcher in order to avoid the creation of the service that access the database. Is this possible?. Why don't you write it as a Dispatcher instead? How are dispatchers and filters related?. The dispatchers are invoked by a RequestFilter added as the the terminator (last RequestFilter executed in the pipeline). Any pointers to the docs would also be appreciated. http://tapestry.apache.org/request-processing.html, specially the diagram in the end. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RequestFilter running after serving assets
Hi all, I have a RequestFilter that serves some content from the database and I would like that it run after the assets dispatcher in order to avoid the creation of the service that access the database. Is this possible?. How are dispatchers and filters related?. Any pointers to the docs would also be appreciated. Regards, Manuel.
Re: Serving Tapestry5 Assets As Static Resources
yes i meant the minimizer, but howard has also hinted tapestry may do more modification in future: Re: Versioned assets (22/02/2012 6:05 AM) "The perfect solution would involve the following: - The version number if replaced with the SHA1 hash of the resource's (uncompressed) content - All CSS is dynamically rewritten to convert relative references into full paths including the correct SHA1 hash" p. On 12/03/2012 8:38 PM, Dmitry Gusev wrote: What do you mean by "css is already modified on the way out"? It's only modified as bytes stream to do gzip compression. Also yuicompressor modifies it somehow by removing not necessary spaces and semicolons, thats all. So for now you have to write your own css preprocessor to implement this. On Sun, Mar 11, 2012 at 23:58, Paul Stanton wrote: nice! i'd like to see the checksum approach in tapestry and since css is already modified on the way out, the checksum url 'could' be applied to relative paths in css? maybe... On 12/03/2012 12:02 AM, Dmitry Gusev wrote: FYI: http://dmitrygusev.blogspot.**com/2012/03/serving-tapestry5-** assets-as-static.html<http://dmitrygusev.blogspot.com/2012/03/serving-tapestry5-assets-as-static.html> --**--**- To unsubscribe, e-mail: users-unsubscribe@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: Serving Tapestry5 Assets As Static Resources
What do you mean by "css is already modified on the way out"? It's only modified as bytes stream to do gzip compression. Also yuicompressor modifies it somehow by removing not necessary spaces and semicolons, thats all. So for now you have to write your own css preprocessor to implement this. On Sun, Mar 11, 2012 at 23:58, Paul Stanton wrote: > nice! i'd like to see the checksum approach in tapestry and since css is > already modified on the way out, the checksum url 'could' be applied to > relative paths in css? maybe... > > On 12/03/2012 12:02 AM, Dmitry Gusev wrote: > >> FYI: >> >> http://dmitrygusev.blogspot.**com/2012/03/serving-tapestry5-** >> assets-as-static.html<http://dmitrygusev.blogspot.com/2012/03/serving-tapestry5-assets-as-static.html> >> >> > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Serving Tapestry5 Assets As Static Resources
nice! i'd like to see the checksum approach in tapestry and since css is already modified on the way out, the checksum url 'could' be applied to relative paths in css? maybe... On 12/03/2012 12:02 AM, Dmitry Gusev wrote: FYI: http://dmitrygusev.blogspot.com/2012/03/serving-tapestry5-assets-as-static.html - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Serving Tapestry5 Assets As Static Resources
FYI: http://dmitrygusev.blogspot.com/2012/03/serving-tapestry5-assets-as-static.html -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Question about caching of assets ...
On Wed, 29 Feb 2012 04:56:17 -0300, Gunnar Eketrapp wrote: Hi! Hi! Would it be possible to tell clients to cache assets for ever and use the version to force a reload. I.e. the way I thought it worked ... As Steve said, you can't control what the browser requests. The Tapestry trick is to implement an AssetSource that provides asset URLs with the application version configuration inside. I think you should do the same, using some kind of hash value or version id. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Question about caching of assets ...
Hi! Caching seems complex and I am fairly new to it. I found out that T5 delivers a 304 for assets that have not been modified since they where fetched. I.e. there is one server request per asset. [When serving an asset T5 delivers a last modified header. And clients sends If-Modified-Since when asking for an asset.] My question is, if my findings are correct. Would it be possible to tell clients to cache assets for ever and use the version to force a reload. I.e. the way I thought it worked ... /Gunnar 2012/2/28 Steve Eynon > Hi, > > I'm sure if you're asking about what T5 serves up, or how the client > interprets what it is served? > > Ultimately you have no control over what the client does - if the > client wants to make a request, it'll make a request. At best all the > server can do is 'suggest' and 'hint' to the client that it uses it's > cache. Hence the 304's, the If-Modified-Since headers and everything > else we throw at the client. > > But if the client has a small cache limit, or is new to the site, then > regardless, it's going to make lots of requests. > > Steve. > > On 27 February 2012 22:58, Gunnar Eketrapp > wrote: > > Hi! > > > > Recently I made a fix so that my uploaded images (stored in db) are > cached. > > > > I did this by returning status 304 (HTTP status not modified) as I found > > out that T5 handles asset requests in that way. > > > > But this means that the client has to perform a request for each > > asset/image. > > > > I thought that the adding of the application version to the assets url > was > > there to inform clients when assets needed to be refetched > > and that they should be fetched from client cache (without a request) > > otherwise. > > > > For my images, the ideal would be as Howard pointed out to add a hashed > > signature to my image url:s and to cache them forever on client side. > > > > But as I found out T5 assets are not handled that way I skipped the hash > > code and just performed a check on the header "If-Modified-Since". > > > > What have I missed? Am I right when i say that T5 assets are handled > with > > a request + 304 reply. > > > > Thanks in advance, > > Gunnar Eketrapp > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- [Hem: 08-715 59 57, Mobil: 0708-52 62 90] Allévägen 2A, 132 42 Saltsjö-Boo
Re: Question about caching of assets ...
Hi, I'm sure if you're asking about what T5 serves up, or how the client interprets what it is served? Ultimately you have no control over what the client does - if the client wants to make a request, it'll make a request. At best all the server can do is 'suggest' and 'hint' to the client that it uses it's cache. Hence the 304's, the If-Modified-Since headers and everything else we throw at the client. But if the client has a small cache limit, or is new to the site, then regardless, it's going to make lots of requests. Steve. On 27 February 2012 22:58, Gunnar Eketrapp wrote: > Hi! > > Recently I made a fix so that my uploaded images (stored in db) are cached. > > I did this by returning status 304 (HTTP status not modified) as I found > out that T5 handles asset requests in that way. > > But this means that the client has to perform a request for each > asset/image. > > I thought that the adding of the application version to the assets url was > there to inform clients when assets needed to be refetched > and that they should be fetched from client cache (without a request) > otherwise. > > For my images, the ideal would be as Howard pointed out to add a hashed > signature to my image url:s and to cache them forever on client side. > > But as I found out T5 assets are not handled that way I skipped the hash > code and just performed a check on the header "If-Modified-Since". > > What have I missed? Am I right when i say that T5 assets are handled with > a request + 304 reply. > > Thanks in advance, > Gunnar Eketrapp - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Question about caching of assets ...
Hi! Recently I made a fix so that my uploaded images (stored in db) are cached. I did this by returning status 304 (HTTP status not modified) as I found out that T5 handles asset requests in that way. But this means that the client has to perform a request for each asset/image. I thought that the adding of the application version to the assets url was there to inform clients when assets needed to be refetched and that they should be fetched from client cache (without a request) otherwise. For my images, the ideal would be as Howard pointed out to add a hashed signature to my image url:s and to cache them forever on client side. But as I found out T5 assets are not handled that way I skipped the hash code and just performed a check on the header "If-Modified-Since". What have I missed? Am I right when i say that T5 assets are handled with a request + 304 reply. Thanks in advance, Gunnar Eketrapp
Re: Versioned assets
ch includes the pathPrefix first
and a
trailing slash.
*/
private final MappathToHandler =
CollectionFactory.newMap();
/**
* List of path prefixes in the pathToHandler, sorted be descending
length.
*/
private final ListassetPaths = CollectionFactory.newList();
private final String pathPrefix;
// PATCH +
private final String pathPrefixPattern;
public AssetDispatcher(Map
configuration,
@Symbol(SymbolConstants.APPLICATION_VERSION) String
applicationVersion,
@Symbol(SymbolConstants.APPLICATION_FOLDER) String applicationFolder,
@Symbol(SymbolConstants.ASSET_PATH_PREFIX) String assetPathPrefix)
{
String folder = applicationFolder.equals("") ? "" : "/" +
applicationFolder;
this.pathPrefix = folder + assetPathPrefix + applicationVersion +
"/";
// PATCH +
this.pathPrefixPattern = "^" + folder + assetPathPrefix +
"[^/]{1,}/(.*)$";
for (String path : configuration.keySet())
{
String extendedPath = this.pathPrefix + path + "/";
pathToHandler.put(extendedPath, configuration.get(path));
assetPaths.add(extendedPath);
}
// Sort by descending length
Collections.sort(assetPaths, new Comparator()
{
public int compare(String o1, String o2)
{
return o2.length() - o1.length();
}
});
}
public boolean dispatch(Request request, Response response) throws
IOException
{
String path = request.getPath();
// Remember that the request path does not include the context
path,
so we can simply start
// looking for the asset path prefix right off the bat.
if (!path.startsWith(pathPrefix))
{
// PATCH +
if (path.matches(pathPrefixPattern))
{
// send 302 temporary redirect to the version this server
is
using
String newPath = request.getContextPath() +
path.replaceAll(pathPrefixPattern, pathPrefix + "$1");
response.setHeader("Location", newPath);
response.sendError(HttpServletResponse.SC_MOVED_TEMPORARILY,
newPath);
return true;
}
return false;
}
for (String extendedPath : assetPaths)
{
if (path.startsWith(extendedPath))
{
AssetRequestHandler handler =
pathToHandler.get(extendedPath);
String extraPath = path.substring(extendedPath.length());
boolean handled = handler.handleAssetRequest(request,
response, extraPath);
if (handled)
{
return true;
}
}
}
response.sendError(HttpServletResponse.SC_NOT_FOUND, path);
return true;
}
}
On 22/02/2012 6:05 AM, Howard Lewis Ship wrote:
I suspect the 302 redirect may be the correct solution, and Tapestry
could support this pretty reasonably.
The perfect solution would involve the following:
- The version number if replaced with the SHA1 hash of the resource's
(uncompressed) content
- All CSS is dynamically rewritten to convert relative references into
full paths including the correct SHA1 hash
I wonder if the 302 redirect could act as a way to avoid rewriting the
CSS?
On Sun, Feb 19, 2012 at 7:57 PM, Paul Stanton
wrote:
Hi Cezary,
I think I have the same need as you.
We use load balanced servers, and when upgrading we upgrade one at a
time
so
that there is always a server running.
But the side effect is that the upgraded server can receive requests
for
the
old assets, and we don't want to fail in this case.
In the past (5.1) I monkey-patched AssetResourceLocatorImpl to allow<=
version number requests.
However in migrating to 5.3 I would like a better solution, and the
implementation is different now anyway.
I like the idea of the 302 redirect.
How did you end up solving this? Is it possible to just contribute
your
own
AssetDispatcher instead of just replacing the class?
Thanks, Paul.
On 24/03/2011 10:09 AM, Cezary Biernacki wrote:
Perhaps the AssetDispatcher could check the requested version number
and
if
it doesn't match the app version, send a 302 redirect to the
"correct"
URL?
/assets/1.3/ctx/script.js -->/assets/1.2/ctx/script.js
Or perhaps it should only deliver the asset if the requested version
os
older than or equal to the app version?
Determining "older" and "newer" would however assume people name
their
application versions in a certain way.
It is exactly what I did in my application. I have overridden
AssetsDispatcher service with my copy based on original one, that
differs
only in handling missing resources: if resource actually exists but
just
version numbers differ, my dispatcher just sends redirec
Re: Versioned assets
Most of the time, you should avoid using the regex methods on the String
class (split, matches, replace etc) as these will compile the
java.util.regex.Pattern for every invocation.
Instead, you should Pattern.compile(regex) once and save the result then
use Pattern.matches(value).
On Wednesday, 22 February 2012, Paul Stanton wrote:
> By the way all,
>
> Here is a solution which does not require any changes to tapestry code.
All code is free to use.
>
> 1. contribute a dispatcher to MasterDispatcher, just before the regular
AssetDispatcher:
>
>public static void bind(ServiceBinder binder)
>{
>binder.bind(Dispatcher.class,
AssetVersionCheckDispatcher.class).withId("AssetVersionCheckDispatcher");
>}
>
>public static void
contributeMasterDispatcher(OrderedConfiguration configuration,
//
>@InjectService("AssetVersionCheckDispatcher") Dispatcher
assetVersionCheckDispatcher)
>{
>configuration.add("AssetVersionCheckDispatcher",
assetVersionCheckDispatcher, "before:AssetDispatcher");
>}
>
> 2. Implementation of AssetVersionCheckDispatcher:
>
> public class AssetVersionCheckDispatcher implements Dispatcher
> {
>private final String pathPrefix;
>private final String pathPrefixPattern;
>
>public
AssetVersionCheckDispatcher(@Symbol(SymbolConstants.APPLICATION_VERSION)
String appVersion,
>@Symbol(SymbolConstants.APPLICATION_FOLDER) String appFolder,
>@Symbol(SymbolConstants.ASSET_PATH_PREFIX) String
assetPathPrefix)
>{
>String folder = appFolder.equals("") ? "" : "/" + appFolder;
>this.pathPrefix = folder + assetPathPrefix + appVersion + "/";
>this.pathPrefixPattern = "^" + folder + assetPathPrefix +
"[^/]{1,}/(.*)$";
>}
>
>@Override
>public boolean dispatch(Request request, Response response) throws
IOException
>{
>String path = request.getPath();
>
>if (!path.startsWith(pathPrefix))
>{
>if (path.matches(pathPrefixPattern))
>{
>// send 302 temporary redirect to the current version
>String newPath = request.getContextPath() +
path.replaceFirst(pathPrefixPattern, pathPrefix + "$1");
>response.setHeader("Location", newPath);
>
response.sendError(HttpServletResponse.SC_MOVED_TEMPORARILY, newPath);
>return true;
>}
>}
>
>return false;
>}
> }
>
> On 22/02/2012 11:08 AM, Paul Stanton wrote:
>
> Didn't think there was a Jira yet, I'll try to get around to logging it
later this week.
>
> On 22/02/2012 8:38 AM, Howard Lewis Ship wrote:
>
> Patches are best provided on JIRA; there's a checkbox that shows you
> have granted the rights to the patch& code to the Apache Software
> Foundation. Thanks!
>
> On Tue, Feb 21, 2012 at 12:28 PM, Paul Stanton
wrote:
>
> Here's my implementation:
>
> // Copyright 2006, 2008, 2009, 2010, 2011 The Apache Software Foundation
> //
> // Licensed under the Apache License, Version 2.0 (the "License");
> // you may not use this file except in compliance with the License.
> // You may obtain a copy of the License at
> //
> // http://www.apache.org/licenses/LICENSE-2.0
> //
> // Unless required by applicable law or agreed to in writing, software
> // distributed under the License is distributed on an "AS IS" BASIS,
> // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
> // See the License for the specific language governing permissions and
> // limitations under the License.
>
> package org.apache.tapestry5.internal.services;
>
> import java.io.IOException;
> import java.util.Collections;
> import java.util.Comparator;
> import java.util.List;
> import java.util.Map;
>
> import javax.servlet.http.HttpServletResponse;
>
> import org.apache.tapestry5.SymbolConstants;
> import org.apache.tapestry5.ioc.annotations.Symbol;
> import org.apache.tapestry5.ioc.annotations.UsesMappedConfiguration;
> import org.apache.tapestry5.ioc.internal.util.CollectionFactory;
> import org.apache.tapestry5.services.ClasspathAssetAliasManager;
> import org.apache.tapestry5.services.Dispatcher;
> import org.apache.tapestry5.services.Request;
> import org.apache.tapestry5.services.Response;
> import org.apache.tapestry5.services.assets.AssetRequestHandler;
>
> /**
> * Recognizes requests where the path begins with "/asset/" and delivers
the
> content therein as a bytestream. Also
> * handles requests that are simply polling for a change to the file.
> *
> * @see ResourceStreamer
> * @see ClasspathAssetAliasManager
> * @see AssetRequestHandler
> */
> // PATCHED incorrect APPLICATION_VERSION 302 temporary redirect to current
> APPLICATION_VERSION
>
> // PATCH +
> @SuppressWarnings("all")
> @UsesMappedConfiguration(AssetRequestHandler.class)
> public class AssetDispatcher implements Dispatcher
> {
>/**
> * Keyed on extended path name, which includes the pathPrefix first
and a
> trailing slash.
> */
>private f
Re: Versioned assets
pestry5.services.ClasspathAssetAliasManager;
>>>> import org.apache.tapestry5.services.Dispatcher;
>>>> import org.apache.tapestry5.services.Request;
>>>> import org.apache.tapestry5.services.Response;
>>>> import org.apache.tapestry5.services.assets.AssetRequestHandler;
>>>>
>>>> /**
>>>> * Recognizes requests where the path begins with "/asset/" and delivers
>>>> the
>>>> content therein as a bytestream. Also
>>>> * handles requests that are simply polling for a change to the file.
>>>> *
>>>> * @see ResourceStreamer
>>>> * @see ClasspathAssetAliasManager
>>>> * @see AssetRequestHandler
>>>> */
>>>> // PATCHED incorrect APPLICATION_VERSION 302 temporary redirect to
>>>> current
>>>> APPLICATION_VERSION
>>>>
>>>> // PATCH +
>>>> @SuppressWarnings("all")
>>>> @UsesMappedConfiguration(AssetRequestHandler.class)
>>>> public class AssetDispatcher implements Dispatcher
>>>> {
>>>> /**
>>>> * Keyed on extended path name, which includes the pathPrefix first
>>>> and a
>>>> trailing slash.
>>>> */
>>>> private final Map pathToHandler =
>>>> CollectionFactory.newMap();
>>>>
>>>> /**
>>>> * List of path prefixes in the pathToHandler, sorted be descending
>>>> length.
>>>> */
>>>> private final List assetPaths = CollectionFactory.newList();
>>>>
>>>> private final String pathPrefix;
>>>>
>>>> // PATCH +
>>>> private final String pathPrefixPattern;
>>>>
>>>> public AssetDispatcher(Map
>>>> configuration,
>>>>
>>>> @Symbol(SymbolConstants.APPLICATION_VERSION) String
>>>> applicationVersion,
>>>>
>>>> @Symbol(SymbolConstants.APPLICATION_FOLDER) String applicationFolder,
>>>>
>>>> @Symbol(SymbolConstants.ASSET_PATH_PREFIX) String assetPathPrefix)
>>>> {
>>>> String folder = applicationFolder.equals("") ? "" : "/" +
>>>> applicationFolder;
>>>>
>>>> this.pathPrefix = folder + assetPathPrefix + applicationVersion +
>>>> "/";
>>>>
>>>> // PATCH +
>>>> this.pathPrefixPattern = "^" + folder + assetPathPrefix +
>>>> "[^/]{1,}/(.*)$";
>>>>
>>>> for (String path : configuration.keySet())
>>>> {
>>>> String extendedPath = this.pathPrefix + path + "/";
>>>>
>>>> pathToHandler.put(extendedPath, configuration.get(path));
>>>>
>>>> assetPaths.add(extendedPath);
>>>> }
>>>>
>>>> // Sort by descending length
>>>>
>>>> Collections.sort(assetPaths, new Comparator()
>>>> {
>>>> public int compare(String o1, String o2)
>>>> {
>>>> return o2.length() - o1.length();
>>>> }
>>>> });
>>>> }
>>>>
>>>> public boolean dispatch(Request request, Response response) throws
>>>> IOException
>>>> {
>>>> String path = request.getPath();
>>>>
>>>> // Remember that the request path does not include the context
>>>> path,
>>>> so we can simply start
>>>> // looking for the asset path prefix right off the bat.
>>>>
>>>> if (!path.startsWith(pathPrefix))
>>>> {
>>>> // PATCH +
>>>> if (path.matches(pathPrefixPattern))
>>>> {
>>>> // send 302 temporary redirect to the version this server
>>>> is
>>>> using
>>>> String newPath = request.getContextPath() +
>>>> path.replaceAll(pathPrefixPattern, pathPrefix + "$1");
>>>> response.setHeader("Location", newPath);
>>>>
>>>> response.sendError(HttpServletResponse.SC_MOVED_TEMPORARILY,
>>>> newPath);
>>>> return true;
>>>> }
>>>> return fa
Re: Versioned assets
private final String pathPrefixPattern;
public AssetDispatcher(Map
configuration,
@Symbol(SymbolConstants.APPLICATION_VERSION) String
applicationVersion,
@Symbol(SymbolConstants.APPLICATION_FOLDER) String
applicationFolder,
@Symbol(SymbolConstants.ASSET_PATH_PREFIX) String assetPathPrefix)
{
String folder = applicationFolder.equals("") ? "" : "/" +
applicationFolder;
this.pathPrefix = folder + assetPathPrefix +
applicationVersion +
"/";
// PATCH +
this.pathPrefixPattern = "^" + folder + assetPathPrefix +
"[^/]{1,}/(.*)$";
for (String path : configuration.keySet())
{
String extendedPath = this.pathPrefix + path + "/";
pathToHandler.put(extendedPath, configuration.get(path));
assetPaths.add(extendedPath);
}
// Sort by descending length
Collections.sort(assetPaths, new Comparator()
{
public int compare(String o1, String o2)
{
return o2.length() - o1.length();
}
});
}
public boolean dispatch(Request request, Response response) throws
IOException
{
String path = request.getPath();
// Remember that the request path does not include the
context path,
so we can simply start
// looking for the asset path prefix right off the bat.
if (!path.startsWith(pathPrefix))
{
// PATCH +
if (path.matches(pathPrefixPattern))
{
// send 302 temporary redirect to the version this
server is
using
String newPath = request.getContextPath() +
path.replaceAll(pathPrefixPattern, pathPrefix + "$1");
response.setHeader("Location", newPath);
response.sendError(HttpServletResponse.SC_MOVED_TEMPORARILY,
newPath);
return true;
}
return false;
}
for (String extendedPath : assetPaths)
{
if (path.startsWith(extendedPath))
{
AssetRequestHandler handler =
pathToHandler.get(extendedPath);
String extraPath =
path.substring(extendedPath.length());
boolean handled = handler.handleAssetRequest(request,
response, extraPath);
if (handled)
{
return true;
}
}
}
response.sendError(HttpServletResponse.SC_NOT_FOUND, path);
return true;
}
}
On 22/02/2012 6:05 AM, Howard Lewis Ship wrote:
I suspect the 302 redirect may be the correct solution, and Tapestry
could support this pretty reasonably.
The perfect solution would involve the following:
- The version number if replaced with the SHA1 hash of the resource's
(uncompressed) content
- All CSS is dynamically rewritten to convert relative references into
full paths including the correct SHA1 hash
I wonder if the 302 redirect could act as a way to avoid rewriting the
CSS?
On Sun, Feb 19, 2012 at 7:57 PM, Paul
Stantonwrote:
Hi Cezary,
I think I have the same need as you.
We use load balanced servers, and when upgrading we upgrade one at
a time
so
that there is always a server running.
But the side effect is that the upgraded server can receive
requests for
the
old assets, and we don't want to fail in this case.
In the past (5.1) I monkey-patched AssetResourceLocatorImpl to
allow<=
version number requests.
However in migrating to 5.3 I would like a better solution, and the
implementation is different now anyway.
I like the idea of the 302 redirect.
How did you end up solving this? Is it possible to just contribute
your
own
AssetDispatcher instead of just replacing the class?
Thanks, Paul.
On 24/03/2011 10:09 AM, Cezary Biernacki wrote:
Perhaps the AssetDispatcher could check the requested version
number
and
if
it doesn't match the app version, send a 302 redirect to the
"correct"
URL?
/assets/1.3/ctx/script.js --> /assets/1.2/ctx/script.js
Or perhaps it should only deliver the asset if the requested
version os
older than or equal to the app version?
Determining "older" and "newer" would however assume people name
their
application versions in a certain way.
It is exactly what I did in my application. I have overridden
AssetsDispatcher service with my copy based on original one, that
differs
only in handling missing resources: if resource actually exists
but just
version numbers differ, my dispatcher just sends redirect
response with
a
correct path.
As a side note, I observed in that - at least in my case -
typically a
favicon was a typical asset requested with wrong version number,
probably
from bookmarks.
Regards,
Cezary
-
Re: Versioned assets
String extraPath = path.substring(extendedPath.length());
boolean handled = handler.handleAssetRequest(request,
response, extraPath);
if (handled)
{
return true;
}
}
}
response.sendError(HttpServletResponse.SC_NOT_FOUND, path);
return true;
}
}
On 22/02/2012 6:05 AM, Howard Lewis Ship wrote:
I suspect the 302 redirect may be the correct solution, and Tapestry
could support this pretty reasonably.
The perfect solution would involve the following:
- The version number if replaced with the SHA1 hash of the resource's
(uncompressed) content
- All CSS is dynamically rewritten to convert relative references into
full paths including the correct SHA1 hash
I wonder if the 302 redirect could act as a way to avoid rewriting the
CSS?
On Sun, Feb 19, 2012 at 7:57 PM, Paul Stantonwrote:
Hi Cezary,
I think I have the same need as you.
We use load balanced servers, and when upgrading we upgrade one at a time
so
that there is always a server running.
But the side effect is that the upgraded server can receive requests for
the
old assets, and we don't want to fail in this case.
In the past (5.1) I monkey-patched AssetResourceLocatorImpl to allow<=
version number requests.
However in migrating to 5.3 I would like a better solution, and the
implementation is different now anyway.
I like the idea of the 302 redirect.
How did you end up solving this? Is it possible to just contribute your
own
AssetDispatcher instead of just replacing the class?
Thanks, Paul.
On 24/03/2011 10:09 AM, Cezary Biernacki wrote:
Perhaps the AssetDispatcher could check the requested version number
and
if
it doesn't match the app version, send a 302 redirect to the "correct"
URL?
/assets/1.3/ctx/script.js --> /assets/1.2/ctx/script.js
Or perhaps it should only deliver the asset if the requested version os
older than or equal to the app version?
Determining "older" and "newer" would however assume people name their
application versions in a certain way.
It is exactly what I did in my application. I have overridden
AssetsDispatcher service with my copy based on original one, that
differs
only in handling missing resources: if resource actually exists but just
version numbers differ, my dispatcher just sends redirect response with
a
correct path.
As a side note, I observed in that - at least in my case - typically a
favicon was a typical asset requested with wrong version number,
probably
from bookmarks.
Regards,
Cezary
-
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: Versioned assets
der("Location", newPath);
> response.sendError(HttpServletResponse.SC_MOVED_TEMPORARILY,
> newPath);
> return true;
> }
> return false;
> }
>
> for (String extendedPath : assetPaths)
> {
>
> if (path.startsWith(extendedPath))
> {
> AssetRequestHandler handler =
> pathToHandler.get(extendedPath);
>
> String extraPath = path.substring(extendedPath.length());
>
> boolean handled = handler.handleAssetRequest(request,
> response, extraPath);
>
> if (handled)
> {
> return true;
> }
> }
> }
>
> response.sendError(HttpServletResponse.SC_NOT_FOUND, path);
>
> return true;
>
> }
> }
>
>
> On 22/02/2012 6:05 AM, Howard Lewis Ship wrote:
>>
>> I suspect the 302 redirect may be the correct solution, and Tapestry
>> could support this pretty reasonably.
>>
>> The perfect solution would involve the following:
>> - The version number if replaced with the SHA1 hash of the resource's
>> (uncompressed) content
>> - All CSS is dynamically rewritten to convert relative references into
>> full paths including the correct SHA1 hash
>>
>> I wonder if the 302 redirect could act as a way to avoid rewriting the
>> CSS?
>>
>> On Sun, Feb 19, 2012 at 7:57 PM, Paul Stanton wrote:
>>>
>>> Hi Cezary,
>>>
>>> I think I have the same need as you.
>>>
>>> We use load balanced servers, and when upgrading we upgrade one at a time
>>> so
>>> that there is always a server running.
>>>
>>> But the side effect is that the upgraded server can receive requests for
>>> the
>>> old assets, and we don't want to fail in this case.
>>>
>>> In the past (5.1) I monkey-patched AssetResourceLocatorImpl to allow<=
>>> version number requests.
>>>
>>> However in migrating to 5.3 I would like a better solution, and the
>>> implementation is different now anyway.
>>>
>>> I like the idea of the 302 redirect.
>>>
>>> How did you end up solving this? Is it possible to just contribute your
>>> own
>>> AssetDispatcher instead of just replacing the class?
>>>
>>> Thanks, Paul.
>>>
>>>
>>> On 24/03/2011 10:09 AM, Cezary Biernacki wrote:
>>>>>
>>>>>
>>>>> Perhaps the AssetDispatcher could check the requested version number
>>>>> and
>>>>> if
>>>>> it doesn't match the app version, send a 302 redirect to the "correct"
>>>>> URL?
>>>>> /assets/1.3/ctx/script.js --> /assets/1.2/ctx/script.js
>>>>>
>>>>> Or perhaps it should only deliver the asset if the requested version os
>>>>> older than or equal to the app version?
>>>>> Determining "older" and "newer" would however assume people name their
>>>>> application versions in a certain way.
>>>>
>>>>
>>>> It is exactly what I did in my application. I have overridden
>>>> AssetsDispatcher service with my copy based on original one, that
>>>> differs
>>>> only in handling missing resources: if resource actually exists but just
>>>> version numbers differ, my dispatcher just sends redirect response with
>>>> a
>>>> correct path.
>>>>
>>>> As a side note, I observed in that - at least in my case - typically a
>>>> favicon was a typical asset requested with wrong version number,
>>>> probably
>>>> from bookmarks.
>>>>
>>>> Regards,
>>>> Cezary
>>>>
>>> -
>>> 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
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
