glassfish
  1. glassfish
  2. GLASSFISH-9720

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

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      9,720

      Description

      Situation:

      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/.

      Motivation:

      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.

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        You didn't affect the application server by placing some jars in domain/lib; you
        only affected admin gui, which is really another application deployed in the
        server. I repeat, domain/lib does not and can not affect the server. Yes, it can
        definitely affect all deployed applications, as it is a shared library folder.
        Having said that, I don't think it is entirely wrong to assume admin gui to be
        part of server. Now that we have support for OSGi-enabled web applications,
        admin gui can use that approach and that way, it will have explicit control over
        what it sees. But, that's a long term goal if at all.

        You have other ways of deploying libraries as shared libraries. You can do the
        following:
        Copy all your library jars to domain/lib/applibs.
        Create a manifest file like this (replace a.jar, b.jar by actual jar names):
        Class-Path: a.jar b.jar
        Do jar cvfm foo.jar manifest
        Now deploy whichever applications need access to this library by running the
        following command:
        asadmin deploy --libraries foo.jar first.war

        If you deploy a second war like this, the second war will use the same library
        instance as the first war.

        More details about --libraries option is available in GlassFish document or in
        Siva's blog:
        http://blogs.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt

        Hope this helps.

        Show
        Sanjeeb Sahoo added a comment - You didn't affect the application server by placing some jars in domain/lib; you only affected admin gui, which is really another application deployed in the server. I repeat, domain/lib does not and can not affect the server. Yes, it can definitely affect all deployed applications, as it is a shared library folder. Having said that, I don't think it is entirely wrong to assume admin gui to be part of server. Now that we have support for OSGi-enabled web applications, admin gui can use that approach and that way, it will have explicit control over what it sees. But, that's a long term goal if at all. You have other ways of deploying libraries as shared libraries. You can do the following: Copy all your library jars to domain/lib/applibs. Create a manifest file like this (replace a.jar, b.jar by actual jar names): Class-Path: a.jar b.jar Do jar cvfm foo.jar manifest Now deploy whichever applications need access to this library by running the following command: asadmin deploy --libraries foo.jar first.war If you deploy a second war like this, the second war will use the same library instance as the first war. More details about --libraries option is available in GlassFish document or in Siva's blog: http://blogs.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt Hope this helps.
        Hide
        kawazu added a comment -

        Re-opening it. Rationales:

        (a) Indeed the admin_gui from my point of view is an integral part of the
        application server so having someone being capable of rendering it useless
        simply by deploying a "wrong" jar to <domain>/lib/ is pretty bad style at
        all, especially considering there is no way of figuring out whether an actual
        jar deployed there will (not) affect the admin_gui or any other applications
        eventually installed. Sure, the latter problem won't possibly be resolved by a
        "single" shared libraries folder but eventually will require more powerful means
        of dependency / library management, but at least an end user should not be
        capable of trashing a part of software that comes with the app server
        (admin_gui) by deploying anything to it.

        (b) The second approach is technically fine but then again I would, here, plead
        for something like "asadmin deploy --shared-libs-folder=... <webapp>" to deploy
        a webapp using all the libs placed in "shared-libs-folder", which is essentially
        what I am asking for.

        Show
        kawazu added a comment - Re-opening it. Rationales: (a) Indeed the admin_gui from my point of view is an integral part of the application server so having someone being capable of rendering it useless simply by deploying a "wrong" jar to <domain>/lib/ is pretty bad style at all, especially considering there is no way of figuring out whether an actual jar deployed there will (not) affect the admin_gui or any other applications eventually installed. Sure, the latter problem won't possibly be resolved by a "single" shared libraries folder but eventually will require more powerful means of dependency / library management, but at least an end user should not be capable of trashing a part of software that comes with the app server (admin_gui) by deploying anything to it. (b) The second approach is technically fine but then again I would, here, plead for something like "asadmin deploy --shared-libs-folder=... <webapp>" to deploy a webapp using all the libs placed in "shared-libs-folder", which is essentially what I am asking for.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

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

            Dates

            • Created:
              Updated: