5 Replies Latest reply on May 19, 2016 2:23 PM by matthull

    What's the best way to upgrade a custom add-on?

    cgum

      I have a custom add-on that installs an app for all users.  When I have a new version, I increment the version appropriately in add-on's meta.json file.  After I upgrade the add-on (either by uninstalling the current version and installing the new version, or just installing the new version over the old), all existing users that navigate to the app will see a warning dialog that says: (excuse the ASCII art)

       

      / ! \

       

      This app cannot be loaded at this time.

       

      Uninstall app: This will remove your data associated with this app.  Your

      subscription to this app will end permanently.

       

      Click here for more info

       

      [ Uninstall App ]   [ Refresh ]

       

       

      Clicking the [ Refresh ] button just causes a copy of the same message to be appended below the current one.

       

      The only workaround that I've found is to click [ Uninstall App ] and then log out and log back in.  After that, it works fine.  But, this has to be done for each user.  If I log in as a different user, I get the same error until I click [ Uninstall App ], logout and login again. I don't want to have to tell thousands of users that they will need to do that after an update.  Any guidance on this?

       

      EDIT

      One more note - when I click the "Click here for more info" link, I get the following:

      Failed to load module prefs for app 'InstanceAppImpl{instanceAppID=1394, title='null', description='null', userID=2132, locallyManaged=false, appURL='https://aws.mydomain.com/cluster-app-aws-dev-1.0.2.3/app/app.xml?version=1.0.2.3', appID=1100, appInstanceUUID=03ec1190-252a-4a75-b669-26691de69565, creationDate=Wed Apr 23 03:04:50 GMT+00:00 2014, modificationDate=Wed Apr 23 03:04:50 GMT+00:00 2014}' for this reason: org.apache.shindig.gadgets.AbstractSpecFactory$SpecRetrievalFailedException: Unable to retrieve spec for https://aws.mydomain.com/cluster-app-aws-dev-1.0.2.3/app/app.xml?version=1.0.2.3. HTTP error 404


      In the case of the error above, this is what shows up AFTER I have upgraded to 1.0.2.4.  So, it's like it's caching the previous version or something.

        • Re: What's the best way to upgrade a custom add-on?
          Ryan Rutan

          Casey Gum,

           

          One suggestion I have...is this add-on just an App?  If so, I would recommend versioning the App rather than the Add-On for the time being.  Not that this isn't a nasty experience, and I will take this internally to see if we can improve the experience; however, if you version the app independently this will help you maintain agility without having to manage the Add-On version, which should allow you to update the app version without updating the App for each user.

           

          Based on your app.xml?version=1.2.0.3 url, I assume you understand what I'm talking about, but if not, let me know and we can talk.  If I get a better answer from engineering, I'll post it back here.

            • Re: What's the best way to upgrade a custom add-on?
              cgum

              HeyRyan Rutan,

               

              If there were a way to programmatically or manually flush the application cache for all users, that would be ideal.  Part of the problem that makes me a little hesitant (maybe bummed is a better word) to change how I'm versioning things is related to my build and deployment process.  When I do a build, the maven profile I'm using (which sets connection strings, etc. for UAT vs. Production) as well as the version number are all incorporated into the .war file name.  When I deploy to Tomcat, it's default behavior is to use the .war file name as the context path for the web app.  This makes it really easy to host dev, UAT and production instances on the same server and to know what version is actually running.

               

              Earlier in the development process, I noticed that changes I was making weren't being seen by other users.  I would use the Dev Console and disable application caching for my development user account so I could see my changes, but then I would log in as another user and it would be serving up cached versions of JavaScript and CSS files that did not reflect my newer changes.  I had hoped that by propagating a version number throughout the application - when requesting stylesheets, JavaScript files, angular templates, etc. - I'd solve the problem of browser caching and Jive's application caching at the same time.

               

              I'll see if I can't temporarily fix the problem by removing the version number in my Apache httpd.conf ProxyPass mappings.

              e.g.

              ProxyPass /my-app-uat http://localhost:8080/my-app-uat-1.2.3.4

              ProxyPassReverse /my-app-uat http://localhost:8080/my-app-uat-1.2.3.4

              ProxyPass /my-app-prod http://localhost:8080/my-app-prod-1.2.3.4

              ProxyPassReverse /my-app-prod http://localhost:8080/my-app-prod-1.2.3.4

               

              EDIT

               

              Okay, that seemed to work.  Here's the process.

              1) Build version 1.0.0

              2) Deploy to Tomcat

              3) Update ProxyPass mappings in httpd.conf

              4) Install add-on in Jive

              5) Log in as several different users and use app

              6) Make changes to code

              7) Build version 1.0.1

              8) Undeploy old version from Tomcat

              9) Deploy new version to Tomcat

              10) Update ProxyPass mappings in httpd.conf

              11) Install new version of add-on in Jive

              12) Log in as several different users and use app (changes should be seen)