You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by GF <ga...@gmail.com> on 2008/04/14 14:51:25 UTC
[S2] Spring: Interceptors, prototype or singleton?
In a guide I found on the web, the interceptor was defined as singleton in
the Spring's ApplicationContext.
If I need to use "changeable" object properties, I need to have it as
Prototype, otherwise different requests will result in a object property
overwriting.
Is there any issues about defining an interceptor as Prototype, or is it ok?
Thanks
GF
[S1] Strecks
Posted by "Zheng, Xiahong" <Xi...@FMR.COM>.
Anybody used Strecks with Struts 1.x? I was made aware of this extension
project and it seems very attractive for integrating existing struts 1.x
applications for struts 2 like features while preserve backward
compatibility. Any thoughts? The mailing list seems to be dead; the last
message posted was more than 1 year ago.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Martin Gainty <mg...@hotmail.com>.
I assume you're speaking of the capabilities of the spring-plugin?
http://struts.apache.org/2.x/docs/spring-plugin.html
A very good article on Spring BeanFactory scope parameters can be found
here:
http://www.theserverside.com/tt/articles/article.tss?l=IntrotoSpring25
where Bean Factory scope is defined to be:
a.. Singleton: in this case, there's one shared instance of the object with
a particular name, which will be retrieved on lookup. This is the default,
and most often used, mode. It's ideal for stateless service objects.
a.. Prototype or non-singleton: in this case, each retrieval will result in
the creation of an independent object. For example, this could be used to
allow each caller to have a distinct object reference.
a.. Custom object "scopes", which typically interact with a store outside
the control of the container. Some of these come out of the box, such as
request and session (for web applications). Others come with third party
products, such as clustered caches. It is easy to define custom scopes in
the event that none of those provided out of the box is sufficient, through
implementing a simple interface.
Once you've committed to BeanFactory scope as either (shared) singleton or
(distinct object reference) prototype
there is no ability to change scope from then on
in /WEB-INF/web.xml you might have a way to determine the
applicationContext.xml file location such as what is displayed here
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext-*.xml,classpath*:applicationContext
-*.xml</param-value>
</context-param>
Simplest case for ./WEB-INF/applicationContext.xml configuration where bean
is declared as prototype (singleton="false")
<beans default-autowire="autodetect">
<bean id="bar" class="com.my.BarClass" singleton="false"/>
</beans>
The autowire property of struts.objectFactory.spring.autoWire is a bit
tricky as for Bean Dependency Injection you will
need an exact match on name, or class-type or constructor
HTH
Martin
----- Original Message -----
From: "GF" <ga...@gmail.com>
To: "Struts Users ML" <us...@struts.apache.org>
Sent: Monday, April 14, 2008 8:51 AM
Subject: [S2] Spring: Interceptors, prototype or singleton?
> In a guide I found on the web, the interceptor was defined as singleton in
> the Spring's ApplicationContext.
>
> If I need to use "changeable" object properties, I need to have it as
> Prototype, otherwise different requests will result in a object property
> overwriting.
> Is there any issues about defining an interceptor as Prototype, or is it
ok?
>
> Thanks
>
> GF
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Don Brown <do...@gmail.com>.
That is correct, but should be highly discouraged. If your
interceptor accepted any parameters, multiple configurations would
step on each other, resulting in nondeterministic behavior.
Interceptors should also be of the 'prototype' scope.
Don
On Tue, Apr 15, 2008 at 5:55 AM, Randy Burgess <RB...@nuvox.com> wrote:
> So the interceptor would have to be declared at the action level in this
> case then? If I have a spring bean named myBean that is default scope and I
> inject another bean declared as a prototype into it, the injected bean will
> still be a singleton since there will be only one instance of myBean.
>
>
> Regards,
> Randy Burgess
> Sr. Web Applications Developer
> Nuvox Communications
>
>
>
> > From: Don Brown <do...@gmail.com>
>
> > Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> > Date: Tue, 15 Apr 2008 01:12:49 +1000
>
> > To: Struts Users Mailing List <us...@struts.apache.org>
> > Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
>
> >
> > To clarify, interceptors aren't technically singletons as each
> > instance in an interceptor stack gets its own interceptor instance.
> > However, for all requests using that stack, the same interceptor will
> > be used. Therefore, you do need to be careful. For example, most
> > interceptors take parameters that configure their use within the
> > stack, like the "validation" interceptor that takes a list of excluded
> > methods from validation. Interceptors can be configured at the stack
> > level or at the action level. If at the action level, you will get a
> > unique interceptor instance for that action.
> >
> > If you want Spring to construct your interceptor, I recommend the
> > prototype scope, so that Struts gets a new instance of the interceptor
> > as expected.
> >
> > Don
> >
> > On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com> wrote:
> >> Interceptors are Singletons according to the documentation. If it were me I
> >> would come up with another method besides Spring for changing object
> >> properties.
> >>
> >> Regards,
> >> Randy Burgess
> >> Sr. Web Applications Developer
> >> Nuvox Communications
> >>
> >>
> >>
> >>> From: GF <ga...@gmail.com>
> >>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> >>> Date: Mon, 14 Apr 2008 14:51:25 +0200
> >>> To: Struts Users ML <us...@struts.apache.org>
> >>> Subject: [S2] Spring: Interceptors, prototype or singleton?
> >>
> >>
> >>>
> >>> In a guide I found on the web, the interceptor was defined as singleton in
> >>> the Spring's ApplicationContext.
> >>>
> >>> If I need to use "changeable" object properties, I need to have it as
> >>> Prototype, otherwise different requests will result in a object property
> >>> overwriting.
> >>> Is there any issues about defining an interceptor as Prototype, or is it ok?
> >>>
> >>> Thanks
> >>>
> >>> GF
> >>
> >>
> >>
> >> This email and any attachments ("Message") may contain legally privileged
> >> and/or confidential information. If you are not the addressee, or if this
> >> Message has been addressed to you in error, you are not authorized to read,
> >> copy, or distribute it, and we ask that you please delete it (including all
> >> copies) and notify the sender by return email. Delivery of this Message to
> >> any person other than the intended recipient(s) shall not be deemed a waiver
> >> of confidentiality and/or a privilege.
> >>
> >>
> >> This email and any attachments ("Message") may contain legally privileged
> >> and/or confidential information. If you are not the addressee, or if this
> >> Message has been addressed to you in error, you are not authorized to read,
> >> copy, or distribute it, and we ask that you please delete it (including all
> >> copies) and notify the sender by return email. Delivery of this Message to
> >> any person other than the intended recipient(s) shall not be deemed a waiver
> >> of confidentiality and/or a privilege.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>
>
>
> This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
>
>
> This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: [S2] Spring: Interceptors, prototype or singleton?
Posted by Brad A Cupit <br...@lsu.edu>.
wow that was a terrific explanation. Thanks Don!
[note: I was not the original poster]
Brad Cupit
Louisiana State University - UIS
e-mail: brad@lsu.edu
office: 225.578.4774
-----Original Message-----
From: Don Brown [mailto:donald.brown@gmail.com]
Sent: Monday, April 14, 2008 10:13 AM
To: Struts Users Mailing List
Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
To clarify, interceptors aren't technically singletons as each
instance in an interceptor stack gets its own interceptor instance.
However, for all requests using that stack, the same interceptor will
be used. Therefore, you do need to be careful. For example, most
interceptors take parameters that configure their use within the
stack, like the "validation" interceptor that takes a list of excluded
methods from validation. Interceptors can be configured at the stack
level or at the action level. If at the action level, you will get a
unique interceptor instance for that action.
If you want Spring to construct your interceptor, I recommend the
prototype scope, so that Struts gets a new instance of the interceptor
as expected.
Don
On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com>
wrote:
> Interceptors are Singletons according to the documentation. If it were
me I
> would come up with another method besides Spring for changing object
> properties.
>
> Regards,
> Randy Burgess
> Sr. Web Applications Developer
> Nuvox Communications
>
>
>
> > From: GF <ga...@gmail.com>
> > Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> > Date: Mon, 14 Apr 2008 14:51:25 +0200
> > To: Struts Users ML <us...@struts.apache.org>
> > Subject: [S2] Spring: Interceptors, prototype or singleton?
>
>
> >
> > In a guide I found on the web, the interceptor was defined as
singleton in
> > the Spring's ApplicationContext.
> >
> > If I need to use "changeable" object properties, I need to have it
as
> > Prototype, otherwise different requests will result in a object
property
> > overwriting.
> > Is there any issues about defining an interceptor as Prototype, or
is it ok?
> >
> > Thanks
> >
> > GF
>
>
>
> This email and any attachments ("Message") may contain legally
privileged and/or confidential information. If you are not the
addressee, or if this Message has been addressed to you in error, you
are not authorized to read, copy, or distribute it, and we ask that you
please delete it (including all copies) and notify the sender by return
email. Delivery of this Message to any person other than the intended
recipient(s) shall not be deemed a waiver of confidentiality and/or a
privilege.
>
>
> This email and any attachments ("Message") may contain legally
privileged and/or confidential information. If you are not the
addressee, or if this Message has been addressed to you in error, you
are not authorized to read, copy, or distribute it, and we ask that you
please delete it (including all copies) and notify the sender by return
email. Delivery of this Message to any person other than the intended
recipient(s) shall not be deemed a waiver of confidentiality and/or a
privilege.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Randy Burgess <RB...@nuvox.com>.
I've never used that method of injection so I wouldn't comment on it one way
or another, I just found it in the Spring documentation.
If you don't declare the scope for a Spring bean it defaults to singleton.
It will never be a prototype unless you explicitly declare it as such using
either annotations or XML.
Randy
> From: Martin Gainty <mg...@hotmail.com>
> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> Date: Tue, 15 Apr 2008 17:16:03 -0400
> To: Struts Users Mailing List <us...@struts.apache.org>
> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
> Yes very clear thank you
>
> so the default assignment of scope=singleton happens under these scenarios:
> 1)bean creation defaulting to singleton as in ApplicationContext
> 2)beanFactory supports registerSingleton
> then a singleton bean can be set to lazy-initialize (that is not be
> pre-instantiated).
>
> For all other situations the default of prototype is implied
>
> This statement about Method Injection is extremely problematic woth regards
> to singletons
>
> For most application scenarios, the majority of the beans in the container
> will be singletons. When a singleton bean needs to collaborate with another
> singleton bean, or a non-singleton bean needs to collaborate with another
> non-singleton bean, the typical and common approach of handling this
> dependency by defining one bean to be a property of the other is quite
> adequate. There is a problem when the bean lifecycles are different.
> Consider a singleton bean A which needs to use a non-singleton (prototype)
> bean B, perhaps on each method invocation on A. The container will only
> create the singleton bean A once, and thus only get the opportunity to set
> the properties once. There is no opportunity for the container to provide
> bean A with a new instance of bean B every time one is needed.
>
> So if prototype bean B changes A has no clue..
>
> I think I'll stay with the scope="prototype/singleton" in the declarator..
>
> Thanks,
> Martin
> ----- Original Message -----
> From: "Randy Burgess" <RB...@nuvox.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Tuesday, April 15, 2008 9:51 AM
> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
>
>> Just about every single S2 action I have ever created uses Spring to
> inject
>> a service object of some sort into the action. I use Spring for
>> transactions, SLSB's, MDB's, JDBC, Hibernate, you name it.
>>
>> Ganfab asked about injecting a new instance of an object into a custom
>> interceptor on every action call and my thinking was that Spring had only
>> constructor or setter injection and that interceptors were always
>> singletons, so the injected bean would always be a singleton. Well I just
>> found in Spring 2.5 they have lookup method injection which can be used to
>> create a new instance of an object from the Spring bean factory and inject
>> them into a Singleton. Using this you could inject new instances and
> declare
>> your interceptor in a package and not have to declare it for every action
>> needing this type of interceptor. See 3.3.7.1.
>>
>>
> http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#bea
>> ns-factory-method-injection
>>
>> I hope I'm being clear about what I mean. :)
>>
>> Regards,
>> Randy Burgess
>> Sr. Web Applications Developer
>> Nuvox Communications
>>
>>
>>
>>> From: Martin Gainty <mg...@hotmail.com>
>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>> Date: Mon, 14 Apr 2008 21:50:15 -0400
>>> To: Struts Users Mailing List <us...@struts.apache.org>
>>> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>>>
>>> Could you provide a scenario where one bean is injected into another?
>>>
>>> Thanks
>>> M-
>>> ----- Original Message -----
>>> From: "Randy Burgess" <RB...@nuvox.com>
>>> To: "Struts Users Mailing List" <us...@struts.apache.org>
>>> Sent: Monday, April 14, 2008 3:55 PM
>>> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>>>
>>>
>>>> So the interceptor would have to be declared at the action level in
> this
>>>> case then? If I have a spring bean named myBean that is default scope
> and
>>> I
>>>> inject another bean declared as a prototype into it, the injected bean
>>> will
>>>> still be a singleton since there will be only one instance of myBean.
>>>>
>>>> Regards,
>>>> Randy Burgess
>>>> Sr. Web Applications Developer
>>>> Nuvox Communications
>>>>
>>>>
>>>>
>>>>> From: Don Brown <do...@gmail.com>
>>>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>>>> Date: Tue, 15 Apr 2008 01:12:49 +1000
>>>>> To: Struts Users Mailing List <us...@struts.apache.org>
>>>>> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>>>>>
>>>>> To clarify, interceptors aren't technically singletons as each
>>>>> instance in an interceptor stack gets its own interceptor instance.
>>>>> However, for all requests using that stack, the same interceptor will
>>>>> be used. Therefore, you do need to be careful. For example, most
>>>>> interceptors take parameters that configure their use within the
>>>>> stack, like the "validation" interceptor that takes a list of excluded
>>>>> methods from validation. Interceptors can be configured at the stack
>>>>> level or at the action level. If at the action level, you will get a
>>>>> unique interceptor instance for that action.
>>>>>
>>>>> If you want Spring to construct your interceptor, I recommend the
>>>>> prototype scope, so that Struts gets a new instance of the interceptor
>>>>> as expected.
>>>>>
>>>>> Don
>>>>>
>>>>> On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com>
>>> wrote:
>>>>>> Interceptors are Singletons according to the documentation. If it
> were
>>> me I
>>>>>> would come up with another method besides Spring for changing object
>>>>>> properties.
>>>>>>
>>>>>> Regards,
>>>>>> Randy Burgess
>>>>>> Sr. Web Applications Developer
>>>>>> Nuvox Communications
>>>>>>
>>>>>>
>>>>>>
>>>>>>> From: GF <ga...@gmail.com>
>>>>>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>>>>>> Date: Mon, 14 Apr 2008 14:51:25 +0200
>>>>>>> To: Struts Users ML <us...@struts.apache.org>
>>>>>>> Subject: [S2] Spring: Interceptors, prototype or singleton?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> In a guide I found on the web, the interceptor was defined as
>>> singleton in
>>>>>>> the Spring's ApplicationContext.
>>>>>>>
>>>>>>> If I need to use "changeable" object properties, I need to have it
> as
>>>>>>> Prototype, otherwise different requests will result in a object
>>> property
>>>>>>> overwriting.
>>>>>>> Is there any issues about defining an interceptor as Prototype, or
> is
>>> it ok?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> GF
>>>>>>
>>>>>>
>>>>>>
>>>>>> This email and any attachments ("Message") may contain legally
>>> privileged
>>>>>> and/or confidential information. If you are not the addressee, or if
>>> this
>>>>>> Message has been addressed to you in error, you are not authorized to
>>> read,
>>>>>> copy, or distribute it, and we ask that you please delete it
> (including
>>> all
>>>>>> copies) and notify the sender by return email. Delivery of this
>>> Message to
>>>>>> any person other than the intended recipient(s) shall not be deemed a
>>> waiver
>>>>>> of confidentiality and/or a privilege.
>>>>>>
>>>>>>
>>>>>> This email and any attachments ("Message") may contain legally
>>> privileged
>>>>>> and/or confidential information. If you are not the addressee, or if
>>> this
>>>>>> Message has been addressed to you in error, you are not authorized to
>>> read,
>>>>>> copy, or distribute it, and we ask that you please delete it
> (including
>>> all
>>>>>> copies) and notify the sender by return email. Delivery of this
>>> Message to
>>>>>> any person other than the intended recipient(s) shall not be deemed a
>>> waiver
>>>>>> of confidentiality and/or a privilege.
>>>>>>
>>
>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> This email and any attachments ("Message") may contain legally
> privileged
>>> and/or confidential information. If you are not the addressee, or if
> this
>>> Message has been addressed to you in error, you are not authorized to
> read,
>>> copy, or distribute it, and we ask that you please delete it (including
> all
>>> copies) and notify the sender by return email. Delivery of this Message
> to
>>> any person other than the intended recipient(s) shall not be deemed a
> waiver
>>> of confidentiality and/or a privilege.
>>>>
>>>>
>>>> This email and any attachments ("Message") may contain legally
> privileged
>>> and/or confidential information. If you are not the addressee, or if
> this
>>> Message has been addressed to you in error, you are not authorized to
> read,
>>> copy, or distribute it, and we ask that you please delete it (including
> all
>>> copies) and notify the sender by return email. Delivery of this Message
> to
>>> any person other than the intended recipient(s) shall not be deemed a
> waiver
>>> of confidentiality and/or a privilege.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
> and/or confidential information. If you are not the addressee, or if this
> Message has been addressed to you in error, you are not authorized to read,
> copy, or distribute it, and we ask that you please delete it (including all
> copies) and notify the sender by return email. Delivery of this Message to
> any person other than the intended recipient(s) shall not be deemed a waiver
> of confidentiality and/or a privilege.
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
> and/or confidential information. If you are not the addressee, or if this
> Message has been addressed to you in error, you are not authorized to read,
> copy, or distribute it, and we ask that you please delete it (including all
> copies) and notify the sender by return email. Delivery of this Message to
> any person other than the intended recipient(s) shall not be deemed a waiver
> of confidentiality and/or a privilege.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Martin Gainty <mg...@hotmail.com>.
Yes very clear thank you
so the default assignment of scope=singleton happens under these scenarios:
1)bean creation defaulting to singleton as in ApplicationContext
2)beanFactory supports registerSingleton
then a singleton bean can be set to lazy-initialize (that is not be
pre-instantiated).
For all other situations the default of prototype is implied
This statement about Method Injection is extremely problematic woth regards
to singletons
For most application scenarios, the majority of the beans in the container
will be singletons. When a singleton bean needs to collaborate with another
singleton bean, or a non-singleton bean needs to collaborate with another
non-singleton bean, the typical and common approach of handling this
dependency by defining one bean to be a property of the other is quite
adequate. There is a problem when the bean lifecycles are different.
Consider a singleton bean A which needs to use a non-singleton (prototype)
bean B, perhaps on each method invocation on A. The container will only
create the singleton bean A once, and thus only get the opportunity to set
the properties once. There is no opportunity for the container to provide
bean A with a new instance of bean B every time one is needed.
So if prototype bean B changes A has no clue..
I think I'll stay with the scope="prototype/singleton" in the declarator..
Thanks,
Martin
----- Original Message -----
From: "Randy Burgess" <RB...@nuvox.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Tuesday, April 15, 2008 9:51 AM
Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> Just about every single S2 action I have ever created uses Spring to
inject
> a service object of some sort into the action. I use Spring for
> transactions, SLSB's, MDB's, JDBC, Hibernate, you name it.
>
> Ganfab asked about injecting a new instance of an object into a custom
> interceptor on every action call and my thinking was that Spring had only
> constructor or setter injection and that interceptors were always
> singletons, so the injected bean would always be a singleton. Well I just
> found in Spring 2.5 they have lookup method injection which can be used to
> create a new instance of an object from the Spring bean factory and inject
> them into a Singleton. Using this you could inject new instances and
declare
> your interceptor in a package and not have to declare it for every action
> needing this type of interceptor. See 3.3.7.1.
>
>
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#bea
> ns-factory-method-injection
>
> I hope I'm being clear about what I mean. :)
>
> Regards,
> Randy Burgess
> Sr. Web Applications Developer
> Nuvox Communications
>
>
>
> > From: Martin Gainty <mg...@hotmail.com>
> > Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> > Date: Mon, 14 Apr 2008 21:50:15 -0400
> > To: Struts Users Mailing List <us...@struts.apache.org>
> > Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> >
> > Could you provide a scenario where one bean is injected into another?
> >
> > Thanks
> > M-
> > ----- Original Message -----
> > From: "Randy Burgess" <RB...@nuvox.com>
> > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > Sent: Monday, April 14, 2008 3:55 PM
> > Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> >
> >
> >> So the interceptor would have to be declared at the action level in
this
> >> case then? If I have a spring bean named myBean that is default scope
and
> > I
> >> inject another bean declared as a prototype into it, the injected bean
> > will
> >> still be a singleton since there will be only one instance of myBean.
> >>
> >> Regards,
> >> Randy Burgess
> >> Sr. Web Applications Developer
> >> Nuvox Communications
> >>
> >>
> >>
> >>> From: Don Brown <do...@gmail.com>
> >>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> >>> Date: Tue, 15 Apr 2008 01:12:49 +1000
> >>> To: Struts Users Mailing List <us...@struts.apache.org>
> >>> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> >>>
> >>> To clarify, interceptors aren't technically singletons as each
> >>> instance in an interceptor stack gets its own interceptor instance.
> >>> However, for all requests using that stack, the same interceptor will
> >>> be used. Therefore, you do need to be careful. For example, most
> >>> interceptors take parameters that configure their use within the
> >>> stack, like the "validation" interceptor that takes a list of excluded
> >>> methods from validation. Interceptors can be configured at the stack
> >>> level or at the action level. If at the action level, you will get a
> >>> unique interceptor instance for that action.
> >>>
> >>> If you want Spring to construct your interceptor, I recommend the
> >>> prototype scope, so that Struts gets a new instance of the interceptor
> >>> as expected.
> >>>
> >>> Don
> >>>
> >>> On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com>
> > wrote:
> >>>> Interceptors are Singletons according to the documentation. If it
were
> > me I
> >>>> would come up with another method besides Spring for changing object
> >>>> properties.
> >>>>
> >>>> Regards,
> >>>> Randy Burgess
> >>>> Sr. Web Applications Developer
> >>>> Nuvox Communications
> >>>>
> >>>>
> >>>>
> >>>>> From: GF <ga...@gmail.com>
> >>>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> >>>>> Date: Mon, 14 Apr 2008 14:51:25 +0200
> >>>>> To: Struts Users ML <us...@struts.apache.org>
> >>>>> Subject: [S2] Spring: Interceptors, prototype or singleton?
> >>>>
> >>>>
> >>>>>
> >>>>> In a guide I found on the web, the interceptor was defined as
> > singleton in
> >>>>> the Spring's ApplicationContext.
> >>>>>
> >>>>> If I need to use "changeable" object properties, I need to have it
as
> >>>>> Prototype, otherwise different requests will result in a object
> > property
> >>>>> overwriting.
> >>>>> Is there any issues about defining an interceptor as Prototype, or
is
> > it ok?
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> GF
> >>>>
> >>>>
> >>>>
> >>>> This email and any attachments ("Message") may contain legally
> > privileged
> >>>> and/or confidential information. If you are not the addressee, or if
> > this
> >>>> Message has been addressed to you in error, you are not authorized to
> > read,
> >>>> copy, or distribute it, and we ask that you please delete it
(including
> > all
> >>>> copies) and notify the sender by return email. Delivery of this
> > Message to
> >>>> any person other than the intended recipient(s) shall not be deemed a
> > waiver
> >>>> of confidentiality and/or a privilege.
> >>>>
> >>>>
> >>>> This email and any attachments ("Message") may contain legally
> > privileged
> >>>> and/or confidential information. If you are not the addressee, or if
> > this
> >>>> Message has been addressed to you in error, you are not authorized to
> > read,
> >>>> copy, or distribute it, and we ask that you please delete it
(including
> > all
> >>>> copies) and notify the sender by return email. Delivery of this
> > Message to
> >>>> any person other than the intended recipient(s) shall not be deemed a
> > waiver
> >>>> of confidentiality and/or a privilege.
> >>>>
>
>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: user-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: user-help@struts.apache.org
> >>>
> >>
> >>
> >>
> >> This email and any attachments ("Message") may contain legally
privileged
> > and/or confidential information. If you are not the addressee, or if
this
> > Message has been addressed to you in error, you are not authorized to
read,
> > copy, or distribute it, and we ask that you please delete it (including
all
> > copies) and notify the sender by return email. Delivery of this Message
to
> > any person other than the intended recipient(s) shall not be deemed a
waiver
> > of confidentiality and/or a privilege.
> >>
> >>
> >> This email and any attachments ("Message") may contain legally
privileged
> > and/or confidential information. If you are not the addressee, or if
this
> > Message has been addressed to you in error, you are not authorized to
read,
> > copy, or distribute it, and we ask that you please delete it (including
all
> > copies) and notify the sender by return email. Delivery of this Message
to
> > any person other than the intended recipient(s) shall not be deemed a
waiver
> > of confidentiality and/or a privilege.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>
>
>
> This email and any attachments ("Message") may contain legally privileged
and/or confidential information. If you are not the addressee, or if this
Message has been addressed to you in error, you are not authorized to read,
copy, or distribute it, and we ask that you please delete it (including all
copies) and notify the sender by return email. Delivery of this Message to
any person other than the intended recipient(s) shall not be deemed a waiver
of confidentiality and/or a privilege.
>
>
> This email and any attachments ("Message") may contain legally privileged
and/or confidential information. If you are not the addressee, or if this
Message has been addressed to you in error, you are not authorized to read,
copy, or distribute it, and we ask that you please delete it (including all
copies) and notify the sender by return email. Delivery of this Message to
any person other than the intended recipient(s) shall not be deemed a waiver
of confidentiality and/or a privilege.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Randy Burgess <RB...@nuvox.com>.
Just about every single S2 action I have ever created uses Spring to inject
a service object of some sort into the action. I use Spring for
transactions, SLSB's, MDB's, JDBC, Hibernate, you name it.
Ganfab asked about injecting a new instance of an object into a custom
interceptor on every action call and my thinking was that Spring had only
constructor or setter injection and that interceptors were always
singletons, so the injected bean would always be a singleton. Well I just
found in Spring 2.5 they have lookup method injection which can be used to
create a new instance of an object from the Spring bean factory and inject
them into a Singleton. Using this you could inject new instances and declare
your interceptor in a package and not have to declare it for every action
needing this type of interceptor. See 3.3.7.1.
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#bea
ns-factory-method-injection
I hope I'm being clear about what I mean. :)
Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications
> From: Martin Gainty <mg...@hotmail.com>
> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> Date: Mon, 14 Apr 2008 21:50:15 -0400
> To: Struts Users Mailing List <us...@struts.apache.org>
> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
> Could you provide a scenario where one bean is injected into another?
>
> Thanks
> M-
> ----- Original Message -----
> From: "Randy Burgess" <RB...@nuvox.com>
> To: "Struts Users Mailing List" <us...@struts.apache.org>
> Sent: Monday, April 14, 2008 3:55 PM
> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
>
>> So the interceptor would have to be declared at the action level in this
>> case then? If I have a spring bean named myBean that is default scope and
> I
>> inject another bean declared as a prototype into it, the injected bean
> will
>> still be a singleton since there will be only one instance of myBean.
>>
>> Regards,
>> Randy Burgess
>> Sr. Web Applications Developer
>> Nuvox Communications
>>
>>
>>
>>> From: Don Brown <do...@gmail.com>
>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>> Date: Tue, 15 Apr 2008 01:12:49 +1000
>>> To: Struts Users Mailing List <us...@struts.apache.org>
>>> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>>>
>>> To clarify, interceptors aren't technically singletons as each
>>> instance in an interceptor stack gets its own interceptor instance.
>>> However, for all requests using that stack, the same interceptor will
>>> be used. Therefore, you do need to be careful. For example, most
>>> interceptors take parameters that configure their use within the
>>> stack, like the "validation" interceptor that takes a list of excluded
>>> methods from validation. Interceptors can be configured at the stack
>>> level or at the action level. If at the action level, you will get a
>>> unique interceptor instance for that action.
>>>
>>> If you want Spring to construct your interceptor, I recommend the
>>> prototype scope, so that Struts gets a new instance of the interceptor
>>> as expected.
>>>
>>> Don
>>>
>>> On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com>
> wrote:
>>>> Interceptors are Singletons according to the documentation. If it were
> me I
>>>> would come up with another method besides Spring for changing object
>>>> properties.
>>>>
>>>> Regards,
>>>> Randy Burgess
>>>> Sr. Web Applications Developer
>>>> Nuvox Communications
>>>>
>>>>
>>>>
>>>>> From: GF <ga...@gmail.com>
>>>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>>>> Date: Mon, 14 Apr 2008 14:51:25 +0200
>>>>> To: Struts Users ML <us...@struts.apache.org>
>>>>> Subject: [S2] Spring: Interceptors, prototype or singleton?
>>>>
>>>>
>>>>>
>>>>> In a guide I found on the web, the interceptor was defined as
> singleton in
>>>>> the Spring's ApplicationContext.
>>>>>
>>>>> If I need to use "changeable" object properties, I need to have it as
>>>>> Prototype, otherwise different requests will result in a object
> property
>>>>> overwriting.
>>>>> Is there any issues about defining an interceptor as Prototype, or is
> it ok?
>>>>>
>>>>> Thanks
>>>>>
>>>>> GF
>>>>
>>>>
>>>>
>>>> This email and any attachments ("Message") may contain legally
> privileged
>>>> and/or confidential information. If you are not the addressee, or if
> this
>>>> Message has been addressed to you in error, you are not authorized to
> read,
>>>> copy, or distribute it, and we ask that you please delete it (including
> all
>>>> copies) and notify the sender by return email. Delivery of this
> Message to
>>>> any person other than the intended recipient(s) shall not be deemed a
> waiver
>>>> of confidentiality and/or a privilege.
>>>>
>>>>
>>>> This email and any attachments ("Message") may contain legally
> privileged
>>>> and/or confidential information. If you are not the addressee, or if
> this
>>>> Message has been addressed to you in error, you are not authorized to
> read,
>>>> copy, or distribute it, and we ask that you please delete it (including
> all
>>>> copies) and notify the sender by return email. Delivery of this
> Message to
>>>> any person other than the intended recipient(s) shall not be deemed a
> waiver
>>>> of confidentiality and/or a privilege.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
> and/or confidential information. If you are not the addressee, or if this
> Message has been addressed to you in error, you are not authorized to read,
> copy, or distribute it, and we ask that you please delete it (including all
> copies) and notify the sender by return email. Delivery of this Message to
> any person other than the intended recipient(s) shall not be deemed a waiver
> of confidentiality and/or a privilege.
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
> and/or confidential information. If you are not the addressee, or if this
> Message has been addressed to you in error, you are not authorized to read,
> copy, or distribute it, and we ask that you please delete it (including all
> copies) and notify the sender by return email. Delivery of this Message to
> any person other than the intended recipient(s) shall not be deemed a waiver
> of confidentiality and/or a privilege.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Martin Gainty <mg...@hotmail.com>.
Could you provide a scenario where one bean is injected into another?
Thanks
M-
----- Original Message -----
From: "Randy Burgess" <RB...@nuvox.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, April 14, 2008 3:55 PM
Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> So the interceptor would have to be declared at the action level in this
> case then? If I have a spring bean named myBean that is default scope and
I
> inject another bean declared as a prototype into it, the injected bean
will
> still be a singleton since there will be only one instance of myBean.
>
> Regards,
> Randy Burgess
> Sr. Web Applications Developer
> Nuvox Communications
>
>
>
> > From: Don Brown <do...@gmail.com>
> > Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> > Date: Tue, 15 Apr 2008 01:12:49 +1000
> > To: Struts Users Mailing List <us...@struts.apache.org>
> > Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
> >
> > To clarify, interceptors aren't technically singletons as each
> > instance in an interceptor stack gets its own interceptor instance.
> > However, for all requests using that stack, the same interceptor will
> > be used. Therefore, you do need to be careful. For example, most
> > interceptors take parameters that configure their use within the
> > stack, like the "validation" interceptor that takes a list of excluded
> > methods from validation. Interceptors can be configured at the stack
> > level or at the action level. If at the action level, you will get a
> > unique interceptor instance for that action.
> >
> > If you want Spring to construct your interceptor, I recommend the
> > prototype scope, so that Struts gets a new instance of the interceptor
> > as expected.
> >
> > Don
> >
> > On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com>
wrote:
> >> Interceptors are Singletons according to the documentation. If it were
me I
> >> would come up with another method besides Spring for changing object
> >> properties.
> >>
> >> Regards,
> >> Randy Burgess
> >> Sr. Web Applications Developer
> >> Nuvox Communications
> >>
> >>
> >>
> >>> From: GF <ga...@gmail.com>
> >>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> >>> Date: Mon, 14 Apr 2008 14:51:25 +0200
> >>> To: Struts Users ML <us...@struts.apache.org>
> >>> Subject: [S2] Spring: Interceptors, prototype or singleton?
> >>
> >>
> >>>
> >>> In a guide I found on the web, the interceptor was defined as
singleton in
> >>> the Spring's ApplicationContext.
> >>>
> >>> If I need to use "changeable" object properties, I need to have it as
> >>> Prototype, otherwise different requests will result in a object
property
> >>> overwriting.
> >>> Is there any issues about defining an interceptor as Prototype, or is
it ok?
> >>>
> >>> Thanks
> >>>
> >>> GF
> >>
> >>
> >>
> >> This email and any attachments ("Message") may contain legally
privileged
> >> and/or confidential information. If you are not the addressee, or if
this
> >> Message has been addressed to you in error, you are not authorized to
read,
> >> copy, or distribute it, and we ask that you please delete it (including
all
> >> copies) and notify the sender by return email. Delivery of this
Message to
> >> any person other than the intended recipient(s) shall not be deemed a
waiver
> >> of confidentiality and/or a privilege.
> >>
> >>
> >> This email and any attachments ("Message") may contain legally
privileged
> >> and/or confidential information. If you are not the addressee, or if
this
> >> Message has been addressed to you in error, you are not authorized to
read,
> >> copy, or distribute it, and we ask that you please delete it (including
all
> >> copies) and notify the sender by return email. Delivery of this
Message to
> >> any person other than the intended recipient(s) shall not be deemed a
waiver
> >> of confidentiality and/or a privilege.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>
>
>
> This email and any attachments ("Message") may contain legally privileged
and/or confidential information. If you are not the addressee, or if this
Message has been addressed to you in error, you are not authorized to read,
copy, or distribute it, and we ask that you please delete it (including all
copies) and notify the sender by return email. Delivery of this Message to
any person other than the intended recipient(s) shall not be deemed a waiver
of confidentiality and/or a privilege.
>
>
> This email and any attachments ("Message") may contain legally privileged
and/or confidential information. If you are not the addressee, or if this
Message has been addressed to you in error, you are not authorized to read,
copy, or distribute it, and we ask that you please delete it (including all
copies) and notify the sender by return email. Delivery of this Message to
any person other than the intended recipient(s) shall not be deemed a waiver
of confidentiality and/or a privilege.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Randy Burgess <RB...@nuvox.com>.
So the interceptor would have to be declared at the action level in this
case then? If I have a spring bean named myBean that is default scope and I
inject another bean declared as a prototype into it, the injected bean will
still be a singleton since there will be only one instance of myBean.
Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications
> From: Don Brown <do...@gmail.com>
> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> Date: Tue, 15 Apr 2008 01:12:49 +1000
> To: Struts Users Mailing List <us...@struts.apache.org>
> Subject: Re: [S2] Spring: Interceptors, prototype or singleton?
>
> To clarify, interceptors aren't technically singletons as each
> instance in an interceptor stack gets its own interceptor instance.
> However, for all requests using that stack, the same interceptor will
> be used. Therefore, you do need to be careful. For example, most
> interceptors take parameters that configure their use within the
> stack, like the "validation" interceptor that takes a list of excluded
> methods from validation. Interceptors can be configured at the stack
> level or at the action level. If at the action level, you will get a
> unique interceptor instance for that action.
>
> If you want Spring to construct your interceptor, I recommend the
> prototype scope, so that Struts gets a new instance of the interceptor
> as expected.
>
> Don
>
> On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com> wrote:
>> Interceptors are Singletons according to the documentation. If it were me I
>> would come up with another method besides Spring for changing object
>> properties.
>>
>> Regards,
>> Randy Burgess
>> Sr. Web Applications Developer
>> Nuvox Communications
>>
>>
>>
>>> From: GF <ga...@gmail.com>
>>> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
>>> Date: Mon, 14 Apr 2008 14:51:25 +0200
>>> To: Struts Users ML <us...@struts.apache.org>
>>> Subject: [S2] Spring: Interceptors, prototype or singleton?
>>
>>
>>>
>>> In a guide I found on the web, the interceptor was defined as singleton in
>>> the Spring's ApplicationContext.
>>>
>>> If I need to use "changeable" object properties, I need to have it as
>>> Prototype, otherwise different requests will result in a object property
>>> overwriting.
>>> Is there any issues about defining an interceptor as Prototype, or is it ok?
>>>
>>> Thanks
>>>
>>> GF
>>
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
>> and/or confidential information. If you are not the addressee, or if this
>> Message has been addressed to you in error, you are not authorized to read,
>> copy, or distribute it, and we ask that you please delete it (including all
>> copies) and notify the sender by return email. Delivery of this Message to
>> any person other than the intended recipient(s) shall not be deemed a waiver
>> of confidentiality and/or a privilege.
>>
>>
>> This email and any attachments ("Message") may contain legally privileged
>> and/or confidential information. If you are not the addressee, or if this
>> Message has been addressed to you in error, you are not authorized to read,
>> copy, or distribute it, and we ask that you please delete it (including all
>> copies) and notify the sender by return email. Delivery of this Message to
>> any person other than the intended recipient(s) shall not be deemed a waiver
>> of confidentiality and/or a privilege.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Don Brown <do...@gmail.com>.
To clarify, interceptors aren't technically singletons as each
instance in an interceptor stack gets its own interceptor instance.
However, for all requests using that stack, the same interceptor will
be used. Therefore, you do need to be careful. For example, most
interceptors take parameters that configure their use within the
stack, like the "validation" interceptor that takes a list of excluded
methods from validation. Interceptors can be configured at the stack
level or at the action level. If at the action level, you will get a
unique interceptor instance for that action.
If you want Spring to construct your interceptor, I recommend the
prototype scope, so that Struts gets a new instance of the interceptor
as expected.
Don
On Tue, Apr 15, 2008 at 12:48 AM, Randy Burgess <RB...@nuvox.com> wrote:
> Interceptors are Singletons according to the documentation. If it were me I
> would come up with another method besides Spring for changing object
> properties.
>
> Regards,
> Randy Burgess
> Sr. Web Applications Developer
> Nuvox Communications
>
>
>
> > From: GF <ga...@gmail.com>
> > Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> > Date: Mon, 14 Apr 2008 14:51:25 +0200
> > To: Struts Users ML <us...@struts.apache.org>
> > Subject: [S2] Spring: Interceptors, prototype or singleton?
>
>
> >
> > In a guide I found on the web, the interceptor was defined as singleton in
> > the Spring's ApplicationContext.
> >
> > If I need to use "changeable" object properties, I need to have it as
> > Prototype, otherwise different requests will result in a object property
> > overwriting.
> > Is there any issues about defining an interceptor as Prototype, or is it ok?
> >
> > Thanks
> >
> > GF
>
>
>
> This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
>
>
> This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [S2] Spring: Interceptors, prototype or singleton?
Posted by Randy Burgess <RB...@nuvox.com>.
Interceptors are Singletons according to the documentation. If it were me I
would come up with another method besides Spring for changing object
properties.
Regards,
Randy Burgess
Sr. Web Applications Developer
Nuvox Communications
> From: GF <ga...@gmail.com>
> Reply-To: Struts Users Mailing List <us...@struts.apache.org>
> Date: Mon, 14 Apr 2008 14:51:25 +0200
> To: Struts Users ML <us...@struts.apache.org>
> Subject: [S2] Spring: Interceptors, prototype or singleton?
>
> In a guide I found on the web, the interceptor was defined as singleton in
> the Spring's ApplicationContext.
>
> If I need to use "changeable" object properties, I need to have it as
> Prototype, otherwise different requests will result in a object property
> overwriting.
> Is there any issues about defining an interceptor as Prototype, or is it ok?
>
> Thanks
>
> GF
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
This email and any attachments ("Message") may contain legally privileged and/or confidential information. If you are not the addressee, or if this Message has been addressed to you in error, you are not authorized to read, copy, or distribute it, and we ask that you please delete it (including all copies) and notify the sender by return email. Delivery of this Message to any person other than the intended recipient(s) shall not be deemed a waiver of confidentiality and/or a privilege.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org