[GLASSFISH-9720] provide a "safe shared lib folder" for deploying jars without affecting the application server Created: 24/Sep/09  Updated: 06/Mar/12

Status: Open
Project: glassfish
Component/s: deployment
Affects Version/s: V3
Fix Version/s: not determined

Type: Improvement Priority: Major
Reporter: kawazu Assignee: Hong Zhang
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
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.



 Comments   
Comment by Sanjeeb Sahoo [ 24/Sep/09 ]

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.

Comment by kawazu [ 24/Sep/09 ]

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.

Comment by Tom Mueller [ 06/Mar/12 ]

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

Generated at Sat Jul 04 10:22:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.