here is an interesting info on why these public methods from non-public super classes are marked as bridged.
http://stackoverflow.com/questions/24106486/why-does-the-java-compiler-add-visibility-bridge-methods-for-public-methods-defi 2015-09-03 14:05 GMT+02:00 Aki Yoshida <[email protected]>: > I used "abstract" in my example, but this behavior/restriction is not > specific to abstract classes but also applies to non-abstract classes. > as long as the classes are not public, their methods are not > accessible over BP's injection mechanism. > > I don't know if this is a bug. When I saw the relevant code fragment > in ReflectionUtils.java, I assumed someone intentionally wanted this > behavior. > https://github.com/apache/aries/blob/trunk/blueprint/blueprint-core/src/main/java/org/apache/aries/blueprint/utils/ReflectionUtils.java#L190 > > Maybe Guillaume can comment on this. > > regards, aki > > 2015-09-03 12:38 GMT+02:00 Benson Margulies <[email protected]>: >> On Thu, Sep 3, 2015 at 2:02 AM, Aki Yoshida <[email protected]> wrote: >>> I am not sure if this is what is happening to your case. >>> But just in case to describe that there is some difference in >>> blueprint's injection in contrast to that of spring or how one >>> intuitively thinks. >>> >>> With blueprint, you can only access the setters from the public super >>> classes and not the setters from from the abstract super classes. >>> >>> So if you have >>> abstract class A { >>> public method setFoo(...) { >>> } >>> } >>> >>> public class B extends A { >>> public method setBar(...) { >>> } >>> } >>> >>> >>> with above, you can do in java >>> B b = new B(); >>> b.setBar(..); >>> b.setFoo(...): >>> >>> and you can also access the foo setter in spring, but not in blueprint. >>> >>> There is a method check in its reflection utility class >>> (ReflectionUtils) that rejects those with m.isBridge() == true. >> >> Yes, that's it! the base class is abstract! >> Is this a bug w/r/t the blueprint spec? If so I'll file a JIRA at Aries. >> >> >>> >>> regards, aki >>> >>> >>> 2015-09-03 2:12 GMT+02:00 Benson Margulies <[email protected]>: >>>> On Wed, Sep 2, 2015 at 6:06 PM, Guillaume Nodet <[email protected]> wrote: >>>>> What's the exception you end up with ? >>>>> I had a brief look at the blueprint code and that seems to be supported. >>>>> >>>> >>>> Error message: >>>> >>>> org.osgi.service.blueprint.container.ComponentDefinitionException: >>>> Unable to find property descriptor requestTracker on class >>>> com.basistech.ws.frontend.service.RaasRsCategorizationService >>>> >>>> And when I duplicated the setter into the derived class, it worked fine. >>>> >>>> >>>>> 2015-09-02 22:53 GMT+02:00 Benson Margulies <[email protected]>: >>>>> >>>>>> While setting up a raft of jax-rs service beans, I am getting an >>>>>> exception >>>>>> that seems to tell me that blueprint cannot use setter methods from base >>>>>> classes. Anyone here have experience one way or the other? >>>>>>
