Uploaded image for project: 'Accumulo'
  1. Accumulo
  2. ACCUMULO-2983

Separate javascript resources (jquery, flot) from monitor

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 2.0.0
    • monitor
    • None

    Description

      The javascript resources (namely jquery, and flot) are included directly in the monitor jar, for inclusion on the classpath. The monitor then loads these resources, as needed, from the classpath.

      Since these are third-party libraries, it may be better to include them as a dependency, and put them in the lib directory.

      At the very least, this would help with downstream packaging, especially in situations where third-party libraries cannot be included in a package, but it may help in other situations, if we need to swap out a different version of jquery/flot dependencies.

      Attachments

        Issue Links

          Activity

            For more details about why these may not be included in other packages is because (at the very least) obfuscated/minimized code is not considered free software, according to http://www.gnu.org/philosophy/free-sw.html or open source, according to http://opensource.org/osd .

            Additionally, because of these definitions, it may also mean that we shouldn't be releasing the minimized versions of these libraries in our source release. Rather, they should be minimized during the build.

            ctubbsii Christopher Tubbs added a comment - For more details about why these may not be included in other packages is because (at the very least) obfuscated/minimized code is not considered free software, according to http://www.gnu.org/philosophy/free-sw.html or open source, according to http://opensource.org/osd . Additionally, because of these definitions, it may also mean that we shouldn't be releasing the minimized versions of these libraries in our source release. Rather, they should be minimized during the build.
            elserj Josh Elser added a comment -

            Interesting. I hadn't thought about min'ified resources in that context before. Honestly, for the scope of the monitor, we're probably not really gaining anything out of serving the min'ified variants. Plus, after the first time, as long as we set the cache-control knobs, the browser shouldn't be re-requesting them after the first visit. There are a lot of other problems we'd hit with the monitor before loading of an extra 4k bytes from a JS file affect us

            elserj Josh Elser added a comment - Interesting. I hadn't thought about min'ified resources in that context before. Honestly, for the scope of the monitor, we're probably not really gaining anything out of serving the min'ified variants. Plus, after the first time, as long as we set the cache-control knobs, the browser shouldn't be re-requesting them after the first visit. There are a lot of other problems we'd hit with the monitor before loading of an extra 4k bytes from a JS file affect us

            I was thinking about this a bit today, while examining our LICENSE/NOTICE files, and I think this issue could simplify some of that, also.

            Here are some options:

            1. Make the paths to the javascript and flot libraries configurable. The default could be to retrieve them from a publicly available CDN. Customers requiring they be served locally can change the configuration to retrieve them from an alternate source.
            2. Provide a way to load and serve these from the classpath without bundling them into our jars. Make it easy to download these resources to the classpath.

            These options could be combined... if it's served locally from the classpath, the configuration could point to where it's served from Jetty, rather than require a separate local webservice or CDN.

            ctubbsii Christopher Tubbs added a comment - I was thinking about this a bit today, while examining our LICENSE/NOTICE files, and I think this issue could simplify some of that, also. Here are some options: Make the paths to the javascript and flot libraries configurable. The default could be to retrieve them from a publicly available CDN. Customers requiring they be served locally can change the configuration to retrieve them from an alternate source. Provide a way to load and serve these from the classpath without bundling them into our jars. Make it easy to download these resources to the classpath. These options could be combined... if it's served locally from the classpath, the configuration could point to where it's served from Jetty, rather than require a separate local webservice or CDN.

            A first step to address this might be to simply stop bundling these in the monitor jar. These web resources can be just as easily loaded from the classpath outside of the jar, where it's more easily updated by users if there's a problem with the bundled version.

            ctubbsii Christopher Tubbs added a comment - A first step to address this might be to simply stop bundling these in the monitor jar. These web resources can be just as easily loaded from the classpath outside of the jar, where it's more easily updated by users if there's a problem with the bundled version.

            This is the strategy I took to address https://bugzilla.redhat.com/show_bug.cgi?id=1132725

            ctubbsii Christopher Tubbs added a comment - This is the strategy I took to address https://bugzilla.redhat.com/show_bug.cgi?id=1132725

            Good enough for 2.0. The resources are bundled, but can be overridden with config to use a CDN.

            ctubbsii Christopher Tubbs added a comment - Good enough for 2.0. The resources are bundled, but can be overridden with config to use a CDN.

            People

              Unassigned Unassigned
              ctubbsii Christopher Tubbs
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: