Hi,
I just downloaded Tomcat 6.0.20, started it, and deployed the
helloworld-webapp.war and it worked fine (see log at end of email).
Do you have a configuration overriding the defaults ?
If you are using Spring you can register your resources classes as
spring beans. See:
http://blogs.sun.com/enterprisetechtips/entry/jersey_and_spring
https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/contribs/jersey-spring/index.html
https://jersey.dev.java.net/nonav/apidocs/1.1.0-ea/contribs/jersey-spring/com/sun/jersey/spi/spring/container/servlet/package-summary.html
Paul.
Jun 24, 2009 9:07:05 AM org.apache.catalina.core.AprLifecycleListener
init
INFO: The APR based Apache Tomcat Native library which allows optimal
performance in production environments was not found on the
java.library.path: .:/Library/Java/Extensions:/System/Library/Java/
Extensions:/usr/lib/java
Jun 24, 2009 9:07:05 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Jun 24, 2009 9:07:05 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 369 ms
Jun 24, 2009 9:07:05 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Jun 24, 2009 9:07:05 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.20
Jun 24, 2009 9:07:05 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Jun 24, 2009 9:07:05 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Jun 24, 2009 9:07:05 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/19 config=null
Jun 24, 2009 9:07:05 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 618 ms
Jun 24, 2009 9:08:07 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive helloworld-webapp.war
Jun 24, 2009 9:08:07 AM com.sun.jersey.api.core.PackagesResourceConfig
init
INFO: Scanning for root resource and provider classes in the packages:
com.sun.jersey.samples.helloworld.resources
Jun 24, 2009 9:08:07 AM com.sun.jersey.api.core.PackagesResourceConfig
init
INFO: Root resource classes found:
class com.sun.jersey.samples.helloworld.resources.HelloWorldResource
Jun 24, 2009 9:08:07 AM com.sun.jersey.api.core.PackagesResourceConfig
init
INFO: Provider classes found:
Jun 24, 2009 9:08:08 AM
com.sun.jersey.server.impl.application.WebApplicationImpl initiate
INFO: Initiating Jersey application, version 'Jersey: 1.1.1-ea-
SNAPSHOT 06/22/2009 05:03 PM'
On Jun 23, 2009, at 9:39 PM, Saavedra, Gisella wrote:
> Paul,
>
> I just tried Tomcat 6 and got the same error. We do not modify any of
> the tomcat .policy files.
> I changed the order of the servlets started (<load-on-startup> in
> web.xml), and put Jersey's as 1st, 2nd,.etc.
> and still got the same error.
>
> I do not know where else I can look at to make the web.xml Jersey
> servlet params to work:
> <init-param>
>
> <param-name>com.sun.jersey.config.property.resourceConfigClass</
> param-na
> me>
>
> <param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-
> value
>> pach
> </init-param>
> <init-param>
>
> <param-name>com.sun.jersey.config.property.packages</param-name>
>
> <param-value>com.navis.framework.rest.resources</param-value>
> </init-param>
>
> As you said, removing the init-params out works, but I would prefer
> not
> to allow all resources be available.
>
> This is the output with tomcat 6.0
>
> Jun 23, 2009 12:11:04 PM org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8280
> Jun 23, 2009 12:11:04 PM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 3518 ms
> Jun 23, 2009 12:11:05 PM org.apache.catalina.core.StandardService
> start
> INFO: Starting service Catalina
> Jun 23, 2009 12:11:05 PM org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
> Jun 23, 2009 12:11:05 PM org.apache.catalina.startup.HostConfig
> deployDescriptor
> Jun 23, 2009 12:11:31 PM
> com.sun.jersey.api.core.PackagesResourceConfig
> init
> INFO: Scanning for root resource and provider classes in the packages:
> com.navis.framework.rest.resources
> Jun 23, 2009 12:11:31 PM
> com.sun.jersey.server.impl.application.WebApplicationIm
> pl initiate
> INFO: Initiating Jersey application, version 'Jersey: 1.1.0-ea
> 04/30/2009 04:46
> PM'
> Jun 23, 2009 12:11:32 PM
> com.sun.jersey.server.impl.application.WebApplicationIm
> pl processRootResources
> SEVERE: The ResourceConfig instance does not contain any root resource
> classes.
> Jun 23, 2009 12:11:36 PM org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8280
>
> We also use the Spring Framework. Any other suggestion for research on
> my side would be great.
>
> Thanks.
>
> -----Original Message-----
> From: Paul Sandoz [mailto:Paul.Sandoz_at_Sun.COM]
> Sent: Wednesday, June 17, 2009 10:50 PM
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] web application resource root class in WEB-INF/
> lib
>
> Hi,
>
> I suspect that the thread context class loader set up by Tomcat is
> restricting access to classes present in WEB-INF/classes.
>
> I think this might be a Tomcat 5.x specific issue. AFAIK Tomcat 6 does
> not have this issue, see here:
>
>
> http://weblogs.java.net/blog/jfarcand/archive/2009/06/getting_started_2
> .
> html
>
>
> On Jun 18, 2009, at 12:20 AM, Saavedra, Gisella wrote:
>
>> I commented out all the init parameters for the jersey servlet, and
>> my classes were found and loaded. It searches WEB-INF/lib and WEB-
>> INF/classes.
>> See log output below.
>>
>> So, I would consider this scenario an issue worth investigating on
>> your side. I don't see a good reason why I have to edit the default
>> application server policy file.
>
> Did you edit the policy file, and if so did package scanning work ?
>
>
>> Even more, I may not want my particular application to load all
>> resource packages it finds.
>
> Note that class scanning using ClasspathResourceConfig is, ironically,
> less portable than package scanning using PackagesResourceConfig :-)
>
>
>>
>> [I'll take a look at the workaround... implement Application?]
>>
>
> Yes, as a workaround. Or use Tomcat 6.x. Or use GF :-)
>
>
>>
>> The PackagesResourceConfig (when specified as init parameter) should
>> find the classes as does the ClasspathResourceConfig that succeeds.
>
> They use different techniques to find the directories where class
> files are located. The PackagesResourceConfig tries to find
> directories using the classloader.getResources(...) where
> "classloader" is obtained by the following:
>
> public static ClassLoader getContextClassLoader() {
> return AccessController.doPrivileged(
> new PrivilegedAction<ClassLoader>() {
> public ClassLoader run() {
> ClassLoader cl = null;
> try {
> cl =
> Thread.currentThread().getContextClassLoader();
> } catch (SecurityException ex) {
> }
> return cl;
> }
> });
> }
>
> The actual loading of classes is performed as follows:
>
> public static Class classForNameWithException(String name,
> ClassLoader cl)
> throws ClassNotFoundException {
> if (cl != null) {
> try {
> return Class.forName(name, false, cl);
> } catch (ClassNotFoundException ex) {
> }
> }
> return Class.forName(name);
> }
>
>
> I am wondering if an empty enumeration is returned i should try:
>
> this.getClass().getClassLoader().getResources(...)
>
> Could you try:
>
> ClassLoader classloader = his.getClass().getClassLoader();
> Enumeration<URL> urls = classloader.getResources("com/navis/
> framework/rest/resources");
>
> Paul.
>
>
>
>>
>> I checked the tomcat documentation for Tomcat 5.5 Servlet/JSP
>> Container
>> and there is information about the Java SecurityManager. The
>> catalina.policy file says
>>
>> // a web application will be given a read FilePermission
>> // and JndiPermission for all files and directories in its document
>> root.
>>
>>
>> I also found in the catalina.properties file, the following example,
>> but this if needed for jersey implies customizing this file for an
>> application:
>> // The permissions granted to the context WEB-INF/classes directory
>> // grant codeBase "file:${catalina.home}/webapps/examples/WEB-INF/
>> classes/-" {
>> // };
>>
>>
>>
>> --- Log output when init params for jersey servlet are commented
>> out -
>>
>> Jun 17, 2009 10:15:15 AM
>> com.sun.jersey.api.core.ClasspathResourceConfig init
>> INFO: Scanning for root resource and provider classes in the paths:
>> C:\N4\sandbox-dev\tools\tomcat-5.5\webapps\sandbox\WEB-INF\lib
>> C:\N4\sandbox-dev\tools\tomcat-5.5\webapps\sandbox\WEB-INF\classes
>> Jun 17, 2009 10:15:44 AM
>> com.sun.jersey.api.core.ClasspathResourceConfig init
>> INFO: Root resource classes found:
>> class com.navis.framework.rest.resources.LogListResource
>> class com.navis.framework.rest.resources.LogBundle
>>
>>
>> From: Gisella%20Saavedra%20%5Bgisellas%40yachay.net%5D
> [mailto:gisellas_at_comcast.net
>> ]
>> Sent: Wednesday, June 17, 2009 3:06 PM
>> To: Saavedra, Gisella
>> Subject: Fwd: [Jersey] web application resource root class in WEB-
>> INF/lib
>>
>>
>> ----- Forwarded Message -----
>> From: "Paul Sandoz" <Paul.Sandoz_at_Sun.COM>
>> To: users_at_jersey.dev.java.net
>> Sent: Wednesday, June 17, 2009 3:28:18 AM GMT -08:00 US/Canada
>> Pacific
>> Subject: Re: [Jersey] web application resource root class in WEB-INF/
>> lib
>>
>> Hi,
>>
>> It looks like the the class loader that is being used is only
>> configured to load classes from the WEB-INF/classes directory.
>>
>> Is there any way to configure, via tomcat, to configure the class
>> loader to load from "WEB-INF/classes" and "WEB-INF/lib" ?
>>
>> I tried a quick test with Glassfish v3 Prelude and it works fine
>> picking up classes in "WEB-INF/classes" and "WEB-INF/lib"
>>
>>
>> Just curious if you remove you init params from your web.xml then
>> class scanning should kick in and it will try and scan for stuff in
>> "WEB-INF/classes" and "WEB-INF/lib", i wonder if that works.
>>
>> A work around is to define your own concrete implementation of
>> javax.ws.rs.Application and explicitly declare your resource classes.
>>
>> Paul.
>>
>>
>> On Jun 16, 2009, at 7:44 PM, Saavedra, Gisella wrote:
>>
>>
>> I am enclosing the image of the scan() call (jersey_package_scan.png
>> for .class files in WEB-INF/lib/xxx.jar). At the point that
>> Enumeration<URL> urls = classloader.getResources("com/navis/
>> framework/rest/resources");
>> is called, the URL classpath points to the tomcat 5.5 server path.
>> That is what it looks like.
>> urls.hasMoreElements() returns false (no elements).
>>
>> I have the Jersey jars in WEB-INF/lib.
>> I am using
>> jersey-client-1.1.0-ea.jar
>> jersey-server-1.1.0-ea.jar
>> jersey-core-1.1.0-ea.jar
>>
>> The jaxb- 2.1.x libs
>> The jsr311-api-1.1.jar, activation, asm, persistence.
>>
>>
>> When I put the .class files under WEB-INF/classes, my application
>> works. I have enclosed a second image showing that the package is
>> found in the WEB-INF/classes directory
>> (jersey_package_scan_class_dir.png for .class files in WEB-INF/
>> classes) .
>>
>> The problem is that we do deliver our application in .jar files, so
>> I really need to resolve this problem.
>>
>> Any suggestion, please I will appreciate.
>>
>> Thanks.
>>
>>
>>
>> Gisella Saavedra
>> Sr. Software Engineer
>> gsaavedra_at_zebra.com
>> <image001.gif>
>> 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T
>> Main+1 510 267 5000 F+1 510 267 5100 | http://www.zebra.com/zes
>>
>>
>> <jersey_package_scan_class_dir.png><jersey_package_scan.png>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>