"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]

Reply via email to