On Dec 15, 2008, at 2:12 PM, Farrukh Najmi wrote:
> Paul Sandoz wrote:
>> Hi Farrukh,
>>
>> Which app server are you using? do you have version 1.0 of Jersey
>> installed in the app server?
>
> Hi Paul,
>
> I am using apache-tomcat-6.0.16. No there are no jersey jars
> installed in tomcat.
>
>>
>> What is the output from the logging in the app server?
>
> I will send it to you separately offlist shortly.
>
>> what is the spring XML configuration file?
>
> I will send it to you separately offlist shortly.
>
>>
>> Maybe the logging of Jersey and Spring will give some clues as both
>> Jersey and Spring will log root resource classes and components
>> found respectively. I have attached the log output from deploying
>> the spring annotations example in GF v3 (with Jersey 1.0.1
>> installed in GF v3).
>
> It does not appear that jersey code 1.0.1 does much logging of the
> scan process. Should I switch to latest CVS bits?
>
Makes no difference. Jersey only logs what it find and does not log
where it is searching beyond the declared package names.
>>
>> From your error it looks like:
>>
>> 1) Jersey is not finding any root resource classes using package
>> scanning; and
>
> What exactly is the criteria for finding a root resource. I have a
> class like the following:
>
> @Path("/search")
> @Component
> @Scope("singleton")
> public class RegistryRestSearchResource {
>
> @Context
> UriInfo uriInfo;
> @Context
> Request request;
> @Context
> HttpServletResponse servletResponse;
> @Autowired
> private RegistryFacade registryFacade = null;
>
> @GET
> @Produces("application/xml")
> public Response search() {
>
> ....
> return Response.status(200).entity(resp).build();//"OK"
>
>
> }
> }
>
> Why would above class not qualify as a root resource?
>
And why would the above class not qualify as a Spring component ? :-)
i.e. Spring is also not find this class when component scanning.
>>
>> 2) Neither is Spring using component scanning
>>
>> Note that fro 1.0.1 if you are using Spring for registration you no
>> longer require that Jersey scan and the packages related init-param
>> is no longer required, if it is present then there should be no
>> side-effects beyond the cost of scanning twice.
>>
>> I am not really sure what is going on and i cannot reproduce the
>> error. If possible could you zip up a reproducible maven example ?
>
> Perhaps we need better instrumentation of log messages to diagnose
> the problem. Would it be possible for us to work of latest svn bits
> and change them if needed to log approproate info?
>
There seems to be a wider issue of both Jersey *and* Spring cannot
find the class. But adding finer grained logging statements to the
scanning process might help resolve the issue.
See the class:
com.sun.jersey.server.impl.container.config.AnnotatedClassScanner
Paul.
> Thanks.
>
>>
>> Paul.
>>
>>
>> INFO: PWC1412: WebModule[/spring] ServletContext.log():Initializing
>> Spring root WebApplicationContext
>> INFO: Root WebApplicationContext: initialization started
>> INFO: Refreshing org.springframework.web.context.support.XmlWebApplicationContext
>> @7f676a: display name [Root WebApplicationContext]; startup date
>> [Mon Dec 15 11:32:03 CET 2008]; root of context hierarchy
>> INFO: Loading XML bean definitions from class path resource
>> [applicationContext.xml]
>> INFO: Bean factory for application context [org.springframework.web.context.support.XmlWebApplicationContext
>> @7f676a]:
>> org
>> .springframework
>> .beans.factory.support.DefaultListableBeanFactory_at_6927e0
>> INFO: Pre-instantiating singletons in
>> org
>> .springframework
>> .beans.factory.support.DefaultListableBeanFactory_at_6927e0: defining
>> beans
>> [springAopResource
>> ,springAopSubResource
>> ,springAutowiredResource
>> ,springResourcedResource
>> ,org
>> .springframework
>> .context
>> .annotation
>> .internalPersistenceAnnotationProcessor
>> ,org
>> .springframework
>> .context
>> .annotation
>> .internalCommonAnnotationProcessor
>> ,org
>> .springframework
>> .context
>> .annotation
>> .internalAutowiredAnnotationProcessor
>> ,org
>> .springframework
>> .context
>> .annotation
>> .internalRequiredAnnotationProcessor
>> ,org
>> .springframework
>> .aop
>> .config
>> .internalAutoProxyCreator,securityAdvice,item1,item2_1,item2_2];
>> root of factory hierarchy
>> INFO: Root WebApplicationContext: initialization completed in 1152 ms
>> INFO: Scanning for root resource and provider classes in the
>> packages:
>> com.sun.jersey.samples.springannotations.resources.jerseymanaged
>> INFO: Root resource classes found:
>> class
>> com
>> .sun
>> .jersey
>> .samples
>> .springannotations.resources.jerseymanaged.JerseyAutowiredResource
>> INFO: Provider classes found:
>> INFO: Registering Spring bean, springAopResource, of type
>> com
>> .sun
>> .jersey.samples.springannotations.resources.aop.SpringAopResource
>> as a root resource class
>> INFO: Registering Spring bean, springAutowiredResource, of type
>> com
>> .sun
>> .jersey.samples.springannotations.resources.SpringAutowiredResource
>> as a root resource class
>> INFO: Registering Spring bean, springResourcedResource, of type
>> com
>> .sun
>> .jersey.samples.springannotations.resources.SpringResourcedResource
>> as a root resource class
>> INFO: Loading application com.sun.jersey.samples_spring-
>> annotations_war_1.0.1 at /spring
>> INFO: Deployment of com.sun.jersey.samples_spring-
>> annotations_war_1.0.1 done is 3448 ms
>>
>> On Dec 15, 2008, at 3:36 AM, Farrukh Najmi wrote:
>>
>>>
>>> Hi Craig,
>>>
>>> Thanks very much for your help!
>>>
>>> Here are the relevant dependencies from my pom.xml:
>>>
>>> <dependency>
>>> <groupId>com.sun.jersey</groupId>
>>> <artifactId>jersey-server</artifactId>
>>> <version>1.0.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>com.sun.jersey.contribs</groupId>
>>> <artifactId>jersey-spring</artifactId>
>>> <version>1.0.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.springframework</groupId>
>>> <artifactId>spring-core</artifactId>
>>> <version>[2.5.5,)</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.springframework</groupId>
>>> <artifactId>spring</artifactId>
>>> <version>[2.5.5,)</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>org.springframework</groupId>
>>> <artifactId>spring-webmvc</artifactId>
>>> <version>[2.5.5,)</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>javax.xml.ws</groupId>
>>> <artifactId>jaxws-api</artifactId>
>>> <version>2.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>javax.annotation</groupId>
>>> <artifactId>jsr250-api</artifactId>
>>> <version>1.0</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>com.sun.xml.bind</groupId>
>>> <artifactId>jaxb-impl</artifactId>
>>> <version>2.1</version>
>>> </dependency>
>>> <dependency>
>>> <groupId>javax.servlet</groupId>
>>> <artifactId>servlet-api</artifactId>
>>> <version>2.5</version>
>>> <scope>provided</scope>
>>> </dependency>
>>>
>>> Does anything look questionable?
>>>
>>> Craig McClanahan wrote:
>>>> Farrukh Najmi wrote:
>>>>>
>>>>> I am using NetBeans 6.1 strictly as an IDE. I am not using any
>>>>> special support for Jersey in NB. I have a straight maven
>>>>> project to which I added a Jersey resource class and added to
>>>>> pom.xml and web.xml and that is that. In other words I do not
>>>>> believe this is an NB related issue AFAIK. Thanks.
>>>>>
>>>> Cool. Now, to narrow it down a little more, could you share what
>>>> you added to your pom.xml file? It might also be that there are
>>>> some missing jar files there.
>>>>
>
>
> --
> Regards,
> Farrukh Najmi
>
> Web: http://www.wellfleetsoftware.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>