Neeme Praks wrote:
>
> > -----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.
Actually... this isn't that bad. I have hacked together
RunData/PortletConfig access within XSP. I would be +1 for making this
the default operation for the CocoonPortlet. Not elagent but certainly
more so than the current solution (using RunData factory :)
... I added this to ./docs/TODO so that it will eventually get in 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.
All of this code is supposed to be threadsafe.
> 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
<snip>
You have got me stumped. I read over everythign and put some decent
thought into it. I can't see how this could be Jetspeed's fault.
Possibly Turbines or your third party authentication. Dont' know :(
Good luck :)
Kevin
--
** Should SUN Open Source Java? Please Vote:
http://relativity.yi.org/java **
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org | http://www.openprivacy.org
Message to SUN Microsystems: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
--
--------------------------------------------------------------
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]
