Sunday, March 5, 2023

Spring Boot Annotations

Spring Boot Annotations is a form of metadata that provides data about a program. In other words, annotations are used to provide supplemental information about a program. It is not a part of the application that we develop. It does not have a direct effect on the operation of the code they annotate. It does not change the action of the compiled program.


@Required: It applies to the bean setter method. It indicates that the annotated bean must be populated at configuration time with the required property, else it throws an exception BeanInitilizationException.

@Autowired: Spring provides annotation-based auto-wiring by providing @Autowired annotation. It is used to autowire spring bean on setter methods, instance variable, and constructor. When we use @Autowired annotation, the spring container auto-wires the bean by matching data-type.

@Configuration: It is a class-level annotation. The class annotated with @Configuration used by Spring Containers as a source of bean definitions.

@ComponentScan: It is used when we want to scan a package for beans. It is used with the annotation @Configuration. We can also specify the base packages to scan for Spring Components.

@Bean: It is a method-level annotation. It is an alternative of XML <bean> tag. It tells the method to produce a bean to be managed by Spring Container.

@Component: It is a class-level annotation. It is used to mark a Java class as a bean. A Java class annotated with @Component is found during the classpath. The Spring Framework pick it up and configure it in the application context as a Spring Bean.

@Controller: The @Controller is a class-level annotation. It is a specialization of @Component. It marks a class as a web request handler. It is often used to serve web pages. By default, it returns a string that indicates which route to redirect. It is mostly used with @RequestMapping annotation.

@Service: It is also used at class level. It tells the Spring that class contains the business logic.

@Repository: It is a class-level annotation. The repository is a DAOs (Data Access Object) that access the database directly. The repository does all the operations related to the database.

@EnableAutoConfiguration: It auto-configures the bean that is present in the classpath and configures it to run the methods. The use of this annotation is reduced in Spring Boot 1.2.0 release because developers provided an alternative of the annotation, i.e. @SpringBootApplication.

@SpringBootApplication: It is a combination of three annotations @EnableAutoConfiguration, @ComponentScan, and @Configuration.

Saturday, July 5, 2014

Why people migrate from Flex to HTML 5 ? - Important Reasons

The web application landscape has shifted rapidly in the past year.  Due to Adobe’s changing view of the Flash Platform, many companies who have relied on technologies like Flex are looking to migrate to HTML 5.  This transition can be tricky both for an organization as well as its developers.  Here are five steps that should be some of the first an organization takes in this process:
1. Choose a Client-Side MVC Architecture
Many developers will quickly become overwhelmed when examining the options for HTML 5 web application frameworks.  With Flex, there was a defined class system, a defined component model, and a similar Model View Controller architecture that most of the micro-architectures implemented.  This is not the case in HTML 5 / JavaScript applications.
Within JavaScript you will find frameworks that differ greatly on each of these points.  For example, Backbone JS is a popular client-side MVC architecture for HTML 5 applications, but it does not dictate how your user interface is rendered.  Some people pair Backbone with a client-side templating solution like Mustache JS while others use manual DOM manipulation and still others generate the interface entirely on the server side.
There are several key points to consider when making this decision for your organization:
  • How documented is the framework?  Can your developers easily pick up new concepts solely from the documentation?
  • Does the framework provide adequate real world examples?  These will be crucial for the internal learning process with your developers.
  • Does the framework provide a level of flexibility for the type of applications that your organization creates?
  • Does the framework allow for you to create testable applications?  Does the framework have a testing story already crafted for its applications?
  • Does the framework provide the level or support needed for your organization?
  • What level of support do you require?  Many frameworks are purely open source with no support options.  Some frameworks (like Sencha Touch / ExtJS) have a level of support available to organizations.
If your company is attempting to decide on an MVC architecture, I would recommend examining Backbone JSEmber JSAngular JS, and ExtJS / Sencha Touch.  Choosing a framework that contains both a client side MVC architecture and a mature class system is almost always going to be superior than piecing multiple frameworks together.  Picking a micro-architecture doesn’t have to be a permanent decision, but it will give your developers a place to start.
In addition, your team can augment the framework that you have chosen over time.  For example, At Universal Mind we work with Sencha Touch and ExtJS (in addition to other frameworks).  To facilitate code organization and reuse one of our team members, John Yanarella, crafted DeftJS which adds dependency injection (among other things) to the core framework that powers both Sencha Touch and ExtJS.  In short, you can make a framework into what you want it to be.
2. Select a DOM Manipulation and AJAX Library
A DOM (Document Object Model) manipulation and AJAX library is an essential tool in JavaScript development.  In Flex, developers could leverage effects, transitions, and states as all of them integrated with the component model.  In JavaScript, to make something change visually within an application, a developer will have to modify the DOM to add elements, remove elements, change styling, and so on.  In addition, the way to modify the DOM differs across browsers.  A proven DOM manipulation library will make these tasks much easier and will work consistently across all of the popular browsers.  Most of these libraries will include functionality to handle HTTP requests in a consistent manner across browsers.
In many cases, the DOM manipulation library will not be included with your MVC framework.  Some solutions (like Sencha Touch / ExtJS) aim to provide an all-in-one framework, but that isn’t the norm. 
The most popular DOM manipulation library is jQuery, and it has a vast online community.  This also includes a large library of community plugins, but many of these may not meet the bar of quality that one would expect for an enterprise application.
There are many other DOM manipulation libraries that exist such as PrototypeDojo, and MooTools (just to name a few).  Determining which one is a best fit for your organization requires an examination of  your developers experiences, desired level of documentation, and proposed use cases.
3. Adopt Code Conventions Quickly
There was a level of consistency across most Flex applications in both MXML and ActionScript.  There were obviously subtle differences from one developer to another, but these differences pale in comparison to the differences that HTML / JavaScript bring to the table.  One of the first steps that any organization must undertake is developing a defined set of HTML / JavaScript code conventions.
This task may seem daunting, so I recommend that your organization initially adopt standards that already exist.  As an example, Douglas Crockford, the Senior JavaScript Architect at Yahoo, has a brief list of JavaScript Code Conventions.  I would recommend starting with something like this and then expanding once your organization has some HTML5 development under its belt.
In addition, tools such as JSLint (also authored by Crockford) can force developers into following many of these best practices and conventions.  JSLint also has integration into many of the popular IDE’s including Aptana and WebStorm.
Organizations that skip this step will find that their code has little coherence between projects, and that it is increasingly difficult for developers to ramp up on a code base created by another team.
4. Develop a Testing Plan
Through its lifetime Flex developed a quality testing story.  Developers could leverage unit testing tools like FlexUnit and also enterprise functional testing tools such as HP’s Quick Test Pro.  Making the switch to HTML5 application requires building a testing plan that is just as rich.  Determining how to integrate your QA team into this process is crucial.
For the first piece of the testing plan, an organization will need to make a decision around testing units of code.  One popular solution is Jasmine, a JavaScript BDD (Behavior Driven Development) testing framework.  If you are looking for a more traditional TDD (Test Driven Development) framework, the jQuery project uses a custom framework called QUnit.  If your team prefers to use something similar to JUnit (which FlexUnit was based on), then I would recommend looking at JSUnit.
Another important area to consider is Code Coverage.  The current options for JavaScript are passable, and I hope that they will mature over time.  Options like JSCoverage can help your organization enforce an expected level of testing in your HTML5 applications. 
The next piece centers on functional testing of HTML5 applications.  This is one area where HTML5 development can exceed Flex.  With Flex development, the only truly powerful testing tool was HP’s Quick Test Pro (because Adobe wrote this integration into the framework).  With web standards development, the integration is a little easier.  Tools like Selenium provide for quality functional testing of your HTML5 applications.
5. Define a Build and Deployment Process
As Flex matured, many organizations adopted build tools such as ANT and Maven.  These tools all had integration with the Flex compiler, and building an optimized Flex application generally only took a few discrete steps.  The process becomes a bit more complicated with HTML5 applications.
As you build your applications, you will need to plan on having a build process that accomplishes the following (or a subset of these items):
  1. Minify all JavaScript code
  2. Combine minified JavaScript into a single file (to reduce the amount of files that have to be loaded)
  3. Compile LESS/SASS CSS code (if your organization chooses to use one of these tools)
  4. Combine CSS code into single file
  5. Validate HTML, JavaScript, and CSS against organization or web standards
  6. Run unit tests
  7. Run functional tests
  8. Execute load tests in a staging environment
This integration will generally be a combination of tools from different locations that all need to be scripted using a tool such as ANT.  You can utilize some of the command line tools to minify your JavaScript and CSS files (such as the YUI Compressor from Yahoo).  Some frameworks like Sencha Touch 2 and ExtJS 4 already have a build tool included that accomplishes these steps.
Developing a repeatable and consistent process to push to production will certainly be key to your organization’s success.
Conclusion
Starting off on the right foot is crucial in this transition.  Empowering your developers with these new technologies requires careful research and planning.  By working your way through these items, you can approach your decision with the required amount of forethought.

Saturday, June 28, 2014

Happy Coding with Junit frameworks ecobertura and Emma




Spring MVC is one of the leading Java Web application frameworks along with Struts. In the next few blogs, I will take an use case and demonstrate how to develop a good quality web application in an enterprise Java world. I will also demonstrate latest capabilities of Spring like Annotation based configurations and its advantages over XML based configurations. Prerequisite for this application is Java 7.x, Tomcat 7.x, Maven 3.x and STS IDE.

The use case I will be talking about is a Bookstore application, where in user register to this application and purchase books. There is also an administration task like creating the book catalog.

Spring MVC application architecture

For this sample application we extensively use the Latest Spring MVC annotation capability. The major advantage with this is we will not be depending on any xml configuration including web.xml. I personally like XML configuration with namespace, because it is readable. The advantage of annotation is, since everything is Java, if we use STS IDE, any typo can be caught at compilation time, and we can write a good quality code and even measure the code coverage. We also used Kickstrap as the css engine for this application. Here is a blog on Integrating Kickstrap with Spring MVC application.

What is code coverage?

Code coverage is a measure of how well you unit tested your code. If you use a good IDE like STS IDE we can install ecobertura using the update site. Once you setup ecobertura, you can start developing your application. When you run your JUnit test in “Cover as” mode, it will show the code coverage of your JUnit tests as below,

eCobertura STS-IDE view