Mike,
Yeah, I was trying to make that point as well that scoped components and IOC
don't work well together. I realized after I sent the message that didn't
state that anywhere. Thanks for putting it in clear english. :-)
Cheers,
Jon...
----- Original Message -----
From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 24, 2003 12:03 PM
Subject: Re: [OS-webwork] Issue with component lifecycle dependencies
> Jon,
>
> Ahh yes - that's exactly the model we use too :)
>
> My point below was that mixing 'scoped components' together in an IOC
> framework (specifically narrowing the scope) is a thread nightmare.
>
> This is exactly the reason you can't do it (xwork won't let you) and the
> reason that a ThreadLocal + IoC approach is the way to go.
>
> Sorry if I wasn't clear.
>
> Cheers,
> Mike
>
> On 24/9/03 5:46 PM, "Jon Lipsky" ([EMAIL PROTECTED]) penned the
> words:
>
> > Hi...
> >
> > I do this exact same thing with WebWork2 right now, however I use a
> > ServletFilter and ThreadLocal variables to solve it.
> >
> > I have an app scoped component called PersistanceManager (PM)
> >
> > When a request comes in (A) it calls PM.getSession() and puts thes the
> > session (SA) in the request and into a ThreadLocal variable.
> >
> > When a request comes in (B) it calls PM.getSession() and puts thes the
> > session (SB) in the request and into a ThreadLocal variable.
> >
> > Similary, the request is finished the ServletFilter takes care of
closing
> > the session when the request is done.
> >
> > During the course of the request, the the code can just call methods
like
> >
> > PM.create(theObject);
> > PM.delete(theObject);
> >
> > What this really does is get this:
> >
> > public create(Object aObject)
> > {
> > // Get the session from the Thread Local variable
> > Object vSession = threadLocalSession.get();
> >
> > create(vSession,aObject);
> > }
> >
> > public create(Object aSession, Object aObject)
> > {
> > ... Insert create code here ...
> > }
> >
> > What this gives me is the abilitiy to have fine control over the session
> > usage if I want, but for 99% of the time I can just assume the Session
is
> > already created in a ThreadLocal variable and happily go on my way. I
can
> > think of only 1 case that I have ever needed to open/close/manage the
> > session manually once this version of the PersistanceManager and the
> > ServletFilter were in place.
> >
> > Jon...
> >
> > BTW - I've used this pattern with Hibernate, JDBC and Prevayler with out
any
> > problems. (That is the reason the Session object is typed as an Object,
> > because when I used this pattern with JDBC, then the session object is
> > really a Connection object).
> >
> > ----- Original Message -----
> > From: "Mike Cannon-Brookes" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 24, 2003 8:34 AM
> > Subject: Re: [OS-webwork] Issue with component lifecycle dependencies
> >
> >
> >> Uhm - please explain how it would be done? (could be done?)
> >>
> >> App scoped component : PersistenceManager (PM)
> >>
> >> There is therefore only one PM.
> >>
> >> Request scoped component: HibernateSession (HS)
> >>
> >> Two requests come in A and B, each with a request scoped component (HS
A
> > and
> >> HS B)
> >>
> >> A calls PM.setSession(HS A);
> >> B calls PM.sesSession(HS B);
> >> A calls PM.save();
> >>
> >> Now you're f'ked because request A is using HS B? :)
> >>
> >> This causes no end of pain as far as I can see. I'm not even sure how
you
> >> could possibly string them together?
> >>
> >> Mike
> >>
> >> On 24/9/03 2:24 PM, "Pat Lightbody" ([EMAIL PROTECTED]) penned the
> > words:
> >>
> >>> I'd actually like to support this eventually (maybe 2.1). The reason
for
> >>> this is that most DB-based resources need to be request-scoped, but
> > really
> >>> only the DB (ie: Hibernate session) needs to. No reason why everything
> > else
> >>> must get dragged down to that level as well. Since WebWork (read: NOT
> > XWork)
> >>> can assume that a request scope can map directly to a single session
> > scope,
> >>> then this is totally possible (albeit hard).
> >>>
> >>> -Pat
> >>>
> >>> ----- Original Message -----
> >>> From: "Jason Carreira" <[EMAIL PROTECTED]>
> >>> To: <[EMAIL PROTECTED]>
> >>> Sent: Tuesday, September 23, 2003 8:20 PM
> >>> Subject: RE: [OS-webwork] Issue with component lifecycle dependencies
> >>>
> >>>
> >>> Umm... Because it's hard? :-)
> >>>
> >>> You'd have to have things stored in ThreadLocals and re-bound for
every
> >>> request, I think...
> >>>
> >>>> -----Original Message-----
> >>>> From: Christian Meunier [mailto:[EMAIL PROTECTED]
> >>>> Sent: Tuesday, September 23, 2003 11:14 PM
> >>>> To: [EMAIL PROTECTED]
> >>>> Subject: [OS-webwork] Issue with component lifecycle dependencies
> >>>>
> >>>>
> >>>> Hi,
> >>>>
> >>>> looking at the doc i see "Note that while components are
> >>>> allowed to have
> >>>> dependencies on other components they must not depend on another
> >>>> component that is of a narrower scope" , is there a good
> >>>> reason why we
> >>>> have this limitation, there are many good cases where an application
> >>>> scoped components could depend on a session scoped/request scoped
> >>>> component and it does not look like it's supported at the moment.
> >>>>
> >>>> Regards
> >>>> Christian Meunier
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------
> >>>> This sf.net email is sponsored by:ThinkGeek
> >>>> Welcome to geek heaven.
> >>>> http://thinkgeek.com/sf
> >>>> _______________________________________________
> >>>> Opensymphony-webwork mailing list
> >>>> [EMAIL PROTECTED]
> >>>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This sf.net email is sponsored by:ThinkGeek
> >>> Welcome to geek heaven.
> >>> http://thinkgeek.com/sf
> >>> _______________________________________________
> >>> Opensymphony-webwork mailing list
> >>> [EMAIL PROTECTED]
> >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This sf.net email is sponsored by:ThinkGeek
> >>> Welcome to geek heaven.
> >>> http://thinkgeek.com/sf
> >>> _______________________________________________
> >>> Opensymphony-webwork mailing list
> >>> [EMAIL PROTECTED]
> >>> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This sf.net email is sponsored by:ThinkGeek
> >> Welcome to geek heaven.
> >> http://thinkgeek.com/sf
> >> _______________________________________________
> >> Opensymphony-webwork mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> >>
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Opensymphony-webwork mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
