AW: AW: Accessing named session attributes in XSP?

[Marco Rolappe <m_...@web.de>]

hi derek,

pretty old mail... anyway... ;-)

try the following: set the <xsp:page>'s attribute @create-session="false".
if you now get a NullPointerException, your xsp wasn't getting an existing
session (from which you wanted to get attributes). as the default is
@create-session="true" you always had a session with no attributes in it.

with 'how the XSP is accessed' I mean several things (ok, was a bit blurry
;-). with cookies disabled (e.g. in browser) and missing url rewriting,
you're effectively not having sessions. and when one browses to the page
created by that XSP, another empty session would be created (cause the other
couldn't be tracked). there are also issues with sessions created by xsps...

I asked that fuzzy question, because I didn't want to enumerate the
possibilities. It's a lot easier to diagnose the problem from a look at the
xsp and accompanying sitemap snippets.
  -----Ursprungliche Nachricht-----
  Von: DHohls@csir.co.za [mailto:DHohls@csir.co.za]
  Gesendet: Dienstag, 11. Februar 2003 08:52
  An: m_rolappe@web.de; cocoon-users@xml.apache.org
  Betreff: Re: AW: Accessing named session attributes in XSP?


  I am not sure by what you mean "How is it accessed";
  it is called by the sitemap as a generator at the start
  of a match entry... in fact, the same XSP may be called
  from more than one match; with different processing
  and transformation taking place thereafter.

  How can I avoid each XSP creating a new session?

  Thanks
  Derek


  >>> m_rolappe@web.de 10/02/2003 08:20:53 >>>
  hi derek,

  could you tell me please how the XSP is accessed? the problem might be
that
  your XSP is dealing with a different session (XSPs default to creating a
new
  session).

  > -----Ursprungliche Nachricht-----
  > Von: cocoon-users-return-46390-m_rolappe=web.de@xml.apache.org
  > [mailto:cocoon-users-return-46390-m_rolappe=web.de@xml.apache.org]Im
  > Auftrag von Derek Hohls
  > Gesendet: Montag, 10. Februar 2003 14:33
  > An: cocoon-users@xml.apache.org
  > Betreff: Accessing named session attributes in XSP?
  >
  >
  > I know I am missing something *very* obvious, but
  > I have "end of day" stare here, and cannot figure what
  > mistake I am making.
  >
  > I am using the Database Authenticator to process a
  > login - the user ID is stored in a session attribute called
  > "userrname"  The auth.xml used looks like:
  >
  > <auth-descriptor>
  >   <connection>myDB</connection>
  >   <table name="user">
  >     <select dbcol="UserName" request-param="username"
  > to-session="username"/>
  >     <select dbcol="UserPassword" request-param="userpass" />
  >   </table>
  > </auth-descriptor>
  >
  > This process seems to be working, as I can now get
  > access to the protected part of the pipeline: ie.
  >
  > <map:match type="sessionstate" pattern="*">
  >    <map:parameter name="attribute-name" value="username"/>
  > <!-- all this is accessible after login -->
  > </map:match>
  >
  > However, when I try and use the username attribute in
  > an XSP file, I just get a "null" returned - here's the snippet
  > from the file:
  >
  > <xsp:page
  >   language="java"
  >   xmlns:xsp="http://apache.org/xsp"
  >   xmlns:xsp-session="http://apache.org/xsp/request/2.0"
  > >
  >
  > <!-- Page-level logic -->
  > <page>
  >
  >   <xsp:logic>
  >     //session
  >     String sUserName = <xsp-session:get-attribute name="username"
  > as="string"/>;
  >   </xsp:logic>
  >
  >   <element><xsp:expr>sUserName</xsp:expr></element>
  >
  > </page>
  >
  >
  > The <element> now contains "null" (wihtout the ")
  >
  >
  > Any idea how to get the username out into the XSP??
  >
  > Thanks
  > Derek
  >
  >
  > --
  > This message has been scanned for viruses and dangerous content by
  > MailScanner, and is believed to be clean.
  >
  > "The CSIR exercises no editorial control over E-mail messages and/or
  > attachments thereto/links referred to therein originating in the
  > organisation and the views in this message/attachments thereto are
  > therefore not necessarily those of the CSIR and/or its employees.
  > The sender of this e-mail is, moreover, in terms of the CSIR's
Conditions
  > of Service, subject to compliance with the CSIR's internal E-mail and
  > Internet Policy."
  >
  >
  > ---------------------------------------------------------------------
  > Please check that your question  has not already been answered in the
  > FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
  >
  > To unsubscribe, e-mail:     <co...@xml.apache.org>
  > For additional commands, e-mail:   <co...@xml.apache.org>
  >


  ---------------------------------------------------------------------
  Please check that your question  has not already been answered in the
  FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

  To unsubscribe, e-mail:     <co...@xml.apache.org>
  For additional commands, e-mail:   <co...@xml.apache.org>



  --
  This message has been scanned for viruses and dangerous content by
  MailScanner, and is believed to be clean.

  "The CSIR exercises no editorial control over E-mail messages and/or
  attachments thereto/links referred to therein originating in the
  organisation and the views in this message/attachments thereto are
  therefore not necessarily those of the CSIR and/or its employees.
  The sender of this e-mail is, moreover, in terms of the CSIR's Conditions
  of Service, subject to compliance with the CSIR's internal E-mail and
  Internet Policy."