Re: [shale] mailreader question

[Wendy Smoak <ws...@gmail.com>]

On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> >
> > > How do *you* know that it's a session scoped bean
> > > (versus perhaps being in some other scope)?
> >
> > Because I put it there.  The question first came up when I put my
> > usual authentication Filter (which puts a 'user' bean in session
> > scope) in front of a webapp, and then wandered around the JSF API for
> > a while trying to figure out how on earth to get it back.
>
>
> True in this specific case -- but that's an arbitrary restriction in the
> general case.  Sort of the same argument as for using dependency injection
> frameworks in the first place ... lazy instantiation may not be what you
> want for a "logged in user" bean, but it is generally quite useful.

I'm still not sure about this one.  That Filter has to be there, and I
have to be able to find that 'user' bean later.  If 'getBean' is the
recommended way to retrieve beans in a ViewController... what happens
if I go ahead and declare the 'user' as a session scoped managed bean,
knowing that the Filter will put it in session scope?

As far as I can tell, the framework should "notice" that the user bean
is already there, and not try to create one.  (If the app is ever in a
state where the user bean is *not* in session scope, things have gone
horribly wrong.)

Or would you do this some other way?

Thanks,
--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [shale] mailreader question

[Craig McClanahan <cr...@apache.org>]

On 12/4/05, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > On 11/25/05, Wendy Smoak <ws...@gmail.com> wrote:
> > >
> > > On 11/25/05, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > > > How do *you* know that it's a session scoped bean
> > > > (versus perhaps being in some other scope)?
> > >
> > > Because I put it there.  The question first came up when I put my
> > > usual authentication Filter (which puts a 'user' bean in session
> > > scope) in front of a webapp, and then wandered around the JSF API for
> > > a while trying to figure out how on earth to get it back.
> >
> >
> > True in this specific case -- but that's an arbitrary restriction in the
> > general case.  Sort of the same argument as for using dependency
> injection
> > frameworks in the first place ... lazy instantiation may not be what you
> > want for a "logged in user" bean, but it is generally quite useful.
>
> I'm still not sure about this one.  That Filter has to be there, and I
> have to be able to find that 'user' bean later.  If 'getBean' is the
> recommended way to retrieve beans in a ViewController... what happens
> if I go ahead and declare the 'user' as a session scoped managed bean,
> knowing that the Filter will put it in session scope?
>
> As far as I can tell, the framework should "notice" that the user bean
> is already there, and not try to create one.  (If the app is ever in a
> state where the user bean is *not* in session scope, things have gone
> horribly wrong.)


That's exactly what happens.  The managed bean facility *first* checks
whether there is a bean in any scope (request, session, then application)
with the given name.  Only if there is no such bean will a new instance be
created (and put into whatever scope you have declared).

Shale doesn't need to do anything about this ... it's standard JSF behavior.

Or would you do this some other way?
>
> Thanks,
> --
> Wendy


Craig


---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>