Repository navigation
All enhanced classes should implement a marker interface #187
Description
From max.ross on March 18, 2008 00:19:58
All enhanced classes should implement a marker interface so that client
code has a reliable way to determine if an object is an instance of a
Guice-enhanced class. Ideally the interface(s) would be configurable by
the client, but if Guice just has its own interface that its proxies always
implement that would be cool too.
Original issue: http://code.google.com/p/google-guice/issues/detail?id=187
Activity
gissuebot commentedon Jul 7, 2014
From max.ross on March 18, 2008 10:14:02
Sorry, this should have been submitted as an enhancement. I don't see a way to
switch the issue type.
gissuebot commentedon Jul 7, 2014
From limpbizkit on May 14, 2008 08:23:44
My only anxiety about this is it adds another interface to our API. That interface doesn't do anything and it
encourages users to use instanceof.
As a hack workaround, I believe you can differentiate between enhanced and standard classes by calling:
boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");
Anybody else have an opinion on this?
Labels: -Type-Defect Type-Enhancement
gissuebot commentedon Jul 7, 2014
From limpbizkit on May 14, 2008 09:26:17
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-Low
gissuebot commentedon Jul 7, 2014
From max.ross on May 14, 2008 09:45:45
Your suggestions is exactly what I'm doing, but it's relying on an internal
implementation detail which you're obviously free to change at any time.
My mistake for trying to dictate the solution rather than just explaining the problem
I need solved.
One use case is when you have a Map keyed by Class. Maybe you're mapping the Class
to a processor that knows how to do something with instances of that Class:
Processor getProcessor(Foo foo) {
return processorsByClass.get(foo.getClass());
}
If you're using Guice and a module is setting up interceptors on instances of Foo and
this method receives a Foo that was created by Guice, the processor lookup will fail.
I'd be happy with any mechanism that allows me to reliably determine if I'm dealing
with a dynamically created Guice subclass. So, an interface works, but if marker
interfaces bother you (and it sounds like they do) then a helper method
(isGuiceEnhanced()) would be just as useful.
Thanks,
Max
gissuebot commentedon Jul 7, 2014
From dhanji on January 30, 2009 21:48:06
This kind of requirement is quite common in classpath scanning code (though I think, not the greatest idea in
the world =). One solution would be to do a super-crawl until you detect a class that's recognized, then cache
the proxy class as a transparent pointer so the next time it's a constant lookup.
gissuebot commentedon Jul 7, 2014
From rcouto on January 31, 2009 04:46:40
Are these objects instances of classes you control (meaning, are they instantiated by
Guice)? If so, maybe you could create an interface of your own with a method that
would return the correct TypeLiteral of each object. The technique that Jesse Wilson
posted on his blog may just do the trick: http://publicobject.com/2008/11/guice-punches-erasure-in-face.html
gissuebot commentedon Jul 7, 2014
From cgruber@google.com on July 16, 2012 11:05:08
Marking acknowledged pending prioritization.
Status: Acknowledged
Labels: Component-Core
gissuebot commentedon Jul 7, 2014
From bruno.medeiros@visagio.com on November 22, 2012 05:03:16
I also miss this feature a lot, and I don't see any problem in inserting a new interface. I'm using Guice now to replace a library internally developed and we have such a mark interface, called EnhancedClass. We do the following:
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(baseClass);
enhancer.setInterfaces(new Class[]{EnhancedClass.class});
> That interface doesn't do anything and it encourages users to use instanceof.
I don't see any reason to avoid the instanceof operator, could you explain more on this?
gissuebot commentedon Jul 7, 2014
From bruno.medeiros@visagio.com on November 22, 2012 07:24:53
One more comment, the workaround should be
boolean isEnhanced = getClass().getName().contains("EnhancerByGuice")
instead of
boolean isEnhanced = getClass().getName().contains("EnhancedByGuice");
At least on Guice 3.0 it is.
gissuebot commentedon Jul 7, 2014
From cgruber@google.com on November 18, 2013 11:59:40
(No comment was entered for this change.)
Status: Accepted
Owner: cgruber@google.com
Labels: -Priority-Low Priority-High
gissuebot commentedon Jul 7, 2014
From cgruber@google.com on November 18, 2013 12:00:54
(No comment was entered for this change.)
Labels: Milestone-Release4.0
tavianator commentedon Jun 25, 2015
Any progress on this? I'm happy to send a PR but I'm not sure where to put the new API. I figure it should be something like
Guice.isAopProxy(), a laScopes.isCircularProxy().bcmedeiros commentedon Sep 18, 2015
I'd also like to see this fixed, my code is still as dirty as
getClass().getName().contains("EnhancerByGuice").Tavianator, I'd use
Guice.isEnhanced(Class<?> class).domhauton commentedon Sep 7, 2017
+1 on this issue. We are using:
to get real class names
Add a utility class for checking if Guice has enhanced a class (and r…
Add a utility class for checking if Guice has enhanced a class (and r…
Add a utility class for checking if Guice has enhanced a class (and r…
Add a utility class for checking if Guice has enhanced a class (and r…