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
