I can confirm that @Specializes on a class extending an abstract class lead to InconsistentSpecializationException. Extending concrete class cause no error. Funilly enough, extending concrete class annotated with @Typed(Object.class) cause the same exception.
Now, the question is - is this intended as per CDI spec or an OWB bug? Would be glad to get a professional opinion before posting jira tickets. Kind regards Reinis -----Ursprüngliche Nachricht----- Betreff: Re: [OWB] make @Specializes to work for me Von: "Reinis Vicups" <[email protected]> An: [email protected] Datum: 2013/05/22 15:29:58 Yes, sorry I somehow assumed that I have some obvious and trivial misconception ... Here's relevant stacktrace: ... INFO - Adding OpenWebBeansPlugin : [CdiPlugin] SEVERE - CDI Beans module deployment failed org.apache.webbeans.exception.WebBeansDeploymentException: org.apache.webbeans.exception.inject.InconsistentSpecializationException: WebBean component class : de.orbitx.specializes.ConcreteFooProducer is not enabled for specialized by the class de.orbitx.specializes.ConcreteFooProducer class at org.apache.webbeans.config.BeansDeployer.checkSpecializations(BeansDeployer.java:709) at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:188) at org.apache.openejb.cdi.OpenEJBLifecycle.startApplication(OpenEJBLifecycle.java:182) at org.apache.openejb.cdi.ThreadSingletonServiceImpl.initialize(ThreadSingletonServiceImpl.java:158) at org.apache.openejb.cdi.CdiBuilder.build(CdiBuilder.java:43) at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:798) at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:612) at org.apache.openejb.assembler.classic.Assembler.createApplication(Assembler.java:608) at org.apache.openejb.testing.ApplicationComposers.before(ApplicationComposers.java:580) at org.apache.openejb.testing.ApplicationComposers.evaluate(ApplicationComposers.java:664) at org.apache.openejb.junit.ApplicationComposer$DeployApplication.evaluate(ApplicationComposer.java:64) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) Caused by: org.apache.webbeans.exception.inject.InconsistentSpecializationException: WebBean component class : de.orbitx.infiniteloop.ConcreteFooProducer is not enabled for specialized by the class de.orbitx.infiniteloop.ConcreteFooProducer class at org.apache.webbeans.util.WebBeansUtil.configureSpecializations(WebBeansUtil.java:784) at org.apache.webbeans.util.WebBeansUtil.configureSpecializations(WebBeansUtil.java:643) at org.apache.webbeans.config.BeansDeployer.checkSpecializations(BeansDeployer.java:700) ... 31 more INFO - Undeploying app: D:\wrk\eclipse-workspace\specializes\FooTest Debugging shows that during WebBeansUtil#configureSpecializations() the check: EnterpriseBeanMarker.class.isInstance(candidate) // where candidate is ConcreteFooProducer wrapped in ManagedBean<T> returns false thus superBean remains null which leads to throwing InconsistentSpecializationException in else condition. The testcase I have ran with the foo bar example (as described bellow) thus it is actually as primitive as I describe it and there is no hidden stuff I might have omitted. Thank you guys for your help! reinis On 22.05.2013 13:39, John D. Ament wrote: > Perhaps if you shared the stacktrace it would be easier to decipher what's > going on. > > > On Wed, May 22, 2013 at 6:42 AM, <[email protected]> wrote: > >> Hi guys, >> >> excuse me for bumping my own message but two days later am still clueless. >> >> Could it possibly be that i may not @Specializes an abstract class? >> >> thx for your help! >> Reinis >> >> -----Ursprüngliche Nachricht----- >> Betreff: [OWB] make @Specializes to work for me >> Von: [email protected] >> An: [email protected] >> Datum: 2013/05/20 11:42:34 >> >> Hi guys, >> >> in my scenario I want to realize a "template method". For this I implement >> common abstract base class: >> >> public abstract AbstractFooProducer { >> >> protected void init() {} >> >> @Produces >> public Foo produceFoo() { >> init(); >> return foo; >> } >> >> and then one or more specific implementations: >> >> public class XmlFooProducer extends AbstractFooProducer { >> @Override >> protected void init() { >> // wicked xml initialization done here >> } >> } >> >> Now, this solution is causing me some headache to realize, here are number >> of wrong assumptions I made: >> >> - I assumed that, because AbstractFooProducer is abstract, OWB will >> activate XmlFooProducer as the only concrete implementation and will >> recognize @Produces method through the inheritance. No, does not happen! >> - Ok, next assumption is that if I decorate XmlFooProducer with >> @Specializes I will get the behavior described above. No and from this >> point on i always get this same exception from OWB: >> InconsistentSpecializationException(not sure if the name is correct since >> am writing this by heart but it is thrown by OWBBeanUtil during >> configureSpecializations()); >> - Next, I will add @Alternative on top of @Specializes and activate it to >> make it work (as described in oracle docs for CDI). Result - the said >> InconsistentSpecializationException; >> - Next, I will @Override the @Produces method from abstract class in the >> concrete implementation (i read some place that specializing class fully >> "replaces" specialized class and interpreted this so that i have to >> replicate then all relevant Cdi annotations). No, the same exception is >> thrown; >> >> At this point i am out of ideas and would appretiate a hint or two on how >> to make it work. >> >> br >> Reinis >> >> >> >> >> >>
