Defining priority / order of advice in Spring AOP

We can use @Order annotation to define the Order of advice

MarkIT Telephonic Interview Questions

1. Difference between ArrayList and LinkedList. Why search in ArrayList is faster than in LL. When to use what

Ans : Array List is implemented as an Array and since arrayList is indexed, we just need to go to array+i th position directly. We do not have to traverse the whole list as in case of LL

2. HashCode and Equals contract

3. Difference between HashTable and HashMap
(If have inserted lakhs of objects in a HashTable and these threads simultaneously want to access a method(lets say equals() method)... one thread will accquire lock on the method, so others will have to wait. This will be a performance hit.
This is the reason why HashMap (not synchronised) came into picture. HashTable is legacy datastructure.

4. Difference between IOC and Dependency Injection

5. Difference between Error and Exception. Are all Errors Irrecoverable. (Think about NoClassDefFoundError)

Around advice vs Before/ After Advice

MethodInterceptor provides the ability to do both berfore and after advices in one advice object:
public interface MethodInterceptor extends Interceptor {
Object invoke(MethodInvocation invocation) throws Throwable;
}
There are two important differences between the MethodInterceptor interface
and the previous two types of advice. First, the MethodInterceptor implementation
controls whether the target method is actually invoked. Invoking the target
method is done by calling MethodInvocation.proceed(). This is in contrast to
MethodBeforeAdvice, where the target method is always called unless you throw
an exception.
Second, MethodInterceptor gives you control over what object is returned. This
means you can return a completely different object than the one returned by proceed().
Remember, with AfterReturningAdvice you had access to the object being returned, but you could not return a different object. While MethodInterceptor
provides this added flexibility, you should use caution when returning a different
object than the one returned by the target method and only do so when necessary.

Advice in Spring AOP

Advice contains the logic of your aspect. So,when you create an advice object, you are writing the code that implements the
cross-cutting functionality. Also, remember that Spring’s joinpoint model is built
around method interception. This means that the Spring advice you write will be
woven into your application at different points around a method’s invocation.
Because there are several points during the execution of a method that Spring
can weave in advice, there are several different advice types.

Advice type Interface Description
Around org.aopalliance.intercept.MethodInterceptor Intercepts calls to the target
method
Before org.springframework.aop.BeforeAdvice Called before the target
method is invoked
After org.springframework.aop.AfterReturningAdvice Called after the target
method returns
Throws org.springframework.aop.ThrowsAdvice Called when target
method throws an
exception

Spring AOP

Spring does not create a proxied object until that proxied bean is needed by the
application. If you are using an ApplicationContext, the proxied objects will be
created when it loads all of the beans from the BeanFactory. Because Spring creates
proxies at runtime, you do not need a special compiler to use Spring’s AOP.
Spring generates proxied classes in two ways. If your target object implements
an interface(s) that exposes the required methods, Spring will use the JDK’s
java.lang.reflect.Proxy class. This class allows Spring to dynamically generate
a new class that implements the necessary interfaces, weave in any advice, and
proxy any calls to these interfaces to your target class.
If your target class does not implement an interface, Spring uses the CGLIB1
library to generate a subclass to your target class. When creating this subclass,
Spring weaves in advice and delegates calls to the subclass to your target class.
When using this type of proxy generation, you need to deploy all of the JAR files
in the lib/cglib directory of your Spring distribution with your application.
There are two important things to take note of when using this approach:
■ Creating a proxy with interfaces is favored over proxying classes, since this
leads to a more loosely coupled application. The ability to proxy classes is
provided so that legacy or third-party classes that do not implement interfaces
can still be advised. This approach should be taken as the exception,
not the rule.
■ Methods marked as final cannot be advised. Remember, Spring generates
a subclass to your target class. Any method that needs to be advised is overridden
and advice is woven in. This is not possible with final methods.

Spring implements AOP Alliance interfaces
The AOP Alliance is a joint project between several parties interested in implementing
AOP in Java. The AOP Alliance shares the same belief as Spring that AOP
can provide cleaner and easier solutions for Java enterprise applications than what
is currently offered by EJB. Their goal is to standardize Java’s AOP interface to provide
interoperability between various Java AOP implementations. This means that
AOP advice that implements their interfaces (as do some of Spring’s implementations)
will be reusable in any other AOP Alliance–compatible framework.
Spring only supports method joinpoints
As mentioned earlier, multiple joinpoint models are available through various
AOP implementations. Spring only supports method joinpoints. This is in contrast
to some other AOP frameworks, such as AspectJ and JBoss, which provide
field joinpoints as well. This prevents you from creating very fine-grained advice,
such as intercepting updates to an object’s field.
However, as Spring focuses on providing a framework for implementing J2EE
services, method interception should suit most, if not all, of your needs. Plus,
Spring’s philosophy is that field interception violates encapsulation. A fundamental
object-oriented concept is that objects initiate operations on themselves
and other objects through method calls. Having advice fired on field modification
as opposed to method invocation arguably violates this concept.

Spring : Good Points

1. IF you are using DI using constructor .. u have to make the constructor as public ... private / protected / default wont work

Life cycle of a bean with Bean Factory Container and ApplicationContext Container

1 The container finds the bean’s definition and instantiates the bean.
2 Using dependency injection, Spring populates all of the properties as
specified in the bean definition.
3 If the bean implements the BeanNameAware interface, the factory calls
setBeanName() passing the bean’s ID.
4 If the bean implements the BeanFactoryAware interface, the factory calls
setBeanFactory(), passing an instance of itself.
5 If there are any BeanPostProcessors associated with the bean, their post-
ProcessBeforeInitialization() methods will be called.
6 If an init-method is specified for the bean, it will be called.
7 Finally, if there are any BeanPostProcessors associated with the bean,
their postProcessAfterInitialization() methods will be called.

At this point, the bean is ready to be used by an application and will remain in the
bean factory until it is no longer needed. It is removed from the bean factory in
two ways.

1 If the bean implements the DisposableBean interface, the destroy()
method is called.
2 If a custom destroy-method is specified, it will be called.

The life cycle of a bean within a Spring application context differs only slightly
from that of a bean within a bean factory

The only difference here is that if the bean implements the ApplicationContext-
Aware interface, the setApplicationContext() method is called.

Spring : Difference between BeanFactory and ApplicationContext

ApplicationContext interface extends the BeanFactory interface.

A big difference between an application context and a bean factory is how
singleton beans are loaded. A bean factory lazily loads all beans, deferring bean
creation until the getBean() method is called. An application context is a bit
smarter and preloads all singleton beans upon context startup. By preloading
singleton beans, you ensure that they will be ready to use when needed—your
application won’t have to wait for them to be created.