Hallo Bernd Danke für deine Antwort. Hat mir sehr geholfen. Ich bin noch James-Neuling und werde die Geschichte mit dem ContextProvider Anfang nächster Woche ausprobieren. Kann dir dann ja nochmal schreiben, wie es gelaufen ist ;-)
Schönes Wochenende Guido Franz -----Ursprüngliche Nachricht----- Von: Bernd Fondermann [mailto:[EMAIL PROTECTED] Gesendet: Fr 22.02.2008 12:28 An: James Users List Betreff: Re: Spring Integration On Fri, Feb 22, 2008 at 11:23 AM, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > Hi Guido, > > > On Fri, Feb 22, 2008 at 9:03 AM, Guido Franz <[EMAIL PROTECTED]> wrote: > > > > Hello > > > > I want to access a Spring application context from within Mailets. It's > easy to load a BeanFactory in a Mailet, but of course what I need is a single > application context. How can I handle this? > > I will have a closer look at this and follow up in a separate post. There are different approaches one could think of. 1. The canonical approach would be to follow the proven mailet injection path. That would require that you'd add a service "MyApplicationContextProvider" in assembly.xml which loads your ApplicationContext. Every mailet which needs access to it and which is subclassing GenericMailet can now call ServiceManager serviceManager = (ServiceManager) getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER); MyApplicationContextProvider datasources = (MyApplicationContextProvider) serviceManager.lookup(MyApplicationContextProvider.ROLE); This should work fine for any James release. 2. If you are running the spring-deployment you could wrap JamesMailetLoader with you own implementation. This implementation would behave just like JamesMailetLoader itself with the exception that everytime it loads a Mailet which is implementing BeanFactoryAware (or ApplicationContextAware) it injects the context into the Mailet. 3. You could even go further and not actually class-load the bean in the Loader but take the Mailet instance from an ApplicationContext itself - where it has already been properly wired with all the stuff it needs. (BTW, this solution would free the Mailet API from "the service lookup dilemma" discussed some time ago.) Which solution is the best in your case depends on your specific requirements. Bernd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
