1. glassfish
  2. GLASSFISH-9720

provide a "safe shared lib folder" for deploying jars without affecting the application server


    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: V3
    • Fix Version/s: not determined
    • Component/s: deployment
    • Labels:
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:



      Following test drives in gfv3-b64, I deployed a load of jar libraries shared by
      all our internal applications (mostly webapps/war artifacts) to <domain>/lib/,
      restarted the application server just to find the admin_gui not working anymore.
      Upon closer inspection, I figured out that this behaviour could be triggered
      reproducibly by dumping a xercesImpl.jar to <domain>/lib/.


      We have pretty large webapp files, a bunch of third-party dependencies which
      come as jar files, and many of them shared by all the webapps. From this point
      of view it is sane not to put the jars into <webapp>/WEB-INF/lib/ but rather
      place them directly in some "shared-library" folder, eventually accepting
      certain restrictions (servlet.jar, ...).

      However, such a folder to store shared libs should be treated in a way so that,
      no matter which jar files will be stored there, it should never ever be
      capable of damaging the application server as a whole as effects of such a
      behaviour may be hard to foresee. Would it be possible to completely wreck, or,
      worse, compromise (from a security point of view) the application server by
      storing a prepared .jar in <domain>/lib/? At least talking about wrecking the
      admin_gui, the answer seems yes.

      Proposed solution / enhancement request:

      Introduce a "safe shared library" folder which is the place to deploy jar
      libraries used by applications (war, ejb, connectors, ...) deployed to the app
      server without affecting the behaviour of the app server itself.


        No work has yet been logged on this issue.


          • Assignee:
            Hong Zhang
          • Votes:
            1 Vote for this issue
            4 Start watching this issue


            • Created: