Hi Cheng,
glassfish_at_javadesktop.org wrote:
>A user at Glassfish Chinese forum reported this problem:
>
>http://gceclub.sun.com.cn/NASApp/sme/jive/thread.jsp?forum=22&thread=46965
>
>When a servlet filter class is packaged in a jar in domain1/lib/applibs/ directory, this filter class is not accessible, and the webapp failed to load. He also reported that placing the jar in domain1/lib didn't work either.
>
>I wrote a simple webapp, and my finding is putting the jar in domain1/lib works, but in lib/applibs does NOT work, i.e., the webapp failed to start because the filter class is not accessible. So a reproducible issue.
>
>Is this a bug or by design?
>
>Since it works when the jar is in domain/lib, so I think the app is properly coded and configured.
>
>I explained the the user that since the web container needs to manage the lifecycle of the filter, the jar needs to reside in domain1/lib so the container code can access it, rather than applibs/, which is used by apps. I find it hard to swallow and can't even convince myself this is a valid answer.
>
>How do you think? Appreciate your opinion.
>
>
Any JAR files placed in the domain's lib directory are visible globally,
i.e., may be accessed by any deployed app.
If you want to limit a JAR's visibility so that it may be accessed
only by specific apps, you place the JAR inside the domain's
lib/applibs directory and then specify the name of the JAR file
as an argument to asadmin's --libraries option during deployment
of your app, as follows:
asadmin deploy --libraries <jar_file_name> <app>
See
http://blogs.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt
for details.
Thanks,
Jan