Hi Steve, The macro files used to live at /ui/macros at some point in time, but have since been moved to /shared/oae/macros, which is also where they are located in the Phoenix release. The /ui/macros path isn't referenced anywhere in the codebase, which still points to a caching issue, especially given that it's working correctly in Firefox and on individual tenants.
Our Nginx configuration specifies that all static files should be served with a far future expires header, to ensure indefinite caching of these. We can do this because we expect production instances to be run with a UI production build, which concatenates and hashes all of the static files, removing caching problems when the code updates. However, this can give the occasional caching problem when developing or when running a non-production build. Because of these far future expires headers, Chrome and Safari can sometimes be very stubborn when clearing the cache, so it might be worth giving it another try (Empty Caches in the Safari Develop menu and a Cmd+Refresh usually does the trick). Let us know if the problem persists, Nicolaas On 28 Jul 2013, at 08:27, Steve Swinsburg wrote: > Hi Branden, > > No I get a different one. I've reset Chrome and the error persists: > > GET http://admin.hostname.com/ui/macros/activity.html 404 (Not Found) > require.text.js:288 > GET http://admin.hostname.com/ui/macros/list.html 404 (Not Found) > require.text.js:288 > Uncaught Error: /ui/macros/activity.html HTTP status: 404 require.text.js:280 > Uncaught Error: /ui/macros/list.html HTTP status: 404 require.text.js:280 > Uncaught Error: Load timeout for modules: oae.api!_unnormalized2,oae.api! > http://requirejs.org/docs/errors.html#timeout > > cheers, > Steve > > > On Sun, Jul 28, 2013 at 12:18 PM, Branden Visser <mrvis...@gmail.com> wrote: > Hi Steve: > > On Sat, Jul 27, 2013 at 6:57 PM, Steve Swinsburg > <steve.swinsb...@gmail.com> wrote: > > Sorry for the multiple emails, but this is what I am using: > > > > nohup node app | bunyan & > > > > Back on the issue of the blank screen in Safari/Chrome, its only on the > > Admin UI, the main tenant login screen is working ok in those browsers. > > > > Can you confirm if it is this issue: > https://github.com/oaeproject/3akai-ux/issues/3100 . That error should > pop up in your network console if it is. If it is happening quite > consistently for someone we'll likely bump up its priority. I don't > seem to run into it very often, and if I do clearing my cache seems to > fix it. > > > > > On Sun, Jul 28, 2013 at 8:55 AM, Steve Swinsburg <steve.swinsb...@gmail.com> > > wrote: > >> > >> I found this thread, regarding the shutdown of node when the terminal > >> session is lost: > >> http://stackoverflow.com/questions/4018154/node-js-as-a-background-service > >> > >> Seems like there are a dozen different ways! What do you use? We should > >> perhaps settle on one approach, WDYT? > > Settling on a common way would be good. Currently we're using an > upstart [2] script to spawn and manage our app as a daemon process. > The benefit of tying into upstart / init is that you get first-class > support from lots of deployment tools like MCollective and Puppet. I > know that both Ubuntu and RHEL have made the switch to upstart and > others seem to be on the way at least, I think it's a good candidate > to standardize on. > > "forever" [1] is also a viable option for daemonizing, which can be > wrapped itself in an upstart e.g., [3], though I'm not a big fan of > the idea of layering it up like that. Daemon-ception? > > [1] https://github.com/nodejitsu/forever > [2] > https://github.com/oaeproject/puppet-hilary/blob/master/modules/hilary/templates/upstart_hilary.conf.erb > [3] > https://www.exratione.com/2013/02/nodejs-and-forever-as-a-service-simple-upstart-and-init-scripts-for-ubuntu/ > > >> > >> cheers, > >> Steve > >> > >> > >> On Sun, Jul 28, 2013 at 8:42 AM, Steve Swinsburg > >> <steve.swinsb...@gmail.com> wrote: > >>> > >>> Ni Nico/Samuel, > >>> > >>> I get this response: > >>> {"anon":true,"tenant":{"alias":"admin","displayName":"Global admin > >>> server"}} > >>> > >>> It seems its broken in Safari and Chrome, on Firefox I get the login > >>> screen. So I might be ok, now that the install is up. Do you want a jira > >>> or > >>> github issue for this? > >>> > >>> Another question, whats the preferred way to start Hilary so that the > >>> process isn't killed on logout? For Tomcat I use nohup, is that the > >>> recommended approach here as well? > >>> > >>> The command I am using is: node app | bunyan > >>> > >>> cheers, > >>> Steve > >>> > >>> > >>> On Sat, Jul 27, 2013 at 6:11 PM, Nicolaas Matthijs > >>> <nicolaas.matth...@caret.cam.ac.uk> wrote: > >>>> > >>>> Hi Steve, > >>>> > >>>> What do you get when you go to <youradminhost>/api/me? > >>>> > >>>> Thanks, > >>>> Nicolaas > >>>> > >>>> > >>>> On 27 Jul 2013, at 08:19, Steve Swinsburg wrote: > >>>> > >>>> > Hi all, > >>>> > > >>>> > I've run through the install docs (a third time) and am pretty sure I > >>>> > have everything configured properly and all servers started. I have > >>>> > started > >>>> > OAE but when I go to the admin host I configured I get a blank screen, > >>>> > however I do see HTML when I view source. > >>>> > > >>>> > Everything looks ok in the logs, all INFO messages. > >>>> > > >>>> > Any ideas? > >>>> > > >>>> > Note this is a remote server. I have DNS records setup to replace the > >>>> > /etc/hosts steps. > >>>> > > >>>> > cheers, > >>>> > Steve > >>>> > _______________________________________________ > >>>> > oae-dev mailing list > >>>> > oae-dev@collab.sakaiproject.org > >>>> > http://collab.sakaiproject.org/mailman/listinfo/oae-dev > >>>> > >>> > >> > > > > > > _______________________________________________ > > oae-dev mailing list > > oae-dev@collab.sakaiproject.org > > http://collab.sakaiproject.org/mailman/listinfo/oae-dev > > >
_______________________________________________ oae-dev mailing list oae-dev@collab.sakaiproject.org http://collab.sakaiproject.org/mailman/listinfo/oae-dev
