DEV Community: irena-sayv

Spring Bean annotation: What, How, and Why?

irena-sayv — Sun, 18 Dec 2022 18:39:23 +0000

@Bean is a method-level annotation that is used to create a spring managed bean. The object returned from the annotated method is registered as a bean in the Spring container. To simplify understanding, bean annotation is analogous to definition in XML configuration. In this blog, we will cover a basic understanding of @Bean with code examples.

How to create a bean using @Bean?

Bean annotated methods are generally placed in a @Configuration annotated class. During bootstrap, Spring reads the bean definition from the @Configuration class, and instantiates and initializes the bean. Bean definition methods can also be declared within a plain class or @Component annotated class but the processing of beans is different. We will touch base upon this concept a little later (See section — Bean Lite mode).

By default, the name of the method is the name of the created bean. You can give a custom name by using the name property of @Bean

public class EmployeeService {

public String getEmployeeName(String employeeCode) {
  // logic to return employee name based on employeeCode
 }
}
@Configuration
public class ApplicationConfig {

 @Bean(name = "customEmployeeService")
 public EmployeeService employeeServiceBean() {
  return new EmployeeService();
 }
}

Here ApplicationConfig is a configuration class where we have provided definition for customEmployeeService bean

To use this bean, we can either

a) get the instance of the bean using the getBean method of ApplicationContext and use it in the consumer class

b) auto-wire it in the consumer class using @Autowire

Bean dependencies

Suppose EmployeeService has a dependency on EmployeeDao type. This is called inter-bean dependency which can be fulfilled through constructor injection or setter injection by directly invoking the bean method of the dependency in the dependent bean method.

Let's modify EmployeeService to include a constructor

public class EmployeeDao {

  public String getEmployeeName(String employeeCode) {
  // code to fetch employee name from databse and return from this method
 }
}

public class EmployeeService {

 private EmployeeDao employeeDao;

 public EmployeeService(EmployeeDao employeeDao) {
  this.employeeDao = employeeDao;
 }

 public String getEmployeeName(String employeeCode) {
  return employeeDao.getEmployeeName(employeeCode);
 }
}

Now we define a bean of type EmployeeDao in ApplicationConfig and inject it in EmployeeService by calling the employeeDao() method in EmployeeService constructor

@Configuration
public class ApplicationConfig {

 @Bean
 public EmployeeDao employeeDao() {
  return new EmployeeDao();
 }

 @Bean(name = "customEmployeeBean")
 public EmployeeService employeeServiceBean() {
  return new EmployeeService(employeeDao());
 }
}

Bean Lite mode

When a bean method is declared in a non @Configuration class — a @Component annotated class or even a plain class, the bean is said to be processed in ‘lite’ mode (‘full’ mode is when the method is declared within a @Configuration annotated class). The bean is still added to the context by component scan but the @Bean method simply acts as a factory method.

In the full mode example that we discussed in the Bean dependencies section, we declared inter-bean dependency in one @Bean method by calling another @Bean method. In lite mode, @Bean methods can not declare inter-dependencies. Invoking another @Bean method does not return the bean from the context, rather it is a normal java method invocation that returns a new instance.

The following code blocks illustrate the comparison between the full mode and lite mode of bean processing

@Configuration
public class ApplicationConfig {

 @Bean
 public EmployeeDao employeeDao() {
  System.out.println("Creating employeeDao bean");
  return new EmployeeDao();
 }

 @Bean(name = "customEmployeeBean")
 public EmployeeService employeeServiceBean() {
  return new EmployeeService(employeeDao());
 }
}


public class Application {

 public static void main(String[] args) {

  ApplicationContext context = new AnnotationConfigApplicationContext(ApplicationConfig.class);
  EmployeeService employeeService1 = context.getBean(EmployeeService.class);
  EmployeeService employeeService2 = context.getBean(EmployeeService.class);

 }
}

Output:
Creating employeeDao bean

@Component
public class ApplicationConfig {

 @Bean
 public EmployeeDao employeeDao() {
  System.out.println("Creating employeeDao bean");
  return new EmployeeDao();
 }

 @Bean(name = "customEmployeeBean")
 public EmployeeService employeeServiceBean() {
  return new EmployeeService(employeeDao());
 }
}

public class Application {

 public static void main(String[] args) {

  ApplicationContext context = new AnnotationConfigApplicationContext(ApplicationConfig.class);
  EmployeeService employeeService1 = context.getBean(EmployeeService.class);
  EmployeeService employeeService2 = context.getBean(EmployeeService.class);

 }
}

Output:
Creating employeeDao bean
Creating employeeDao bean

Why do we need @Bean when there is @Component?

In the above example, we created a @Configuration annotated class and manually defined our bean with @Bean. Why? We could have just annotated EmployeeService class with @Component (or @Service annotation to be more specific) for Spring to auto-detect and auto-configure it

@Bean can be used to create a bean of a class that is outside of the Spring container, which can be the case when the class is part of a library and you can not edit source code to add @Component annotation

@Bean also allows you to customize the instance before being used. For example, a RestTemplate configured with a custom timeout configuration to be used across the Spring boot application

@Configuration
public class ApplicationConfig {

 @Bean
    public RestTemplate restTemplate(RestTemplateBuilder restTemplateBuilder) 
    {
        return restTemplateBuilder
           .setConnectTimeout(Duration.ofSeconds(5))
           .setReadTimeout(Duration.ofSeconds(5))
           .build();
    }
}

Hope this article helped to get a basic understanding of @Bean and how and when it can be used.

Google Cloud Monitoring: Monitoring and Alerting on number of kubernetes pod replicas in GKE

irena-sayv — Mon, 07 Mar 2022 18:36:04 +0000

Monitoring and Alerting is critical for operations and cost management of business applications.

As part of the Operations team, we were required to create a mechanism to get automated alerts when the pod replicas for a deployment goes down the expected number or a pod is not available for a business critical deployment, or when the count of pod replicas goes up beyond the expected number pointing towards unusual traffic.

There is no built-in metric available for getting the count of replicas for a Kubernetes Pod in Cloud Monitoring. In this blog, we will look at how we can enable alerting policy based on the pod replicas count.

Using container/uptime metric

Containers are encapsulated in a Pod. We can leverage container Uptime metric for determining the count of pod replicas with below configurations

We have used resource label container_name along with the cluster name in Filter, you may need additional filters such as namespace to identify a container. The Aggregate function 'count' reduces the multiple timeseries data to a single value giving us the count of containers that are up at the given time

Here, sum is used as Aligner, but any of the available aligner options can be used as we do not care about the intermediate value

Policy Conditions

Condition for checking when number of containers is below 5

There will be no record for a container when it is not up. So we need an additional condition that will trigger an alert if a container is missing in the metric output

An alert is triggered when any of the above conditions is met

Move files from Google Cloud Storage to Azure Blob Storage programmatically

irena-sayv — Fri, 04 Jun 2021 18:59:15 +0000

Copying files from Google Cloud Storage to Azure Blob Storage programmatically can be achieved by streaming the data directly from cloud storage to blob storage. We will be using google cloud storage and azure storage client libraries for java in this blog.

Streaming allows to transfer the data without requiring the file to be saved first. Saving the entire file in memory and then writing it to the destination can exhaust the memory leading to OutOfMemoryError if the file is large. Instead, we will iterate through and read some bytes at a time, do some processing and clear them.

ReadChannel

ReadChannel, extended from java.nio.channels.ReadableByteChannel, is a reading channel for reading object’s content. Cloud storage client library comes with a reader method which returns ReadChannel to read blob’s content

BlobOutputStream

BlobOutputStream is a stream for writing into azure blob storage. It is extended from java.io.OutputStream

Maven dependencies
<dependency> <groupId>com.google.cloud</groupId> <artifactId>google-cloud-storage</artifactId> <version>1.70.0</version> </dependency> <dependency> <groupId>com.microsoft.azure</groupId> <artifactId>azure-storage</artifactId> <version>8.4.0</version> </dependency>
(keyvault and azure active directory dependencies will be required for retrieving sas token)

Get Storage service object
StorageOptions options = StorageOptions.newBuilder().setProjectId(projectId).setCredentials(GoogleCredentials.fromStream(new FileInputStream(jsonKeyPath))).build(); Storage storage = options.getService();

Get CloudBlockBlob instance
// assuming sas token is retrieved from Azure keyVault
CloudBlockBlob cloudBlob = new CloudBlockBlob(new URI(contentUri + sasToken));

Stream data
try (ReadChannel reader = storage.reader(bucketName, blobPath); BlobOutputStream outputStream = blob.openOutputStream()) { ByteBuffer bytes = ByteBuffer.allocate(64 * 1024); while (reader.read(bytes) > 0) { bytes.flip(); outputStream.write(bytes.array()); bytes.clear(); } } catch (Exception e) { // handle } }