It looks like Guice is still not injecting resources properly. Here is the
call stack-trace for constructing my main resource:
"http-thread-pool-8080-(2)"
com.foo.health.server.DoctorsResource.<init>(DoctorsResource.java:23)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(NativeConstructorAccessorImpl.java)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
com.sun.jersey.server.spi.component.ResourceComponentConstructor._construct(ResourceComponentConstructor.java:177)
com.sun.jersey.server.spi.component.ResourceComponentConstructor.construct(ResourceComponentConstructor.java:159)
com.sun.jersey.server.impl.resource.PerRequestFactory$PerRequest._getInstance(PerRequestFactory.java:179)
com.sun.jersey.server.impl.resource.PerRequestFactory$AbstractPerRequest.getInstance(PerRequestFactory.java:141)
com.sun.jersey.server.impl.application.WebApplicationContext.getResource(WebApplicationContext.java:181)
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:66)
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:133)
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:71)
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:990)
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:941)
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:932)
com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:384)
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:451)
com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:632)
javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:67)
com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:122)
com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:110)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
com.sun.grizzly.ContextTask.run(ContextTask.java:69)
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
java.lang.Thread.run(Thread.java:662)
Notice how Jersey is constructing the resource instead of Guice. Here is my
Guice Module:
public class GuiceConfig extends GuiceServletContextListener
{
private static final class DataSourceProvider implements
Provider<DataSource>
{
@Override
public DataSource get()
{
return new JdbcDataSource();
}
}
@Override
protected Injector getInjector()
{
return Guice.createInjector(new JerseyServletModule()
{
@Override
protected void configureServlets()
{
install(new
MyBatisModule.Builder().setDataSourceProviderType(DataSourceProvider.class).
setTransactionFactoryType(JdbcTransactionFactory.class).addMapperClasses(Doctors.class).
create());
bindConstant().annotatedWith(Names.named("mybatis.environment.id")).to("development");
Map<String, String> params = Maps.newHashMap();
params.put(PackagesResourceConfig.PROPERTY_PACKAGES,
GuiceConfig.class.getPackage().getName());
serve("/*").with(GuiceContainer.class, params);
}
});
}
}
and here is the GlassFish output on startup:
INFO: Loading application com.foo_health.server_war_1.0-SNAPSHOT at /foo
INFO: com.foo_health.server_war_1.0-SNAPSHOT was successfully deployed in
2,700 milliseconds.
INFO: GlobalStatsProvider registered
INFO: Initiating Jersey application, version 'Jersey: 1.1.5 01/20/2010 04:04
PM'
INFO: Adding the following classes declared in
META-INF/services/jersey-server-components to the resource configuration:
class com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider
class com.sun.jersey.multipart.impl.MultiPartConfigProvider
class com.sun.jersey.multipart.impl.MultiPartReader
class com.sun.jersey.multipart.impl.MultiPartWriter
INFO: Instantiating the Application class, named
com.foo.health.server.ApplicationConfig. The following root resource and
provider classes are registered: [class
org.codehaus.jackson.jaxrs.JacksonJsonProvider, class
org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider, class
org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper, class
com.foo.health.server.DoctorsResource, class
org.codehaus.jackson.jaxrs.JsonParseExceptionMapper]
INFO: Scanning for root resource and provider classes in the packages:
com.foo.health.server
INFO: Root resource classes found:
class com.foo.health.server.DoctorsResource
INFO: No provider classes found.
INFO: Initiating Jersey application, version 'Jersey: 1.1.5 01/20/2010 04:04
PM'
INFO: Adding the following classes declared in
META-INF/services/jersey-server-components to the resource configuration:
class com.sun.jersey.multipart.impl.FormDataMultiPartDispatchProvider
class com.sun.jersey.multipart.impl.MultiPartConfigProvider
class com.sun.jersey.multipart.impl.MultiPartReader
class com.sun.jersey.multipart.impl.MultiPartWriter
INFO: Binding com.foo.health.server.DoctorsResource to
GuiceInstantiatedComponentProvider
... Upon further investigation I noticed that the Jersey-1.5 source-code and
code being profiled did not match so I tried "Overriding Jersey with WAR
Files" (section 12.1) found at
http://jersey.java.net/nonav/documentation/1.5-SNAPSHOT/glassfish.html -- I
did not implement section 12.2 or any other section.
Sadly, now I'm getting this exception:
SEVERE: Missing dependency for constructor public
com.foo.health.server.DoctorsResource(com.foo.health.server.data.Doctors) at
parameter index 0
SEVERE: WebModule[/foo]StandardWrapper.Throwable
This is with Glassfish 3.0.1 so I can't blame any sort of stability
problems. I'm back to square-one... Any ideas?
Gili
--
View this message in context: http://jersey.576304.n2.nabble.com/jersey-guice-Missing-dependency-for-constructor-tp5920703p5924200.html
Sent from the Jersey mailing list archive at Nabble.com.