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
