[ http://issues.apache.org/jira/browse/TAPESTRY-704?page=comments#action_12332223 ]
Howard M. Lewis Ship commented on TAPESTRY-704: ----------------------------------------------- This code was changed in beta-11. It has been tested (using unit tests and the Workbench) so I stand behind it ... but there was a change to the configuration of the asset-encoder: <contribution configuration-id="tapestry.url.ServiceEncoders"> <asset-encoder id="asset" path="/assets"/> </contribution> Note that there's no trailing slash anymore. This is documented at http://jakarta.apache.org/tapestry/UsersGuide/friendly-urls.html > AssetEncoder slash comparison mismatch, not decoding / showing assets > --------------------------------------------------------------------- > > Key: TAPESTRY-704 > URL: http://issues.apache.org/jira/browse/TAPESTRY-704 > Project: Tapestry > Type: Bug > Components: Framework > Versions: 4.0 > Environment: Tapestry 4.0-beta-11 > Reporter: Leonardo Quijano Vincenzi > Priority: Critical > > Images and javascript are not shown in a page when using Tapestry's provided > assets: > Seems like AssetEncoder is violating its own assumptions when comparing > servlet paths in decode(): > In org.apache.tapestry.engine.encoders.AssetEncoder.java we have a _path > instance variable, which describes the encoding path for the asset service: > private String _path; > It seems like this variable always end with a slash, or so the comment says > in encode(): > String path = encoding.getParameterValue(AssetService.PATH); > String digest = encoding.getParameterValue(AssetService.DIGEST); > // _path ends with a slash, path starts with one. > String fullPath = _path + "/" + digest + path; > When decoding, the Encoder makes a equals() comparison on the _path variable > and servletPath() in encoding: > if (!encoding.getServletPath().equals(_path)) > return; > It returns if they're not equal. The problem is, the value of > encoding.getServletPath() doesn't end with a slash, since it's really > getActivationPath(): > /** > * Returns the path of the resource which activated this request (this is > the equivalent of the > * servlet path for a servlet request). The activation path will not end > with a slash. > * > * @returns the full servlet path (for servlet requests), or a blank > string (for portlet > * requests). > */ > public String getActivationPath(); > In RequestCycleFactory: > QueryParameterMap parameters = extractParameters(request); > decodeParameters(request.getActivationPath(), request.getPathInfo(), > parameters); > decodeParameters then calls the ServiceEncodingImpl with this activation path. > In the end run, an URL like: > /sigep/assets//9cb2cb0b4c4ff29f71e74cb753448021/org/apache/tapestry/form/DatePicker.js > is not shown in the page, since the AssetService is never called. > (_path = "/assets/", encoding.getServletPath() = "/assets"). > I'm setting this as critical since it's breaking form javascript, datepicker, > etc.. > Also, path construction is creating double slashed paths in encode() if > digest is not empty: > String path = encoding.getParameterValue(AssetService.PATH); > String digest = encoding.getParameterValue(AssetService.DIGEST); > // _path ends with a slash, path starts with one. > String fullPath = _path + "/" + digest + path; > If the assumptions in the comment are right, that "/" is not needed. Even > more, it's breaking digest reading in decode(): > String pathInfo = encoding.getPathInfo(); > // The lead character is a slash, so find the next slash (the divider > between the > // digest and the path). > int slashx = pathInfo.indexOf('/', 1); > encoding.setParameterValue(ServiceConstants.SERVICE, > Tapestry.ASSET_SERVICE); > encoding.setParameterValue(AssetService.DIGEST, pathInfo.substring(1, > slashx)); > encoding.setParameterValue(AssetService.PATH, > pathInfo.substring(slashx)); > (since we have two slashes, slashx would be 2, DIGEST would come empty, and > PATH would include the digest value. Certainly that's not what it's intended). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
