org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Only one AsyncAnnotationBeanPostProcessor may exist within the context. Offending resource: URL [jar:file:/C:/Stuff/GwtDev/server/target/server-1.0.0.jar!/applicationContext.xml]
at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:70)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85)
at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:72)
at org.springframework.scheduling.config.AnnotationDrivenBeanDefinitionParser.parse(AnnotationDrivenBeanDefinitionParser.java:67)
at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:74)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1411)
at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1401)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:172)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.doRegisterBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:142)
at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:94)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:508)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:392)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:336)
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:304)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:181)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:217)
at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:188)
at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:125)
at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:94)
at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:129)
at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:614)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:515)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:443)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:325)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:107)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:800)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:444)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:791)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:294)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)
at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:550)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:140)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.server.Server.start(Server.java:387)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:354)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:760)
at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:636)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:923)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:706)
at com.google.gwt.dev.DevMode.main(DevMode.java:432)
Hi,
I have a Maven multi-module project that uses Spring Framework in the backend. Everything was working fine until I tried to migrate from GWT 2.7.0 to 2.8.1. Supposedly production mode works fine (never tried though so far), but in SuperDev mode I am getting initialization errors coming from Spring bootstrap. Some built-in Spring beans require them to be created only once, while attempts to create several of them are taken (see the log file attached for an example). Digging into this, I discovered that it has something to do with the fix for https://github.com/gwtproject/gwt/issues/9292, namely, in com.google.gwt.dev.shell.jetty.JettyLauncher.WebAppContextWithReload.WebAppClassLoaderExtension#getResources method. Before this fix, Jetty's classloader loaded resources strictly from the lib folder of the web application, and now it is so greedy that it loads them both from this said folder AND local Maven repo. This makes all my Maven submodules available twice in the classpath, each if them is treated individually.
To demonstrate the issue, I've created a simple application that resembles my original setup. This application is available here: https://github.com/AndrewAni/GwtDev. If these two scheduler-related bean definitions are commented out, the problem doesn't present itself.
It appears that if I go with Java-based Spring configuration, this wouldn't bother me anymore, since the suspicious classloader code affects only loading resources like XMLs. But I cannot shake the feeling that I am doing something wrong, and with the next GWT development iteration even Java classes would be loaded differently, breaking my stuff even more.
Am I missing something? Is my setup wrong somehow? Something about Maven layout maybe?
-- I have a Maven multi-module project that uses Spring Framework in the backend. Everything was working fine until I tried to migrate from GWT 2.7.0 to 2.8.1. Supposedly production mode works fine (never tried though so far), but in SuperDev mode I am getting initialization errors coming from Spring bootstrap. Some built-in Spring beans require them to be created only once, while attempts to create several of them are taken (see the log file attached for an example). Digging into this, I discovered that it has something to do with the fix for https://github.com/gwtproject/gwt/issues/9292, namely, in com.google.gwt.dev.shell.jetty.JettyLauncher.WebAppContextWithReload.WebAppClassLoaderExtension#getResources method. Before this fix, Jetty's classloader loaded resources strictly from the lib folder of the web application, and now it is so greedy that it loads them both from this said folder AND local Maven repo. This makes all my Maven submodules available twice in the classpath, each if them is treated individually.
To demonstrate the issue, I've created a simple application that resembles my original setup. This application is available here: https://github.com/AndrewAni/GwtDev. If these two scheduler-related bean definitions are commented out, the problem doesn't present itself.
It appears that if I go with Java-based Spring configuration, this wouldn't bother me anymore, since the suspicious classloader code affects only loading resources like XMLs. But I cannot shake the feeling that I am doing something wrong, and with the next GWT development iteration even Java classes would be loaded differently, breaking my stuff even more.
Am I missing something? Is my setup wrong somehow? Something about Maven layout maybe?
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment