On 12/27/2012 2:57 PM, Mark Struberg wrote:
FYI, that did work.
Or we just gonna fix this issue and ship owb-1.8 :)
That would be ideal :)
Can you please create a patch with a small test case and attach it to a JIRA,
please?
Just the Foo classes as the test case?
Thanks
Mike
txs and LieGrue,
strub
----- Original Message -----
From: Mike Olson <[email protected]>
To: [email protected]
Cc:
Sent: Thursday, December 27, 2012 10:55 PM
Subject: Re: OWB 1.7 ignores Alternative when using the provider interface
On 12/27/2012 2:43 PM, Mark Struberg wrote:
It does, but I can't use @Inject in this case. I cannot statically bind
to a single instance of Foo.
I suppose I could create a FooWrapper class.
class FooWrapper {
@Inject Foo foo;
}
Then in Main use:
@Inject
Provider<FooWrapper> fooWrapperProvider;
Mike
And simply @Inject doesn't work?
LieGrue,
strub
----- Original Message -----
From: Mike Olson <[email protected]>
To: [email protected]
Cc:
Sent: Thursday, December 27, 2012 9:56 PM
Subject: Re: OWB 1.7 ignores Alternative when using the provider
interface
On 12/27/2012 3:35 AM, Mark Struberg wrote:
Hi Mark,
Hi Mike!
Thanks for your great tests, always good to get such feedback!
I guess you get a Instance<Foo> as Provider, right?
Yes, that is what I am seeing.
In that case 5.2.1 defines that we need to take the Alternative
into
account and filter it away.
Any thoughts on a work around until this can be fixed? I need to use
the Provider interface to decouple my implementation. I have a Mock
version of "Foo" in my unit tests, qualified as an
Alternative (and
noted in the beans.xml file).
Thanks
Mike
LieGrue,
strub
----- Original Message -----
From: Mike Olson <[email protected]>
To: [email protected]
Cc:
Sent: Thursday, December 27, 2012 5:18 AM
Subject: OWN 1.7 ignores Alternative when using the provider
interface
Hello,
I have a very simple setup where I have classes Foo1 and
Foo2 that
implement
the Foo interface
public interface Foo {
}
@Default
public class Foo1 implements Foo {
}
@Alternative
public class Foo2 implements Foo {
}
Then a class that gets 2 Foos injected
public class Main {
@Inject
Foo fooA;
@Inject
Provider<Foo> fooB;
@PostConstruct
public void init() {
System.err.println("FooA:" + fooA);
System.err.println("FooB:" + fooB.get());
}
}
If my beans.xml file is empty, then I get 2 instances of Foo1
injected
into the
class, as expected.
However, if I add
<alternatives>
<class>Foo2</class>
</alternatives>
to my beans.xml, then I get an error when I run the
application.
"""
INFO: All injection points were validated successfully.
Dec 26, 2012 9:11:29 PM
org.apache.webbeans.lifecycle.AbstractLifeCycle
startApplication
INFO: OpenWebBeans Container has started, it took [359] ms.
FooA:Foo2@152c4d9
Dec 26, 2012 9:11:29 PM
org.apache.webbeans.component.AbstractInjectionTargetBean
postConstructDefault
SEVERE: An error occurred while executing [@PostConstruct.]
javax.enterprise.inject.AmbiguousResolutionException: There
is more
than one api
type with : Foo with qualifiers : Qualifiers:
[@javax.enterprise.inject.Default()]
found beans:
Foo1, Name:null, WebBeans Type:MANAGED, API
Types:[Foo,Foo1,java.lang.Object],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
Foo2, Name:null, WebBeans Type:MANAGED, API
Types:[Foo,java.lang.Object,Foo2],
Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
at
org.apache.webbeans.util.InjectionExceptionUtils.throwAmbiguousResolutionExceptionForBeans(InjectionExceptionUtils.java:121)
at
org.apache.webbeans.util.InjectionExceptionUtils.throwAmbiguousResolutionException(InjectionExceptionUtils.java:111)
at
org.apache.webbeans.container.ResolutionUtil.checkResolvedBeans(ResolutionUtil.java:80)
at
org.apache.webbeans.inject.instance.InstanceImpl.get(InstanceImpl.java:110)
at Main.init(Main.java:23)
"""
This exception happens when I call Provider.get(). I assumed
that the
Provider
interface would respect the Alternative Qualifiers, but that
does not
seem to be
the case.
Is this a bug in what I am doing, or a bug in OWB?
Thanks
Mike
-- Mike Olson
--
Mike Olson
--
Mike Olson
--
Mike Olson
