I have a method interceptor that has a number of dependencies (all guice managed objects), as explained in http://code.google.com/p/google-guice/wiki/AOP the use of requestInjection should have guice inject the dependencies auto-magically. But, when the interceptor is called, all the dependencies are null. In my case, all dependencies are in the default scope, so I doubt the problem to be a scoping issue. I did a google and a StackOverflow search, but no case seems to be such as mine...maybe is binding out of order issue...if such thing exist. Any recommendations on who to approach this problem?
> I have a method interceptor that has a number of dependencies (all > guice managed objects), as explained > in http://code.google.com/p/google-guice/wiki/AOP > the use of requestInjection should have guice inject the dependencies > auto-magically. But, when the interceptor is called, all the > dependencies are null. In my case, all dependencies are in the default > scope, so I doubt the problem to be a scoping issue. I did a google > and a StackOverflow search, but no case seems to be such as > mine...maybe is binding out of order issue...if such thing exist. Any > recommendations on who to approach this problem?
> -- > You received this message because you are subscribed to the Google > Groups "google-guice" group.
> To view this discussion on the web visit > https://groups.google.com/d/msg/google-guice/-/Jki7NswRYUwJ.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to > google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en.
It'd be helpful if you posted some code, such as where you request
injection and what the interceptor looks like.
On Nov 15, 2012 9:13 PM, "transmeta01" <transmet...@gmail.com> wrote:
> I have a method interceptor that has a number of dependencies (all guice
> managed objects), as explained in
> http://code.google.com/p/google-guice/wiki/AOP > the use of requestInjection should have guice inject the dependencies
> auto-magically. But, when the interceptor is called, all the dependencies
> are null. In my case, all dependencies are in the default scope, so I doubt
> the problem to be a scoping issue. I did a google and a StackOverflow
> search, but no case seems to be such as mine...maybe is binding out of
> order issue...if such thing exist. Any recommendations on who to approach
> this problem?
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-guice/-/Jki7NswRYUwJ.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to
> google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
}
On Thu, Nov 15, 2012 at 9:35 PM, Fred Faber <ffa...@gmail.com> wrote:
> It'd be helpful if you posted some code, such as where you request
> injection and what the interceptor looks like.
> On Nov 15, 2012 9:13 PM, "transmeta01" <transmet...@gmail.com> wrote:
>> I have a method interceptor that has a number of dependencies (all guice
>> managed objects), as explained in
>> http://code.google.com/p/google-guice/wiki/AOP >> the use of requestInjection should have guice inject the dependencies
>> auto-magically. But, when the interceptor is called, all the dependencies
>> are null. In my case, all dependencies are in the default scope, so I doubt
>> the problem to be a scoping issue. I did a google and a StackOverflow
>> search, but no case seems to be such as mine...maybe is binding out of
>> order issue...if such thing exist. Any recommendations on who to approach
>> this problem?
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/google-guice/-/Jki7NswRYUwJ.
>> To post to this group, send email to google-guice@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-guice+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-guice?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to
> google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
> AuditServiceImpl auditInterceptor = new AuditServiceImpl();
> requestInjection(auditInterceptor);
^ requestInjection can only perform setter or field injection, it cannot perform constructor injection because the object is already constructed. Your interceptor expects constructor injection, which is why you see null values.
Personally I would try to separate the interceptor into its own class, rather than conflate it with an actual service implementation. Then you would only need to @Inject the service you need to use in the interceptor (with @Inject on a field/setter) which would make the code cleaner and easier to maintain.
> On Thu, Nov 15, 2012 at 9:35 PM, Fred Faber <ffa...@gmail.com> wrote:
> It'd be helpful if you posted some code, such as where you request injection and what the interceptor looks like.
> On Nov 15, 2012 9:13 PM, "transmeta01" <transmet...@gmail.com> wrote:
> I have a method interceptor that has a number of dependencies (all guice managed objects), as explained in http://code.google.com/p/google-guice/wiki/AOP > the use of requestInjection should have guice inject the dependencies auto-magically. But, when the interceptor is called, all the dependencies are null. In my case, all dependencies are in the default scope, so I doubt the problem to be a scoping issue. I did a google and a StackOverflow search, but no case seems to be such as mine...maybe is binding out of order issue...if such thing exist. Any recommendations on who to approach this problem?
> -- > You received this message because you are subscribed to the Google Groups "google-guice" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/google-guice/-/Jki7NswRYUwJ.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "google-guice" group.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "google-guice" group.
> To post to this group, send email to google-guice@googlegroups.com.
> To unsubscribe from this group, send email to google-guice+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
Good point about separation of method interception and service
implementation... Tried field injection...didn't work, then tried method
injection...didn't work either. Here is the exception I am getting:
On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
> Good point about separation of method interception and service implementation...
Another reason to separate them is the fact that you're using the manually new'd instance as the interceptor, but also have the implementation registered with an implicit @ImplementedBy binding. The implicit binding would create a separate instance whenever someone injected AuditService (assuming you didn't explicitly bind your new'd instance to AuditService). Not an issue here, but it could be in the future if someone decided to mark it this class as a @Singleton and wondered why they saw two instances being created - one via new and the other via Guice.
> Tried field injection...didn't work, then tried method injection...didn't work either. Here is the exception I am getting:
It looks as though the PersistService has not been started at the time the DAOs are being injected into the interceptor.
public class PersistServiceInitializer {
@Inject PersistServiceInitializer(PersistService service) {
service.start(); } }
and then bind it as an eager singleton before the requestInjection line, which should ensure the PersistService is started before the interceptor is injected.
AuditServiceImpl auditInterceptor = new AuditServiceImpl();
requestInjection(auditInterceptor);
bindInterceptor(Matchers.any(), Matchers.annotatedWith(AuditTrail.class),
auditInterceptor);
AuthorizationService authorizationService = new AuthorizationService();
requestInjection(authorizationService);
bindInterceptor(Matchers.any(), Matchers.annotatedWith(RequiresRole.class),
authorizationService);
EntityNotFoundInterptor entityNotfound = new EntityNotFoundInterptor();
bindInterceptor(Matchers.any(), Matchers.annotatedWith(NullEntity.class),
entityNotfound);
filter("/rest/*").through(PersistFilter.class);
// init rest service
serve("/rest/*").with(GuiceContainer.class, params);
binder().bind(GuiceContainer.class).asEagerSingleton();
}
}, new JpaPersistModule("logbook-persistence"));
the JpaPersistModule is instantiated after the requestInjection call...I am
looking at ways to use some kind of deferred binding...perhaps using a
Provider<T>...Not sure if that would solve my issue though...Any
recommendations?
On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
> Good point about separation of method interception and service
> implementation...
> Another reason to separate them is the fact that you're using the manually
> new'd instance as the interceptor, but also have the implementation
> registered with an implicit @ImplementedBy binding. The implicit binding
> would create a separate instance whenever someone injected AuditService
> (assuming you didn't explicitly bind your new'd instance to AuditService).
> Not an issue here, but it could be in the future if someone decided to mark
> it this class as a @Singleton and wondered why they saw two instances being
> created - one via new and the other via Guice.
> Tried field injection...didn't work, then tried method injection...didn't
> work either. Here is the exception I am getting:
> It looks as though the PersistService has not been started at the time the
> DAOs are being injected into the interceptor.
> public class PersistServiceInitializer {
> @Inject PersistServiceInitializer(PersistService service) {
> service.start();
> }
> }
> and then bind it as an eager singleton before the requestInjection line,
> which should ensure the PersistService is started before the interceptor is
> injected.
> EntityNotFoundInterptor entityNotfound = new EntityNotFoundInterptor();
> bindInterceptor(Matchers.any(), Matchers.annotatedWith(NullEntity.class), entityNotfound);
> filter("/rest/*").through(PersistFilter.class);
> // init rest service
> serve("/rest/*").with(GuiceContainer.class, params);
> binder().bind(GuiceContainer.class).asEagerSingleton();
> }
> }, new JpaPersistModule("logbook-persistence"));
> the JpaPersistModule is instantiated after the requestInjection call...I am looking at ways to use some kind of deferred binding...perhaps using a Provider<T>...Not sure if that would solve my issue though...Any recommendations?
Yes, injecting a Provider for the DAO into the interceptor will help defer use of the PersistService until you actually need it.
> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com> wrote:
> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>> Good point about separation of method interception and service implementation...
> Another reason to separate them is the fact that you're using the manually new'd instance as the interceptor, but also have the implementation registered with an implicit @ImplementedBy binding. The implicit binding would create a separate instance whenever someone injected AuditService (assuming you didn't explicitly bind your new'd instance to AuditService). Not an issue here, but it could be in the future if someone decided to mark it this class as a @Singleton and wondered why they saw two instances being created - one via new and the other via Guice.
>> Tried field injection...didn't work, then tried method injection...didn't work either. Here is the exception I am getting:
> It looks as though the PersistService has not been started at the time the DAOs are being injected into the interceptor.
> public class PersistServiceInitializer {
> @Inject PersistServiceInitializer(PersistService service) {
> service.start(); > } > }
> and then bind it as an eager singleton before the requestInjection line, which should ensure the PersistService is started before the interceptor is injected.
>> com.google.inject.CreationException: Guice creation errors:<|<|1) Error in custom provider, java.lang.NullPointerException<| while locating com.google.inject.persist.jpa.JpaPersistService<| while locating javax.persistence.EntityManager<| for parameter 0 at com.nashen.dao.AuditDao.<init>(AuditDao.java:19)<| while locating com.nashen.dao.AuditDao<| for parameter 0 at com.nashen.service.audit.AuditServiceImpl.setAuditDao(AuditServiceImpl.java :123)<| at com.nashen.integration.GuiceServletConfig$1.configureServlets(GuiceServletC onfig.java:65)<|Caused by: java.lang.NullPointerException<|?at com.google.inject.persist.jpa.JpaPersistService.begin(JpaPersistService.jav a:70)<|?at com.google.inject.persist.jpa.JpaPersistService.get(JpaPersistService.java: 50)<|?at com.google.inject.persist.jpa.JpaPersistService.get(JpaPersistService.java: 34)<|?at com.google.inject.internal.BoundProviderFactory.get(BoundProviderFactory.ja va:55)<|?at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterIn jector.java:38)<|?at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterIn jector.java:62)<|?at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjecto r.java:84)<|?at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBi ndingImpl.java:254)<|?at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterIn jector.java:38)<|?at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterIn jector.java:62)<|?at com.google.inject.internal.SingleMethodInjector.inject(SingleMethodInjector .java:83)<|?at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjecto rImpl.java:110)<|?at com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.j ava:75)<|?at com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.j ava:73)<|?at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:102 4)<|?at com.google.inject.internal.MembersInjectorImpl.injectAndNotify(MembersInjec torImpl.java:73)<|?at com.google.inject.internal.Initializer$InjectableReference.get(Initializer. java:147)<|?at com.google.inject.internal.Initializer.injectAll(Initializer.java:92)<|?at com.google.inject.internal.InternalInjectorCreator.injectDynamically(Intern alInjectorCreator.java:173)<|?at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCr eator.java:109)<|?at com.google.inject.Guice.createInjector(Guice.java:95)<|?at com.google.inject.Guice.createInjector(Guice.java:83)<|?at com.nashen.integration.GuiceServletConfig.getInjector(GuiceServletConfig.ja va:45)<|?at com.google.inject.servlet.GuiceServletContextListener.contextInitialized(Gu iceServletContextListener.java:45)<|?at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(Cont extHandler.java:771)<|?at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(Serv letContextHandler.java:411)<|?at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler .java:763)<|?at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContext Handler.java:247)<|?at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1238 )<|?at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java :706)<|?at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:480)<|?at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle. java:64)<|?at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardSt arter.java:39)<|?at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)<|? at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager .java:494)<|?at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:14 1)<|?at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAp pProvider.java:145)<|?at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(Scanning AppProvider.java:56)<|?at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)<|?at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)<|?at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)<|?at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)<|?at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle. java:64)<|?at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppP rovider.java:121)<|?at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle. java:64)<|?at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManag er.java:555)<|?at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:2 30)<|?at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle. java:64)<|?at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCy cle.java:81)<|?at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.ja va:58)<|?at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java :96)<|?at org.eclipse.jetty.server.Server.doStart(Server.java:277)<|?at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle. java:64)<|?at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1265)<|? at java.security.AccessController.doPrivileged(Native Method)<|?at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1188)<|?a t sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)<|?at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9)<|?at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25)<|?at java.lang.reflect.Method.invoke(Method.java:597)<|?at org.eclipse.jetty.start.Main.invokeMain(Main.java:468)<|?at org.eclipse.jetty.start.Main.start(Main.java:616)<|?at org.eclipse.jetty.start.Main.main(Main.java:92)<|<|2) Error in custom provider, java.lang.NullPointerException<| while locating com.google.inject.persist.jpa.JpaPersistService<| while locating javax.persistence.EntityManager<| for parameter 0 at com.nashen.dao.PilotStatusDao.<init>(PilotStatusDao.java:14)<| while locating com.nashen.dao.PilotStatusDao<| for parameter 0 at
There is still a problem: how do I construct the DAO object in the
provider? It has a guice managed dependencie (the EntityManager)? What is
the simplest or elegant way of doing it?
On Fri, Nov 16, 2012 at 11:43 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
> // init rest service
> serve("/rest/*").with(GuiceContainer.class, params);
> binder().bind(GuiceContainer.class).asEagerSingleton();
> }
> }, new JpaPersistModule("logbook-persistence"));
> the JpaPersistModule is instantiated after the requestInjection call...I
> am looking at ways to use some kind of deferred binding...perhaps using a
> Provider<T>...Not sure if that would solve my issue though...Any
> recommendations?
> Yes, injecting a Provider for the DAO into the interceptor will help defer
> use of the PersistService until you actually need it.
> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>> Good point about separation of method interception and service
>> implementation...
>> Another reason to separate them is the fact that you're using the
>> manually new'd instance as the interceptor, but also have the
>> implementation registered with an implicit @ImplementedBy binding. The
>> implicit binding would create a separate instance whenever someone injected
>> AuditService (assuming you didn't explicitly bind your new'd instance to
>> AuditService). Not an issue here, but it could be in the future if someone
>> decided to mark it this class as a @Singleton and wondered why they saw two
>> instances being created - one via new and the other via Guice.
>> Tried field injection...didn't work, then tried method injection...didn't
>> work either. Here is the exception I am getting:
>> It looks as though the PersistService has not been started at the time
>> the DAOs are being injected into the interceptor.
>> You could create a simple initializer, such as:
>> public class PersistServiceInitializer {
>> @Inject PersistServiceInitializer(PersistService service) {
>> service.start();
>> }
>> }
>> and then bind it as an eager singleton before the requestInjection line,
>> which should ensure the PersistService is started before the interceptor is
>> injected.
On 16 Nov 2012, at 16:52, Richard Mutezintare wrote:
> There is still a problem: how do I construct the DAO object in the provider? It has a guice managed dependencie (the EntityManager)? What is the simplest or elegant way of doing it?
Just change:
@Inject AuditDao auditDao;
into:
@Inject Provider<AuditDao> auditDaoProvider;
and then use auditDaoProvider.get() to get the DAO.
>> // init rest service
>> serve("/rest/*").with(GuiceContainer.class, params);
>> binder().bind(GuiceContainer.class).asEagerSingleton();
>> }
>> }, new JpaPersistModule("logbook-persistence"));
>> the JpaPersistModule is instantiated after the requestInjection call...I am looking at ways to use some kind of deferred binding...perhaps using a Provider<T>...Not sure if that would solve my issue though...Any recommendations?
> Yes, injecting a Provider for the DAO into the interceptor will help defer use of the PersistService until you actually need it.
>> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com> wrote:
>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>>> Good point about separation of method interception and service implementation...
>> Another reason to separate them is the fact that you're using the manually new'd instance as the interceptor, but also have the implementation registered with an implicit @ImplementedBy binding. The implicit binding would create a separate instance whenever someone injected AuditService (assuming you didn't explicitly bind your new'd instance to AuditService). Not an issue here, but it could be in the future if someone decided to mark it this class as a @Singleton and wondered why they saw two instances being created - one via new and the other via Guice.
>>> Tried field injection...didn't work, then tried method injection...didn't work either. Here is the exception I am getting:
>> It looks as though the PersistService has not been started at the time the DAOs are being injected into the interceptor.
>> You could create a simple initializer, such as:
>> public class PersistServiceInitializer {
>> @Inject PersistServiceInitializer(PersistService service) {
>> service.start(); >> } >> }
>> and then bind it as an eager singleton before the requestInjection line, which should ensure the PersistService is started before the interceptor is injected.
public class AuditDaoProvider implements Provider<AuditDao> {
AuditDao _auditDao;
@Inject
public AuditDaoProvider(AuditDao auditDao) {
_auditDao = auditDao;
}
@Override
public AuditDao get() {
return _auditDao;
}
and in the method interceptor I have:
@Inject private Provider<AuditDao> _auditDaoProvider;
public AuditServiceImpl(Provider<AuditDao> auditDaoProvider) {
_auditDaoProvider = auditDaoProvider;
}
... and when I need the DAO, I do: _auditDaoProvider.get().persist(audit);
it seems a binding of the provider is missing in the servletModule
config...or it is not necessary to explicitly bind the provider?
On Fri, Nov 16, 2012 at 11:59 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
> On 16 Nov 2012, at 16:52, Richard Mutezintare wrote:
> There is still a problem: how do I construct the DAO object in the
> provider? It has a guice managed dependencie (the EntityManager)? What is
> the simplest or elegant way of doing it?
> Just change:
> @Inject AuditDao auditDao;
> into:
> @Inject Provider<AuditDao> auditDaoProvider;
> and then use auditDaoProvider.get() to get the DAO.
>> // init rest service
>> serve("/rest/*").with(GuiceContainer.class, params);
>> binder().bind(GuiceContainer.class).asEagerSingleton();
>> }
>> }, new JpaPersistModule("logbook-persistence"));
>> the JpaPersistModule is instantiated after the requestInjection call...I
>> am looking at ways to use some kind of deferred binding...perhaps using a
>> Provider<T>...Not sure if that would solve my issue though...Any
>> recommendations?
>> Yes, injecting a Provider for the DAO into the interceptor will help
>> defer use of the PersistService until you actually need it.
>> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>>> Good point about separation of method interception and service
>>> implementation...
>>> Another reason to separate them is the fact that you're using the
>>> manually new'd instance as the interceptor, but also have the
>>> implementation registered with an implicit @ImplementedBy binding. The
>>> implicit binding would create a separate instance whenever someone injected
>>> AuditService (assuming you didn't explicitly bind your new'd instance to
>>> AuditService). Not an issue here, but it could be in the future if someone
>>> decided to mark it this class as a @Singleton and wondered why they saw two
>>> instances being created - one via new and the other via Guice.
>>> Tried field injection...didn't work, then tried method
>>> injection...didn't work either. Here is the exception I am getting:
>>> It looks as though the PersistService has not been started at the time
>>> the DAOs are being injected into the interceptor.
>>> You could create a simple initializer, such as:
>>> public class PersistServiceInitializer {
>>> @Inject PersistServiceInitializer(PersistService service) {
>>> service.start();
>>> }
>>> }
>>> and then bind it as an eager singleton before the requestInjection line,
>>> which should ensure the PersistService is started before the interceptor is
>>> injected.
> and in the method interceptor I have:
> @Inject private Provider<AuditDao> _auditDaoProvider;
> public AuditServiceImpl(Provider<AuditDao> auditDaoProvider) {
> _auditDaoProvider = auditDaoProvider;
> }
> ... and when I need the DAO, I do: _auditDaoProvider.get().persist(audit);
> it seems a binding of the provider is missing in the servletModule
> config...or it is not necessary to explicitly bind the provider?
> On Fri, Nov 16, 2012 at 11:59 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>> On 16 Nov 2012, at 16:52, Richard Mutezintare wrote:
>> There is still a problem: how do I construct the DAO object in the
>> provider? It has a guice managed dependencie (the EntityManager)? What is
>> the simplest or elegant way of doing it?
>> Just change:
>> @Inject AuditDao auditDao;
>> into:
>> @Inject Provider<AuditDao> auditDaoProvider;
>> and then use auditDaoProvider.get() to get the DAO.
>>> // init rest service
>>> serve("/rest/*").with(GuiceContainer.class, params);
>>> binder().bind(GuiceContainer.class).asEagerSingleton();
>>> }
>>> }, new JpaPersistModule("logbook-persistence"));
>>> the JpaPersistModule is instantiated after the requestInjection call...I
>>> am looking at ways to use some kind of deferred binding...perhaps using a
>>> Provider<T>...Not sure if that would solve my issue though...Any
>>> recommendations?
>>> Yes, injecting a Provider for the DAO into the interceptor will help
>>> defer use of the PersistService until you actually need it.
>>> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>>>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>>>> Good point about separation of method interception and service
>>>> implementation...
>>>> Another reason to separate them is the fact that you're using the
>>>> manually new'd instance as the interceptor, but also have the
>>>> implementation registered with an implicit @ImplementedBy binding. The
>>>> implicit binding would create a separate instance whenever someone injected
>>>> AuditService (assuming you didn't explicitly bind your new'd instance to
>>>> AuditService). Not an issue here, but it could be in the future if someone
>>>> decided to mark it this class as a @Singleton and wondered why they saw two
>>>> instances being created - one via new and the other via Guice.
>>>> Tried field injection...didn't work, then tried method
>>>> injection...didn't work either. Here is the exception I am getting:
>>>> It looks as though the PersistService has not been started at the time
>>>> the DAOs are being injected into the interceptor.
>>>> You could create a simple initializer, such as:
>>>> public class PersistServiceInitializer {
>>>> @Inject PersistServiceInitializer(PersistService service) {
>>>> service.start();
>>>> }
>>>> }
>>>> and then bind it as an eager singleton before the requestInjection
>>>> line, which should ensure the PersistService is started before the
>>>> interceptor is injected.
Also the AuditDaoProvider class won't work because you're injecting AuditDao into the constructor, which means it's not lazily loaded (and it also introduces a cycle).
> and in the method interceptor I have: > @Inject private Provider<AuditDao> _auditDaoProvider; > public AuditServiceImpl(Provider<AuditDao> auditDaoProvider) {
> _auditDaoProvider = auditDaoProvider;
> }
> ... and when I need the DAO, I do: _auditDaoProvider.get().persist(audit);
> it seems a binding of the provider is missing in the servletModule config...or it is not necessary to explicitly bind the provider?
If you use the built-in Provider<AuditDao> binding to lazy load AuditDao then you don't need to explicitly bind a provider.
> On Fri, Nov 16, 2012 at 11:59 AM, Stuart McCulloch <mccu...@gmail.com> wrote:
> On 16 Nov 2012, at 16:52, Richard Mutezintare wrote:
>> There is still a problem: how do I construct the DAO object in the provider? It has a guice managed dependencie (the EntityManager)? What is the simplest or elegant way of doing it?
> Just change:
> @Inject AuditDao auditDao;
> into:
> @Inject Provider<AuditDao> auditDaoProvider;
> and then use auditDaoProvider.get() to get the DAO.
>>> // init rest service
>>> serve("/rest/*").with(GuiceContainer.class, params);
>>> binder().bind(GuiceContainer.class).asEagerSingleton();
>>> }
>>> }, new JpaPersistModule("logbook-persistence"));
>>> the JpaPersistModule is instantiated after the requestInjection call...I am looking at ways to use some kind of deferred binding...perhaps using a Provider<T>...Not sure if that would solve my issue though...Any recommendations?
>> Yes, injecting a Provider for the DAO into the interceptor will help defer use of the PersistService until you actually need it.
>>> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com> wrote:
>>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>>>> Good point about separation of method interception and service implementation...
>>> Another reason to separate them is the fact that you're using the manually new'd instance as the interceptor, but also have the implementation registered with an implicit @ImplementedBy binding. The implicit binding would create a separate instance whenever someone injected AuditService (assuming you didn't explicitly bind your new'd instance to AuditService). Not an issue here, but it could be in the future if someone decided to mark it this class as a @Singleton and wondered why they saw two instances being created - one via new and the other via Guice.
>>>> Tried field injection...didn't work, then tried method injection...didn't work either. Here is the exception I am getting:
>>> It looks as though the PersistService has not been started at the time the DAOs are being injected into the interceptor.
>>> You could create a simple initializer, such as:
>>> public class PersistServiceInitializer {
>>> @Inject PersistServiceInitializer(PersistService service) {
>>> service.start(); >>> } >>> }
>>> and then bind it as an eager singleton before the requestInjection line, which should ensure the PersistService is started before the interceptor is injected.
> Also the AuditDaoProvider class won't work because you're
> injecting AuditDao into the constructor, which means it's not lazily loaded
> (and it also introduces a cycle).
> and in the method interceptor I have:
> @Inject private Provider<AuditDao> _auditDaoProvider;
> public AuditServiceImpl(Provider<AuditDao> auditDaoProvider) {
> _auditDaoProvider = auditDaoProvider;
> }
> ... and when I need the DAO, I do: _auditDaoProvider.get().persist(audit);
> it seems a binding of the provider is missing in the servletModule
> config...or it is not necessary to explicitly bind the provider?
> If you use the built-in Provider<AuditDao> binding to lazy load AuditDao
> then you don't need to explicitly bind a provider.
> On Fri, Nov 16, 2012 at 11:59 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>> On 16 Nov 2012, at 16:52, Richard Mutezintare wrote:
>> There is still a problem: how do I construct the DAO object in the
>> provider? It has a guice managed dependencie (the EntityManager)? What is
>> the simplest or elegant way of doing it?
>> Just change:
>> @Inject AuditDao auditDao;
>> into:
>> @Inject Provider<AuditDao> auditDaoProvider;
>> and then use auditDaoProvider.get() to get the DAO.
>>> // init rest service
>>> serve("/rest/*").with(GuiceContainer.class, params);
>>> binder().bind(GuiceContainer.class).asEagerSingleton();
>>> }
>>> }, new JpaPersistModule("logbook-persistence"));
>>> the JpaPersistModule is instantiated after the requestInjection call...I
>>> am looking at ways to use some kind of deferred binding...perhaps using a
>>> Provider<T>...Not sure if that would solve my issue though...Any
>>> recommendations?
>>> Yes, injecting a Provider for the DAO into the interceptor will help
>>> defer use of the PersistService until you actually need it.
>>> On Fri, Nov 16, 2012 at 11:19 AM, Stuart McCulloch <mccu...@gmail.com>wrote:
>>>> On 16 Nov 2012, at 15:48, Richard Mutezintare wrote:
>>>> Good point about separation of method interception and service
>>>> implementation...
>>>> Another reason to separate them is the fact that you're using the
>>>> manually new'd instance as the interceptor, but also have the
>>>> implementation registered with an implicit @ImplementedBy binding. The
>>>> implicit binding would create a separate instance whenever someone injected
>>>> AuditService (assuming you didn't explicitly bind your new'd instance to
>>>> AuditService). Not an issue here, but it could be in the future if someone
>>>> decided to mark it this class as a @Singleton and wondered why they saw two
>>>> instances being created - one via new and the other via Guice.
>>>> Tried field injection...didn't work, then tried method
>>>> injection...didn't work either. Here is the exception I am getting:
>>>> It looks as though the PersistService has not been started at the time
>>>> the DAOs are being injected into the interceptor.
>>>> You could create a simple initializer, such as:
>>>> public class PersistServiceInitializer {
>>>> @Inject PersistServiceInitializer(PersistService service) {
>>>> service.start();
>>>> }
>>>> }
>>>> and then bind it as an eager singleton before the requestInjection
>>>> line, which should ensure the PersistService is started before the
>>>> interceptor is injected.
