|
From: Brian M. <br...@ap...> - 2004-09-20 19:00:49
|
I may be wrong in thinking that this doesn't exist in Spring, if I am,
please tell me! I cannot find anything though.
In the SpringMVC configurator I would like to have scope BeanFactory
instances. One, as currently, in the application scope, one in the
session, and one in the request. Each factory would have the higher
scope as its parent.
The primary reason for this is that I would like to have strongly typed
session scoped components.
public class ThrowAwayFooController
{
private BarComponent bar;
public void setBarComponent(BarComponent bar) { this.bar = bar; }
public void doStuff() {
bar.setSomeSessionData("wombats!");
}
}
would sit in the request scope factory as a singleton, the BarComponent
(following)
public class BarComponent
{
private String animalType;
public void setBarComponent(BarComponent bar) { this.bar = bar; }
public void setSomeSessionData(final String animalsType) {
this.animalType = animalType;
}
public String getAnimalType() { return animalType; }
}
would be in the session scope factory.
Later throwaway controllers could also be dependent on BarComponent and
receive the same one.
This provides a much cleaner way of handling session state than using a
flat map, I think. It also allows you to change component scopes by
simply moving them to a different factory -- presuming the hierarchy is
respected, nothing changes (say a stateful thing becomes stateless so
can be moved to the application scope, or vice versa).
Thoughts?
-Brian
|
|
From: Rob B. <cro...@ya...> - 2004-09-20 20:02:10
|
Hey Brian,
I don't know about using separate bean factories for
handling session state because usually bean factories
are for creating new (prototype) objects or dishing up
singletons, not storing objects that have been
manipulated in the application. I don't think bean
factories will do what your looking to do. Although I
know where your trying going with it. ;)
If your really set on trying this approach though you
can construct a new bean factory and then store it in
session. You can set it's parent to be the
application bean factory, and set where to read it's
config file from. Infact.. I've never done it, but
since a bean factory *should be* a javabean in and of
itself, you can configure your application bean
factory to have a bean factory prototype. Then all
you would do is getBean("sessionBean"), and you would
get a fully configured "session" bean to stick in
session. By extension, you could then have a "request
session bean" configured within that. So you could
then call sessionBean.getBean("requestBean") and that
would return a fully configured request scope bean
which you could store in the request object.
Now what's really neat about this is, I have been
trying to think of a good way to implement dynamic
configuration for a web application... and this looks
like it could fit perfectly. When your user begins a
new work flow you can "load" the configuration by
requesting a new session scoped bean factory... Which
would actually load the configuration file at that
time and retain all the setings until it was
explicitly refreshed or better yet, removed from
session and a new one loaded when the next workflow
started.
Now all that is needed is to have the various spring
MVC stuff look for a session bean factory BEFORE they
look at the application bean factory. This would
allow per user configuration state to be maintained..
which is exactly what you need for a dynamically
configurable application... Because you may need to
maintain whatever the configuration was when the user
started the current workflow.. but if their session
times out, or if they finish the workflow subsequent
operations should use the new configuration with the
updates.
Any chance of this capability being built into the
framework guys?
Later
Rob
--- Brian McCallister <br...@ap...> wrote:
> I may be wrong in thinking that this doesn't exist
> in Spring, if I am,
> please tell me! I cannot find anything though.
>
> In the SpringMVC configurator I would like to have
> scope BeanFactory
> instances. One, as currently, in the application
> scope, one in the
> session, and one in the request. Each factory would
> have the higher
> scope as its parent.
>
> The primary reason for this is that I would like to
> have strongly typed
> session scoped components.
>
> public class ThrowAwayFooController
> {
> private BarComponent bar;
>
> public void setBarComponent(BarComponent bar) {
> this.bar = bar; }
>
> public void doStuff() {
> bar.setSomeSessionData("wombats!");
> }
> }
>
> would sit in the request scope factory as a
> singleton, the BarComponent
> (following)
>
> public class BarComponent
> {
> private String animalType;
>
> public void setBarComponent(BarComponent bar) {
> this.bar = bar; }
>
> public void setSomeSessionData(final String
> animalsType) {
> this.animalType = animalType;
> }
>
> public String getAnimalType() { return animalType;
> }
> }
>
> would be in the session scope factory.
>
> Later throwaway controllers could also be dependent
> on BarComponent and
> receive the same one.
>
> This provides a much cleaner way of handling session
> state than using a
> flat map, I think. It also allows you to change
> component scopes by
> simply moving them to a different factory --
> presuming the hierarchy is
> respected, nothing changes (say a stateful thing
> becomes stateless so
> can be moved to the application scope, or vice
> versa).
>
> Thoughts?
>
> -Brian
>
>
>
>
>
-------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE.
> Be one of 170
> Project Admins to receive an Apple iPod Mini FREE
> for your judgement on
> who ports your project to Linux PPC the best.
> Sponsored by IBM.
> Deadline: Sept. 24. Go here:
> http://sf.net/ppc_contest.php
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
|
|
From: Brian M. <br...@ap...> - 2004-09-20 20:27:06
|
On Sep 20, 2004, at 4:01 PM, Rob Butler wrote: > Hey Brian, > > I don't know about using separate bean factories for > handling session state because usually bean factories > are for creating new (prototype) objects or dishing up > singletons, not storing objects that have been > manipulated in the application. Really, what I want are the one-per-scope "singleton" instances. The session-scoped "singleton" is a PERFECT place for sticking session state, particularly when child factories can build their prototypes from it. > I don't think bean factories will do what your looking to do. Quite possibly not, I have spent a lot more time in the pico world, but Rod has been doing a good job of trying to get me to convert ;-) > If your really set on trying this approach though you > can construct a new bean factory and then store it in > session. You can set it's parent to be the > application bean factory, and set where to read it's > config file from. That is exactly what I want. Ideally the beans could sit in the session directly and be proxied in the container, but as long as the container/factory/context is session compatible (serializable and able to rebuild dependencies intelligently after serialization (proxy proxy proxy!) this works great. > Now what's really neat about this is, I have been > trying to think of a good way to implement dynamic > configuration for a web application... and this looks > like it could fit perfectly. When your user begins a > new work flow you can "load" the configuration by > requesting a new session scoped bean factory... Which > would actually load the configuration file at that > time and retain all the setings until it was > explicitly refreshed or better yet, removed from > session and a new one loaded when the next workflow > started. =) > > Now all that is needed is to have the various spring > MVC stuff look for a session bean factory BEFORE they > look at the application bean factory. This would > allow per user configuration state to be maintained.. > which is exactly what you need for a dynamically > configurable application... Because you may need to > maintain whatever the configuration was when the user > started the current workflow.. but if their session > times out, or if they finish the workflow subsequent > operations should use the new configuration with the > updates. Exactly! -Brian |
|
From: bryan <nih...@gm...> - 2004-09-20 20:42:39
|
I may have you completely wrong but here is a question. So people using hibernate session factories etc would have one session factory built for every user logged into the web container ? There are a lot of things like this that have a high startup cost. --b On Mon, 20 Sep 2004 16:26:57 -0400, Brian McCallister <br...@ap...> wrote: > On Sep 20, 2004, at 4:01 PM, Rob Butler wrote: > > > Hey Brian, > > > > I don't know about using separate bean factories for > > handling session state because usually bean factories > > are for creating new (prototype) objects or dishing up > > singletons, not storing objects that have been > > manipulated in the application. > > Really, what I want are the one-per-scope "singleton" instances. The > session-scoped "singleton" is a PERFECT place for sticking session > state, particularly when child factories can build their prototypes > from it. > > > I don't think bean factories will do what your looking to do. > > Quite possibly not, I have spent a lot more time in the pico world, but > Rod has been doing a good job of trying to get me to convert ;-) > > > If your really set on trying this approach though you > > can construct a new bean factory and then store it in > > session. You can set it's parent to be the > > application bean factory, and set where to read it's > > config file from. > > That is exactly what I want. Ideally the beans could sit in the session > directly and be proxied in the container, but as long as the > container/factory/context is session compatible (serializable and able > to rebuild dependencies intelligently after serialization (proxy proxy > proxy!) this works great. > > > Now what's really neat about this is, I have been > > trying to think of a good way to implement dynamic > > configuration for a web application... and this looks > > like it could fit perfectly. When your user begins a > > new work flow you can "load" the configuration by > > requesting a new session scoped bean factory... Which > > would actually load the configuration file at that > > time and retain all the setings until it was > > explicitly refreshed or better yet, removed from > > session and a new one loaded when the next workflow > > started. > > =) > > > > > Now all that is needed is to have the various spring > > MVC stuff look for a session bean factory BEFORE they > > look at the application bean factory. This would > > allow per user configuration state to be maintained.. > > which is exactly what you need for a dynamically > > configurable application... Because you may need to > > maintain whatever the configuration was when the user > > started the current workflow.. but if their session > > times out, or if they finish the workflow subsequent > > operations should use the new configuration with the > > updates. > > Exactly! > > > > -Brian > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: Brian M. <br...@ap...> - 2004-09-20 21:05:27
|
No, but hibernate sessions are a good example: Imagine three factories containing components, each with the parent (one above) as parent container). Format is as follows (ScopeName (ComponentName(ComponentDependencyList) OtherComponent)) (Application (HibernateSessionFactory(DataSource) DataSource Catalog)) (Session (ShoppingCart)) (Request (LazyHibernateSession(HibernateSessionFactory) AddToCartThrowAwayController(LazyHibernateSession, Catalog))) If 500 AddToCartThrowAwayController's are instantiated at any one time there will be in the application 1 Catalog, 1 HibernateSessionFactory, 500 + n ShoppingCart instances (where n is number still in sessions), 500 LazyHibernateSession instances, and 500 AddToCartThrowAwayController instances. Hibernate Session is actually not a great example for this because of the "session" namespace collision. Ah well =) Each HttpSession contains a ShoppingCart (or rather, contains a context which contains a shopping cart), each HttpServletRequest (on the AddToCartThrowAwayController controller) contains a context which contains a LazyHibernateSession and an AddToCartThrowAwayController. The parent context/factory for each of the request context/factories (someone throw me a bone with Spring idiosyncratic terminology here ;-) has its respective session set as parent, and all session ones (heh) have the application (servlet context, really) one. Make sense? -Brian On Sep 20, 2004, at 4:42 PM, bryan wrote: > I may have you completely wrong but here is a question. > > So people using hibernate session factories etc would have > one session factory built for every user logged into the web > container ? > > There are a lot of things like this that have a high startup > cost. > > --b > > > > On Mon, 20 Sep 2004 16:26:57 -0400, Brian McCallister > <br...@ap...> wrote: >> On Sep 20, 2004, at 4:01 PM, Rob Butler wrote: >> >>> Hey Brian, >>> >>> I don't know about using separate bean factories for >>> handling session state because usually bean factories >>> are for creating new (prototype) objects or dishing up >>> singletons, not storing objects that have been >>> manipulated in the application. >> >> Really, what I want are the one-per-scope "singleton" instances. The >> session-scoped "singleton" is a PERFECT place for sticking session >> state, particularly when child factories can build their prototypes >> from it. >> >>> I don't think bean factories will do what your looking to do. >> >> Quite possibly not, I have spent a lot more time in the pico world, >> but >> Rod has been doing a good job of trying to get me to convert ;-) >> >>> If your really set on trying this approach though you >>> can construct a new bean factory and then store it in >>> session. You can set it's parent to be the >>> application bean factory, and set where to read it's >>> config file from. >> >> That is exactly what I want. Ideally the beans could sit in the >> session >> directly and be proxied in the container, but as long as the >> container/factory/context is session compatible (serializable and able >> to rebuild dependencies intelligently after serialization (proxy proxy >> proxy!) this works great. >> >>> Now what's really neat about this is, I have been >>> trying to think of a good way to implement dynamic >>> configuration for a web application... and this looks >>> like it could fit perfectly. When your user begins a >>> new work flow you can "load" the configuration by >>> requesting a new session scoped bean factory... Which >>> would actually load the configuration file at that >>> time and retain all the setings until it was >>> explicitly refreshed or better yet, removed from >>> session and a new one loaded when the next workflow >>> started. >> >> =) >> >>> >>> Now all that is needed is to have the various spring >>> MVC stuff look for a session bean factory BEFORE they >>> look at the application bean factory. This would >>> allow per user configuration state to be maintained.. >>> which is exactly what you need for a dynamically >>> configurable application... Because you may need to >>> maintain whatever the configuration was when the user >>> started the current workflow.. but if their session >>> times out, or if they finish the workflow subsequent >>> operations should use the new configuration with the >>> updates. >> >> Exactly! >> >> >> >> -Brian >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >> Project Admins to receive an Apple iPod Mini FREE for your judgement >> on >> who ports your project to Linux PPC the best. Sponsored by IBM. >> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
|
From: bing r. <br...@bn...> - 2004-09-21 09:21:44
|
Hi, This may not be what you want, but I have been fascinated by the jsf-spring project (http://jsf-spring.sourceforge.net) and one of the nice features it provides is to allow me to place Spring beans in the web scopes I like. Of course if you hate jsf.... Bing -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Brian McCallister Sent: Tuesday, September 21, 2004 3:01 AM To: spr...@li... Subject: [Springframework-developer] SpringMVC BeanFactory/Component Scopes I may be wrong in thinking that this doesn't exist in Spring, if I am, please tell me! I cannot find anything though. In the SpringMVC configurator I would like to have scope BeanFactory instances. One, as currently, in the application scope, one in the session, and one in the request. Each factory would have the higher scope as its parent. The primary reason for this is that I would like to have strongly typed session scoped components. public class ThrowAwayFooController { private BarComponent bar; public void setBarComponent(BarComponent bar) { this.bar = bar; } public void doStuff() { bar.setSomeSessionData("wombats!"); } } would sit in the request scope factory as a singleton, the BarComponent (following) public class BarComponent { private String animalType; public void setBarComponent(BarComponent bar) { this.bar = bar; } public void setSomeSessionData(final String animalsType) { this.animalType = animalType; } public String getAnimalType() { return animalType; } } would be in the session scope factory. Later throwaway controllers could also be dependent on BarComponent and receive the same one. This provides a much cleaner way of handling session state than using a flat map, I think. It also allows you to change component scopes by simply moving them to a different factory -- presuming the hierarchy is respected, nothing changes (say a stateful thing becomes stateless so can be moved to the application scope, or vice versa). Thoughts? -Brian ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |