Re: LocaleProvder not unique
thank you, will look at it and report on dev On Wed, Mar 15, 2017, at 09:23, Lukasz Lenart wrote: > Christian > > Change is here https://github.com/apache/struts/pull/122 > > 2017-03-14 10:16 GMT+01:00 Lukasz Lenart : > > Feel free to register an issue with your case > > > > 2017-03-14 10:13 GMT+01:00 Christian Grobmeier : > >> Yes, actually I think you are right: LocaleProvider and TextProvider > >> have both the same issue. It's just popping up for me with > >> LocaleProvider first, but TextProvider will surely follow. > >> > >> I try to read more dev list again, so feel free to ping me whenever you > >> want me to test/help > >> > >> On Tue, Mar 14, 2017, at 06:57, Lukasz Lenart wrote: > >>> https://issues.apache.org/jira/browse/WW-4756 > >>> > >>> I know that this is for TextProvider but the same approach I can use > >>> for LocaleProvider > >>> > >>> 2017-03-14 6:53 GMT+01:00 Lukasz Lenart : > >>> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier : > >>> >> OK, using component scan i had success with using DefaultLocaleProvider > >>> >> as default in my applicationContext.xml: > >>> >> >>> >> class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> > >>> >> > >>> >> (mind the primary) > >>> >> > >>> >> So far it makes halfway sense to me. A few tests fail still because > >>> >> they > >>> >> access getText and do no receive a context. Digging into this > >>> > > >>> > Hmm... I think I see your point and this is somehow aligned with what > >>> > I want to do with TextProvider layer. I mean, there is already a > >>> > TextProviderFactory that is used to create custom TextProviders so I > >>> > think I will used instead of TextProvider to inject as a dependency. > >>> > This will allow to have TextProvider implemented by the ActionSupport > >>> > and use TextProviderFactory as a dependency and there be type > >>> > conflicts. > >>> > > >>> > Here is a first step to do so > >>> > https://github.com/apache/struts/pull/121 > >>> > > >>> > I will start another PR soon to replace TextProvider with > >>> > TextProviderFactory, if you could test this approach it would be cool > >>> > :) > >>> > > >>> > > >>> > Regards > >>> > -- > >>> > Łukasz > >>> > + 48 606 323 122 http://www.lenart.org.pl/ > >>> > >>> - > >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >>> For additional commands, e-mail: user-h...@struts.apache.org > >>> > >> > >> - > >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > >> For additional commands, e-mail: user-h...@struts.apache.org > >> > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Christian Change is here https://github.com/apache/struts/pull/122 2017-03-14 10:16 GMT+01:00 Lukasz Lenart : > Feel free to register an issue with your case > > 2017-03-14 10:13 GMT+01:00 Christian Grobmeier : >> Yes, actually I think you are right: LocaleProvider and TextProvider >> have both the same issue. It's just popping up for me with >> LocaleProvider first, but TextProvider will surely follow. >> >> I try to read more dev list again, so feel free to ping me whenever you >> want me to test/help >> >> On Tue, Mar 14, 2017, at 06:57, Lukasz Lenart wrote: >>> https://issues.apache.org/jira/browse/WW-4756 >>> >>> I know that this is for TextProvider but the same approach I can use >>> for LocaleProvider >>> >>> 2017-03-14 6:53 GMT+01:00 Lukasz Lenart : >>> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier : >>> >> OK, using component scan i had success with using DefaultLocaleProvider >>> >> as default in my applicationContext.xml: >>> >> >> >> class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> >>> >> >>> >> (mind the primary) >>> >> >>> >> So far it makes halfway sense to me. A few tests fail still because they >>> >> access getText and do no receive a context. Digging into this >>> > >>> > Hmm... I think I see your point and this is somehow aligned with what >>> > I want to do with TextProvider layer. I mean, there is already a >>> > TextProviderFactory that is used to create custom TextProviders so I >>> > think I will used instead of TextProvider to inject as a dependency. >>> > This will allow to have TextProvider implemented by the ActionSupport >>> > and use TextProviderFactory as a dependency and there be type >>> > conflicts. >>> > >>> > Here is a first step to do so >>> > https://github.com/apache/struts/pull/121 >>> > >>> > I will start another PR soon to replace TextProvider with >>> > TextProviderFactory, if you could test this approach it would be cool >>> > :) >>> > >>> > >>> > Regards >>> > -- >>> > Łukasz >>> > + 48 606 323 122 http://www.lenart.org.pl/ >>> >>> - >>> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >>> For additional commands, e-mail: user-h...@struts.apache.org >>> >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Feel free to register an issue with your case 2017-03-14 10:13 GMT+01:00 Christian Grobmeier : > Yes, actually I think you are right: LocaleProvider and TextProvider > have both the same issue. It's just popping up for me with > LocaleProvider first, but TextProvider will surely follow. > > I try to read more dev list again, so feel free to ping me whenever you > want me to test/help > > On Tue, Mar 14, 2017, at 06:57, Lukasz Lenart wrote: >> https://issues.apache.org/jira/browse/WW-4756 >> >> I know that this is for TextProvider but the same approach I can use >> for LocaleProvider >> >> 2017-03-14 6:53 GMT+01:00 Lukasz Lenart : >> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier : >> >> OK, using component scan i had success with using DefaultLocaleProvider >> >> as default in my applicationContext.xml: >> >> > >> class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> >> >> >> >> (mind the primary) >> >> >> >> So far it makes halfway sense to me. A few tests fail still because they >> >> access getText and do no receive a context. Digging into this >> > >> > Hmm... I think I see your point and this is somehow aligned with what >> > I want to do with TextProvider layer. I mean, there is already a >> > TextProviderFactory that is used to create custom TextProviders so I >> > think I will used instead of TextProvider to inject as a dependency. >> > This will allow to have TextProvider implemented by the ActionSupport >> > and use TextProviderFactory as a dependency and there be type >> > conflicts. >> > >> > Here is a first step to do so >> > https://github.com/apache/struts/pull/121 >> > >> > I will start another PR soon to replace TextProvider with >> > TextProviderFactory, if you could test this approach it would be cool >> > :) >> > >> > >> > Regards >> > -- >> > Łukasz >> > + 48 606 323 122 http://www.lenart.org.pl/ >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Yes, actually I think you are right: LocaleProvider and TextProvider have both the same issue. It's just popping up for me with LocaleProvider first, but TextProvider will surely follow. I try to read more dev list again, so feel free to ping me whenever you want me to test/help On Tue, Mar 14, 2017, at 06:57, Lukasz Lenart wrote: > https://issues.apache.org/jira/browse/WW-4756 > > I know that this is for TextProvider but the same approach I can use > for LocaleProvider > > 2017-03-14 6:53 GMT+01:00 Lukasz Lenart : > > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier : > >> OK, using component scan i had success with using DefaultLocaleProvider > >> as default in my applicationContext.xml: > >> >> class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> > >> > >> (mind the primary) > >> > >> So far it makes halfway sense to me. A few tests fail still because they > >> access getText and do no receive a context. Digging into this > > > > Hmm... I think I see your point and this is somehow aligned with what > > I want to do with TextProvider layer. I mean, there is already a > > TextProviderFactory that is used to create custom TextProviders so I > > think I will used instead of TextProvider to inject as a dependency. > > This will allow to have TextProvider implemented by the ActionSupport > > and use TextProviderFactory as a dependency and there be type > > conflicts. > > > > Here is a first step to do so > > https://github.com/apache/struts/pull/121 > > > > I will start another PR soon to replace TextProvider with > > TextProviderFactory, if you could test this approach it would be cool > > :) > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
https://issues.apache.org/jira/browse/WW-4756 I know that this is for TextProvider but the same approach I can use for LocaleProvider 2017-03-14 6:53 GMT+01:00 Lukasz Lenart : > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier : >> OK, using component scan i had success with using DefaultLocaleProvider >> as default in my applicationContext.xml: >> > class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> >> >> (mind the primary) >> >> So far it makes halfway sense to me. A few tests fail still because they >> access getText and do no receive a context. Digging into this > > Hmm... I think I see your point and this is somehow aligned with what > I want to do with TextProvider layer. I mean, there is already a > TextProviderFactory that is used to create custom TextProviders so I > think I will used instead of TextProvider to inject as a dependency. > This will allow to have TextProvider implemented by the ActionSupport > and use TextProviderFactory as a dependency and there be type > conflicts. > > Here is a first step to do so > https://github.com/apache/struts/pull/121 > > I will start another PR soon to replace TextProvider with > TextProviderFactory, if you could test this approach it would be cool > :) > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
2017-03-13 21:51 GMT+01:00 Christian Grobmeier : > OK, using component scan i had success with using DefaultLocaleProvider > as default in my applicationContext.xml: > class="com.opensymphony.xwork2.DefaultLocaleProvider" primary="true" /> > > (mind the primary) > > So far it makes halfway sense to me. A few tests fail still because they > access getText and do no receive a context. Digging into this Hmm... I think I see your point and this is somehow aligned with what I want to do with TextProvider layer. I mean, there is already a TextProviderFactory that is used to create custom TextProviders so I think I will used instead of TextProvider to inject as a dependency. This will allow to have TextProvider implemented by the ActionSupport and use TextProviderFactory as a dependency and there be type conflicts. Here is a first step to do so https://github.com/apache/struts/pull/121 I will start another PR soon to replace TextProvider with TextProviderFactory, if you could test this approach it would be cool :) Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
OK, using component scan i had success with using DefaultLocaleProvider as default in my applicationContext.xml: (mind the primary) So far it makes halfway sense to me. A few tests fail still because they access getText and do no receive a context. Digging into this On Mon, Mar 13, 2017, at 20:44, Christian Grobmeier wrote: > > > On Mon, Mar 13, 2017, at 19:08, Lukasz Lenart wrote: > > 2017-03-13 19:03 GMT+01:00 Christian Grobmeier : > > > Wether @Service was right or not, I need to somehow tell Spring how to > > > find my beans (i.e. @Component). > > > I can understand Springs confusion, when it realizes every Action is a > > > LocaleProvider. > > > > > > Is there any best practice? > > > > Struts will delegate creation of any object to Spring, if Spring fails > > it will fall back to Struts ObjectFactory to create the object. So as > > far I know, Spring should be able create an object from a class with > > default constructor implemented. > > Sure, but if you use the Spring component scanner, we are back to the > problem I was running into earlier. Because if I am not having an > annotation, it's not picked up by Spring, but by Struts, which returns > it to Spring. Standard testing is very difficult. > > > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
On Mon, Mar 13, 2017, at 19:08, Lukasz Lenart wrote: > 2017-03-13 19:03 GMT+01:00 Christian Grobmeier : > > Wether @Service was right or not, I need to somehow tell Spring how to > > find my beans (i.e. @Component). > > I can understand Springs confusion, when it realizes every Action is a > > LocaleProvider. > > > > Is there any best practice? > > Struts will delegate creation of any object to Spring, if Spring fails > it will fall back to Struts ObjectFactory to create the object. So as > far I know, Spring should be able create an object from a class with > default constructor implemented. Sure, but if you use the Spring component scanner, we are back to the problem I was running into earlier. Because if I am not having an annotation, it's not picked up by Spring, but by Struts, which returns it to Spring. Standard testing is very difficult. > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
2017-03-13 19:03 GMT+01:00 Christian Grobmeier : > Sorry, one more thing. > > With removing the @Service annotation I delegated the instantiation of > the Actions to Struts as the Spring component scanner will not find my > Bean no more. Struts - to my knowledge - will somehow create the bean > using Spring too. > > The problem to use the applicationContext outside the web environment, i > .e. test cases. > > Wether @Service was right or not, I need to somehow tell Spring how to > find my beans (i.e. @Component). > I can understand Springs confusion, when it realizes every Action is a > LocaleProvider. > > Is there any best practice? Struts will delegate creation of any object to Spring, if Spring fails it will fall back to Struts ObjectFactory to create the object. So as far I know, Spring should be able create an object from a class with default constructor implemented. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Sorry, one more thing. With removing the @Service annotation I delegated the instantiation of the Actions to Struts as the Spring component scanner will not find my Bean no more. Struts - to my knowledge - will somehow create the bean using Spring too. The problem to use the applicationContext outside the web environment, i .e. test cases. Wether @Service was right or not, I need to somehow tell Spring how to find my beans (i.e. @Component). I can understand Springs confusion, when it realizes every Action is a LocaleProvider. Is there any best practice? On Mon, Mar 13, 2017, at 18:29, Christian Grobmeier wrote: > > > On Mon, Mar 13, 2017, at 18:26, Lukasz Lenart wrote: > > 2017-03-13 17:55 GMT+01:00 Christian Grobmeier : > > > Removing @Service helped. In addition I had to remove the remaining > > > Actions from applicationContext.xml (I am in the middle of a > > > transition). > > > > > > It's kind a weird, because it worked with the previous version of > > > Struts. Was there a change in the injection behavior? I am glad I know > > > about @Service yet, but still, I would love to know. > > > > No, it isn't related to an injection mechanism, I mean there was no > > change as far I know. Basically defining actions as services is a bad > > idea - actions should be clients for services not to provide them. As > > ActionSupport implements LocaleProvider by default it means it can be > > injected in any bean that requires it (e.g. I18NInterceptor). > > > > I am not sure why it worked before, LocaleProvider is there for a bit > > and it's used in few places but since 2.5.5 is also used in the > > interceptor https://issues.apache.org/jira/browse/WW-4677 - maybe > > that's the case. > > Got it, thank you a lot. > > Christian > > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
On Mon, Mar 13, 2017, at 18:26, Lukasz Lenart wrote: > 2017-03-13 17:55 GMT+01:00 Christian Grobmeier : > > Removing @Service helped. In addition I had to remove the remaining > > Actions from applicationContext.xml (I am in the middle of a > > transition). > > > > It's kind a weird, because it worked with the previous version of > > Struts. Was there a change in the injection behavior? I am glad I know > > about @Service yet, but still, I would love to know. > > No, it isn't related to an injection mechanism, I mean there was no > change as far I know. Basically defining actions as services is a bad > idea - actions should be clients for services not to provide them. As > ActionSupport implements LocaleProvider by default it means it can be > injected in any bean that requires it (e.g. I18NInterceptor). > > I am not sure why it worked before, LocaleProvider is there for a bit > and it's used in few places but since 2.5.5 is also used in the > interceptor https://issues.apache.org/jira/browse/WW-4677 - maybe > that's the case. Got it, thank you a lot. Christian > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
2017-03-13 17:55 GMT+01:00 Christian Grobmeier : > Removing @Service helped. In addition I had to remove the remaining > Actions from applicationContext.xml (I am in the middle of a > transition). > > It's kind a weird, because it worked with the previous version of > Struts. Was there a change in the injection behavior? I am glad I know > about @Service yet, but still, I would love to know. No, it isn't related to an injection mechanism, I mean there was no change as far I know. Basically defining actions as services is a bad idea - actions should be clients for services not to provide them. As ActionSupport implements LocaleProvider by default it means it can be injected in any bean that requires it (e.g. I18NInterceptor). I am not sure why it worked before, LocaleProvider is there for a bit and it's used in few places but since 2.5.5 is also used in the interceptor https://issues.apache.org/jira/browse/WW-4677 - maybe that's the case. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Removing @Service helped. In addition I had to remove the remaining Actions from applicationContext.xml (I am in the middle of a transition). It's kind a weird, because it worked with the previous version of Struts. Was there a change in the injection behavior? I am glad I know about @Service yet, but still, I would love to know. Thanks Lukasz! On Mon, Mar 13, 2017, at 16:44, Christian Grobmeier wrote: > > > On Mon, Mar 13, 2017, at 16:31, Lukasz Lenart wrote: > > 2017-03-13 16:25 GMT+01:00 Christian Grobmeier : > > > @Service > > > @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) > > > public class EmptyAction extends AbstractAction { > > > > Looks like you have turned each action in a bean. Can you drop > > @Service annotation? It's not needed, you should use @Service only for > > services that you want to inject into actions. > > I can try that. > > For the record, I just found out 2.5.5 is the first version of Struts > where my code stopped working. It's still working with 2.5.2 > > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
On Mon, Mar 13, 2017, at 16:31, Lukasz Lenart wrote: > 2017-03-13 16:25 GMT+01:00 Christian Grobmeier : > > @Service > > @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) > > public class EmptyAction extends AbstractAction { > > Looks like you have turned each action in a bean. Can you drop > @Service annotation? It's not needed, you should use @Service only for > services that you want to inject into actions. I can try that. For the record, I just found out 2.5.5 is the first version of Struts where my code stopped working. It's still working with 2.5.2 > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
2017-03-13 16:25 GMT+01:00 Christian Grobmeier : > Sure. > > I use annotations, i. e.: > > @Service > @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) > public class EmptyAction extends AbstractAction { Looks like you have turned each action in a bean. Can you drop @Service annotation? It's not needed, you should use @Service only for services that you want to inject into actions. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
Sure. I use annotations, i. e.: @Service @Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE) public class EmptyAction extends AbstractAction { (AbstractAction extends ActionSupport) In applicationContext: I have used my own stack with: - The action config is still xml. like: /jsp/mysite.jsp It worked with 2.5.1, but no more with 2.5.10.1. Spring version is 4.1.6.RELEASE Thanks Lukasz! Christian On Mon, Mar 13, 2017, at 16:12, Lukasz Lenart wrote: > 2017-03-13 16:02 GMT+01:00 Christian Grobmeier : > > Hello all, > > > > I trying to upgrade my Struts app from 2.5.1 to 2.5.10.1. > > > > I saw there are some changes in I18nInterceptor like that: > > https://github.com/apache/struts/commit/ea92e95461386f1ddfda37bb09ec170b8e306ae7#diff-f9eff9d34d35d47f349c7fa0531e51bdR130 > > > > My actions extend from ActionSupport, which is implementing > > LocaleProvider. > > I am also using Spring for DI. > > > > Unfortunately I now get this exception when starting the container: > > > > SpringObjectFactory- Error building bean > > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > > creating bean with name > > 'org.apache.struts2.interceptor.I18nInterceptor': Unsatisfied dependency > > expressed through bean property 'localeProvider': : No qualifying bean > > of type [com.opensymphony.xwork2.LocaleProvider] is defined: expected > > single matching bean but found 95: emptyAction, ... > > > > It lists all my actions and it seems as Spring would try to instantiate > > I18nInterceptor after my actions. > > > > Does anybody else experience that or got an idea how to improve my code? > > This is strange, can you share how did you setup your actions in > struts.xml? > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: LocaleProvder not unique
2017-03-13 16:02 GMT+01:00 Christian Grobmeier : > Hello all, > > I trying to upgrade my Struts app from 2.5.1 to 2.5.10.1. > > I saw there are some changes in I18nInterceptor like that: > https://github.com/apache/struts/commit/ea92e95461386f1ddfda37bb09ec170b8e306ae7#diff-f9eff9d34d35d47f349c7fa0531e51bdR130 > > My actions extend from ActionSupport, which is implementing > LocaleProvider. > I am also using Spring for DI. > > Unfortunately I now get this exception when starting the container: > > SpringObjectFactory- Error building bean > org.springframework.beans.factory.UnsatisfiedDependencyException: Error > creating bean with name > 'org.apache.struts2.interceptor.I18nInterceptor': Unsatisfied dependency > expressed through bean property 'localeProvider': : No qualifying bean > of type [com.opensymphony.xwork2.LocaleProvider] is defined: expected > single matching bean but found 95: emptyAction, ... > > It lists all my actions and it seems as Spring would try to instantiate > I18nInterceptor after my actions. > > Does anybody else experience that or got an idea how to improve my code? This is strange, can you share how did you setup your actions in struts.xml? Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org