Hi, Alex
I'm including *.css and *.png by simply using link rel, like this:
<link rel="stylesheet" type="text/css"
href="/assets/anjlab/cubics/css/cube.css" />
cube.css located here:
ping-service\war\WEB-INF\lib\cubics-renders-1.0.1.jar\anjlab\cubics\css\cube.css
I also set up regexAuthorizer:
public void contributeRegexAuthorizer(Configuration<String> regex)
{
String pathPattern =
"([^/.]+/)*[^/.]+\\.((css)|(js)|(jpg)|(jpeg)|(png)|(gif))$";
regex.add("^anjlab/cubics/css/" + pathPattern);
regex.add("^anjlab/cubics/images/" + pathPattern);
regex.add("^anjlab/cubics/js/" + pathPattern);
regex.add("^anjlab/cubics/js/jquery-1.3.2.js");
}
I can't say I have any problems with this.
At least right now in my error list at GAE Admin console I don't have any
assets related issues.
I have only one page actively using *.css, *.js, etc., here's the
declarations:
<head>
<title>Job Analytics - Ping Service</title>
<link rel="stylesheet" type="text/css" href="/css/all.css" />
<link rel="icon" type="image/png" href="/favicon.png" />
<link rel="stylesheet" type="text/css"
href="/assets/anjlab/cubics/css/cube.css" />
<link rel="stylesheet" type="text/css" href="/css/analytics.css" />
<script type="text/javascript"
src="/assets/anjlab/cubics/js/jquery-1.3.2.js"></script>
<script type="text/javascript"
src="/assets/anjlab/cubics/js/cube.js"></script>
<!--[if IE]><script language="javascript" type="text/javascript"
src="excanvas.min.js"></script><![endif]-->
<script type="text/javascript" src="/js/jquery.flot.js"></script>
<script type="text/javascript" src="/js/jquery.flot.pie.js"></script>
<script type="text/javascript" src="/js/analytics.js"></script>
</head>
p.s.
One issue I have though is '/favicon.ico' problem :)
On Tue, Apr 13, 2010 at 17:20, Alex Kotchnev <akoch...@gmail.com> wrote:
> Daniel,
> I do try to watch out for T5/GAE related posts on this list and try to
> respond to the best of my ability. I would blog about this more if I
> weren't
> as swamped with things to do.
>
> I would be interested in hearing from other folks (e.g. Dmitry) that have
> deployed on GAE - in previous questions relating to this issue, folks had
> mentioned that they don't have a problem w/ this, which makes me think that
> I might have something configured incorrectly (although I'm not doing
> special here, other than having a few images loaded from the stylesheet).
> I
> do use the AssetAuthorizer (that was eventually added to 5.2) and that's
> another possible failure point (e.g. if for whatever reason, the
> authorization fails in some cases and denies access).
>
> On the other hand, serving these assets as static content has dropped my
> CPU usage - I had an cron job watching the site and keeping it warm (so
> that
> GAE doesn't swap it out), which was using up about 40% of the free CPU
> quota
> - so far, the CPU usage should be about 20% lower.
>
> Regards,
>
> Alex Kotchnev
>
> On Tue, Apr 13, 2010 at 3:44 AM, Daniel Henze <dhe...@googlemail.com>
> wrote:
>
> > 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
> >
> >
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
