bineanzhou / google-guice

Automatically exported from code.google.com/p/google-guice
Apache License 2.0
0 stars 0 forks source link

Support Provision Interception / Construction Interception #78

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Bob will add more details.

Original issue reported on code.google.com by kevin...@gmail.com on 19 Mar 2007 at 6:29

GoogleCodeExporter commented 9 years ago

Original comment by limpbizkit on 30 May 2008 at 6:46

GoogleCodeExporter commented 9 years ago
The elevator pitch - give classes a hook to introspect a type at injector 
creation time. Then whenever an instance 
of that type is instantiated, the classes get a callback. This can be used to 
implement arbitrary APIs (such as EJB) 
on top of Guice.

Original comment by limpbizkit on 6 Jun 2008 at 4:20

GoogleCodeExporter commented 9 years ago
Here's a first spike towards a solution based on the conversations here 
http://groups.google.com/group/google-guice/browse_thread/thread/db156057ec65888
d and the great 
suggestion by Dhanji to use ConstructorInterceptor.

I'll continue to noodle on this and try make more test cases for it; plus the 
generics code in 
ProxyFactory.wrapConstructorProxy() could be cleaner; but it seems to work!

Original comment by james.st...@gmail.com on 3 Oct 2008 at 3:52

Attachments:

GoogleCodeExporter commented 9 years ago
here's a secondary patch which adds support for the default spring post 
construct lifecycle - using Spring's 
InitializingBean interface which makes it easy to work with spring beans

Original comment by james.st...@gmail.com on 3 Oct 2008 at 4:32

Attachments:

GoogleCodeExporter commented 9 years ago
here's a complete patch which replaces the previous two; it includes improved 
javadoc along with a JSR 250 
module which adds support for @PostConstruct along with some tests.

This patch requires the jar installed at lib/build/jsr250-api-1.0.jar and to 
create a new IDEA module.

BTW I added an extra helper method in the Matchers too; 
Matchers.methodAnnotatedWith() which makes it easy 
to create matchers for most annotation driven post construction points

Original comment by james.st...@gmail.com on 4 Oct 2008 at 2:52

Attachments:

GoogleCodeExporter commented 9 years ago
BTW I've added another patch based on this patch to issue 62 
(http://code.google.com/p/google-
guice/issues/detail?id=62) which also includes support for closing down 
singleton/REQUEST/SESSION scoped 
objects. In adding this second patch I did a small amount of cosmetic 
refactoring such as moving the constructor 
interceptor's bind() methods for spring/jsr250 into a separate class and 
renaming a few test cases. If this patch 
gets applied in some form I'll happily recut the patch for 62 if you like.

Original comment by james.st...@gmail.com on 6 Oct 2008 at 1:41

GoogleCodeExporter commented 9 years ago
BTW after Jesse's recent changes it took a bit of work to get my recent patches 
(62, 78, 258) all working again - 
they're now in this svk mirror : 
http://code.google.com/p/guiceyfruit/source/browse/#svn/trunk/guice if thats 
any help. 

I'm not sure yet how to create a patch from an svk mirror so I can attach it 
here :(. Shame we don't all use git :)

Original comment by james.st...@gmail.com on 15 Oct 2008 at 12:22

GoogleCodeExporter commented 9 years ago
Aha - figured out the diff commands to create a new patch of my changes 
whenever you're ready to take a look; 
they are all at the bottom of this wiki page

http://code.google.com/p/guiceyfruit/wiki/GuicePatches

I'll keep merging my patches with trunk of guice so whenever you're ready to 
take a look just run those diff 
commands and you'll get an up-to-date patch

Original comment by james.st...@gmail.com on 15 Oct 2008 at 1:17

GoogleCodeExporter commented 9 years ago
Months has passed, the complete_patch.patch has outdated. Guiceyfruit doesn't 
seem to  
has the latest source code from google-guice. Does anybody got an "up-to-date" 
patch? 
I'm wondering, why such important feature is still being left off from trunk?

Right now Guice source code is checked into my project's svn, if only I knew 
Guice's 
internals enough to add this feature in.

Original comment by apithef...@gmail.com on 11 Mar 2009 at 11:24

GoogleCodeExporter commented 9 years ago
@apithefire: The latest injectable type listener in trunk now acts as an 
alternative to my previous patch. I've 
updated GuiceyFruit to use the latest Guice trunk and its now working fine for 
@PostConstruct post commit 
hook notification.

So its quite easy to add this yourself on top of guice - or reuse GuiceyFruit 
if you want JSR 250 / Spring post 
commit hook support.

Original comment by james.st...@gmail.com on 3 Apr 2009 at 9:57

GoogleCodeExporter commented 9 years ago
Its tempting to close this issue - though I'd prefer the (very trivial & 
minor!) patch for
 http://code.google.com/p/google-guice/issues/detail?id=351
to be applied first as this allows you to register either a custom injector 
listener - or a post injection listener 
(e.g. to avoid @PostContruct hooks being fired before injection has completed).

So its nearly there! :)

Original comment by james.st...@gmail.com on 3 Apr 2009 at 9:59

GoogleCodeExporter commented 9 years ago
you can close this issue now IMHO - as 351 is now resolved too (thanks to 
MembersInjector and InjectionListener 
on TypeEncounter)

Original comment by james.st...@gmail.com on 15 Apr 2009 at 3:50

GoogleCodeExporter commented 9 years ago
@james.strachan We still don't provide general provision interception. For 
example, we don't have hooks when 
@Provides methods are used to satisfy bindings.

Original comment by limpbizkit on 15 Apr 2009 at 4:37

GoogleCodeExporter commented 9 years ago

Original comment by sberlin on 22 Feb 2011 at 1:51

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Attached is a proof-of-concept (rough around the edges, needs more tests, etc.. 
but completely working AFAICT) patch that adds provision listening for normal 
(constructor) bindings & provider bindings.  The API is:

 bindListener(Matcher<? super Key<?>>, ProvisionListener)
 ProvisionListener {
   <T> void onProvision(ProvisionInvocation<T> invocation)
   ProvisionInvocation<T> {
     Key<T> getKey()
     T provision();
   }
 }

The idea is similar to TypeListeners, except with less overheard & it can apply 
to _all_ bindings that require provisioning, not just injectable ones (which 
excluded Provider bindings).  It also lets you match based on Key rather than 
TypeLiteral.

ProvisionListener acts similar to a MethodInterceptor, except the user is 
unable to change any of the arguments or return value.  If the user "forgets" 
to call provision(), it is done automatically.  Exceptions handling is a little 
complicated, but it basically follows a rule of:
  * If an exception is thrown while performing the provision, the listener will see it as ProvisionException during the provision() call.  Regardless of what the user does to the exception (including if they supress it, manipulate it, or throw another exception type afterwards), Guice will rethrow the original exception.
  * If a listener throws an exception, Guice will rethrow that exception within a ProvisionException.

Original comment by sberlin on 8 May 2011 at 8:00

Attachments:

GoogleCodeExporter commented 9 years ago
Tried out the patch locally and it looks good wrt. the new functionality, 
exactly what we need

Original comment by mccu...@gmail.com on 10 May 2011 at 3:05

GoogleCodeExporter commented 9 years ago
implemented in r1551.  please review, try it out, & open new issues for 
problems!

Original comment by sberlin on 5 Jun 2011 at 6:33

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
SCM has been changed to git, making the old r1551 link in comment #18 404. The 
URL to this change is now 
http://code.google.com/p/google-guice/source/detail?r=132a5db7c643b8f367eb5f0902
4cf13ea37c9831 !

This feature finally turns Guice from a statically wired injection system into 
a firebreathing dynamical beast! Love it so much!!!!

Original comment by rektide on 18 Mar 2013 at 3:54