Haven't ran into this problem yet since all our users need to log in but do
see the logic.

I too  would like to see an official way of storing things in the session
directly.

Colin

----- Original Message -----
From: "Chris K Chew" <[EMAIL PROTECTED]>
To: "Turbine Developers List" <[EMAIL PROTECTED]>
Sent: Friday, March 21, 2003 6:50 PM
Subject: RE: Tool Scoles (test application url inside. :-) )


> Hi Henning.
>
> I like the idea of a Tool tutorial.
>
> For other readers, note that the war is mapped to /app, so I started
tomcat
> and browsed to http://localhost/tooltime-1.0/app/ to get started.
>
> FYI, I couldn't get the "Restart new Session" link to work with IE6, with
or
> without cookies.  I think this is something we would want to work on
before
> it is rolled out.
>
> As far as the doco, how do you picture the logistics working?  Do we put
the
> war and source on the turbine web server, and then refer to it in the
Tools
> section?
>
> And as far as the authorized tool scope, I am a big fan of it.  I also
agree
> with Quinton that session tools should be available pre and post login.
> Putting session tools in the session seems like a logical why to do this.
I
> have secretly thought for some time now that user.setTemp() was awkward.
I
> would like to see an official way of storing things in the session
directly.
>
> Thanks,
>
> Chris
>
> > -----Original Message-----
> > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 21, 2003 6:57 AM
> > To: [EMAIL PROTECTED]
> > Subject: Tool Scoles (test application url inside. :-) )
> >
> >
> > "Quinton McCombs" <[EMAIL PROTECTED]> writes:
> >
> > >> If you have a session tool added with the anonymous user, you
> > >> get these added to the anonymous users temp data. This
> > >> happens in the Velocity Service _before_ the login action is
> > >> run. Now you log an user in and get a new user object
> > >> _without_ the session tools and your first screen will not
> > >> have any session tools.
> >
> > Quinton,
> >
> > it is much worse. Even with the current code, the session tools might
> > change if an user logs in a second time while the first is still
> > active.
> >
> > I was thinking long and hard about this but didn't come to a really
> > good idea. So I decided to get a little more visual about the tool
> > scopes and wrote a test application. :-)
> >
> > You can get it from
> >
> > ftp://ftp.hometree.net/pub/java/tooltime/tooltime-1.0.war
> >
> > and the source from
> >
> > ftp://ftp.hometree.net/pub/java/tooltime/tooltime-1.0.tar.gz
> >
> > The included turbine-2.3-dev.jar has a few patches, noticeably one for
> > debugging the pool code which forces the pool to hand out a new object
> > for each request until the pool is half full. By doing so, you will
catch
> > bugs where you expect to get the same object all the time but in reality
> > the object goes through the pool, gets recycled and you get the same
> > object by accident (or because there isn't enough pressure on the pool).
> >
> > You can control this behaviour by setting
services.PoolService.pool.debug
> > to true or false. I intent to put these fixes into the jakarta
repository
> > sometime later.
> >
> > This might be interesting for people not too much into this specific
> > problems; the source/war contains a working (:-) ) application on
> > Turbine-2.3 dev HEAD using pull tools and a dummy security service
> > (you can log on with any user and any password and get authenticated).
> >
> > You can try this app out by simply dropping the .war into your webapps
> > directory of your servlet container and restarting (or deploying,
> > whatever).  Success stories welcome!
> >
> > Chris, I'm more than willing to donate that code to the documentation
> > project as an example for tool scopes and stuff. Please take look at
> > it.
> >
> > The displayed ids are the HashCodes of the tool objects, you can
> > verify which object you got by looking at the ids.
> >
> > There are two authentication scopes in this applications. They can be
> > used simultaneously.
> >
> > - The "classic" Turbine scope. The app has either an anonymous User
> >   object which is never logged in or a "real" user which is logged in.
> >
> > - A scope with I use in one application. Here you can select a user
> >   first and then authenticate it later (no, in the real application you
> >   must authenticate in the first step too, there is no simple pulldown)
> >
> >   Here you can have
> >
> >   - an anonymous user which is never logged in
> >   - a real user object that has never logged in
> >   - a real user object that is logged in
> >   - a real ser object that is not logged in but has been logged in
before
> >
> > Problems that I currently see:
> >
> >   - Tools right after selecting the user compared to the tools after
> >     the next "Reload page"
> >
> >   - Tools right after authorization compared to the tools after the
> >     next "Reload page". Same after "unauthorize".
> >
> >   - The session tools "jump" if you log in the same user from two
browser
> >     windows (set "accept cookies" to false in your browser or the
> >     container to provide cookie free session ids) with different
sessions.
> >
> >
> > I will think about the tool scopes on the weekend and send out some
ideas
> > while doing so. Discussion very welcome!
> >
> > >But this is a breaking change.  It has been possible up until now to
> >
> > Yep. I have such a comment in our internal CVS, I forgot to transfer it
> > to jakarta. My fault, sorry.
> >
> > >have session pull tools available before the user logs in.  There is a
> > >Scarab issue for the the issue with losing the session scope tools
after
> > >the login executes.  I have a simple hack in my application to avoid
> > >this problem.
> >
> > Ok, we definitely need to think about this much harder. =:-(
> >
> > >I am looking at a way to fix the problem with session scope tools being
> > >removed by login.  IMHO, session scope tools should not be in the user.
> > >They should be in the session.  I just don't have this working cleanly
> > >enough to commit yet.
> >
> > Yes.
> >
> > Regards
> > Henning
> >
> > --
> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> > [EMAIL PROTECTED]        +49 9131 50 654 0   http://www.intermeta.de/
> >
> > Java, perl, Solaris, Linux, xSP Consulting, Web Services
> > freelance consultant -- Jakarta Turbine Development  -- hero for hire
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to