• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Declarative Usage of Application Contexts

 
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Programmatic Usage of Application Contexts


ApplicationContext ctx= new ClassPathXmlApplicationContext("ch03/sample2/applicationContext.xml");

Once the bean factory or application context has been loaded, accessing beans in a basic fashion is as simple as using getBean() from the BeanFactory interface:

WeatherService ws = (WeatherService) ctx.getBean("weatherService");



Declarative Usage of Application Contexts as in (From: Professional Java Development with the Spring Framework)

Following IoC principles, as little application code as possible should know about the application context. We've mentioned that in spite of these principles, it is sometimes necessary for a small amount of glue code to know about the context. For a Spring-enabled J2EE web-app, it is possible to reduce or completely eliminate even this small amount of code by using Spring code to declaratively specify that an application context should be loaded at web-app startup.Spring's ContextLoader is the class that provides this capability.

At this time, containers known to work with the listener approach are Apache Tomcat 4.x+, Jetty 4.x+, Resin 2.1.8+, JBoss 3.0+, WebLogic 8.1 SP3+, and Orion 2.0.2+.
Containers known to not work with the listener approach, and which need the servlet approach, are BEA WebLogic up to 8.1 SP2, IBM WebSphere up to 5.x, and Oracle OC4J up to 9.0.x.

ContextLoaderListener is configured via a <listener> element in the standard J2EE web.xml file that is part of every web-app:

...
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-
class>
</listener>
...

Setting up ContextLoaderServlet instead is done via the <servlet> element in the web.xml file:

<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-
class>
<load-on-startup>1</load-on-startup>
</servlet>

Having done this declarative set-up, how can I access each individual bean?..i.e, doing something similar to getBean() method in programmatic approach.

Thank you,
Himalay
 
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You're supposed to use DI, not getBean. Try to use Spring Web MVC, you'll understand.
 
Himalay Majumdar
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for looking into it Kengkaj.

I have followed This Link.
I understood that we inject dependencies using Spring Configuration File, but finally we need to use getbean.

i.e,


Please correct me, if you can point me to an example, that would be great.

-Himalay
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No we don't need getBean, we should not use getBean.
ContextLoaderListener loads applicationContext, we can use DI.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My understanding is...
In case of a web application one can use the contextLoaderListener to load the spring configuration files. I would prefer this approach as spring does the job for me of creating the Application context. So in this example below...

<!--------- In Web.xml ----------->


ContextLoaderListener will look for the param contextConfigLocation and load the configuration files used in the value, in this case applicationContext1. So if later I want to change the path of my applicationContext1.xml I can do it here with out any re-compilation of code required. So internally appContext is created by spring for me.

One has to get hands on to this context to extract the beans of the applicationContext1.xml. One way I think this can be acheived is the use of ApplicationContextAware interface. An example of this usage is given here http://jerlinworld.wordpress.com/2009/07/20/making-your-spring-application-context-aware/. Once access to the context is available one can created a Factory class and using the getBean method on the context beans can be extraceted from applicationContext1.xml.

The usage of getBean is the required glue code between spring and your application. DI is just a concept of injecting resources in to bean so that the bean is avaialble ready to use out of the box.


 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nandeesh Satishkumar wrote:
The usage of getBean is the required glue code between spring and your application.


Not always true. In web applications, we should not use a single getBean. Using getBean will tie code to Spring Framework which should be avoid if possible.
If you use Spring Web MVC, you can specify Spring Web MVC controllers in *-servlet.xml and you can just use DI.
 
Himalay Majumdar
Ranch Hand
Posts: 324
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Consider this example from Professional Java Development with the Spring Framework



Do you mean I should not use getBean in the above case, can you demonstrate with an example?
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You should try to use Spring Web MVC as I suggested, you'll immediately understand.

Using getBean in test code is fine. But we should not use a single getBean in web applications.
ContextLoaderListener will instantiate an application context, and application context will pre-instantiate singleton beans and inject dependencies to beans defined in bean definition. There is no need to use getBean.
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that we don't have a use for getBean in a regular scenario like if we are using Spring MVC. But there are situations where getBean can come handy. I remember doing a EJB facade over the spring layer and the Spring MVC interacted with this EJB facade. Here the EJB facade has no managed access to the business layer and it had to use getBean (using ApplicationContextAware) to access the spring beans.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't know what you mean by EJB facade over Spring, could you please to explain more?
 
Ben Narendren
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Please take a look at this java world article on EJB facades over Spring Business services

http://www.javaworld.com/javaworld/jw-02-2005/jw-0214-springejb.html

This piece of code which you will find in the article is an example of where getBean() is called instead of DI

reply
    Bookmark Topic Watch Topic
  • New Topic