Quantcast

LocaleProvder not unique

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LocaleProvder not unique

Christian Grobmeier-3
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?

Thanks

Christian

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
2017-03-13 16:02 GMT+01:00 Christian Grobmeier <[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
Sure.

I use annotations, i. e.:

@Service
@Scope(value = ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class EmptyAction extends AbstractAction {

(AbstractAction  extends ActionSupport)

In applicationContext:

<beans ... default-autowire="byType">
<context:component-scan base-package="de.grobmeier..."
annotation-config="true" />

I have used my own stack with:

-<interceptor-ref name="i18n"/>

The action config is still xml. like:

<action name="myname" class="de.grobmeier....EmptyAction">
<result>/jsp/mysite.jsp</result>
</action>

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 <[hidden email]>:
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
2017-03-13 16:25 GMT+01:00 Christian Grobmeier <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3


On Mon, Mar 13, 2017, at 16:31, Lukasz Lenart wrote:
> 2017-03-13 16:25 GMT+01:00 Christian Grobmeier <[hidden email]>:
> > @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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
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 <[hidden email]>:
> > > @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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
2017-03-13 17:55 GMT+01:00 Christian Grobmeier <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3


On Mon, Mar 13, 2017, at 18:26, Lukasz Lenart wrote:

> 2017-03-13 17:55 GMT+01:00 Christian Grobmeier <[hidden email]>:
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
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 <[hidden email]>:
> > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
2017-03-13 19:03 GMT+01:00 Christian Grobmeier <[hidden email]>:

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3


On Mon, Mar 13, 2017, at 19:08, Lukasz Lenart wrote:

> 2017-03-13 19:03 GMT+01:00 Christian Grobmeier <[hidden email]>:
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
OK, using component scan i had success with using DefaultLocaleProvider
as default in my applicationContext.xml:
<bean name="localeProvider"
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

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 <[hidden email]>:
> > > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
> OK, using component scan i had success with using DefaultLocaleProvider
> as default in my applicationContext.xml:
> <bean name="localeProvider"
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

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 <[hidden email]>:

> 2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
>> OK, using component scan i had success with using DefaultLocaleProvider
>> as default in my applicationContext.xml:
>> <bean name="localeProvider"
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
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 <[hidden email]>:
> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
> >> OK, using component scan i had success with using DefaultLocaleProvider
> >> as default in my applicationContext.xml:
> >> <bean name="localeProvider"
> >> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
Feel free to register an issue with your case

2017-03-14 10:13 GMT+01:00 Christian Grobmeier <[hidden email]>:

> 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 <[hidden email]>:
>> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
>> >> OK, using component scan i had success with using DefaultLocaleProvider
>> >> as default in my applicationContext.xml:
>> >> <bean name="localeProvider"
>> >> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Lukasz Lenart
Christian

Change is here https://github.com/apache/struts/pull/122

2017-03-14 10:16 GMT+01:00 Lukasz Lenart <[hidden email]>:

> Feel free to register an issue with your case
>
> 2017-03-14 10:13 GMT+01:00 Christian Grobmeier <[hidden email]>:
>> 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 <[hidden email]>:
>>> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
>>> >> OK, using component scan i had success with using DefaultLocaleProvider
>>> >> as default in my applicationContext.xml:
>>> >> <bean name="localeProvider"
>>> >> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocaleProvder not unique

Christian Grobmeier-3
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 <[hidden email]>:
> > Feel free to register an issue with your case
> >
> > 2017-03-14 10:13 GMT+01:00 Christian Grobmeier <[hidden email]>:
> >> 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 <[hidden email]>:
> >>> > 2017-03-13 21:51 GMT+01:00 Christian Grobmeier <[hidden email]>:
> >>> >> OK, using component scan i had success with using DefaultLocaleProvider
> >>> >> as default in my applicationContext.xml:
> >>> >> <bean name="localeProvider"
> >>> >> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...