I want to modify some aspects of my app with javascript.
Have placed a application.js file in appname/appserver/static
When I refresh any page in my app I dont see the application.js file being included with any script tag.
We are using Splunk 4.1.7
What am I missing?
A couple issues here to know:
1) restart splunkWeb? when you first add it, application.js wont show up until you restart splunkWeb. Or you can restart the whole server, but restarting splunkWeb is sufficient and although splunk will dissappear for a couple seconds nobody gets logged out which is nice.
2) The 'bump' endpoint. If you're just changing an existing application.js, or application.css, or a custom module file for that matter, beware of cacheing. SplunkWeb has VERY aggressive cache headers. And then other techniques are employed to bust those caches.
a) static URLs have a segment in them that is the actual Splunk build number, to bust the cache on upgrade of the core product.
b) static URLs have a segment in them that is the 'build' number from the current app's app.conf. This is to bust the cache on app upgrade - note that a bug exists whereby custom module URLs do not get this number so sometimes the admin upgrading the app has to do #3 themselves.
c) static URLs have a segment in them that is the 'bump' number. This is so that admins and app-developers can manually hit a button on a particular Splunk instance and bust everybody's cache. Go to
http://<your host and port>/en-US/_bump
and click the button you see there.
If you are using splunk's simple xml to design your page.. rename your "application.js" as "dashboard.js"...
same is applicable for css.... "application.css" to "dashboard.css"
Splunk internally loads... application.XX for advanced xml and dashboard.XX for simple xml
A couple issues here to know:
1) restart splunkWeb? when you first add it, application.js wont show up until you restart splunkWeb. Or you can restart the whole server, but restarting splunkWeb is sufficient and although splunk will dissappear for a couple seconds nobody gets logged out which is nice.
2) The 'bump' endpoint. If you're just changing an existing application.js, or application.css, or a custom module file for that matter, beware of cacheing. SplunkWeb has VERY aggressive cache headers. And then other techniques are employed to bust those caches.
a) static URLs have a segment in them that is the actual Splunk build number, to bust the cache on upgrade of the core product.
b) static URLs have a segment in them that is the 'build' number from the current app's app.conf. This is to bust the cache on app upgrade - note that a bug exists whereby custom module URLs do not get this number so sometimes the admin upgrading the app has to do #3 themselves.
c) static URLs have a segment in them that is the 'bump' number. This is so that admins and app-developers can manually hit a button on a particular Splunk instance and bust everybody's cache. Go to
http://<your host and port>/en-US/_bump
and click the button you see there.
Yea it's the same with application.css, also with customFileName.css that you may include with stylesheet="customFileName.css" in the top level tag in the XML. Also the case with custom modules. And you actually only need to do 'splunk restart splunkWeb', which is a lot lighter weight and wont even log anybody out.
It was in fact just a simple restart of splunk that was needed. Is this the same case with application.css? There really needs to be more documentation on this.
Sure, but you cant clear your users' caches for them, so it can be worse than nothing in production.
To point #2, also consider explicitly clearing cache in the browser. There's also a Clear Cache Button addon for Firefox that's nice to have when testing app changes.