We Keep Coding

DI and IOC in spring mvc implementation

I am new to spring mvc and DI. I have came to know about the flow of the spring project and i know how the web projects in spring mvc is developed and worked on few projects too. All the annotation uses and xml configuration files in the spring mvc. But i am confused where the DI is used? and how the DI is implemented in spring with the help of IOC??
Can anyone please explain me the concept of DI and IOC and their implementation in spring mvc.
Thanks in advance!!!

DI and IOC happening through web.xml where you created the dispatcherservlet.
From Spring MVC docs :
The DispatcherServlet, provides a shared algorithm for request processing while actual work is performed by configurable, delegate components
The DispatcherServlet, as any Servlet, needs to be declared and mapped according to the Servlet specification using Java configuration or in web.xml. In turn the DispatcherServlet uses Spring configuration to discover the delegate components it needs for request mapping, view resolution, exception handling, and more.
internally it will register Spring mvc app and it will create an object and inject dependencies .

How to use MVC in Java EE 6/7 without using other frameworks?

I have already implemented the MVC pattern using the Spring framework.
In Spring there are #Controller and #RequestMapping annotations in the controller class and this framework doesn't use any HttpServlet.
I want this exact structure in Java EE (but without using any other framework).
So my question is: how can I use MVC in Java EE without using other frameworks?
Note: I don't want to use HttpServlet class

(1)
You can use JAX-RS and CDI to respond to HTTP requests, using annotations such as #Path and #RequestScoped. You might need some JAX-RS extensions or utilities for convenience, for better handling of parameters (e.g. RestEasy's #Form) and forwards to views (e.g. Jersey's Viewable).
(2)
You can also write a single HttpServlet (I hope that's not a problem) that will act as a front controller, instantiating the controller for each request. Using CDI, you can annotate your controllers with #Model (which is the same as #RequestScoped and #Named), and instantiate them in your front controller with:
#Inject #Any
private Instance<ControllerBaseClass> controllerInstance;
(...)
ControllerBaseClass controller = controllerInstance.select(«something»).get();
controller.processRequest(); // or execute() or anything you want.
request.getRequestDispatcher(«page»).forward(request, response); // or a redirect if it's a destructive operation.
What do you need to pass to select(«something»)? You can select an instance in CDI using annotation literals (consult CDI documentation) or classes (Class.forName(...)), depending on the request parameters.
Using CDI you can also make your controllers #ApplicationScoped instead of #RequestScoped.
As you see, you may need to build some infrastructure and stick to some patterns from then on, but it's perfectly feasible. I have used a mix of both strategies in a personal project and it works fine.

You can do it with technologies available in Java EE.
It's important to mention that Java EE is itself composed of many specifications/frameworks, for which there are more implementations. See this: https://java.net/projects/javaee-spec/pages/Home
Example with JSF http://www.tutorialspoint.com/jsf/jsf_architecture.htm
Example with JSP http://www.datadisk.co.uk/html_docs/jsp/jsp_mvc_tutorial.htm
Another example with JAX-RS https://jersey.java.net/documentation/latest/mvc.html
JSF is much more feature rich than JSP, and there are many components already made for it: Omnifaces, Primefaces etc. JAX-RS is for web services.
Have fun!

By simply using EJB for business logic, CDI for bean management and JSF for view.

It is incorrect to say that with Spring MVC there is no HttpServlet. From Spring Framework javadoc : DispatcherServlet (a subclass of HttpServlet) is the Central dispatcher for HTTP request handlers/controllers of the Spring framework. So it's hidden in the framework but present.
In fact, except in JSP only applications (not really MVC ... and JSP are translated in ... Servlets !) or JSF applications, you have (subclasses of) HttpServlet in all Java EE applications. And as JSF is only a specification you have to use an implemantation of JSF. There are 2 well known implementations, Oracle Mojarra or Apache MyFaces but both are ... frameworks.
Of course, you can do MVC in Java EE without any framework. As explained in Model View Component on Wikipedia MVC is a design patter independant of any of its implementations. The hard part will be no HttpServlet.

EJB injections vs only JSF managed beans

I don't know may be my question is completely meaningless, but I can't find any straight information about it.
I had my JSF + Tomcat application and it worked just fine. I want to implement Restful services and JAAS logic. In order to do that, I switched to TomEE++.
Switching to TomEE means that my server will now be more heavy and I'm afraid than it will require more cpu and ram resources than I have in my Amazon AWS micro instance.
The question is: Will the performance drop down if I switch from only JSF managed beans to JSF + EJB?
The sub-question is: what EJB injections can do, and JSF managed beans can not do? (JSF does not allow cyclic injections for example)

Will the performance drop down if I switch from only JSF managed beans to JSF + EJB?
Measuring is knowing. But generally, this concern makes no sense.
what EJB injections can do, and JSF managed beans can not do? (JSF does not allow cyclic injections for example)
Generally, they are not intented to be interchangeable. Each have their own clear responsibility. You use JSF bean management annotations to manage beans for front-end (JSF pages). You use EJB bean management annotations to manage beans for business services (BOs/DAOs). That's it.
To learn how JSF+EJB(+JPA) are supposed to work together head to the concrete examples and explanations shown in the following answers:
JSF Service Layer
JSF managed-bean EJB injection
Filter do not initialize EntityManager
JSF request scoped bean keeps recreating new Stateful session beans on every request?

Integrating JSF with Spring

I haven't implemented any code, I'm still working the overall architecture for a new application and this going to be the first time I use JSF+Spring.
I need to put web services in front of the Spring service beans (business logic tier) since these beans could be accessed by other applications besides the presentation tier. While defining the different layers or tiers for the application, I feel unsure about how to integrate JSF (the presentation tier) with Spring (the business tier in this application).
I'm considering to define some sort of common tier or service tier in order to provide the glue code for JSF and Spring, but before that I want to hear from others what have they done or if they have used other frameworks to help with the glue code for this scenario (I already checked Spring MVC/Spring Faces, but I'm not sure if that's what I need since I'm thinking of this application more like JSF-centric than Spring-centric, but maybe you could help me about considering another approach).
Thanks in advance.

The "glue" is the spring ELResolver, which you must configure in your faces-config.xml:
<application>
<!--
This is the JSF 1.2 ELResolver that delegates to the Spring root
WebApplicationContext resolving name references to Spring-defined
beans.
-->
<el-resolver>
org.springframework.web.jsf.el.SpringBeanFacesELResolver
</el-resolver>
</application>
This means that each #{bean.property} is handled by the resolving the bean in the spring context.

Spring MVC 3.0: how do I define an interceptor with annotations?

I am developing an app with Spring MVC (3.0).
I defined some controllers with annotations, how can I define an intereceptor with annotations too.

You can't. Hopefully we'll get that in 3.1. Until then, we have to use the HandlerInterceptor interface.