You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <hp...@intermeta.de> on 2003/03/21 14:57:19 UTC
Tool Scoles (test application url inside. :-) )
"Quinton McCombs" <qm...@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
Re: Tool Scoles (test application url inside. :-) )
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Chris K Chew" <ch...@fenetics.com> writes:
>The future tutorial-sample-app will fit nicely in there as well. Although I
>am worried about keeping them updated with whatever versions of turbine they
>use. Maybe it would be easier to maintain them in the jakarta-turbine-2
>module -- especially if they were tested as part of the maven build process.
That's what the POM of an appliation is for. :-) We simply tag the various
versions for the various turbine releases.
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
RE: Tool Scoles (test application url inside. :-) )
Posted by Chris K Chew <ch...@fenetics.com>.
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>
> "Chris K Chew" <ch...@fenetics.com> writes:
>
> >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.
The future tutorial-sample-app will fit nicely in there as well. Although I
am worried about keeping them updated with whatever versions of turbine they
use. Maybe it would be easier to maintain them in the jakarta-turbine-2
module -- especially if they were tested as part of the maven build process.
Thanks,
Ck
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Tool Scoles (test application url inside. :-) )
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Chris K Chew" <ch...@fenetics.com> 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:hps@intermeta.de]
>> Sent: Friday, March 21, 2003 6:57 AM
>> To: turbine-dev@jakarta.apache.org
>> Subject: Tool Scoles (test application url inside. :-) )
>>
>>
>> "Quinton McCombs" <qm...@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
--
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
Re: Tool Scoles (test application url inside. :-) )
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Colin Chalmers" <co...@maxware.nl> writes:
>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.
data.getSession().setAttribute("foo", fooObject);
is IMHO the 'official' way. Or
$data.Session.setAttribute("foo", $foo)
#set ($foo = $!data.Session.getAttribute("foo"))
from Velocity.
A tool which can do
$session.put("foo", $foo);
#set ($foo = $!session.foo)
is pretty simple. It should look like this:
Tr.props:
tool.global.session = de.intermeta.tools.SessionTool
--- cut ---
package de.intermeta.tools;
import org.apache.turbine.services.pull.RunDataApplicationTool
import org.apache.turbine.util.RunData;
public class SessionTool
implements RunDataApplicationTool
{
private RunData data = null;
public SessionTool()
{
}
public void init(Object obj)
{
}
public void refresh(Object obj)
{
this.data = (RunData) obj;
}
public void put(String key, Object val)
throws Exception
{
data.getSession().setAttribute(key, val);
}
public Object get(String key)
throws Exception
{
return data.getSession().getAttribute(key)
}
}
--- cut ---
Regards
Henning
>Colin
>----- Original Message -----
>From: "Chris K Chew" <ch...@fenetics.com>
>To: "Turbine Developers List" <tu...@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 [mailto:hps@intermeta.de]
>> > Sent: Friday, March 21, 2003 6:57 AM
>> > To: turbine-dev@jakarta.apache.org
>> > Subject: Tool Scoles (test application url inside. :-) )
>> >
>> >
>> > "Quinton McCombs" <qm...@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
--
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
Re: Tool Scoles (test application url inside. :-) )
Posted by Colin Chalmers <co...@maxware.nl>.
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" <ch...@fenetics.com>
To: "Turbine Developers List" <tu...@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 [mailto:hps@intermeta.de]
> > Sent: Friday, March 21, 2003 6:57 AM
> > To: turbine-dev@jakarta.apache.org
> > Subject: Tool Scoles (test application url inside. :-) )
> >
> >
> > "Quinton McCombs" <qm...@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
RE: Tool Scoles (test application url inside. :-) )
Posted by Quinton McCombs <qm...@nequalsone.com>.
I will put together a simple session tool that can be used to replace
setTemp() and getTemp(). We should document this in the tutorial.
--------------------------------------------
Quinton McCombs
NequalsOne - HealthCare marketing tools
mailto:qmccombs@NequalsOne.com
http://www.NequalsOne.com
> -----Original Message-----
> From: Chris K Chew [mailto:chris@fenetics.com]
> Sent: Friday, March 21, 2003 11:50 AM
> To: Turbine Developers List
> 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:hps@intermeta.de]
> > Sent: Friday, March 21, 2003 6:57 AM
> > To: turbine-dev@jakarta.apache.org
> > Subject: Tool Scoles (test application url inside. :-) )
> >
> >
> > "Quinton McCombs" <qm...@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
RE: Tool Scoles (test application url inside. :-) )
Posted by Chris K Chew <ch...@fenetics.com>.
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:hps@intermeta.de]
> Sent: Friday, March 21, 2003 6:57 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Tool Scoles (test application url inside. :-) )
>
>
> "Quinton McCombs" <qm...@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
RE: Tool Scoles (test application url inside. :-) )
Posted by Quinton McCombs <qm...@nequalsone.com>.
Nice tool for testing the tool scopes....
--------------------------------------------
Quinton McCombs
NequalsOne - HealthCare marketing tools
mailto:qmccombs@NequalsOne.com
http://www.NequalsOne.com
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Friday, March 21, 2003 7:57 AM
> To: turbine-dev@jakarta.apache.org
> Subject: Tool Scoles (test application url inside. :-) )
>
>
> "Quinton McCombs" <qm...@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