I was reading/testing the following tutorial about CDI: [link].
And I got an exception when I added a producer class to the code.
Basically, there's an interface with a default implementation:
public interface ATMTransport {
public void communicateWithBank(byte[] datapacket);
}
#Default
public class StandardAtmTransport implements ATMTransport {
public void communicateWithBank(byte[] datapacket) {
System.out.println("communicating with bank via Standard transport");
}
}
Next, there's another class which injects the ATMTransport interface:
#Named("atm")
public class AutomatedTellerMachineImpl implements AutomatedTellerMachine {
#Inject
private ATMTransport transport;
public void deposit(BigDecimal bd) {
transport.communicateWithBank(null);
}
}
Everything is OK so far. So in the section about 'producers', they show a new class:
public class TransportFactory {
#Produces ATMTransport createTransport() {
System.out.println("ATMTransport created with producer");
return new StandardAtmTransport();
}
}
Then, by adding the producer class I got this exception:
WELD-001409: Ambiguous dependencies for type ATMTransport with qualifiers #Default
at injection point [BackedAnnotatedField] #Inject private AutomatedTellerMachineImpl.transport at AutomatedTellerMachineImpl.transport(AutomatedTellerMachineImpl.java:0)
Possible dependencies:
- Managed Bean [class StandardAtmTransport] with qualifiers [#Default #Any],
- Producer Method [ATMTransport] with qualifiers [#Any #Default] declared as [[BackedAnnotatedMethod] #Produces TransportFactory.createTransport()]
I solved the problem by using qualifiers, but I really don't know why.
My question is, why does the producer class cause that exception? (They didn't mention anything about it on their tutorial).
I really need a little explanation.
Based on the code you supplied, you ended up creating a default implementation of ATMTransport that is a managed bean. The exception is caused by having both beans available with the same injection targets. #Default is the qualifier added to all CDI beans. Basically, there is no need for the producer method since the one provided by the class definition by itself is the same.
I guess the bigger question - what were you trying to do with the producer method?
Related
In a JSF project, we wrote our own PartialViewContext to listen to some events fired by pages beans:
#RequestScoped
public class OurPartialViewContext extends PartialViewContextWrapper
{
...
// called by cdi
#SuppressWarnings("unused")
private void listenForUpdate(#Observes OurRefreshEvent event)
{
...
And we wrote the matching factory, injecting it:
public class OurPartialViewContextFactory extends PartialViewContextFactory
{
#Inject
private OurPartialViewContext customPartialViewContext;
...
Problem is that in the newest versions of JSF, the empty constructor for PartialViewContextWrapper is deprecated, asking us to use another constructor with the wrapped object in parameter.
Currently, our PartialViewContext needs to be tied to the request scope, in order to be modified during the request by the observed events and to be used by a custom PartialResponseWriter we also wrote.
So our PartialViewContext currently both:
must have an empty constructor, as it is a #RequestScoped bean;
should not have an empty constructor, as it is deprecated for PartialViewContextWrapper which it inherits from.
How could we find a solution there?
We tried to remove it from the scope and build it in the Factory with a simple new OurPartialViewContext(), but then the #Observes methods are never called.
You are required to pass the wrapped instance into the constructor and to use getWrapped() over all place in delegate methods. Otherwise your application will most probably not work when you install other JSF libraries which also ship with their own PartialViewContext implementation such as OmniFaces and PrimeFaces. You would be effectively completely skipping the functionality of their PartialViewContext implementation. This mistake was previously observed in too many custom implementations of factory-provided classes. Hence the urge to mark the default constructor as #Deprecated so that the developers are forced to use the proper design pattern.
Your specific issue can be solved by simply refactoring the listenForUpdate() method into a fullworthy request scoped CDI bean, which you then inject in the factory who in turn ultimately passes it into the constructor of your PartialViewContext implementation.
Thus, so:
#RequestScoped
public class OurEventObserver {
public void listenForUpdate(#Observes OurRefreshEvent event) {
// ...
}
}
public class OurPartialViewContextFactory extends PartialViewContextFactory {
#Inject
private OurEventObserver observer;
public OurPartialViewContextFactory(PartialViewContextFactory wrapped) {
super(wrapped);
}
#Override
public PartialViewContext getPartialViewContext(FacesContext context) {
PartialViewContext wrapped = getWrapped().getPartialViewContext(context);
return new OurPartialViewContext(wrapped, observer);
}
}
public class OurPartialViewContext extends PartialViewContextWrapper {
private OurEventObserver observer;
public OurPartialViewContext(PartialViewContext wrapped, OurEventObserver observer) {
super(wrapped);
this.observer = observer;
}
// ...
}
Inside any of the overridden methods of OurPartialViewContext you can simply access the state of the observer, provided that the listenForUpdate() modifies some instance variables representing the state.
Given
public class BeanContainer {
#Produces
Bean bean = new Bean();
}
and its alternative:
#Alternative
public class BeanContainerAlt extends BeanContainer {
#Produces
int producerInt = 10;
}
where Bean is
public class Bean {
boolean didPostConstruct = false;
#PostConstruct
public void postConstruct() {
didPostConstruct = true;
}
}
injected into MainClass:
public class MainClass {
#Inject
Bean bean;
#Inject
Integer producedInt;
}
Then:
Weld weld = new Weld()
.disableDiscovery()
.addBeanClass(MainClass.class)
.addBeanClass(BeanContainer.class)
.addBeanClass(BeanContainerAlt.class)
.alternatives(BeanContainerAlt.class);
WeldContainer container = weld.initialize();
final MainClass mainClass = container.select(MainClass.class).get();
assertFalse(mainClass.bean.didPostConstruct);
assertEquals(10, (long)mainClass.producedInt);
BeanContainer containerObject = container.select(BeanContainer.class).get();
assertEquals(BeanContainerAlt.class, containerObject.getClass());
gives no error. I would have expected that Bean.class would have to be added using addBeanClass to be able to satisfy the inject in MainClass. The explanation is that the Superclass of BeanContainerAlt whose Producers should imO not be effective, produces the Bean-Object.
Is that behavior intended or even according to the spec (I did not find it), is it probably defined in the weld-documentation?
The sourcecode can be found in
examplesrc
mvn clean install -Dtest=ReproProducersInSuperclasses
in that project should make it run
Indeed, the fields and methods annotated with #Producer are not inherited - as discussed in the accepted answer to Why are Producers not inherited in CDI
However, according to the CDI specification:
5.1.2. Enabled and disabled beans
A bean is said to be enabled if:
(E1) it is deployed in a bean archive, and
(E2) it is not a producer method or field of a disabled bean, and
(E3) it is not specialized by any other enabled bean, as defined in Specialization, and either
(E4) it is not an alternative, or it is a selected alternative of at least one bean archive or the application.
Otherwise, the bean is said to be disabled.
According to these definitions and code above:
BeanContainer is not an alternative (E4) and therefore is enabled managed bean
BeanContainerAlt is a selected alternative (E4) and therefore is enabled managed bean
Bean and int are enabled because they are not a producer method or field of a disabled bean (E2), as BeanContainer and BeanContainerAlt are both enabled (E4)
Therefore producer fields in both BeanContainer and BeanContainerAlt are used to resolve dependencies.
The test fails as shown below when BeanContainer is not deployed (E1):
WELD-001408: Unsatisfied dependencies for type Bean with qualifiers #Default
at injection point [BackedAnnotatedField] #Inject
net.oneandone.iocunit.testalt.MainClass.bean
The test fails as shown below when BeanContainerAlt is not selected (E4):
WELD-001408: Unsatisfied dependencies for type Integer with qualifiers #Default
at injection point [BackedAnnotatedField] #Inject
net.oneandone.iocunit.testalt.MainClass.producedInt
I tried to implement solution from another SO question:
https://stackoverflow.com/a/10059245/1943765 but it is not working in all cases.
When I put this code in CDI bean (bean code is shown on bottom):
#Inject #HttpParam
private String code;
everything works fine. But when I try to define value for #HttpParam annotation (so, not default one) Weld is unable to start:
#Inject #HttpParam(value="code")
private String token;
I get this exception:
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type String with qualifiers #HttpParam
at injection point [BackedAnnotatedField] #Inject #HttpParam private org.test.site.jsf.beans.request.ActivationBean.token
at org.test.site.jsf.beans.request.ActivationBean.token(ActivationBean.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
- Producer Method [String] with qualifiers [#HttpParam #Any] declared as [[BackedAnnotatedMethod] #Produces #HttpParam public org.test.site.cdi.producer.HttpParamProducer.getHttpParameter(InjectionPoint)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
... 4 more
The code I used is similar to linked SO question.
The custom #HttpParam annotation:
#Qualifier
#Retention(RUNTIME)
#Target({METHOD, FIELD, PARAMETER})
public #interface HttpParam {
public String value() default "";
}
The annotation value producer:
public class HttpParamProducer {
#Inject
FacesContext facesContext;
#Produces
#HttpParam
String getHttpParameter(InjectionPoint ip) {
String name = ip.getAnnotated().getAnnotation(HttpParam.class).value();
if ("".equals(name)) name = ip.getMember().getName();
return facesContext.getExternalContext()
.getRequestParameterMap()
.get(name);
}
}
And CDI bean using it is something like:
#Named("activation")
#RequestScoped
public class ActivationBean implements Serializable{
#Inject
#HttpParam(value="code")
private String token;
// rest of valid class code
}
Also I am using Tomcat 8 server with Weld Servlet 2.3.1.Final.
So.. what am I doing wrong? :-/
You need to add #Nonbinding to your value attribute so that its value does not necessarily select which producer method to invoke, but allows for a single factory style producer inspecting your injection point.
You may also want to review what is the purpose of #Nonbinding annotation in a Qualifier supposed to be in Java EE7?
By default , attributes in CDI Qualifier also are used to determine which bean to be injected.
Since you inject #HttpParam(value="code") , but your producer just produces #HttpParam(value=""). They are not matched and CDI don't know what to inject.
To make CDI ignore attributes in CDI Qualifier when determining which bean to be injected, you can mark #Nonbinding on these attributes
#Qualifier
#Retention(RUNTIME)
#Target({METHOD, FIELD, PARAMETER})
public #interface HttpParam {
#Nonbinding
public String value() default "";
}
I am late to add this, but for the sake of others who may be using this question to write similar parameter based injections, let me add this.
Adding a specific which I did not find above. I faced the same situation, but with a twist in the flavor.My Qualifier and the Producer method were in a module (say injector-module) different from the one in which I was doing the injection (say injected-module). All NonBinding annotations were given.
However, I had the beans.xml only in the injected-module.
The injection failed.
Adding the beans.xml in the META-INF of the injector-module did the trick.
I have the following classes:
#Named
#ViewScoped
public class BaseClass {
private SomeDependency dep;
public BaseClass(){}
#Inject
public BaseClass(SomeDependency dep) {
this.dep = dep;
}
#PostConstruct
private void initialize() {
dep.doSomething(); // Point "A"
}
public String getProperty() {
return "BaseClass-Property";
}
#Specializes
public class SpecialClass extends BaseClass() {
#Override
public String getProperty() {
return "SpecialClass-Property";
}
}
Now in some .xhtml I have something like
<h:outputText value="#{baseClass.property}" />
This works fine without the SpecialClass. It breaks with a NullPointerException at Point "A" if I include the SpecialClass in the project.
Well, according to the Weld specification, this is more or less intended behavior:
When an enabled bean specializes another bean, the other bean is never
instantiated or called by the container.
Nevertheless, now I have to make sure that every #Specializes bean implements the complete constructor like
public SpecialClass() {}
#Inject
public SpecialClass(SomeDependency dep) { super(dep); }
which IMHO is kind of counter-intuitive and produces a lot of duplicated, boilerplate code, especially with something like 5-6 arguments for every constructor. Also, this is never caught when creating a new specialized bean since the project is always still compile clean.
Am I doing something wrong or is there no alternative to implementing the constructors over and over again?
BTW, I do use Constructor Injection to create easily testable classes where I can just use the constructor to "Inject" dummy implementations of the dependencies.
CDI 1.1 spec at section 4.3 says:
"The only way one bean can completely override a second bean at all
injection points is if it implements all the bean types and declares
all the qualifiers of the second bean."
Your base class is annotated with the Named qualifier and the specializing class is not. You should also mark it with Alternative and enable it in beans.xml. There's also the ViewScoped annotation. Unless it's the Omnifaces' ViewScoped, it looks like you're mixing up JSF managed beans with CDI beans.
I'm new in Java EE/JSF and now read about CDI qualifiers - the possibility to change class implementation. This is great but I have got one question. As far as I understand I can change class implementation using qualifier but I need to change it everywhere I use this implementation. What is the best solution to do it in one place? With my small knowledge about Java EE I figured out this one.
Lets imagine that we are creating simple Calculator application. We need to create few classes:
Calculator (basic implementation of calculator)
ScientificCalculator (scientific implementation of calculator)
MiniCalculator (with minimum potentiality)
MockCalculator (for unit tests)
Qualifier #Calculator (will indicate to the actual implementation of calculator; should I create qualifier for each implementation?)
Here is the question. I've got four implementations of calculator and I want to use one of them in few places but only one at time (in the initial project phase I will use MiniCalculator, then Calculator and so on). How can I change implementation without change code in every place where object is injected? Should I create factory which will be responsible for injecting and will work as method injector? Is my solution correct and meaningful?
Factory
#ApplicationScoped
public class CalculatorFctory implements Serializable {
private Calculator calc;
#Produces #Calculator Calculator getCalculator() {
return new Calculator();
}
}
Class which uses Calculator
public class CalculateUserAge {
#Calculator
#Inject
private Calculator calc;
}
Is this the correct solution? Please correct me if I'm wrong or if there is a better solution. Thanks!.
There are several issues here.
What is the best way to change the desired implementation in the entire application? Look into #Alternatives.
Do I need a qualifier for each implementation? No, see this answer for a lengthy and detailed explanation.
Should I use a producer to decide which implementation is injected? Could be the solution you want, but I doubt it. Producers are generally used to perform some sort of initialization that can't be done in the constructor / #PostConstruct. You could also use it to inspect the injection point and make runtime decisions about what to inject. See the link 2. for some clues.
Is this solution correct? This will work, but you'll still have to mess with the code to change the implementation, so consider 1. first. Also #Calculator Calculator seems highly redundant. Again, see the link at 2.
#ApplicationScoped
public class CalculatorFctory implements Serializable {
private Calculator calc;
#Produces #Calculator Calculator getCalculator() {
return new Calculator();
}
}
Update:
CDI uses qualifiers in addition to types for dependency resolution. In other words, as long as there is only one type that matches the type of the injection point, types alone are enough and qualifiers are not needed. Qualifiers are there for disambiguation when types alone are not enough.
For example:
public class ImplOne implements MyInterface {
...
}
public class ImplTwo implements MyInterface {
...
}
To be able to inject either implementation, you don't need any qualifiers:
#Inject ImplOne bean;
or
#Inject ImplTwo bean;
That's why I say #Calculator Calculator is redundant. If you define a qualifier for each implementation, you're not gaining much, might as well just use the type. Say, two qualifiers #QualOne and #QualTwo:
#Inject #QualOne ImplOne bean;
and
#Inject #QualTwo ImplTwo bean;
The example directly above does not gain anything since in the previous example no dis-ambiguity existed already.
Sure, you can do this for cases where you don't have access to particular implementation types:
#Inject #QualOne MyInterface bean; // to inject TypeOne
and
#Inject #QualTwo MyInterface bean; // to inject TypeTwo
However OP shouldn't be using #Produces when he wants Calculator implementations to be CDI managed.
#Avinash Singh - CDI manages #Produces as well as anything they return, as long as it is CDI that calls the method. See this section of the spec if you please. This includes returning `#...Scoped beans which will support dependency injection, life-cycle callbacks, etc.
I overlooked some details here, so consider the following two:
public class SomeProducer {
#Inject ImplOne implOne;
#Inject ImplTwo implTwo;
#Inject ImplThree implThree;
#Produces
public MyInterface get() {
if (conditionOne()) {
return implOne;
} else if (conditionTwo()) {
return implTwo;
} else {
return implThree;
}
}
}
and
public class SomeProducer {
#Produces
public MyInterface get() {
if (conditionOne()) {
return new ImplOne();
} else if (conditionTwo()) {
return new ImplTwo();
} else {
return new ImplThree;
}
}
}
Then, in the first example, CDI will manage the life cycle (i.e. #PostConstruct and #Inject support) of what's returned from the producer, but in the second one it will not.
Back to the original question - what's the best way to switch between implementations without having to modify the source? The assumption is that you want the change to be application wide.
#Default
public class ImplOne implements MyInterface {
...
}
#Alternative
public class ImplTwo implements MyInterface {
...
}
#Alternative
public class ImplThree implements MyInterface {
...
}
Then, any for any #Inject MyInterface instance, ImplOne will be injected, unless
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<alternatives>
<class>ImplTwo</class>
</alternatives>
</beans>
is specified, in which case ImplTwo will be injected everywhere.
Further Update
There are indeed things in the Java EE environment that are not managed by CDI, such as EJBs and web services.
How would you inject a web service into a CDI managed bean? It's simple really:
#WebServiceRef(lookup="java:app/service/PaymentService")
PaymentService paymentService;
That's it, there you'll have a valid reference to the payment service which is managed outside CDI.
But, what if you didn't want to use the full #WebServiceRef(lookup="java:app/service/PaymentService") everywhere you need it? What if you only want to inject it by type? Then you do this somewhere:
#Produces #WebServiceRef(lookup="java:app/service/PaymentService")
PaymentService paymentService;
and in any CDI bean that needs a reference to that payment service you can simply #Inject it using CDI like this:
#Inject PaymentService paymentService;
Note that before defining the producer field, PaymentService wouldn't be available for injection the CDI way. But it is always available the old way. Also, in either case the web service is not managed by CDI but defining the producer field simply makes that web service reference available for injection the CDI way.
If you want to swap the implementation in your code using a factory method then your factory method is managing the beans and not CDI and so there is really no need for #Calculator.
#ApplicationScoped
public class CalculatorFactory implements Serializable {
enum CalculatorType{MiniCaculator,ScientificCaculator,MockCalculator};
Calculator getCalculator(CalculatorType calctype) {
switch(calctype)
case MiniCaculator : return new MiniCalculator();
case ScientificCalculator : new ScientificCalculator();
case MockCalculator : new MockCalculator();
default:return null;
}
}
public class CalculatorScientificImpl {
private Calculator calc =
CalculatorFactory.getCaclulator(CaclutorType.ScientificCalculator);
doStuff(){}
}
public class CalculatorTest {
private Calculator calc =
CalculatorFactory.getCaclulator(CaclutorType.MockCalculator);
doStuff(){}
}
However if you want your Caclulator beans to be CDI managed for injections and life cycle management using #PostConstruct etc then you can use one of the below approaches.
Approach 1 :
Advantage :You can avoid creating annotation using #Named("miniCalculator")
Disadvantage : compiler will not give an error with this approach if there is a name change from say miniCalculator to xyzCalculator.
#Named("miniCalculator")
class MiniCalculator implements Calculator{ ... }
#ApplicationScoped
public class CalculatorFactory implements Serializable {
private calc;
#Inject
void setCalculator(#Named("miniCalculator") Caclulator calc) {
this.calc = calc;
}
}
Approach 2 : Recommended (Compiler keeps track of injection if any injection fails)
#Qualifier
#Retention(RUNTIME)
#Target({FIELD, TYPE, METHOD})
public #interface MiniCalculator{
}
#ApplicationScoped
public class CalculatorFactory implements Serializable {
private calc;
#Inject
void setCalculator(#MiniCalculator calc) {
this.calc = calc;
}
}
Approach 3: If you are using a factory method to generate your object.Its lifecycle wont be managed be CDI but the Injection will work fine using #Inject .
#ApplicationScoped
public class CalculatorFactory implements Serializable {
private Calculator calc;
#Produces Calculator getCalculator() {
return new Calculator();
}
}
public class CalculateUserAge {
#Inject
private Calculator calc;
}
All three approaches will work for testing , say you have a class named CaculatorTest,
class ScientificCalculatorTest{
Caclulator scientificCalculator;
#Inject
private void setScientificCalculator(#ScientificCalculator calc) {
this.scientificCalculator = calc;
}
#Test
public void testScientificAddition(int a,int b){
scientificCalculator.add(a,b);
....
}
}
if you want to use a mock implementation in your test then do something like this,
class CalculatorTest{
Caclulator calc;
#PostConstruct
init() {
this.calc = createMockCaclulator();
}
#Test
public void testAddition(int a,int b){
calc.add(a,b);
.....
}
}