Hi Alex,
thanks for that follow-up post. Since I'm going to develop with T5 on
GAE as well, this will be in the back of my head as a potential cave-at.
I'll be interested in any further findings regarding GAE since it seems
that Tapestry is better tailored towards this particular platform
(compared to Wicket).
Best regards
Daniel
Am 13.04.2010 06:23, schrieb Alex Kotchnev:
I spent some more time looking at this and I ended up removing the usage of
the ${asset:context:css/foobar.css} from the main templates. After doing so,
all of the issues related to the stylesheet (and the sub-stylesheets and
images that it loads) were cleared up - now, the stylesheets load properly
every time when they're not loaded through the asset service.
I first thought that this might be an issue w/ how GAE handles static files
- supposedly, all files in the web context are handled specially ( w/ the
exception of JSPs of course, but that's not relevant in T5), probably served
up from outside of Jetty (which is what runs the app in GAE) and there might
be something that is weird in GAE giving access to those static assets.
However, after I switched to just using the raw path to the css (w/o using
the asset:context binding prefixes), I continued having the same
intermittent access issues for assets that are served from a component.
Which on its own indicates that the issue is somewhere between the Asset
service (which I haven't looked at the source code for yet) and the way it
uses the servlet API and/or the filesystem to serve the assets that it's
asked for.
I haven't moved all my css / image serving out of the asset service - it has
some cool ideas in terms of being able to package the app. However,
considering that I'm dealing w/ a fairly simple app, and despite that I like
the ideas behind the asset service, I'll probably move off of it - I do
recall seeing some mentions of an alternative binding prefix to serve the
assets in question from a CDN ; however, considering that the google static
file serving infrastructure is probably as good as serving from a CDN, I'll
probably just stick to static files.
Anyway, I thought this might be useful to someone else that might run into
issues with the Asset service and GAE. It would be interesting to look at
the asset service implementation and see if there is an issue to be filed w/
GAE re: accessing resources (classpath and web context).
Regards,
Alex K
On Mon, Apr 12, 2010 at 1:27 PM, akochnev_chub<akoch...@commercehub.com>wrote:
I've been running into some issues w/ the asset service, in that at times
it
responds to service requests with 404s. After "warming up" the app by
reloading the pages in question a few times, the asset service eventually
responds w/ the assets. However, this results in a very unreliable
rendering
of the pages - at times (if the app happens to be "warm"), the pages
render
just fine; at other times, I have to reload them a few times before getting
to proper rendering. Below are some more details on the issue, any
suggestions on how to deal w/ it would be highly appreciated.
There is a pretty good chance that this might be an issue w/ the underlying
platform (GAE), and the way it chooses to swap the application in and out;
however, if that were the case, I would have expected more of the requests
to fail instead of the page content rendering fine and then the assets not
returning in time.
I think the issue is partially aggravated by the fact that I load the main
stylesheet as a context asset (asset:context:/css/foo.css or something
similar), instead of just using the "naked" (e.g. /css/foo.css w/o a
context: prefix) path to the css in the layout; as a result, all of the
"other" css (using yaml for layout) and the images referenced by the main
css depend on the asset service (e.g.
http://zadachite-dev.appspot.com/assets/ctx/91328db67ddf7725/images/layout_v2/footer.jpg
)
instead of just being loaded as static files. I was thinking that switching
the reference to the main stylesheet to not be a context: reference and
marking the web app context resources as static (in the GAE web config
file)
might resolve the issue.
So, here's an example :
1. go to http://zadachite-dev.appspot.com (this is the "dev" version which
is unlikely to be warm right now)
2. Upon the initial loading of the pages, some of the graphics (more or
less
randomly) or stylesheets don't return as they get 404s:
<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>404 Unable to locate asset
'classpath:ctx/91328db67ddf7725/yaml/core/base.css' (the file does not
exist).</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Unable to locate asset
'classpath:ctx/91328db67ddf7725/yaml/core/base.css' (the file does not
exist).</h1>
</body></html>
or for images, it's a straight 404 w/o any further response.
3. Browse to some of the other pages of the site - one by one, the
"missing"
assets start showing up one by one and eventually the layout renders
correctly. After the app is "warmed up" now, even if you refresh the page
including the initially cached assets, they load fine.
--
View this message in context:
http://old.nabble.com/Asset-service-issues-in-GAE-tp28219164p28219164.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
