On Oct 3, 2008, at 5:04 AM, Gili wrote:
>
>
> Craig McClanahan wrote:
>>
>> Gotta love defaults :-). The default for Jersey is the classpath
>> scanner that analyzes every class visible to the webapp class loader
>> (from WEB-INF/lib/*.jar, WEB-INF/classes/*, and whatever the server
>> makes available).
>>
>
> How can it do that? The last time I checked, ClassLoaders don't
> expose a
> list of classes or packages they have loaded...
>
For servlet it resolves the WEB-INF/lib and WEB-INF/classes to
directories, then scans the jars and class files using ASM. A similar
trick is done for package scanning. The former is not portable across
app servers. Works on GF and Tomcat. The latter is more portable but
will not work where classes are loaded from some "virtual" mechanism.
For more details, see the JavaDoc and code for the following in the
jersey-core module:
com.sun.jersey.api.core.PackagesResourceConfig
com.sun.jersey.api.core.ClasspathResourceConfig
Also see the JavaDoc for:
com.sun.jersey.spi.container.servlet.ServletContainer
that documents the configuration.
>
> Craig McClanahan wrote:
>>
>> This has the potential to be slower than the package
>> scanner, but serves nicely as a default for smaller webapps because
>> there are not so many classes that the universal scan takes too long.
>>
>> If you've got Hibernate, or all of Spring, or something else that
>> big in
>> your classpath, you'll probably prefer the package scanner.
>>
>
> Frankly, I think I would prefer this default even if my classpath
> *was*
> bigger. It works great out-of-the-box and focuses on ease-of-use above
> performance, which has always been my preference. Don't get me
> started on
> Hibernate's classpath hell.
>
:-)
> Good job Jersey! :)
>
Thanks!
Paul.