-
1. Re: Injection at invocation time, not instantiation time
bdecoste Oct 10, 2007 11:49 AM (in response to bdecoste)The problem with delaying instantation or injection is that the @Service bean may never be invoked - it could be some background service ...
God, I feel like Adrian talking to myself on the forums :-) -
2. Re: Injection at invocation time, not instantiation time
cbredesen Oct 10, 2007 11:50 AM (in response to bdecoste)The case against this would be service beans that aren't interactive, but are background workers, and thus never invoked. So at what point do you deploy/inject those? The obvious answer is that you make those work like the current service beans (deployed at startup) but then how do you differentiate between the beans that are invoked and ones that are purely background ones?
-
3. Re: Injection at invocation time, not instantiation time
wolfc Oct 10, 2007 12:18 PM (in response to bdecoste)The service beans are also used for one time startup logic. These never get called.
-
4. Re: Injection at invocation time, not instantiation time
bdecoste Oct 10, 2007 12:29 PM (in response to bdecoste)There seems to be an echo in here. The more I think about it, the more I like the idea of doing injection based on an interceptor. The interceptor could be bound to constructors or to methods, so config would control when injection occurs.
-
5. Re: Injection at invocation time, not instantiation time
wolfc Oct 10, 2007 12:45 PM (in response to bdecoste)JSR 250 disallows for injection after construction. (See also EJBTHREE-1055.)
So either we don't allow it, or it's a JBoss specific feature. -
6. Re: Injection at invocation time, not instantiation time
bdecoste Oct 10, 2007 12:51 PM (in response to bdecoste)The problem is only for @Service beans because we instantiate at deploy time - I still like the idea of being flexible. We support injection at instantiation but give the flexibility to inject at invocation.