HomeSales Assignment 1

implement a service interface and implementation component

package a service within a Maven module separate from the application module

implement a Maven module dependency to make the component class available to the application module

use a @Bean factory method of a @Configuration class to instantiate a Spring-managed component

Create an interface module with

Create a HomeSale implementation module with

Create an application module with

Turn in a source tree with three or more complete Maven modules that will build and demonstrate a configured Spring Boot application.

implement a service interface and implementation component

package a service within a Maven module separate from the application module

implement a Maven module dependency to make the component class available to the application module

use a @Bean factory method of a @Configuration class to instantiate Spring-managed components

The spring-boot-maven-plugin can be used to both build the Spring Boot executable JAR and execute the JAR to demonstrate the instantiations, injections, and desired application output.

A quick start project is available in assignment-starter/homesales-starters/assignment1-homesales-beanfactory. Modify Maven groupId and Java package if used.

implement value injection into a Spring Component

define a default value for the injection

specify property files from different locations

specify a property file for a basename

specify properties based on an active profile

specify a both straight properties and YAML property file sources

Create a dependency on the support module. (provided in starter)

<dependency>
    <groupId>info.ejava.assignments.propertysource.homesales</groupId>
    <artifactId>homesales-support-propertysource</artifactId>
    <version>${ejava.version}</version>
</dependency>

Add a @SpringBootApplication class with main() (provided in starter)

package info.ejava_student.starter.assignment1.propertysource.sales;

import info.ejava.assignments.propertysource.sales.PropertyCheck;

@SpringBootApplication
public class PropertySourceApp {

Provide the following property file sources. (provided in starter) application.properties will be provided through the dependency on the support module and will get included in the JAR.

src/main/resources:/ (1)
    application-default.properties
    application-dev.yml (3)
    application-prd.properties
src/test/resources/ (2)
    application-dev1.properties
    application-site1.properties
    application-site2.yml (3)

Enable the unit integration test from the starter when you are ready to test — by removing @Disabled.

package info.ejava_student.starter.assignment1.propertysource.sales;

import info.ejava.assignments.propertysource.sales.PropertySourceTest;
...
//we will cover testing in a future topic, very soon
@Disabled //enable when ready to start assignment
public class MyPropertySourceTest extends PropertySourceTest {

Use a constant base command. This part of the command remains constant.

$ java -jar target/*-propertysource-1.0-SNAPSHOT-bootexec.jar --spring.config.location=classpath:/,optional:file:src/test/resources/ (1)

--spring.profiles.active= (1)

Populate the property and YAML files so that the scenarios in the following paragraph are satisfied. The default starter with the "base command" and "no active profile" set, produces the following by default.

$ java -jar target/*-propertysource-1.0-SNAPSHOT-bootexec.jar --spring.config.location=classpath:/,optional:file:src/test/resources/

configName=(default value)
configLocation=classpath:/,optional:file:src/test/resources/
profilesActive=(default value)
prioritySource=application-default.properties
Sales has started
dbUrl=mongodb://user:NOT_SUPPLIED@NOT_SUPPLIED:00000/test?authSource=admin

Turn in a source tree with a complete Maven module that will build and demonstrate the @Value injections for the 4 different active profile settings.

implement value injection into a Spring Component

define a default value for the injection

specify property files from different locations

specify properties based on an active profile

specify both straight properties and YAML property file sources

The spring-boot-maven-plugin can be used to both build the Spring Boot executable JAR and demonstrate the instantiations, injections, and desired application output.

A quick start project is available in assignment-starter/homesales-starter/assignment1-homesales-propertysource that supplies much of the boilerplate file and Maven setup. Modify Maven groupId and Java package if used.

An integration unit test (PropertySourceTest) is provided within the support module that can automate the verifications.

Ungraded Question to Ponder: How could you at runtime, provide a parameter option to the application to make the following output appear?

configName=homesales
configLocation=(default value)
profilesActive=(default value)
prioritySource=not assigned
Race Registration has started
dbUrl=not assigned

map a Java @ConfigurationProperties class to a group of properties

create a read-only @ConfigurationProperties class using @ConstructorBinding

define a Jakarta EE Java validation rule for a property and have the property validated at runtime

generate boilerplate JavaBean methods using Lombok library

map nested properties to a @ConfigurationProperties class

reuse a @ConfigurationProperties class to map multiple property trees of the same structure

use @Qualifier annotation and other techniques to map or disambiguate an injection

Given the following read-only property classes, application.yml file, and @Component …​

When running the application, a @ConfigurationProperties beans will be created to represent the contents of the YAML file as two separate List<SalesProperties> objects and a BoatSaleProperties object. When properly configured, they will be injected into the @Component, and and it will output the following.

homes:
*SalesProperties(id=1, saleDate=2010-07-01, saleAmount=100.0, buyerName=Joe Camper, location=AddressProperties(city=Jonestown, state=PA))
*SalesProperties(id=4, saleDate=2021-05-01, saleAmount=500000, buyerName=Jill Suburb, location=AddressProperties(city=, state=MD)) (1)
*SalesProperties(id=5, saleDate=2021-07-01, saleAmount=1000000, buyerName=M.R. Bigshot, location=AddressProperties(city=Rockville, state=MD))
autos:
*SalesProperties(id=2, saleDate=2000-01-01, saleAmount=1000, buyerName=Itis Clunker, location=AddressProperties(city=Dundalk, state=MD))
boat:
*BoatSaleProperties(id=3, saleDate=2022-08-01, saleAmount=200000, buyerName=Alexus Blabidy, location=AddressProperties(city=Annapolis, state=MD))

Configure your solution so that the BoatSaleProperties bean is injected into the PropertyPrinter component along with the List of home and auto SalesProperties. There is a skeletal configuration supplied in the application class. Most of your work will be within this class.

@SpringBootApplication
public class ConfigPropertiesApp {
    public static void main(String[] args)

    public List<SalesProperties> homes() {
        return new ArrayList<>();
    }
    public List<SalesProperties> autos() {
        return new ArrayList<>();
    }
}

Turn in a source tree with a complete Maven module that will build and demonstrate the configuration property processing and output of this application.

map a Java @ConfigurationProperties class to a group of properties

create a read-only @ConfigurationProperties class using @ConstructorBinding

generate boilerplate JavaBean methods using Lombok library

map nested properties to a @ConfigurationProperties class

reuse a @ConfigurationProperties class to map multiple property trees of the same structure

use @Qualifier annotation and other techniques to map or disambiguate an injection

A starter project is available in homesales-starter/assignment1-homesales-configprops. Modify Maven groupId and Java package if used.

I included an additional, general purpose LocalDateConverter @Component in the starter with the property classes. This is a necessary option to successfully parse the date expressed in the YAML file and have it injected as a LocalDate in the @ConfigurationProperties class.

sales:
  homes:
    - id: 1
      saleDate: 2010-07-01

import org.springframework.boot.context.properties.ConfigurationPropertiesBinding;
import org.springframework.core.convert.converter.Converter;
...
@Component
@ConfigurationPropertiesBinding
public class LocalDateConverter implements Converter<String, LocalDate> {
    @Override
    public LocalDate convert(String source) {
        return null==source ? null : LocalDate.parse(source);
    }
}

public class BoatSaleProperties {
    private int id;
    private LocalDate saleDate;

Failed to bind properties under 'sales.homes[0].sale-date' to java.time.LocalDate:
...
DateTimeParseException: Text '2010-07-01' could not be parsed at index 4)

The spring-boot-maven-plugin can be used to both build the Spring Boot executable JAR and demonstrate the instantiations, injections, and desired application output.

The support project contains an integration unit test that verifies the PropertyPrinter component was defined and injected with the expected data. It is activated through a Java class in the starter module. Activate it when you are ready to test.

//we will cover testing in a future topic, very soon
@Disabled //remove to activate when ready to test
public class MyConfigurationTest extends ConfigurationPropertyTest {
}

Ungraded Question to Ponder: What change(s) could be made to the application to validate the properties and report the following error?

Binding validation errors on sales.homes[1].location
...
codes [sales.homes[1].location.city,city]; arguments []; default message [city]]; default message [must not be blank]

Create a @Configuration class or @Bean factory method to be registered based on the result of a condition at startup

Create a Spring Boot Auto-configuration module to use as a "Starter"

Bootstrap Auto-configuration classes into applications using a spring.factories metadata file

Create a conditional component based on the presence of a property value

Create a conditional component based on a missing component

Create a conditional component based on the presence of a class

Define a processing dependency order for Auto-configuration classes

Create a SalesService interface module (already completed for beanfactory)

Create a HomeSales implementation implementation module (already completed for beanfactory)

Create a AutoSales implementation implementation module (new)

Create an Application Module with a @SpringBootApplication class

Create a Sale starter Module

Augment the Application module pom to address dependencies

Verify your solution will determine its results based on the available classes and properties at runtime. Your solution must have the following behavior

Turn in a source tree with a complete Maven module that will build and demonstrate the Auto-Configuration property processing and output of this application.

Create a @Configuration class/@Bean factory method to be registered based on the result of a condition at startup

Create a Spring Boot Auto-configuration module to use as a "Starter"

Bootstrap Auto-configuration classes into applications using a spring.factories metadata file

Create a conditional component based on the presence of a property value

Create a conditional component based on a missing component

Create a conditional component based on the presence of a class

Define a processing dependency order for Auto-configuration classes

A starter project is available in homesales-starter/assignment1-homesales-autoconfig. Modify Maven groupId and Java package if used.

A unit integration test is supplied to check the results. We will cover testing very soon. Activate the test when you are ready to get feedback results. The test requires:

obtain access to an SLF4J Logger

issue log events at different severity levels

format log events for regular parameters

filter log events based on source and severity thresholds

Create several components in different Java sub-packages (app, svc, and repo)

Implement a chain of calls from the AppCommand @Component run() method through the other components.

Figure 4. Required Call Sequence

Implement a toString() method in HomeSaleDTO that includes the homeId, buyerId, and time information.

Instantiate an SLF4J Logger into each of the four components

Implement logging statements in each of the methods

Output available race results information in log statements

Supply two profiles

Wrap your solution in a Maven build that executes the JAR three times with:

obtain access to an SLF4J Logger

issue log events at different severity levels

format log events for regular parameters

filter log events based on source and severity thresholds

You may use any means to instantiate/inject the components (i.e., @Bean factories or @Component annotations)

You are encouraged to use Lombok to declare constructors, getter/setter methods, and anything else helpful except for the manual instantiation of the "X.Y" logger in AppCommand.

A starter project is available in homesales-starter/assignment1-homesales-logging. It contains a Maven pom that is configured to build and run the application with the following profiles for this assignment:

There is an integration unit test (MyLoggingNTest) provided in the starter module. We will discuss testing very soon. Enable this test when you are ready to have the results evaluated.

efficiently bypass log statements that do not meet criteria

Update the toString() method in HomeSaleDTO to be expensive to call

Refactor your log statements, if required, to only call toString() when TRACE is active

efficiently bypass log statements that do not meet criteria

Include these modifications with the previous work on this overall logging assignment. Meaning — there will not be a separate module turned in for this portion of the assignment.

The app-debug should not exhibit any additional delays. The repo-only should exhibit a 4 (2x2sec) second delay.

There is an integration unit test (MyLoggingEfficiencyNTest) provided in the starter module. We will discuss testing very soon. Enable this test when you are ready to have the results evaluated.

filter log events based on source and severity thresholds

customize log patterns

customize appenders

add contextual information to log events using Mapped Diagnostic Context

use Spring Profiles to conditionally configure logging

Declare two Appenders as part of a custom Logback configuration

Assign the Appenders to Loggers

Add an appenders profile that

Add a requestId property to the Mapped Diagnostic Context (MDC)

Figure 6. Initialize Mapped Diagnostic Context (MDC)

Declare a custom logging pattern in the appenders profile that includes the MDC requestId value in each log statements written by the FILE Appender

Add an additional trace profile that

Apply the appenders profile to

Apply the appenders and trace profiles to

filter log events based on source and severity thresholds

customize log patterns

customize appenders

add contextual information to log events using Mapped Diagnostic Context

use Spring Profiles to conditionally configure logging

You may use the default Spring Boot LogBack definition for the FILE and CONSOLE Appenders (i.e., include them in your logback configuration definition).

<configuration>
    <include resource="org/springframework/boot/logging/logback/defaults.xml"/>
    <include resource="org/springframework/boot/logging/logback/console-appender.xml"/>
    <include resource="org/springframework/boot/logging/logback/file-appender.xml"/>
...

Your appenders and trace profiles may re-define the logging pattern for the FILE logger or add/adjust parameterized definitions. However, try to implement an optional parameterization as your first choice to keep from repeating the same definition.

The following snippet shows an example resulting logfile from when appenders and then appenders,trace profiles were activated. Yours may look similar to the following:

$ rm target/logs/appenders.log
$ java -jar target/assignment1-*-logging-1.0-SNAPSHOT-bootexec.jar --spring.profiles.active=appenders
$ head target/logs/appenders.log

head target/logs/appenders.log       (1)
21:46:01.335  INFO -- [c934e045-1294-43c9-8d22-891eec2b8b84]  Y : HomeSales has started (2)

$ rm target/logs/appenders.log
$ java -jar target/assignment1-*-logging-1.0-SNAPSHOT-bootexec.jar --spring.profiles.active=appenders,trace
$ head target/logs/appenders.log

$ head target/logs/appenders.log             (1)
21:47:33.784  INFO -- [0289d00e-5b28-4b01-b1d5-1ef8cf203d5d]  Y.run:27 : HomeSales has started (2)

There is a set of unit integration tests provided in the support module. We will cover testing very soon. Enable them when you are ready to evaluate your results.

write a test case and assertions using JUnit 5 "Jupiter" constructs

leverage the AssertJ assertion library

execute tests using Maven Surefire plugin

Start with a dependency on supplied and completed BuyerValidatorImpl and BuyerDTO classes in the homesales-support-testing module. You only need to understand and test them. You do not need to implement or modify anything being tested.

Implement a plain unit test case class for BuyerValidatorImpl

The unit test case must have an init() method configured to execute "before each" test

The unit test case must have a test that verifies a valid BuyerDTO will be reported as valid.

The unit test case must have a test method that verifies an invalid BuyerDTO will be reported as invalid with a string message for each error.

Name the test so that it automatically gets executed by the Maven Surefire plugin.

write a test case and assertions using JUnit 5 "Jupiter" constructs

leverage AssertJ assertion libraries

execute tests using Maven Surefire plugin

A quick start project is available in homesales-starter/assignment1-homesales-testing, but

You are expected to form a dependency on the homesales-support-testing module. The only things present in your src/main would be demonstration code that is supplied to you in the starter — but not part of any requirement.

implement a mock (using Mockito) into a JUnit unit test

define custom behavior for a mock

capture and inspect calls made to mocks by subjects under test

Start with a dependency on supplied and completed BuyersServiceImpl and other classes in the homesales-support-impl module. You only need to understand and test them. You do not need to implement or modify anything being tested.

Implement a unit test case for the BuyersService to verify validation for a valid and invalid BuyerDTO

The unit test case must have an init() method configured to run "before each" test and initialize the BuyersServiceImpl with the Mock instance for BuyerValidator.

The unit test case must have a test that verifies a valid registration will be handled as valid.

The unit test case must have a test method that verifies an invalid registration will be reported with an exception.

Name the test so that it automatically gets executed by the Maven Surefire plugin.

implement a mock (using Mockito) into a JUnit unit test

define custom behavior for a mock

capture and inspect calls made to mocks by subjects under test

This portion of the assignment is expected to primarily consist of one additional test case added to the src/test tree.

You may use BDD or non-BDD syntax for this test case and tests.

to implement unit integration tests within Spring Boot

implement mocks (using Mockito) into a Spring context for use with unit integration tests

Start with a supplied, completed, and injectable 'BuyersServiceImpl' versus instantiating one like you did in the pure unit tests.

Implement a unit integration test for the BuyersService for a valid and invalid BuyerDTO

The unit integration test case must have a test that verifies a valid registration will be handled as valid.

The unit integration test case must have a test method that verifies an invalid registration will be reported with an exception.

Name the unit integration test so that it automatically gets executed by the Maven Surefire plugin.

to implement unit integration tests within Spring Boot

implement mocks (using Mockito) into a Spring context for use with unit integration tests

This portion of the assignment is expected to primarily consist of

Anything you may have been tempted to simply instantiate as private X x = new X(); can be changed to an injection by adding a @(Test)Configuration/@Bean factory to support testing. The point of having the 100% injection requirement is to encourage encapsulation and reuse among Test Cases for all types of test support objects.

You may add the BuyersTestConfiguration to the Spring context using either of the two annotation properties

You may want to experiment with applying @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) versus the default @Scope(ConfigurableBeanFactory.SCOPE_SINGLETON) to you injected Buyer and generate a random name in the @Bean factory. Every injected SCOPE_SINGLETON (default) gets the same instance. SCOPE_PROTOTYPE gets a separate instance. Useful to know, but not a graded part of the assignment.

make use of BDD acceptance test keywords

Start with a supplied, completed, and injectable BuyersServiceImpl by creating a dependency on the homesales-support-testing module. There are to be no POJO or Mock implementations of any classes under test.

Implement a unit integration test for the BuyersService for a valid and invalid BuyerDTO

The unit integration test case must have

The unit integration test case must have a test that verifies a valid registration will be handled as valid.

The unit integration test case must have a test method that verifies an invalid registration will be reported with an exception.

Name the unit integration test so that it automatically gets executed by the Maven Surefire plugin.

make use of BDD acceptance test keywords

This portion of the assignment is expected to primarily consist of adding a test case that

The "custom test method naming policy" can be set using either an @Annotation or property. The properties approach has the advantage of being global to all tests within the module.