Re: spring context troubles
I'm getting this error on T 5.0.18. I'm not using 5.1, just 5.0.18, and I'm
pretty sure I haven't added anything else than the listing below:
filter
filter-nametapestry5/filter-name
filter-classorg.apache.tapestry5.spring.TapestrySpringFilter/filter-class
/filter
listener
listener-classorg.springframework.web.context.ContextLoaderListener/listener-class
/listener
context-param
param-namecontextConfigLocation/param-name
param-value/WEB-INF/applicationContext.xml/param-value
/context-param
I'm getting the following error on server startup:
2009-01-20 14:20:56.143:/moby:INFO: Initializing Spring root
WebApplicationContext
0[main] INFO org.springframework.web.context.ContextLoader - Root
WebApplicationContext: initialization started
42 [main] INFO
org.springframework.web.context.support.XmlWebApplicationContext -
Refreshing
org.springframework.web.context.support.xmlwebapplicationcont...@54ec115b:
display name [Root WebApplicationContext]; startup date [Tue Jan 20 14:20:56
CET 2009]; root of context hierarchy
86 [main] INFO
org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Loading XML
bean definitions from ServletContext resource
[/WEB-INF/applicationContext.xml]
351 [main] INFO
org.springframework.web.context.support.XmlWebApplicationContext - Bean
factory for application context
[org.springframework.web.context.support.xmlwebapplicationcont...@54ec115b]:
org.springframework.beans.factory.support.defaultlistablebeanfact...@5da5e65f
368 [main] INFO
org.springframework.beans.factory.support.DefaultListableBeanFactory -
Pre-instantiating singletons in
org.springframework.beans.factory.support.defaultlistablebeanfact...@5da5e65f:
defining beans [systemBO]; root of factory hierarchy
383 [main] INFO org.springframework.web.context.ContextLoader - Root
WebApplicationContext: initialization completed in 381 ms
2009-01-20 14:20:56.526::WARN: Failed startup of context
org.mortbay.jetty.webapp.webappcont...@7afaa550
{/moby,c:/dev/projects/Moby/web}
java.lang.IllegalStateException: Cannot initialize context because there is
already a root application context present - check whether you have multiple
ContextLoader* definitions in your web.xml!
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:182)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
On Sun, Jan 4, 2009 at 10:26 AM, Otho taa...@googlemail.com wrote:
As I said it is a nice to have feature. But I would reckon that in
overwhelming number of cases you would inject Spring beans into Tapestry
and
not Tapestry services into beans. So even if you would have to maintain
duplicate config for a small number of beans/services you are still better
off than being forced to use an older version of a Tapestry library or
require the Tapestry team to maintain 2 different versions.
If you use Tapestry and Spring together, it is probably the easiest way to
not define any Tapestry services which you need in a Spring config but
define them as spring beans from the ground on. Injection of beans into
Tapestry was seamless, so there is not really a NEED for the other way
round
IMO.You can write your commandline app with services as beans as usual and
use everything in Tapestry by @Inject. For me that is/was one of the
greatest points in Tapestry: Not being forced to use the Tapestry IOC
except
in cases where I really want to.
Summing up to 6cts. now :)
2009/1/3 Jonathan Barker jonathan.theit...@gmail.com
One use of injecting Tapestry services into Spring beans would be to take
advantage of Spring's transaction management. Or convenience features
for
setting up a Quartz scheduler. Or making Tapestry services available via
JMS
or SOAP or whatever. Spring does have a rich feature set.
Some services I write need to work within a T5 app, and also from
command-line support utilities. I tend to use just Spring for those
situations, but what if I want to include an optional (autowired)
reference
to a service only available in the web application? I wind up
duplicating
service configurations.
There have been a few cases where it would have been really handy to have
it
NOT MATTER where I set up the service.
I'm hoping there is some perfect solution that comes to Howard in a
moment
of inspiration. If not, supporting two libraries or at least
configuration
modes would seem to be necessary.
Another 2 cents.
Jonathan
-Original Message-
From: Otho [mailto:taa...@googlemail.com]
Sent: Saturday, January 03, 2009 10:59
To: Tapestry users
Subject: Re: spring context troubles
Hmm, the question is, how important it is to inject Tapestry IOC
services
into Spring beans compared to just being able to use the Spring beans
as
usual.
I would think the latter option is much less effort overall. If I want
Re: spring context troubles
As I said it is a nice to have feature. But I would reckon that in overwhelming number of cases you would inject Spring beans into Tapestry and not Tapestry services into beans. So even if you would have to maintain duplicate config for a small number of beans/services you are still better off than being forced to use an older version of a Tapestry library or require the Tapestry team to maintain 2 different versions. If you use Tapestry and Spring together, it is probably the easiest way to not define any Tapestry services which you need in a Spring config but define them as spring beans from the ground on. Injection of beans into Tapestry was seamless, so there is not really a NEED for the other way round IMO.You can write your commandline app with services as beans as usual and use everything in Tapestry by @Inject. For me that is/was one of the greatest points in Tapestry: Not being forced to use the Tapestry IOC except in cases where I really want to. Summing up to 6cts. now :) 2009/1/3 Jonathan Barker jonathan.theit...@gmail.com One use of injecting Tapestry services into Spring beans would be to take advantage of Spring's transaction management. Or convenience features for setting up a Quartz scheduler. Or making Tapestry services available via JMS or SOAP or whatever. Spring does have a rich feature set. Some services I write need to work within a T5 app, and also from command-line support utilities. I tend to use just Spring for those situations, but what if I want to include an optional (autowired) reference to a service only available in the web application? I wind up duplicating service configurations. There have been a few cases where it would have been really handy to have it NOT MATTER where I set up the service. I'm hoping there is some perfect solution that comes to Howard in a moment of inspiration. If not, supporting two libraries or at least configuration modes would seem to be necessary. Another 2 cents. Jonathan -Original Message- From: Otho [mailto:taa...@googlemail.com] Sent: Saturday, January 03, 2009 10:59 To: Tapestry users Subject: Re: spring context troubles Hmm, the question is, how important it is to inject Tapestry IOC services into Spring beans compared to just being able to use the Spring beans as usual. I would think the latter option is much less effort overall. If I want to inject something into a spring bean I have to define it as a bean and wire it up as usual. And I can use it in Tapestry just like a service. I can't really think of a scenario where it would really be needed to @Inject something into a spring bean. Sure it would be nice to have, but if I have to mix different versions of Tapestry libraries for that it is probably not worth it. Just my 2cts I guess it is mainly for the Web Flow integration, but if the price is, that 2009/1/2 Howard Lewis Ship hls...@gmail.com Seems like I'm faced with two evils: breaking compatibility on the one hand, maintaining two different sets of Spring integration on the other. On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla f...@alum.mit.edu wrote: That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved
Re: spring context troubles
Hmm, the question is, how important it is to inject Tapestry IOC services into Spring beans compared to just being able to use the Spring beans as usual. I would think the latter option is much less effort overall. If I want to inject something into a spring bean I have to define it as a bean and wire it up as usual. And I can use it in Tapestry just like a service. I can't really think of a scenario where it would really be needed to @Inject something into a spring bean. Sure it would be nice to have, but if I have to mix different versions of Tapestry libraries for that it is probably not worth it. Just my 2cts I guess it is mainly for the Web Flow integration, but if the price is, that 2009/1/2 Howard Lewis Ship hls...@gmail.com Seems like I'm faced with two evils: breaking compatibility on the one hand, maintaining two different sets of Spring integration on the other. On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla f...@alum.mit.edu wrote: That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory,
Re: spring context troubles
Oops, the last line survived the editing. It should have been deleted.
RE: spring context troubles
One use of injecting Tapestry services into Spring beans would be to take advantage of Spring's transaction management. Or convenience features for setting up a Quartz scheduler. Or making Tapestry services available via JMS or SOAP or whatever. Spring does have a rich feature set. Some services I write need to work within a T5 app, and also from command-line support utilities. I tend to use just Spring for those situations, but what if I want to include an optional (autowired) reference to a service only available in the web application? I wind up duplicating service configurations. There have been a few cases where it would have been really handy to have it NOT MATTER where I set up the service. I'm hoping there is some perfect solution that comes to Howard in a moment of inspiration. If not, supporting two libraries or at least configuration modes would seem to be necessary. Another 2 cents. Jonathan -Original Message- From: Otho [mailto:taa...@googlemail.com] Sent: Saturday, January 03, 2009 10:59 To: Tapestry users Subject: Re: spring context troubles Hmm, the question is, how important it is to inject Tapestry IOC services into Spring beans compared to just being able to use the Spring beans as usual. I would think the latter option is much less effort overall. If I want to inject something into a spring bean I have to define it as a bean and wire it up as usual. And I can use it in Tapestry just like a service. I can't really think of a scenario where it would really be needed to @Inject something into a spring bean. Sure it would be nice to have, but if I have to mix different versions of Tapestry libraries for that it is probably not worth it. Just my 2cts I guess it is mainly for the Web Flow integration, but if the price is, that 2009/1/2 Howard Lewis Ship hls...@gmail.com Seems like I'm faced with two evils: breaking compatibility on the one hand, maintaining two different sets of Spring integration on the other. On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla f...@alum.mit.edu wrote: That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache
Re: spring context troubles
I hope you're starting to see, this is a bigger than backward compatibility. This is totally scrapping a huge piece of functionality. Exposing tapestry services as beans it totally new and different from exposing my spring beans within tapestry. They serve totally different purposes, needs and requirements. Just because you have not used it, doesn't mean that it's not pivotal to most people's architectures now... really. If you turn that off, I would have to totally re-architect my apps (many apps) .. . Howard Lewis Ship wrote: Seems like I'm faced with two evils: breaking compatibility on the one hand, maintaining two different sets of Spring integration on the other. On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla f...@alum.mit.edu wrote: That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator,
Re: spring context troubles
Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator, PageElementFactory, PageLoader, PageMarkupRenderer, PagePool, PageRenderQueue, PageRenderRequestHandler, PageResponseRenderer, PageTemplateLocator, PartialMarkupRenderer, PersistentFieldManager, PersistentLocale, PipelineBuilder, PropBindingFactory, PropertyAccess, PropertyConduitSource, PropertyShadowBuilder, RegistryStartup, RenderSupport, Request, RequestExceptionHandler, RequestGlobals, RequestHandler, RequestLogFilter, RequestPageCache, RequestPathOptimizer, RequestSecurityManager, ResourceCache, ResourceDigestGenerator, ResourceStreamer, Response, ResponseRenderer, ServiceLifecycleSource, ServletApplicationInitializer, SessionApplicationStatePersistenceStrategy, StrategyBuilder, SymbolSource, TemplateParser, ThreadLocale, TranslateBindingFactory, TranslatorSource, TypeCoercer, URLEncoder, UpdateListenerHub, ValidateBindingFactory, ValidationConstraintGenerator, ValidationMessagesSource, ValueEncoderSource. at org.apache.tapestry5.ioc.internal.RegistryImpl.locateModuleForService(RegistryImpl.java:321) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:288) at
Re: spring context troubles
That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator, PageElementFactory, PageLoader, PageMarkupRenderer, PagePool, PageRenderQueue, PageRenderRequestHandler, PageResponseRenderer, PageTemplateLocator, PartialMarkupRenderer, PersistentFieldManager, PersistentLocale, PipelineBuilder, PropBindingFactory, PropertyAccess, PropertyConduitSource, PropertyShadowBuilder, RegistryStartup, RenderSupport, Request, RequestExceptionHandler, RequestGlobals, RequestHandler, RequestLogFilter, RequestPageCache, RequestPathOptimizer, RequestSecurityManager, ResourceCache, ResourceDigestGenerator, ResourceStreamer, Response, ResponseRenderer, ServiceLifecycleSource, ServletApplicationInitializer, SessionApplicationStatePersistenceStrategy, StrategyBuilder, SymbolSource, TemplateParser, ThreadLocale, TranslateBindingFactory, TranslatorSource,
Re: spring context troubles
Seems like I'm faced with two evils: breaking compatibility on the one hand, maintaining two different sets of Spring integration on the other. On Fri, Jan 2, 2009 at 10:50 AM, Fernando Padilla f...@alum.mit.edu wrote: That's alright to keep them separate, but I'm just worried that the 5.0.18 will stop working at some point.. That is why I proposed that you should really have two different pacakges.. one for each direction of integration, and people can explicitly choose which one to use. It just seems kind of brittle saying never to upgrade your spring package, that strategy will fail at some point, and could just confuse people in the interim... Howard Lewis Ship wrote: Actually, I'm liking the idea that compatibility on this comes from continuing to use the old version of tapestry-spring. I haven't found a way to do both: allow injection of Tapestry services into Spring beans and expose Spring beans as Tapestry services. The lifecycles of the two containers do not mesh easily. On Thu, Jan 1, 2009 at 3:23 PM, Fernando Padilla f...@alum.mit.edu wrote: nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator, PageElementFactory, PageLoader, PageMarkupRenderer, PagePool, PageRenderQueue, PageRenderRequestHandler, PageResponseRenderer, PageTemplateLocator, PartialMarkupRenderer, PersistentFieldManager, PersistentLocale, PipelineBuilder, PropBindingFactory, PropertyAccess, PropertyConduitSource, PropertyShadowBuilder, RegistryStartup, RenderSupport, Request, RequestExceptionHandler, RequestGlobals, RequestHandler, RequestLogFilter, RequestPageCache, RequestPathOptimizer,
Re: spring context troubles
nice work around. but I want to make sure, this will be a temporary work around until you get the latest spring module working as you desire, with two-way integration?? Howard Lewis Ship wrote: I think the best option for you is to use Tapestry 5.1, but revert tapestry-spring to 5.0.18. This allows you to benefit from the improvements to tapestry-core without having any compatibility problems with the changes to tapestry-spring. I'm adding documentation to the web site to explain this. On Mon, Dec 29, 2008 at 4:20 PM, Fernando Padilla f...@alum.mit.edu wrote: I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator, PageElementFactory, PageLoader, PageMarkupRenderer, PagePool, PageRenderQueue, PageRenderRequestHandler, PageResponseRenderer, PageTemplateLocator, PartialMarkupRenderer, PersistentFieldManager, PersistentLocale, PipelineBuilder, PropBindingFactory, PropertyAccess, PropertyConduitSource, PropertyShadowBuilder, RegistryStartup, RenderSupport, Request, RequestExceptionHandler, RequestGlobals, RequestHandler, RequestLogFilter, RequestPageCache, RequestPathOptimizer, RequestSecurityManager, ResourceCache, ResourceDigestGenerator, ResourceStreamer, Response, ResponseRenderer, ServiceLifecycleSource, ServletApplicationInitializer, SessionApplicationStatePersistenceStrategy, StrategyBuilder, SymbolSource, TemplateParser, ThreadLocale, TranslateBindingFactory, TranslatorSource, TypeCoercer, URLEncoder, UpdateListenerHub, ValidateBindingFactory, ValidationConstraintGenerator, ValidationMessagesSource, ValueEncoderSource. at org.apache.tapestry5.ioc.internal.RegistryImpl.locateModuleForService(RegistryImpl.java:321) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:288) at org.apache.tapestry5.ioc.internal.ObjectLocatorImpl.getService(ObjectLocatorImpl.java:39) at org.apache.tapestry5.internal.services.ServiceAnnotationObjectProvider.provide(ServiceAnnotationObjectProvider.java:35) at org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl$1.invoke(MasterObjectProviderImpl.java:50) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at
Re: spring context troubles
This is a change in behavior from Tapestry 5.0; it was necessary in order to coordinate Spring and Tapestry IoC. It is necessary to let Tapestry initialize Spring and use Tapestry-specific subclasses of XmlWebApplicationContext and DefaultListableBeanFactory, to hook in the logic that allows Spring beans to use @Inject and @InjectService. You should be fine if you just remove the ContextLoaderListener from your web.xml. On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla f...@citizensportsinc.com wrote: I just tried to run with the latest tapestry-trunk, and I get this really nasty exception :( :( I initialize my own spring context with a ContextLoaderListener, because I need spring outside of tapestry. Why is tapestry attempting to create a context? 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Operations trace: 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 1] Realizing service ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 2] Invoking ObjectCreator for Spring ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating Spring ApplicationContext via ContextLoader 2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext - Construction of service ApplicationContext failed: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! org.apache.tapestry5.ioc.internal.OperationException: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.internal.spring.SpringModuleDef$1$2.createObject(SpringModuleDef.java:76) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.SingletonServiceLifecycle.createService(SingletonServiceLifecycle.java:29) at org.apache.tapestry5.ioc.internal.LifecycleWrappedServiceCreator.createObject(LifecycleWrappedServiceCreator.java:52) at org.apache.tapestry5.ioc.internal.InterceptorStackBuilder.createObject(InterceptorStackBuilder.java:56) at org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(RecursiveServiceCreationCheckWrapper.java:60) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:65) at $ConfigurableWebApplicationContext_11e850a8929.delegate($ConfigurableWebApplicationContext_11e850a8929.java) at $ConfigurableWebApplicationContext_11e850a8929.getBeanDefinitionCount($ConfigurableWebApplicationContext_11e850a8929.java) at
Re: spring context troubles
Also, code that expects the ContextLoaderListener will STILL work, because Tapestry uses the same code, ContextLoader, that CLL does ... just a little differently. On Mon, Dec 29, 2008 at 3:40 PM, Fernando Padilla f...@alum.mit.edu wrote: I just tried to run with the latest tapestry-trunk, and I get this really nasty exception :( :( I initialize my own spring context with a ContextLoaderListener, because I need spring outside of tapestry. Why is tapestry attempting to create a context? 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Operations trace: 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 1] Realizing service ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 2] Invoking ObjectCreator for Spring ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating Spring ApplicationContext via ContextLoader 2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext - Construction of service ApplicationContext failed: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! org.apache.tapestry5.ioc.internal.OperationException: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.internal.spring.SpringModuleDef$1$2.createObject(SpringModuleDef.java:76) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.SingletonServiceLifecycle.createService(SingletonServiceLifecycle.java:29) at org.apache.tapestry5.ioc.internal.LifecycleWrappedServiceCreator.createObject(LifecycleWrappedServiceCreator.java:52) at org.apache.tapestry5.ioc.internal.InterceptorStackBuilder.createObject(InterceptorStackBuilder.java:56) at org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(RecursiveServiceCreationCheckWrapper.java:60) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:65) at $ConfigurableWebApplicationContext_11e850a8929.delegate($ConfigurableWebApplicationContext_11e850a8929.java) at $ConfigurableWebApplicationContext_11e850a8929.getBeanDefinitionCount($ConfigurableWebApplicationContext_11e850a8929.java) at org.apache.tapestry5.internal.spring.SpringModule$1.initializeApplication(SpringModule.java:45) at $ApplicationInitializer_11e850a892a.initializeApplication($ApplicationInitializer_11e850a892a.java) at org.apache.tapestry5.services.TapestryModule$37.initializeApplication(TapestryModule.java:1912) at
Re: spring context troubles
I just tried it, and it won't work like that :(
Like I said, I use spring outside of tapestry. So I need a valid
working spring context before the first request ever gets to tapestry
filter..
Here is my exception when I comment out the normal ContextLoaderListener..
[Console output redirected to
file:/local/fern/work/social-app-repository/trunk/fanwars/site/../../log.txt]
2008-12-29 15:58:26,140 [main] ERROR org.mortbay.log - failed OpenDS
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
2008-12-29 15:58:26,142 [main] ERROR org.mortbay.log - Failed startup of
context org.mortbay.jetty.webapp.webappcont...@1961581{/,src/main/webapp}
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
Howard Lewis Ship wrote:
This is a change in behavior from Tapestry 5.0; it was necessary in
order to coordinate Spring and Tapestry IoC. It is necessary to let
Tapestry initialize Spring and use Tapestry-specific subclasses of
XmlWebApplicationContext and DefaultListableBeanFactory, to hook in
the logic that allows Spring beans to use @Inject and @InjectService.
You should be fine if you just remove the ContextLoaderListener from
your web.xml.
On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla
f...@citizensportsinc.com wrote:
I just tried to run with the latest tapestry-trunk, and I get this really
nasty exception :( :(
I initialize my own spring context with a ContextLoaderListener, because I
need spring outside of tapestry. Why is tapestry attempting to create a
context?
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Cannot initialize context because there is already a root application
context present - check whether you have multiple ContextLoader* definitions
in your web.xml!
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Operations trace:
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [
1] Realizing service ApplicationContext
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [
2] Invoking ObjectCreator for Spring ApplicationContext
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [
3] Creating Spring ApplicationContext via ContextLoader
2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext -
Construction of service ApplicationContext failed: Cannot initialize context
because there is already a root application context present - check whether
you have multiple ContextLoader* definitions in your web.xml!
org.apache.tapestry5.ioc.internal.OperationException: Cannot initialize
context because there is already a root application context present - check
whether you have multiple ContextLoader* definitions in your web.xml!
at
org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:74)
at
Re: spring context troubles
We need to figure out the order that the filters are initialized, so
that the Tapestry filter can be initialized first. I think just
listing it first in the web.xml may do the trick.
On Mon, Dec 29, 2008 at 4:00 PM, Fernando Padilla f...@alum.mit.edu wrote:
I just tried it, and it won't work like that :(
Like I said, I use spring outside of tapestry. So I need a valid working
spring context before the first request ever gets to tapestry filter..
Here is my exception when I comment out the normal ContextLoaderListener..
[Console output redirected to
file:/local/fern/work/social-app-repository/trunk/fanwars/site/../../log.txt]
2008-12-29 15:58:26,140 [main] ERROR org.mortbay.log - failed OpenDS
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at
com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
2008-12-29 15:58:26,142 [main] ERROR org.mortbay.log - Failed startup of
context org.mortbay.jetty.webapp.webappcont...@1961581{/,src/main/webapp}
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at
com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
Howard Lewis Ship wrote:
This is a change in behavior from Tapestry 5.0; it was necessary in
order to coordinate Spring and Tapestry IoC. It is necessary to let
Tapestry initialize Spring and use Tapestry-specific subclasses of
XmlWebApplicationContext and DefaultListableBeanFactory, to hook in
the logic that allows Spring beans to use @Inject and @InjectService.
You should be fine if you just remove the ContextLoaderListener from
your web.xml.
On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla
f...@citizensportsinc.com wrote:
I just tried to run with the latest tapestry-trunk, and I get this really
nasty exception :( :(
I initialize my own spring context with a ContextLoaderListener, because
I
need spring outside of tapestry. Why is tapestry attempting to create a
context?
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Cannot initialize context because there is already a root application
context present - check whether you have multiple ContextLoader*
definitions
in your web.xml!
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Operations trace:
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry -
[
1] Realizing service ApplicationContext
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry -
[
2] Invoking ObjectCreator for Spring ApplicationContext
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry -
[
3] Creating Spring ApplicationContext via ContextLoader
2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext -
Construction of service ApplicationContext failed: Cannot initialize
context
because there is already a root application context present - check
whether
you have multiple ContextLoader* definitions in your web.xml!
Re: spring context troubles
I was expecting you would be working on this feature, but I really don't want to change the way I instantiate my spring context.. Could you hook in something that allows me to turn off this new feature and have it be perfectly backward compatible? Or if it finds an already instantiated Spring Context, use that without any of the fanciness you're planning? Howard Lewis Ship wrote: This is a change in behavior from Tapestry 5.0; it was necessary in order to coordinate Spring and Tapestry IoC. It is necessary to let Tapestry initialize Spring and use Tapestry-specific subclasses of XmlWebApplicationContext and DefaultListableBeanFactory, to hook in the logic that allows Spring beans to use @Inject and @InjectService. You should be fine if you just remove the ContextLoaderListener from your web.xml. On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla f...@citizensportsinc.com wrote: I just tried to run with the latest tapestry-trunk, and I get this really nasty exception :( :( I initialize my own spring context with a ContextLoaderListener, because I need spring outside of tapestry. Why is tapestry attempting to create a context? 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Operations trace: 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 1] Realizing service ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 2] Invoking ObjectCreator for Spring ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating Spring ApplicationContext via ContextLoader 2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext - Construction of service ApplicationContext failed: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! org.apache.tapestry5.ioc.internal.OperationException: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.internal.spring.SpringModuleDef$1$2.createObject(SpringModuleDef.java:76) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.SingletonServiceLifecycle.createService(SingletonServiceLifecycle.java:29) at org.apache.tapestry5.ioc.internal.LifecycleWrappedServiceCreator.createObject(LifecycleWrappedServiceCreator.java:52) at org.apache.tapestry5.ioc.internal.InterceptorStackBuilder.createObject(InterceptorStackBuilder.java:56) at org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(RecursiveServiceCreationCheckWrapper.java:60) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.services.JustInTimeObjectCreator.createObject(JustInTimeObjectCreator.java:65)
Re: spring context troubles
On Mon, Dec 29, 2008 at 4:09 PM, Fernando Padilla f...@alum.mit.edu wrote: I was expecting you would be working on this feature, but I really don't want to change the way I instantiate my spring context.. Could you hook in something that allows me to turn off this new feature and have it be perfectly backward compatible? Please add an issue and I'll work on it. You'll lose the ability to inject Tapestry services into Spring beans. Or if it finds an already instantiated Spring Context, use that without any of the fanciness you're planning? That would confuse people more, as they would get mysterious errors that they couldn't inject Tapestry into Spring or vice-versa, because of the incomplete initialization. I no longer using warnings for this kind of thing, as they are universally ignored (even by people having problems in this specific area), therefore an exception or explicit configuration is the way to go. Howard Lewis Ship wrote: This is a change in behavior from Tapestry 5.0; it was necessary in order to coordinate Spring and Tapestry IoC. It is necessary to let Tapestry initialize Spring and use Tapestry-specific subclasses of XmlWebApplicationContext and DefaultListableBeanFactory, to hook in the logic that allows Spring beans to use @Inject and @InjectService. You should be fine if you just remove the ContextLoaderListener from your web.xml. On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla f...@citizensportsinc.com wrote: I just tried to run with the latest tapestry-trunk, and I get this really nasty exception :( :( I initialize my own spring context with a ContextLoaderListener, because I need spring outside of tapestry. Why is tapestry attempting to create a context? 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! 2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry - Operations trace: 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 1] Realizing service ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 2] Invoking ObjectCreator for Spring ApplicationContext 2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry - [ 3] Creating Spring ApplicationContext via ContextLoader 2008-12-29 15:18:27,365 [main] ERROR Spring.ApplicationContext - Construction of service ApplicationContext failed: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! org.apache.tapestry5.ioc.internal.OperationException: Cannot initialize context because there is already a root application context present - check whether you have multiple ContextLoader* definitions in your web.xml! at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:74) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.internal.spring.SpringModuleDef$1$2.createObject(SpringModuleDef.java:76) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:96) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:68) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:871) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator.createObject(OperationTrackingObjectCreator.java:49) at org.apache.tapestry5.ioc.internal.SingletonServiceLifecycle.createService(SingletonServiceLifecycle.java:29) at org.apache.tapestry5.ioc.internal.LifecycleWrappedServiceCreator.createObject(LifecycleWrappedServiceCreator.java:52) at org.apache.tapestry5.ioc.internal.InterceptorStackBuilder.createObject(InterceptorStackBuilder.java:56) at org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject(RecursiveServiceCreationCheckWrapper.java:60) at org.apache.tapestry5.ioc.internal.OperationTrackingObjectCreator$1.invoke(OperationTrackingObjectCreator.java:45) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36)
Re: spring context troubles
but this seems really really flaky, undeterministic and appserver
dependent..
If you really want to create a SpringContext/TapestryIoC love child :)
could you create a new ContextLoaderListener to replace spring's that
does what you want?
So that both the SpringContext and TapestryIoC are loaded properly
before anything else (servlets, filters, etc)??
Or again, can you have the feature you're adding be backward compatible
and not require changes to the way people load up their spring
context... (though i know the new feature would be turned off at that
point).
Howard Lewis Ship wrote:
We need to figure out the order that the filters are initialized, so
that the Tapestry filter can be initialized first. I think just
listing it first in the web.xml may do the trick.
On Mon, Dec 29, 2008 at 4:00 PM, Fernando Padilla f...@alum.mit.edu wrote:
I just tried it, and it won't work like that :(
Like I said, I use spring outside of tapestry. So I need a valid working
spring context before the first request ever gets to tapestry filter..
Here is my exception when I comment out the normal ContextLoaderListener..
[Console output redirected to
file:/local/fern/work/social-app-repository/trunk/fanwars/site/../../log.txt]
2008-12-29 15:58:26,140 [main] ERROR org.mortbay.log - failed OpenDS
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at
com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
2008-12-29 15:58:26,142 [main] ERROR org.mortbay.log - Failed startup of
context org.mortbay.jetty.webapp.webappcont...@1961581{/,src/main/webapp}
java.lang.NullPointerException
at com.protrade.common.spring.OpenDSFilter.init(OpenDSFilter.java:28)
at
com.protrade.common.web.ProtradeFilter.init(ProtradeFilter.java:37)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1216)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:509)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:447)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
at runjettyrun.Bootstrap.main(Bootstrap.java:76)
Howard Lewis Ship wrote:
This is a change in behavior from Tapestry 5.0; it was necessary in
order to coordinate Spring and Tapestry IoC. It is necessary to let
Tapestry initialize Spring and use Tapestry-specific subclasses of
XmlWebApplicationContext and DefaultListableBeanFactory, to hook in
the logic that allows Spring beans to use @Inject and @InjectService.
You should be fine if you just remove the ContextLoaderListener from
your web.xml.
On Mon, Dec 29, 2008 at 3:22 PM, Fernando Padilla
f...@citizensportsinc.com wrote:
I just tried to run with the latest tapestry-trunk, and I get this really
nasty exception :( :(
I initialize my own spring context with a ContextLoaderListener, because
I
need spring outside of tapestry. Why is tapestry attempting to create a
context?
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Cannot initialize context because there is already a root application
context present - check whether you have multiple ContextLoader*
definitions
in your web.xml!
2008-12-29 15:18:27,363 [main] ERROR org.apache.tapestry5.ioc.Registry -
Operations trace:
2008-12-29 15:18:27,364 [main] ERROR org.apache.tapestry5.ioc.Registry -
[
1] Realizing service ApplicationContext
2008-12-29 15:18:27,364 [main] ERROR
Re: spring context troubles
I'm sorry that I'm hammering on this code, while it's still probably a work in progress.. (always available through im) but I commented out the spring ContextLoaderListener, moved the filter up to be first, and this seems to initialize properly at least for Jetty (within eclipse). The next issue, it looks like it did not register the spring beans in the TapestryIoC.. so now I'm getting exceptions saying that it can't find particular beans: Caused by: java.lang.RuntimeException: Service id 'common-conf-properties' is not defined by any module. Defined services: ActionRenderResponseGenerator, AjaxComponentEventRequestHandler, AjaxComponentEventResultProcessor, AjaxPartialResponseRenderer, Alias, AliasOverrides, AppSubscriptionHandler, ApplicationContext, ApplicationDefaults, ApplicationGlobals, ApplicationInitializer, ApplicationStateManager, ApplicationStatePersistenceStrategySource, AspectDecorator, AssetBindingFactory, AssetObjectProvider, AssetSource, BaseURLSource, BeanBlockOverrideSource, BeanBlockSource, BeanModelSource, BindingSource, ChainBuilder, ClassNameLocator, ClasspathAssetAliasManager, ClasspathAssetFactory, ClasspathURLConverter, ClientPersistentFieldStorage, ClientPersistentFieldStrategy, ComponentClassCache, ComponentClassFactory, ComponentClassResolver, ComponentClassTransformWorker, ComponentClassTransformer, ComponentClassesInvalidationEventHub, ComponentDefaultProvider, ComponentEventRequestHandler, ComponentEventResultProcessor, ComponentInstanceResultProcessor, ComponentInstantiatorSource, ComponentInvocationMap, ComponentMessagesInvalidationEventHub, ComponentMessagesSource, ComponentPageElementResourcesSource, ComponentSource, ComponentTemplateSource, ComponentTemplatesInvalidationEventHub, Context, ContextAssetFactory, ContextPathEncoder, ContextValueEncoder, CookieSink, CookieSource, Cookies, CtClassSource, DataTypeAnalyzer, DefaultDataTypeAnalyzer, DefaultFileItemFactory, DefaultImplementationBuilder, EndOfRequestListenerHub, Environment, EnvironmentalShadowBuilder, ExceptionAnalyzer, ExceptionTracker, FacebookAuthFilterImpl, FactoryDefaults, FbForceModeFilter, FieldTranslatorSource, FieldValidationSupport, FieldValidatorDefaultSource, FieldValidatorSource, FormSupport, HiddenFieldLocationRules, HttpServletRequest, HttpServletRequestHandler, IgnoredPathsFilter, InjectionProvider, InternalRequestGlobals, LinkCreationHub, LinkFactory, LocalizationSetter, LocationRenderer, LoggingDecorator, MarkupRenderer, MarkupWriterFactory, MasterDispatcher, MasterObjectProvider, MessageBindingFactory, MetaDataLocator, MultipartDecoder, NullFieldStrategyBindingFactory, NullFieldStrategySource, ObjectRenderer, OsForceTypeFilter, PageActivationContextCollector, PageContentTypeAnalyzer, PageDocumentGenerator, PageElementFactory, PageLoader, PageMarkupRenderer, PagePool, PageRenderQueue, PageRenderRequestHandler, PageResponseRenderer, PageTemplateLocator, PartialMarkupRenderer, PersistentFieldManager, PersistentLocale, PipelineBuilder, PropBindingFactory, PropertyAccess, PropertyConduitSource, PropertyShadowBuilder, RegistryStartup, RenderSupport, Request, RequestExceptionHandler, RequestGlobals, RequestHandler, RequestLogFilter, RequestPageCache, RequestPathOptimizer, RequestSecurityManager, ResourceCache, ResourceDigestGenerator, ResourceStreamer, Response, ResponseRenderer, ServiceLifecycleSource, ServletApplicationInitializer, SessionApplicationStatePersistenceStrategy, StrategyBuilder, SymbolSource, TemplateParser, ThreadLocale, TranslateBindingFactory, TranslatorSource, TypeCoercer, URLEncoder, UpdateListenerHub, ValidateBindingFactory, ValidationConstraintGenerator, ValidationMessagesSource, ValueEncoderSource. at org.apache.tapestry5.ioc.internal.RegistryImpl.locateModuleForService(RegistryImpl.java:321) at org.apache.tapestry5.ioc.internal.RegistryImpl.getService(RegistryImpl.java:288) at org.apache.tapestry5.ioc.internal.ObjectLocatorImpl.getService(ObjectLocatorImpl.java:39) at org.apache.tapestry5.internal.services.ServiceAnnotationObjectProvider.provide(ServiceAnnotationObjectProvider.java:35) at org.apache.tapestry5.ioc.internal.services.MasterObjectProviderImpl$1.invoke(MasterObjectProviderImpl.java:50) at org.apache.tapestry5.ioc.internal.InvokableToRunnable.run(InvokableToRunnable.java:36) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.run(OperationTrackerImpl.java:52) Howard Lewis Ship wrote: We need to figure out the order that the filters are initialized, so that the Tapestry filter can be initialized first. I think just listing it first in the web.xml may do the trick. On Mon, Dec 29, 2008 at 4:00 PM, Fernando Padilla f...@alum.mit.edu wrote: I just tried it, and it won't work like that :( Like I said, I use spring outside of tapestry. So I need a valid working spring context before the first request ever gets to tapestry filter.. Here is my exception when I comment out
