I like to add a filter that binds the app context to the current
thread. Then you can make a static helper class to access all the
beans you like.
On 10/4/05, Eduardo Rocha <[EMAIL PROTECTED]> wrote:
> How do you test your pages with static references to Spring beans? Do you
> use stubs or do you use the actual bean (service) implementation?
>
> 2005/10/4, Dariusz Wojtas <[EMAIL PROTECTED]>:
> > Thanks for this message Andrew.
> > This should be really useful to many people.
> >
> > The project I am involved in, uses the #2 approach and it perfectly
> > fits our needs.
> > The system is divided into some services, each contains it's own
> > Spring bean definition.
> > Some of these services depend on each other, and they all depend on a
> > database resource.
> > But! On the XML level you do not need to manage any relations between
> > these files.
> > Dependencies between services are injected by Spring after definitions
> > from all files are read - referenced from a single
> > 'beanRefFactory.xml' file.
> > This is enough for Spring to load/resolve/autowire dependencies
> > between various services.
> >
> > The top level application code uses - indirectly -
> > SingletonBeanFactoryLocator which just provides references to all used
> > services.
> > Also, as the work is divided into teams, people need to work with much
> > smaller, simpler.
> >
> > For convenience we have just created ourselves a bean with static
> > methods, example
> > [i don't have access to it right now, this is just to show the idea]:
> >
> > public class SpringConfig {
> >
> > public static BeanFactory getBeanFactory() {
> > //.. here you need to put 3-5 lines of code explained in
> > SingletonBeanFactoryLocator
> > }
> >
> > public static IService1 getService1() {
> > return (IService1)
> getBeanFactory().getBean("service1");
> > }
> >
> > public static IService2 getService2() {
> > return (IService2)
> getBeanFactory().getBean("service2");
> > }
> >
> > }
> >
> > If I need a service anywhere, I just call it this way:
> > SpringConfig.getService1().doSomething(...);
> >
> > No need to keep any extra references anywhere in the web specific part.
> > Giving somewhere in wiki just an example of this could simplify
> > people's life a lot.
> >
> > Darek
> >
> > On 04/10/05, Andrew Berman <[EMAIL PROTECTED]> wrote:
> > > I've successfully used two different methods for
> > > getting the ApplicationContext which does not require
> > > the weird wiring of beans for the WicketServlet and
> > > requires no special Application classes.
> > >
> > > 1. See
> > > http://forum.springframework.org/viewtopic.php?t=3224
> > > Scroll to the bottom. He extends
> > > ContextLoaderListener and provides a static reference
> > > to the AppContext.
> > >
> > > 2. Use SingletonBeanFactoryLocator or
> > > ContextSingletonBeanFactoryLocator. The API docs for
> > > SingletonBeanFactoryLocator explain exactly how to do
> > > it.
> > >
> > > Because I currently still have code using Spring MVC,
> > > I decided to use #1, so my old code can still access
> > > the AppContext as well as my new Wicket code. The
> > > second method will load up a second instance of the
> > > AppContext if you are already loading up one anywhere
> > > in the app. Anyone have any thoughts on these two
> > > methods? I think the advantages are that you can
> > > setup Wicket without any fancy jazz in the appContext.
> > >
> > > --Andrew
> >
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
