[
https://issues.apache.org/jira/browse/TAP5-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806807#comment-13806807
]
Magnus Kvalheim edited comment on TAP5-2201 at 10/28/13 3:04 PM:
-----------------------------------------------------------------
So, what I've come up with so far is not perfect - but will hopefully do the
job.
The goal is to avoid writing full url's for assets embedded within css files.
(to support both sticky sessions with slightly different app versions and
cdn/cloudfront resources on cookieless domain)
The current infrastructure don't allow us to know if an asset is referenced
from a css or not.
So have added a decorator that detects if the current file served is a css/less
and set a request/thread flag.
The CDNAssetPathConverter will check for flag and avoid converting if it's
referenced from a css
It is smelling a bit fishy, and not completely what I'd hoped for. But there
don't seem to be other options(to my knowledge).
I can't override or replace a service as it's a decorator.
I can't replace or skip a decorator.
I realize there might be little interest in this use case - so I'd be perfectly
fine customizing for our cases.
Would hope that it would be a bit less challenging though.
Think Howard also suggests a simpler approach here:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Selective-caching-of-resources-td5721008.html
{code:title=Current workaround - AppModule.java|borderStyle=solid}
@Decorate(id = "CSSURLRewriteOverride", serviceInterface =
StreamableResourceSource.class)
@Order("before:CSSURLRewrite")
public StreamableResourceSource enableCSSURLRewriting(
@InjectService("Request") final Request
request,
StreamableResourceSource delegate,
OperationTracker tracker,
AssetSource assetSource,
AssetChecksumGenerator
checksumGenerator) {
final List<String> accepted = Lists.newArrayList("css", "less");
return new DelegatingSRS(delegate) {
@Override
public StreamableResource getStreamableResource(
Resource baseResource,
StreamableResourceProcessing processing,
ResourceDependencies dependencies) throws
IOException {
StreamableResource sr = null;
String filename = baseResource.getFile();
String ext = FilenameUtil.getExt(filename);
boolean isCss = (ext!=null &&
accepted.contains(ext.toLowerCase()));
//before
if(isCss)
request.setAttribute(CDNAssetPathConverter.CSS_FILE_MARKER,
baseResource.getPath());
//get res
sr = super.getStreamableResource(baseResource,
processing, dependencies);
//after
if(isCss)
request.setAttribute(CDNAssetPathConverter.CSS_FILE_MARKER, null);
return sr;
}
};
}
{code}
was (Author: [email protected]):
So, what I've come up with so far is not perfect - but will hopefully do the
job.
The goal is to avoid writing full url's for assets embedded within css files.
(to support both sticky sessions with slightly different app versions and
cdn/cloudfront resources on cookieless domain)
The current infrastructure don't allow us to know if an asset is referenced
from a css or not.
So have added a decorator that detects if the current file served is a css/less
and set a request/thread flag.
The CDNAssetPathConverter will check for flag and avoid converting if it's
referenced from a css
It is smelling a bit fishy, and not completely what I'd hoped for. But there
don't seem to be other options(to my knowledge).
I can't override or replace a service as it's a decorator.
I can't replace or skip a decorator.
I realize there might be little interest in this use case - so I'd be perfectly
fine customizing for our cases.
Would hope that it would be a bit less challenging though.
Think Howard also suggests a simpler approach here:
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Selective-caching-of-resources-td5721008.html
--Current workaround---------------------------------------
@Decorate(id = "CSSURLRewriteOverride", serviceInterface =
StreamableResourceSource.class)
@Order("before:CSSURLRewrite")
public StreamableResourceSource enableCSSURLRewriting(
@InjectService("Request") final Request
request,
StreamableResourceSource delegate,
OperationTracker tracker,
AssetSource assetSource,
AssetChecksumGenerator
checksumGenerator) {
final List<String> accepted = Lists.newArrayList("css", "less");
return new DelegatingSRS(delegate) {
@Override
public StreamableResource getStreamableResource(
Resource baseResource,
StreamableResourceProcessing processing,
ResourceDependencies dependencies) throws
IOException {
StreamableResource sr = null;
String filename = baseResource.getFile();
String ext = FilenameUtil.getExt(filename);
boolean isCss = (ext!=null &&
accepted.contains(ext.toLowerCase()));
//before
if(isCss)
request.setAttribute(CDNAssetPathConverter.CSS_FILE_MARKER,
baseResource.getPath());
//get res
sr = super.getStreamableResource(baseResource,
processing, dependencies);
//after
if(isCss)
request.setAttribute(CDNAssetPathConverter.CSS_FILE_MARKER, null);
return sr;
}
};
}
> Serious issue with assets and checksums - different for same file
> -----------------------------------------------------------------
>
> Key: TAP5-2201
> URL: https://issues.apache.org/jira/browse/TAP5-2201
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.4
> Reporter: Magnus Kvalheim
> Labels: 5.4.22
> Attachments: bootstrap.server2.css, bootstrap.server3.css,
> server2.png, server3.png
>
>
> 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
--
This message was sent by Atlassian JIRA
(v6.1#6144)
