FAQ

[Turbine-dev] cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/pull TurbinePullService.java

Colin Chalmers
Mar 22, 2003 at 7:05 am
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" <chris@fenetics.com>
To: "Turbine Developers List" <turbine-dev@jakarta.apache.org>
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
Sent: Friday, March 21, 2003 6:57 AM
To: turbine-dev@jakarta.apache.org
Subject: Tool Scoles (test application url inside. :-) )


"Quinton McCombs" <qmccombs@nequalsone.com> 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
hps@intermeta.de +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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
reply

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions