You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Ulrich Mayring <ul...@denic.de> on 2000/07/20 12:35:49 UTC
cooperative session handling (was: Dynamic XML generation)
Jeremy Quinn wrote:
>
> So instead of invalidating the whole session, just remove your stuff from
> it
> (just keep your hands of my values, right? :)
I think what we need to do is this:
to create a session or use an existing one:
request.getSession(true);
if (((String) session.getValue("myprefix:myprefix")).equals("true")) {
// my session already exists
}
else {
// this session is a new one for me (but may have existed before for
another taglib)
session.putValue("myprefix:myprefix","true");
}
to save values in a session:
session.putValue("myprefix:myname",value);
to get values from a session:
session.getValue("myprefix:myname",value);
to end my session:
remove all myprefix:* values from session
check if there are any other values left (are there any "standard"
values, which we must ignore?)
if yes: do nothing
if no: session.invalidate();
I am using session.getValue and session.putValue here, which are
deprecated as of JSDK2.2, but I think we should use them for backwards
compatibility to JSDK2.1 (which JServ needs).
Any comments?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> I don't know what kind of overhead this produces, or if this is considered
> good practice. It is the only way I can think of handling it safely when
> several TagLibs or Servlets on the same machine could be sharing a session
> object to keep data in.
You are right, so I'll do it like that.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 21:49 +0200 20/07/00, Uli Mayring wrote:
>On Thu, 20 Jul 2000, Jeremy Quinn wrote:
>Yeah, the session times out after one hour in my case, so you
>theoretically can have the user surfing unprotected pages for one hour and
>the servlet engine keeps the session needlessly. Is this overhead
>negligible?
I don't know what kind of overhead this produces, or if this is considered
good practice. It is the only way I can think of handling it safely when
several TagLibs or Servlets on the same machine could be sharing a session
object to keep data in.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
child node
Posted by tc...@dff.st.
Lets say I have a template that is matched
against "text". Now I want to check if there
is a child node named "defaulttext". If there
is one I want to apply it's template.
I was thinking of something like the following but
I guess my XPath syntax for the test is not correct.
XML:
<text>
<sometag>bla</sometag>
<defaulttext>blub</defaulttext>
</text>
XSL:
<xsl:template match="text">
<xsl:choose>
<xsl:when test="@url">
...
</xsl:when>
<xsl:when test="child::defaulttext">
<xsl:apply-templates select="child::defaulttext"/>
</xsl:when>
</xsl:choose>
</xsl:template>
<xsl:template match="defaulttext">
<h1><xsl:apply-templates/></h1>
</xsl:template>
--
Torsten
Re: Cocoon UML Diagrams (in HTML)
Posted by Alex Ferrer <al...@home.com>.
Don't want to get off topic here, (if anyone wants you can email me directly)
but I can't believe that their use (UML) is not wide spread, to me it makes
the process of getting aquainted with a new piece of software much easier.
Anyway yes I built them with TogetherJ, a pretty cool UML tool (pure java) ..
it is pretty expensive (like $2000!) but I got this from their site
www.togethersoft.com, and a 1 month time key to try it.
The diagram builds itself (pretty easy), the printout is also neat, but the
tool itself is really awsome..
Any more info, contact me directly so we dont "contaminate" the list .. I'll
be glad to answer any questions.
alx.
Alex Ferrer
alex@ftconsult.com
Chris Todd wrote:
> OK, my bad, I should have done "View Source" prior to posting this
> question...
>
> So you use Together to produce these kinds of diagrams, huh? Did you have
> to create all the UML diagrams yourself? Did Together generate the Java
> docs and navigation frames automatically? I know this is off-topic, and
> asking for details about a commercial software package that has nothing to
> do with Cocoon, so perhaps you could email me directly. I'd love to know
> what you had to do to produce those web pages (that is, how easy or
> difficult it was).
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
RE: Cocoon UML Diagrams (in HTML)
Posted by Chris Todd <cl...@bellatlantic.net>.
OK, my bad, I should have done "View Source" prior to posting this
question...
So you use Together to produce these kinds of diagrams, huh? Did you have
to create all the UML diagrams yourself? Did Together generate the Java
docs and navigation frames automatically? I know this is off-topic, and
asking for details about a commercial software package that has nothing to
do with Cocoon, so perhaps you could email me directly. I'd love to know
what you had to do to produce those web pages (that is, how easy or
difficult it was).
Sincerest regards,
Chris Todd
Software Engineer
Alabanza Corporation
ctodd@alabanza.com
> -----Original Message-----
> From: Chris Todd [mailto:cltodd@bellatlantic.net]
> Sent: Saturday, July 22, 2000 1:48 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: Cocoon UML Diagrams (in HTML)
>
>
> OK, I know this is a little off-topic, but those pages are
> really too-cool!
> How did you make them? Is there a software package you used?
> Did you use
> Alexandria? I simply have to know, as my company could
> really make use of
> this kind of coordinated documentation.
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
>
> > -----Original Message-----
> > From: Alex Ferrer [mailto:alexferrer@home.com]
> > Sent: Thursday, July 22, 1999 12:39 PM
> > To: cocoon-users@xml.apache.org
> > Subject: Cocoon UML Diagrams (in HTML)
> >
> >
> > FYI,
> > This is not a big deal but I made a set of UML diagrams &
> > JavaDocs for cocoon
> > (In HTML) , it is pretty helpfull in understanding the
> > overall picture, if
> > anybody cares for them they are at:
> > http://www.ftconsult.com/cocoonUML/
> >
> > note: you can navigate the diagrams with a click of the mouse.
> >
> > enjoy
> > alx.
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: Cocoon UML Diagrams (in HTML)
Posted by Mark Washeim <31...@t-online.de>.
on 22/7/00 7:47 pm, Chris Todd at cltodd@bellatlantic.net wrote:
> OK, I know this is a little off-topic, but those pages are really too-cool!
> How did you make them? Is there a software package you used? Did you use
> Alexandria? I simply have to know, as my company could really make use of
> this kind of coordinated documentation.
>
> Sincerest regards,
> Chris Todd
> Software Engineer
> Alabanza Corporation
> ctodd@alabanza.com
>
>
>> -----Original Message-----
>> From: Alex Ferrer [mailto:alexferrer@home.com]
>> Sent: Thursday, July 22, 1999 12:39 PM
>> To: cocoon-users@xml.apache.org
>> Subject: Cocoon UML Diagrams (in HTML)
>>
>>
>> FYI,
>> This is not a big deal but I made a set of UML diagrams &
>> JavaDocs for cocoon
>> (In HTML) , it is pretty helpfull in understanding the
>> overall picture, if
>> anybody cares for them they are at:
>> http://www.ftconsult.com/cocoonUML/
>>
>> note: you can navigate the diagrams with a click of the mouse.
>>
>> enjoy
>> alx.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
>> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Those pages were made with togetherJ the java modeling tool
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
RE: Cocoon UML Diagrams (in HTML)
Posted by Chris Todd <cl...@bellatlantic.net>.
OK, I know this is a little off-topic, but those pages are really too-cool!
How did you make them? Is there a software package you used? Did you use
Alexandria? I simply have to know, as my company could really make use of
this kind of coordinated documentation.
Sincerest regards,
Chris Todd
Software Engineer
Alabanza Corporation
ctodd@alabanza.com
> -----Original Message-----
> From: Alex Ferrer [mailto:alexferrer@home.com]
> Sent: Thursday, July 22, 1999 12:39 PM
> To: cocoon-users@xml.apache.org
> Subject: Cocoon UML Diagrams (in HTML)
>
>
> FYI,
> This is not a big deal but I made a set of UML diagrams &
> JavaDocs for cocoon
> (In HTML) , it is pretty helpfull in understanding the
> overall picture, if
> anybody cares for them they are at:
> http://www.ftconsult.com/cocoonUML/
>
> note: you can navigate the diagrams with a click of the mouse.
>
> enjoy
> alx.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Cocoon UML Diagrams (in HTML)
Posted by Alex Ferrer <al...@home.com>.
FYI,
This is not a big deal but I made a set of UML diagrams & JavaDocs for cocoon
(In HTML) , it is pretty helpfull in understanding the overall picture, if
anybody cares for them they are at: http://www.ftconsult.com/cocoonUML/
note: you can navigate the diagrams with a click of the mouse.
enjoy
alx.
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 22 Jul 2000, Jeremy Quinn wrote:
> I think there will be a mixture.
> I think Uli want's his TagLib to control the Session itself, while I want
> people to be able to use the Session TagLib mixed in with FP TagLib.
Well, I wanted to, but you guys convinced me to give it up :)
Presently I am putting auth:auth with value "true" into the session,
whenever I request it. That tells me that I have used this session before.
When the user is successfully authenticated I put auth:id with value
[auth-scheme-name] into the session. When the user logs out, I delete all
values from the session, whose names start with auth:
Uli
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:31 -0400 21/07/00, Donald Ball wrote:
>> - a method to check, if this session is my session (by passing it the
>> taglib prefix I use)
>> - a method to delete all values starting with the prefix passed to it
>
>ooh, that'd be clever. of course, are y'all using the session taglib from
>your taglibs or talking to the session object directly?
I think there will be a mixture.
I think Uli want's his TagLib to control the Session itself, while I want
people to be able to use the Session TagLib mixed in with FP TagLib.
Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Sat, 22 Jul 2000, Jeremy Quinn wrote:
> Identify common functionalities, encode them as TagLibs and all of a sudden
> the number of people who can use them grows outside of Java Programmers.
>
> This is extremely empowering!
Yeah, except that for learning this taglib stuff and finding out what
tags are available the users have to read the Java API and the source code
:-)
Still, you are right, of course, I was speaking from the very narrow point
of view of myself and forgot about the rest of the world. Not good :)
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 01:14 +0200 22/07/00, Uli Mayring wrote:
>On Fri, 21 Jul 2000, Donald Ball wrote:
>
>> ooh, that'd be clever. of course, are y'all using the session taglib from
>> your taglibs or talking to the session object directly?
>
>I'm talking directly, do you think I'm a whimp? :-)
>
>Seriously, I am wondering about the usefulness of the session (and some
>other) taglibs. I mean, if you make a taglib that just wraps the API
>methods, then you don't get anything new. Compare:
>
><response:send-redirect href="somewhere.xml"/>
>
>response.sendRedirect("somewhere.xml");
>
>I mean, what's the point besides aesthetic completeness?
A well designed TagLib lets a non-programmer (who is able to at least
understand the problem) effectively write a Servlet, just by using simple
XML Tags.
I think this is a very important benefit!
>A taglib should be like the util taglib, which incorporates a number of
>really useful functions, which are not available anywhere else.
I would rather deal with a few simple Tags than having Java Code exposed in
my XSP Pages (though this is nice too :).
Identify common functionalities, encode them as TagLibs and all of a sudden
the number of people who can use them grows outside of Java Programmers.
This is extremely empowering!
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sat, 22 Jul 2000, Uli Mayring wrote:
> On Fri, 21 Jul 2000, Donald Ball wrote:
>
> > ooh, that'd be clever. of course, are y'all using the session taglib from
> > your taglibs or talking to the session object directly?
>
> I'm talking directly, do you think I'm a whimp? :-)
>
> Seriously, I am wondering about the usefulness of the session (and some
> other) taglibs. I mean, if you make a taglib that just wraps the API
> methods, then you don't get anything new. Compare:
>
> <response:send-redirect href="somewhere.xml"/>
>
> response.sendRedirect("somewhere.xml");
>
> I mean, what's the point besides aesthetic completeness?
well, not much really, but you can allow authors to use these utility
taglibs while forbidding them from using xsp: elements to call java
directly. that can be handy.
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Fri, 21 Jul 2000, Donald Ball wrote:
> ooh, that'd be clever. of course, are y'all using the session taglib from
> your taglibs or talking to the session object directly?
I'm talking directly, do you think I'm a whimp? :-)
Seriously, I am wondering about the usefulness of the session (and some
other) taglibs. I mean, if you make a taglib that just wraps the API
methods, then you don't get anything new. Compare:
<response:send-redirect href="somewhere.xml"/>
response.sendRedirect("somewhere.xml");
I mean, what's the point besides aesthetic completeness?
A taglib should be like the util taglib, which incorporates a number of
really useful functions, which are not available anywhere else.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 21 Jul 2000, Ulrich Mayring wrote:
> Nicola Ken Barozzi wrote:
> >
> > +1 on the facade.
> > I posted a similar idea some days ago, and this is even better. :-)
> > Don't you guys think it's a good idea?
> > Taglibs have to cooperate without authors sharing implementation
> > details.
> >
> > > Just my thoughts....
> >
> > Hey, you're not alone! :-)
>
> Well, instead of the servlet class name (which will vary depending on
> what directory the XSP page is in) I would use the taglib prefix. And I
> think everyone should always do request.getSession(true) and never
> session.invalidate()
>
> Perhaps we could share some code (or put it in the session taglib):
>
> - a method to check, if this session is my session (by passing it the
> taglib prefix I use)
> - a method to delete all values starting with the prefix passed to it
ooh, that'd be clever. of course, are y'all using the session taglib from
your taglibs or talking to the session object directly?
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 21/7/00 10:20 am, Ulrich Mayring at ulim@denic.de wrote:
> Nicola Ken Barozzi wrote:
>>
>> +1 on the facade.
>> I posted a similar idea some days ago, and this is even better. :-)
>> Don't you guys think it's a good idea?
>> Taglibs have to cooperate without authors sharing implementation
>> details.
>>
>>> Just my thoughts....
>>
>> Hey, you're not alone! :-)
>
> Well, instead of the servlet class name (which will vary depending on
> what directory the XSP page is in) I would use the taglib prefix. And I
> think everyone should always do request.getSession(true) and never
> session.invalidate()
>
Yeah, I thought you and Jeremy were on the money with the tag-lib prefix. I
was simply giving an example from another domain.
> Perhaps we could share some code (or put it in the session taglib):
>
> - a method to check, if this session is my session (by passing it the
> taglib prefix I use)
> - a method to delete all values starting with the prefix passed to it
>
> Ulrich
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Nicola Ken Barozzi wrote:
>
> +1 on the facade.
> I posted a similar idea some days ago, and this is even better. :-)
> Don't you guys think it's a good idea?
> Taglibs have to cooperate without authors sharing implementation
> details.
>
> > Just my thoughts....
>
> Hey, you're not alone! :-)
Well, instead of the servlet class name (which will vary depending on
what directory the XSP page is in) I would use the taglib prefix. And I
think everyone should always do request.getSession(true) and never
session.invalidate()
Perhaps we could share some code (or put it in the session taglib):
- a method to check, if this session is my session (by passing it the
taglib prefix I use)
- a method to delete all values starting with the prefix passed to it
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
----- Original Message -----
From: "Mark Washeim" <31...@t-online.de>
To: <co...@xml.apache.org>
Sent: Thursday, July 20, 2000 10:19 PM
Subject: Re: cooperative session handling (was: Dynamic XML generation)
> on 20/7/00 9:49 pm, Uli Mayring at ulim@denic.de wrote:
>
> > On Thu, 20 Jul 2000, Jeremy Quinn wrote:
> >
> >> so your taglib could do something like this:
> >>
> >> if there a session?
> >> if it contains my auth.stuff?
> >> go for it
> >> else
> >> login
> >> else
> >> make one
> >
> > Yeah, that's what I'm doing with the only difference that I care about
> > invalidating sessions. More below.
> >
> >> When you want to log a user out, you remove your auth:stuff from the
> >> Session, and only invalidate the session if it contains nothing else. In
> >> fact due to the multithreaded nature of the Beast, it would probably be
> >> safer never to invalidate a session, in case something else was about to
> >> use it.
> >
> > What's the session.invalidate() method for, then? Sorry if I sound dumb,
> > but I believe Sun doesn't implement random methods for fun and profits. It
> > would be much, much easier for me to implement auth: if I didn't have to
> > worry about invalidating sessions. So I am really not reluctant to take
> > your advice, it just "feels bad" not to clean up :)
> >
> >> Reading the Servlet Spec ....
> >> Sessions should be automatically invalidated by the server or Servlet
> >> engine, there should be a setting for "session persistence" in your engine.
> >> Servers can offload active sessions to file if memory gets constrained.
> >
> > Yeah, the session times out after one hour in my case, so you
> > theoretically can have the user surfing unprotected pages for one hour and
> > the servlet engine keeps the session needlessly. Is this overhead
> > negligible?
> >
> > Ulrich
>
>
> Just my two bits.
>
> In most cases where any significant number of applications are running,
> namely, most public websites running servlets, there is rarely a need for
> any individual servlet to invalidate the session.
>
> In fact, there is more overhead in the creation of session objects than
> called for.
>
> Our application framework hides the session from individual servlets and
> 'pools' the session objects, as it were. We found that running dozens of
> servlets for any given client required the session practically persistantly
> and so, added a facade to it...
>
> The facade ensures unique identity for names of keys by prefixing the
> servlet class name.
+1 on the facade.
I posted a similar idea some days ago, and this is even better. :-)
Don't you guys think it's a good idea?
Taglibs have to cooperate without authors sharing implementation
details.
> Just my thoughts....
Hey, you're not alone! :-)
nicola_ken
Nicola Ken Barozzi - AISA Industries S.p.A
http://www.aisaindustries.it/
Via Leonardo da Vinci,2 Ticengo (CR) Italy
Personal homepage at Java Guru:
http://www.jguru.com/jguru/guru/viewchannel.jsp?EID=39153
Personal FAQ at Java Guru:
http://www.jguru.com/jguru/guru/viewfaqs.jsp?EID=39153
Research Activity:
Politecnico di Milano - Dipartimento di Meccanica
Piazza Leonardo da Vinci, n.32 - 20133 Milano (Italy)
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 20/7/00 9:49 pm, Uli Mayring at ulim@denic.de wrote:
> On Thu, 20 Jul 2000, Jeremy Quinn wrote:
>
>> so your taglib could do something like this:
>>
>> if there a session?
>> if it contains my auth.stuff?
>> go for it
>> else
>> login
>> else
>> make one
>
> Yeah, that's what I'm doing with the only difference that I care about
> invalidating sessions. More below.
>
>> When you want to log a user out, you remove your auth:stuff from the
>> Session, and only invalidate the session if it contains nothing else. In
>> fact due to the multithreaded nature of the Beast, it would probably be
>> safer never to invalidate a session, in case something else was about to
>> use it.
>
> What's the session.invalidate() method for, then? Sorry if I sound dumb,
> but I believe Sun doesn't implement random methods for fun and profits. It
> would be much, much easier for me to implement auth: if I didn't have to
> worry about invalidating sessions. So I am really not reluctant to take
> your advice, it just "feels bad" not to clean up :)
>
>> Reading the Servlet Spec ....
>> Sessions should be automatically invalidated by the server or Servlet
>> engine, there should be a setting for "session persistence" in your engine.
>> Servers can offload active sessions to file if memory gets constrained.
>
> Yeah, the session times out after one hour in my case, so you
> theoretically can have the user surfing unprotected pages for one hour and
> the servlet engine keeps the session needlessly. Is this overhead
> negligible?
>
> Ulrich
Just my two bits.
In most cases where any significant number of applications are running,
namely, most public websites running servlets, there is rarely a need for
any individual servlet to invalidate the session.
In fact, there is more overhead in the creation of session objects than
called for.
Our application framework hides the session from individual servlets and
'pools' the session objects, as it were. We found that running dozens of
servlets for any given client required the session practically persistantly
and so, added a facade to it...
The facade ensures unique identity for names of keys by prefixing the
servlet class name.
Just my thoughts....
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Thu, 20 Jul 2000, Donald Ball wrote:
> what you could do is when you get the session instance, if you created
> it, record the fact that you created it. when you're done, if the session
> is otherwise empty, invalidate it.
That's precisely what I'm doing. Or, better, what I'm trying to do,
because I don't get it to work :)
It's really much harder than it sounds, at least if you're trying to make
it as user-friendly as possible.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 20 Jul 2000, Uli Mayring wrote:
> > When you want to log a user out, you remove your auth:stuff from the
> > Session, and only invalidate the session if it contains nothing else. In
> > fact due to the multithreaded nature of the Beast, it would probably be
> > safer never to invalidate a session, in case something else was about to
> > use it.
>
> What's the session.invalidate() method for, then? Sorry if I sound dumb,
> but I believe Sun doesn't implement random methods for fun and profits. It
> would be much, much easier for me to implement auth: if I didn't have to
> worry about invalidating sessions. So I am really not reluctant to take
> your advice, it just "feels bad" not to clean up :)
what you could do is when you get the session instance, if you created
it, record the fact that you created it. when you're done, if the session
is otherwise empty, invalidate it.
like so much else in the servlet spec, i don't think sun thought through
all of the issues perfectly beforehand. well, hindsight is colorblind.
- donald
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Uli Mayring <ul...@denic.de>.
On Thu, 20 Jul 2000, Jeremy Quinn wrote:
> so your taglib could do something like this:
>
> if there a session?
> if it contains my auth.stuff?
> go for it
> else
> login
> else
> make one
Yeah, that's what I'm doing with the only difference that I care about
invalidating sessions. More below.
> When you want to log a user out, you remove your auth:stuff from the
> Session, and only invalidate the session if it contains nothing else. In
> fact due to the multithreaded nature of the Beast, it would probably be
> safer never to invalidate a session, in case something else was about to
> use it.
What's the session.invalidate() method for, then? Sorry if I sound dumb,
but I believe Sun doesn't implement random methods for fun and profits. It
would be much, much easier for me to implement auth: if I didn't have to
worry about invalidating sessions. So I am really not reluctant to take
your advice, it just "feels bad" not to clean up :)
> Reading the Servlet Spec ....
> Sessions should be automatically invalidated by the server or Servlet
> engine, there should be a setting for "session persistence" in your engine.
> Servers can offload active sessions to file if memory gets constrained.
Yeah, the session times out after one hour in my case, so you
theoretically can have the user surfing unprotected pages for one hour and
the servlet engine keeps the session needlessly. Is this overhead
negligible?
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 15:52 +0200 20/07/00, Ulrich Mayring wrote:
>> yea, let XSP make the session for you.
>> why bother invalidating the session?
>
>How does XSP know when I need a session and when not?
Users of your taglib would do this
<xsp:page create-session="true">
<your stuff/>
</xsp:page>
I'm guessing ....
Your TagLib would look to see it it's own things were set up in the session
or not, the existence or not of the session is not the key, obviously if
there is no session at all you can do something about it, but you cannot
assume there will not already be one, maybe created by another
TagLib/Servlet whatever with it's stuff in it.
so your taglib could do something like this:
if there a session?
if it contains my auth.stuff?
go for it
else
login
else
make one -- this would save users remembering to do create-session="true"
login
When you want to log a user out, you remove your auth:stuff from the
Session, and only invalidate the session if it contains nothing else. In
fact due to the multithreaded nature of the Beast, it would probably be
safer never to invalidate a session, in case something else was about to
use it.
> I don't want sessions to hang around forever, this is overhead and a security
> issue.
Reading the Servlet Spec ....
Sessions should be automatically invalidated by the server or Servlet
engine, there should be a setting for "session persistence" in your engine.
Servers can offload active sessions to file if memory gets constrained.
hope this helps
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 16:03 +0200 20/07/00, Mark Washeim wrote:
>
>:) My solution is to use cookies, when I need to persist something
>indefinately. It's a bit more hassle, but it's more reliable.
Cool, your users become your user info database :)
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Mark Washeim <31...@t-online.de>.
on 20/7/00 3:52 pm, Ulrich Mayring at ulim@denic.de wrote:
> Jeremy Quinn wrote:
>>
>> yea, let XSP make the session for you.
>> why bother invalidating the session?
>
> How does XSP know when I need a session and when not? I don't want
> sessions to hang around forever, this is overhead and a security issue.
>
> Ulrich
Not to mention load-balancers will often invalidate your sessions in any
case.
This is a fairly serious problem that pertains to a higher level problem.
Namely, behaviours outside of the cocoon context which you cann't even
predict the behaviour of.
In the case of eurofootball, I'm fighting a load balancer that times
sessions out after 10 minutes! And that's to keep the load balancer for ...
crashing because of load!
:) My solution is to use cookies, when I need to persist something
indefinately. It's a bit more hassle, but it's more reliable.
--
Mark (Poetaster) Washeim
'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.
Quem colorem habet sapientia?'
Evan S. Connell
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Ulrich Mayring <ul...@denic.de>.
Jeremy Quinn wrote:
>
> yea, let XSP make the session for you.
> why bother invalidating the session?
How does XSP know when I need a session and when not? I don't want
sessions to hang around forever, this is overhead and a security issue.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: cooperative session handling (was: Dynamic XML generation)
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 12:35 +0200 20/07/00, Ulrich Mayring wrote:
>Jeremy Quinn wrote:
>>
>> So instead of invalidating the whole session, just remove your stuff from
>> it
>> (just keep your hands of my values, right? :)
>
>I think what we need to do is this:
>
>to create a session or use an existing one:
> request.getSession(true);
> if (((String) session.getValue("myprefix:myprefix")).equals("true")) {
> // my session already exists
> }
> else {
> // this session is a new one for me (but may have existed before for
>another taglib)
> session.putValue("myprefix:myprefix","true");
> }
>
>to save values in a session:
> session.putValue("myprefix:myname",value);
>
>to get values from a session:
> session.getValue("myprefix:myname",value);
>
>to end my session:
> remove all myprefix:* values from session
> check if there are any other values left (are there any "standard"
>values, which we must ignore?)
> if yes: do nothing
> if no: session.invalidate();
>
>I am using session.getValue and session.putValue here, which are
>deprecated as of JSDK2.2, but I think we should use them for backwards
>compatibility to JSDK2.1 (which JServ needs).
>
>Any comments?
yea, let XSP make the session for you.
why bother invalidating the session?
Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>