Groovy-based Spring Boot DI by example - groovy

In a traditional Spring DI-based application, you define an application.xml file and wire your beans as needed. Then in your main class you can just grab the ApplicationContext (that is configured with those wirings) or you can even make a class ApplicationContextAware.
But it seems everything has changed with Spring Boot. With Boot, it seems as though you annotate classes with #Component, however I have been unable to find any really good concrete examples of its use. Furthermore, I don't see solutions to scenarios where there are different instances of the same class/component that you want to wire into dependent beans differently, or how #Component-based injections work with Groovyisms like #Canonical. So I figured I would start with a concrete example and see if anyone could point me in the right direction:
// Groovy pseudo-code
#Canonical
class Fizz {
boolean checked
String umberGUID
}
#Canonical
class Buzz {
Fizz fizz // # always use Fizz instance #1 for all Buzz instances
int value
}
#Canonical
class Widget {
Fizz fizz // always use Fizz instance #2 for all Widget instances
String magicNumber // we need to define and wire a different magic number into each Widget instance
}
===
The example below is how I would accomplish dependency injection in Guice
using the classes and constraints above:
===
#Canonical
class Fizz {
#Inject #Named('checked')
boolean checked
#Inject #Named('umberGUID')
String umberGUID
}
#Canonical
class Buzz {
#Inject #Named('buzz_fizz')
Fizz fizz
#Inject #Named('buzz_value')
int value
}
#Canonical
class Widget {
#Inject #Named('widget_fizz')
Fizz fizz
#Inject #Named('magic_number')
String magicNumber
}
class MyGuiceModule extends AbstractModule {
#Override
void configure() {
}
// I wont write Provider methods for everything above, just showing
// 2 here as as an example.
#Provides #Named('buzz_fizz')
Fizz provideBuzzFizz() {
new Fizz(true, 'A', null)
}
#Provides #Named('widget_fizz')
Fizz provideWidgetFizz() {
new Fizz(false, 'D', 'blue')
}
}
How would I wire these beans up with each other in Spring Boot? The end result should be my ability to access, say, a Widget instance inside some fourth class, say, "HerpDerp", and have the Widget instance have properly-injected fizz/magicNumber fields on it. If that answer requires more info, I'm happy to whip something up, just ask!

From the description of your problem, This is really not a question dependent on features of SpringBoot, or Groovy, but is more of a question about Spring and how the configuration is different between the XML based configuration: application.xml, vs. a Java based configuration and/or with the use of annotations like #Component.
I bring this up, because if you are looking for documentation, then you would really want to refer directly to the Spring documentation on the Java based configuration to get the most information. A good start would be 5.12.1 Basic concepts: #Bean and #Configuration.
As I mentioned in the comments to your question, I don't think the #Canonical annotation affects this at all. #Canonical is simply a composite annotation, used to auto-generate commonly used methods to your Groovy classes. Specifically, as stated directly in the #Canonical GroovyDoc :
The #Canonical meta-annotation combines the #EqualsAndHashCode, #ToString and #TupleConstructor annotations. It is used to assist in the creation of mutable classes. It instructs the compiler to execute AST transformations which add positional constructors, equals, hashCode and a pretty print toString to your class.
None of which affects how beans are 'wired' up in your application, regardless of whether you are using Java, Spring, Groovy, or Spring Boot.
With all of that said, how would you accomplish your requirements using Spring Boot and Groovy?
I think the best way to demonstrate would be with a concrete example.
To provide a good example, I have created a Test SpringBoot project, with Gradle as the build tool and Groovy as the language of choice. For this example, I have place the Groovy classes in the com.app.bootinjection package. Here is a screenshot showing the folder and package structure:
To build the application, I have created the build.gradle file, seen in the image, with the following contents:
buildscript {
ext {
springBootVersion = '1.3.1.RELEASE'
}
repositories {
jcenter()
mavenCentral()
}
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
}
}
apply plugin: 'groovy'
apply plugin: 'idea'
apply plugin: 'spring-boot'
repositories {
jcenter()
mavenCentral()
}
dependencies {
compile('org.codehaus.groovy:groovy-all:2.4.5')
compile('org.springframework.boot:spring-boot-starter-web')
compile('org.apache.tomcat.embed:tomcat-embed-jasper:8.0.30')
compile('com.fasterxml.jackson.core:jackson-core:2.7.1')
compile('com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.7.1')
}
springBoot{
mainClass = 'com.app.Application'
}
task wrapper(type: Wrapper) {
gradleVersion = '2.9'
}
Note in the build.gradle file, I have added 2 compile time dependencies on Jackson libraries. The 'core' library to support JSON output, and the 'dataformat' library to make the JSON output formatted nicely when viewing in a client like the browser.
Because this is to be a SpringBoot application, I have created a simple Application class annotated with the #SpringBootApplication annotation, which contains the main method and starts up our application:
Application.groovy:
package com.app
import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.context.ApplicationContext
#SpringBootApplication
public class Application {
public static void main(String[] args) {
ApplicationContext ctx = SpringApplication.run(Application.class, args)
}
}
I also created a Groovy class representative of each class mentioned in your question: Fizz, Buzz, Widget and HerpDerp. Each is annotated with both the #Canonical annotation and the #Component annotation. When component scanning is done, Spring will see the #Component annotation and as a default will construct a single (singleton like) instance of that class and register it as a bean. By default, the bean name will be the same name of the class, with the first letter in the class name lower cased. So, the Fizz class will be instantiated as a bean and registered under the bean name 'fizz'. For more information, see the Spring docs in Section 5.10.1 #Component. By the way, you could change the 'scope' of the bean to have a new one created every time it is injected, using the #Scope(value = "prototype"). But, I would recommend only doing that if absolutely required.
Fizz.groovy:
package com.app.bootinjection
import groovy.transform.Canonical
import org.springframework.stereotype.Component
#Canonical
#Component
class Fizz {
boolean checked
String umberGUID = 0
}
Note: I have defaulted umberGUID to a value of 0 for demonstration/output purposes only.
Buzz.groovy:
package com.app.bootinjection
import groovy.transform.Canonical
import org.springframework.stereotype.Component
import javax.annotation.Resource
#Canonical
#Component
class Buzz {
#Resource
Fizz fizz1
int value
}
Widget.groovy:
package com.app.bootinjection
import groovy.transform.Canonical
import org.springframework.stereotype.Component
import javax.annotation.Resource
#Component
#Canonical
class Widget {
#Resource
Fizz fizz2
#Resource
Buzz buzz
#Resource
String magicalNumber
}
HerpDerp.groovy:
package com.app.bootinjection
import groovy.transform.Canonical
import org.springframework.stereotype.Component
import javax.annotation.Resource
#Component
#Canonical
class HerpDerp {
#Resource
Widget widget
#Resource
Fizz fizz
}
Note the usage of #Resource to inject beans into our objects. On our projects, we switched from #Autowired initially to #Inject and now to the #Resource annotation. In most cases, we have found the #Resource to be more appropriate and work more often within our projects. For example, notice the declaration of Fizz fizz1 in the class Buzz. Using the #Resource, it will inject the proper instance of Fizz where the bean name matches fizz1. For more clarification on when/why to use either, refer to Section 5.9.3 of the Spring docs, which states:
Tip
If you intend to express annotation-driven injection by name, do not primarily use #Autowired, even if is technically capable of referring to a bean name through #Qualifier values. Instead, use the JSR-250 #Resource annotation, which is semantically defined to identify a specific target component by its unique name, with the declared type being irrelevant for the matching process.
As a specific consequence of this semantic difference, beans that are themselves defined as a collection or map type cannot be injected through #Autowired, because type matching is not properly applicable to them. Use #Resource for such beans, referring to the specific collection or map bean by unique name.
#Autowired applies to fields, constructors, and multi-argument methods, allowing for narrowing through qualifier annotations at the parameter level. By contrast, #Resource is supported only for fields and bean property setter methods with a single argument. As a consequence, stick with qualifiers if your injection target is a constructor or a multi-argument method.
Sow how do we declare multiple beans of the same instance with different names? Remember you can use the #Component annotation alone to have Spring create a single instance of the class, defaulting the bean name to the class name (first character lower cased). You can also specify the name to override the default when using the #Component. For example: #Component("myBean"). Still, a single instance will be created. You can also specify the 'scope' as mentioned before using the #Scope("prototype") annotation. Now, each time the bean is injected, a new instance is created and injected.
If you want to control the number of beans created, specify unique names, and inject with the unique names, you need a more configurable solution. The preferred solution compared to the XML configuration is a Java based solution. You can create any class and configure it with the #Configuration annotation to indicate to Spring this class is intended to provide configuration information. For this example, I have created the ApplicationConfiguration class:
ApplicationConfiguration.groovy:
package com.app
import com.app.bootinjection.Fizz
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
#Configuration
class ApplicationConfiguration {
#Bean
Fizz fizz1(){
new Fizz(checked: true, umberGUID: 1)
}
#Bean
Fizz fizz2(){
new Fizz(checked: false, umberGUID: 2)
}
#Bean
#Scope("prototype")
String magicNumber(){
System.currentTimeMillis()
}
}
In the configuration, we create 2 methods for the Fizz class to create 2 unique fizz instances: fizz1 and fizz2. The name of the method will become the bean name, hence the method fizz1() and fizz2). Also note that only one instance of each is created. Spring takes care of instantiating the beans and only creating a single instance of each.
Now if you look back at the Buzz class, you will see that we use the #Resource annotation to inject the instance of the Fizz class that matches the bean name fizz1, which matches the bean name declared in the configuration class. The same is true for fizz2 in Widget. Also for demonstration purposes, notice that we also inject a Fizz instance in the HerpDerp class, called simply fizz. Since we annotated the Fizz class with #Component, when Spring performs the component scan, it will see the annotated class and by default create a separate instance with the default name of fizz.
In the configuration class, we have another bean method, annotated with #Bean called magicNumber(). Because we want the magic number injected to be unique every time, I have annotated that bean with a scope of prototype: Scope("prototype"). The bean, of type String, is then injected in the Widget class as required.
Finally, to put it all together, I have created a REST web service controller that simply injects the HerpDerp bean instance and returns it, which is then serialized to JSON to demonstrate the output we expect. The results are seen by accessing http://localhost:8080 :
TestController.groovy:
package com.app.bootinjection
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController
import javax.annotation.Resource
#RestController
class TestController {
#Resource
HerpDerp herpDerp
#RequestMapping("/")
def index(){
[herpDerp]
}
}
With a resulting output of:
<HerpDerp xmlns="">
<widget>
<fizz2>
<checked>false</checked>
<umberGUID>2</umberGUID>
</fizz2>
<buzz>
<fizz1>
<checked>true</checked>
<umberGUID>1</umberGUID>
</fizz1>
<value>0</value>
</buzz>
<magicalNumber>1464240486303</magicalNumber>
</widget>
<fizz>
<checked>false</checked>
<umberGUID>0</umberGUID>
</fizz>
</HerpDerp>
I hope this proves to be a comprehensive demonstration that covers the topics you are trying to accomplish. I think you will see that Spring/SpringBoot make it very easy to produce the results you are looking for. Good luck!

Related

CDI injection of subclasses of session scoped beans as a managed property

I am using JSF 2.3 and I want to inject different sublaccess of a session scoped bean as a managed property using CDI.
From the link below
How to inject different subclasses as ManagedProperty JSF 2?
I understood that this was not possible for RequestScoped beans using the "old" JSF and JEE-annotations, but my beans have session scope and I am using CDI injection, and therefore different annotations than the ones used in the above link.
In particular I do have:
public abstract class BaseContainer {
String prop1;
}
#Named
#SessionScoped
public class MaklerContainer extends BaseContainer {
String prop 2;
}
#Named
#SessionScoped
public class AppManagerContainer extends MaklerContainer {
String prop 3;
}
public abstract class BaseBean {
#Inject
#javax.faces.annotation.ManagedProperty(value = "#{maklerSessionContainer}")
private MaklerSessionContainer maklerSessionContainer;
}
Is it possible to inject interchangeably instances of both MaklerContainer and AppManagerContainer as a managed property maklerSessionContainer of the class BaseBean above?
Let me describe one option, there may be others.
First of all, if you want to inject different sublaccess, you have to find a way to disambiguate them for CDI, or it will complain about "Ambiguous dependencies". E.g. given the class hierarchy of the question, the line below results in ambiguous dependency exception, because CDI cannot decide whether to inject the MaklerContainer or the AppManagerContainer that extends it:
#Inject MaklerContainer maklerContainer; // ambiguous!
You can use qualifiers, named beans, or #Typed (perhaps there are even more ways).
Let's use #Named, since it is already present.
The idea is to create a producer that introduces a third bean of type MaklerContainer, with a different name, to the appropriate scope. The producer code will decide which of the 2 implementations to choose at runtime. Something like this:
#ApplicationScoped
public class TheProducer {
#Inject #Named("maklerContainer")
private MaklerContainer maklerContainer;
#Inject #Named("appManagerContainer")
private AppManagerContainer appManagerContainer;
#Inject
private User currentUser;
#Produces
#SessionScoped
#Named("theOne") // choose appropriate name of course
public MaklerContainer makeMaklerContainer() {
if (currentUser.hasRole("Role1")) {
return appManagerContainer;
} else {
return maklerContainer;
}
}
}
Now all you have to do is inject the appropriate named MaklerContainer, like:
#Inject #Named("theOne") MaklerContainer maklerContainer;

How to annotate helper class to be visible inside JSF?

I have a helper class, which is neither a stateful managed bean, nor a stateless EJB, nor an entity mapped to a table via JPA or Hibernate. It is simply a collection of static methods that do simple things like return date formats and similar.
Given that, in order for a Java class to be visible inside a JSF, that class must be annotated in a way that the container assigns as visible to JSFs, is there a way to annotate a helper class that does not match any of the standard JSF visible categories so that it becomes visible? An alternative, of course, is to have a conduit method in the managed bean that passes the call from the JSF to the helper class but I prefer not to clutter my managed bean if I can call it directly from the JSF. I understand that doing this with a stateless EJB from a JSF would be considered an anti-pattern but the methods in the class I wish to use are all very simple and non-transactional.
Mark your class as #ApplicationScoped. Make sure it has a public no-arg constructor and that this class doesn't have state and its methods are thread safe.
E.g.
Managed bean (pure JSF)
//this is important
import javax.faces.bean.ApplicationScoped;
#ManagedBean
#ApplicationScoped
public class Utility {
public static String foo(String another) {
return "hello " + another;
}
}
CDI version
//this is important
import javax.enterprise.context.ApplicationScoped;
#Named
#ApplicationScoped
public class Utility {
public static String foo(String another) {
return "hello " + another;
}
}
View
<h:outputText value="#{utility.foo('amphibient')}" />

CDI #Specializes and Constructor Injection with #Postconstruct

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.

How to use CDI qualifiers with multiple class implementations?

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);
.....
}
}

Dependency injection in abstract and concrete classes

I'm using JSF and am running in a problem for quite awhile, I've searched at a lot of places but couldn't find any suitable answer.
Can I have dependency injection working in an abstract (or more generally a class higher in the hierarchy) class ?
Also, how should we handle annotations when working with inheritance ? I've read that the common practice would be not to annotate the abstract class, only the concrete one, but then, it would imply no injection for that abstract ?
My problem is that one (check the last comment) :
Abstract class
#ManagedBean
#ViewScoped
public abstract class AbstractController<T extends VersionedObject> implements Serializable {
#ManagedProperty("#{libraryVersionController}")
private LibraryVersionController libraryVersionController;
public List<T> loadFromDatasource(IVersionedServiceBase<T> service) {
log.info("Loading generic VO from data source");
VersionedObjectFilter filter = new VersionedObjectFilter();
filter.setSelectedLibVersion(libraryVersionController.getSelectedItem());
// etc
}
// getters, setters...
}
Concrete class
#ManagedBean
#ViewScoped
public class DomainController extends AbstractController<Domain> implements Serializable {
private List<Domain> allItems;
private Domain[] selectedItem;
#ManagedProperty(value = "#{domainService}")
private DomainService domainService;
#PostConstruct
public void loadFromDatasource() {
allItems = super.loadFromDatasource(domainService);
// !! DOES NOT WORK, null pointer exception on abstract class (libraryVersionController)
// etc
}
Getters and setters are correctly set up, as I could read in my .xhml it is the concrete class that I'm referencing (#{domainController.allItems}), there is only one #PostConstruct. I'm using JSF2.1 and Mojarra.
Thanks for your help !
As to your NullPointerException, my guess is that AbstractController.setLibraryVersionController is missing. As I understand it, when the AbstractController is constructed (presumably it has an implicit constructor even though it's abstract), that method is needed to fill in the appropriate value.
I know you said all getters and setters are there, but this one seems tricky, so possibly you missed it. If you add logging to this method, you can check that JSF is attempting to fill in the value, and also check whether the value is null or not.
On the general question of how dependency injection works with the inheritance hierarchy, I would guess that your approach is OK, and that dependencies are injected for the base class and then for the derived class, down the chain.

Resources