> -----Original Message-----
> From: burtonator [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 28, 2000 1:27 PM
[snip]
> ug. Can you point out the sections of code you think might be a
> problem?
well, I haven't found any particular part of the code yet. But I'll
explain what am I doing and the behaviour that I'm getting... maybe you
can tell me something obvious that could be wrong...
> Multithreadint can be interesting. It has a *really* good way of
> finding situations you didn't think of or didn't know was possible.
> Worse yet when there is a bug it is just *wierd* behavior
> like what you
> are experiencing. In most other situations it is usually a
> exception or
> somethign that can be tested in a regular manner (IE not time
> dependent).
yep, this is the worst kind of bugs... difficult to reproduce exactly.
Ok, here is a short overview of what I'm doing:
In order to output some meaningful data in Cocoon portlet, I need access
to PortletConfig (and RunData). I've solved this by storing
PortletConfig in JetspeedServletRequest. Inside portlet (under Cocoon,
in XSP page) I retrieve PortletConfig by casting the request object to
JetspeedServletRequest and getting the PortletConfig from there.
Maybe there is something wrong with this approach? (This is the first
place I have my suspicions about)
>From PortletConfig I retrieve also Rundata and from Rundata I get
ParameterParser and User object.
The second place that I have my suspicions about is the way I retrieve
User object from Turbine:
Basically, the situation is that we have two user classes:
1. our proprietary system has it's own User object that we use in our
code instead of Turbine's.
2. then there is a modified version of Turbine user class that has all
the database functionality (peers) commented out and simply sits there
as a wrapper around our own object.
The way I chose to store our user object in Tubine user object is
following:
Upon login, LoginAction asks the UserFactory to create an authenticated
user object. The factory creates this object and then stores our
proprietary user object in the temporary storage of that user
(implemented as hashtable in Turbine). Later in my code I simply
retrieve the object from the temporary storage.
I hope it made some sense...
The behaviour that I'm getting with my Cocoon portlets is the following:
When two users load a page at the same time (meaning that the second
user requests a page before the page generation has ended for the first
user), both users get the contents of the page as if the second user was
logged on.
Things to take note of:
* The users can have different content (different portlets) on their
pages and the portlets displayed are correct. This means that the
owerall request information (page layout) is not messed up.
* also cocoon loads and renders the content with correct classes (XSP
files) as it should, so Cocoon should also be working ok.
* the problem is that the proprietary user object seems to be "shared"
by the requests. This means that all the operations on that user object
return the information of the second user. So my closest guess would be
that I'm getting incorrect user object from temporary storage
hashtable... but why..?
Neeme
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
