"Chris K Chew" <[EMAIL PROTECTED]> writes: >Hi Henning.
>I like the idea of a Tool tutorial. Hi, >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. yep. I was thinking about this tonight and realized that I omitted this information. >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. Ok, I should change this to explicit session invalidation. >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? How about jakarta-turbine-apps repository and simply putting the source in there? Hopefully we will get more than just one app. We could move and (update) Flux tool there, too. >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. Having the session tool hanging off the user also introduces some possible cross-login issues if your security service hands out the same user object if a user logs in twice (that's what I provoked in the DummySecurityService). Having a tool scope in the session itself makes me sleep much better. :-) I will look over Quintons code because I'd like to separate out the tool storage from the user and the session and streamline it. But the main idea is IMHO very good. Regards Henning >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] -- 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]
