If you want to do stuff like that, you can consider using custom
request cycles to do this. A request cycle is allways in the context
of the current thread, and they won't be reused.
Eelco
On 10/5/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
> 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
>
-------------------------------------------------------
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
