It's all about the answers!

Ask a question

redeploy an RM extension / deploy a new version of the same extension?

Sam Briggs (3759) | asked Jan 07 '15, 8:58 a.m.

I am working with Jazz Team Server (jts) v 5.02, mainly for using the requirements management / DOORS-NG area. I have been starting to look at extensions for this purpose and have successfully got the example extensions provided on ( up and running on a test jts+tomcat server on my local machine.

My problem is that I when I’ve changed the .js or .css files associated with one of the extensions in the catalogue (specifically the ‘module explorer’/mod-exp.js extension), request a server reset and restart the jts, there are no changes to the mod-exp.js file / it is not redeployed. When I visit the location of the .js file, it remains the same. (https://[server]:[port]/extensions/module_explorer/js/mod-exp.js)

I have reset the server via https://[server]:[port]/rm/admin?internal=true URL, https://[server]:[port]/rm/admin/cmd/resetRequest and by deleting tomcat\work\Catalina\localhost\rm\built-on.txt  Have you any idea why this is failing for me?

Thanks once again,

Robert Wen commented Jan 07 '15, 9:24 a.m.

I'm putting this in the category of "silly guess".

Have you tried removing the entry in the widget catalog XML file corresponding to the extension you modified, resetting the RM, and then reinserting the entry and resetting again?  I'm not sure the server is smart enough to pick up on modifications to already-existing extensions.

Hope this helps!

Accepted answer

permanent link
Steve Wood (1162) | answered Jan 14 '15, 7:13 a.m.
 Hi Sam,

What you're describing sounds to me like a browser cache issue ?  If you have updated the file on disk (on the server) then you do not need to restart the server to get the browser to pick up new JS or CSS files.  

It should work if you just refresh the browser page, so if the files have changed on disk, then my first reaction is to think that browser is fetching that file from it's local cache instead of going to the server again.

Most browsers these days come with a "private" browsing mode, this should make it not cache things like JS and CSS files.

Browsers these days come with pretty decent developer tools which you can use to debug your JavaScript code, you can use these tools to turn off the cache and you can also look at the network tab to see if the browser actually made a network request to load the newly updated file.

Hope this helps.

Steve Wood
RDNG Developer.

Sam Briggs selected this answer as the correct answer

Sam Briggs commented Jan 14 '15, 10:02 a.m. | edited Jan 14 '15, 10:02 a.m.

Hi Steve,

This may have been a factor. However I did also restart my browser, was prompted to login to JTS once more, and the widgets still hadn't updated. Could this still be being called from the cache? And if a direct request was made (like when I navigated to the changed .js file https://[server]:[port]/extensions/module_explorer/js/mod-exp.js) would this still be called from the cache?

This is hard to test now as I have fixed my problem on my test set-up, AND that of my colleague's by following the steps I outlined in my answer above. If those steps solved my problem, I wonder if it was still to do with caching? Ever since I removed/rentered the widget location last week my changes have shown up, with the same browser settings.


Steve Wood commented Jan 14 '15, 10:35 a.m.

Hi Sam,

if you navigate directly to e.g. https://[server]:[port]/extensions/module_explorer/js/mod-exp.js then this request doesn't touch any DNG code, so if you still don't see the updated file (and assuming the file has changed on disk) then it does sound like a cache issue.  There's no requirement for example that the JS and the extension XML file reside in the same place for example, so when the browser comes to load the JavaScript it just makes a direct HTTP request to fetch it.  


Sam Briggs commented Jan 14 '15, 11:14 a.m.

Hi Steve,

My colleague started reporting these problems again and when I told him to clear the cache the issue was fixed. Presumably whatever 'fixed' my setup before was fragile and possibly not a fix at all.

Anyway, it seems that this is the solution. Thank you very much for your help! My mistake for thinking it was an issue with DNG / JTS.


Steve Wood commented Jan 14 '15, 11:18 a.m.

 No worries - glad to have helped :)

2 other answers

permanent link
Hubert Spieß (2123) | answered Jan 12 '15, 5:46 p.m.
I have the same problem. I tested with the HelloWorld simple example widget.
My first run: Adding the widget via Catalog (I am hosting the widgets on an apache webserver)
Result: Content of the widget is empty; Javascript error in web console: TypeError: this._viewInfo is undefined

My second run: Adding the widget directly via "Add OpenSocial Gadget" with the URL https://clmrational:444/hello-world/HelloWorld.xml
Result: Content of the widget is available and I can update the content text and after a refresh of the widget this update is visible

permanent link
Sam Briggs (3759) | answered Jan 14 '15, 6:30 a.m.
Thanks Robert and Hubert for your suggestions/solutions,

I have now found a solution that has worked on more than one set up with widget catalogues, although I'm not totally sure why. I tried Robert's suggestion and it did not solve the issue.

SCENARIO: using a widget catalogue hosted on the express install apache/tomcat webserver:
with the widget catalogue set in the .../rm/admin 'Advanced Settings'  under setting

PROBLEM: editing files within the extensions folder does not change the extensions hosted on the server

SOLUTION: return to .../rm/admin 'Advanced Settings', remove (cut: ctrl + x) the URL entered under, save changes, immediately enter the URL again (paste: ctrl + v), save the changes.

Any changes now seem to update on the server with a refresh of the web browser... weird!

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.