Re: LocaleProvder not unique

2017-03-15 Thread Christian Grobmeier
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

2017-03-15 Thread Lukasz Lenart
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

2017-03-14 Thread 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

2017-03-14 Thread 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



Re: LocaleProvder not unique

2017-03-13 Thread Lukasz Lenart
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 Thread 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 Thread Christian Grobmeier
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

2017-03-13 Thread Christian Grobmeier


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 Thread Lukasz Lenart
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

2017-03-13 Thread 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?

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

2017-03-13 Thread Christian Grobmeier


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 Thread Lukasz Lenart
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

2017-03-13 Thread 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.

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

2017-03-13 Thread Christian Grobmeier


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 Thread Lukasz Lenart
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

2017-03-13 Thread Christian Grobmeier
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 Thread Lukasz Lenart
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