Re: [J2] Bug: render called twice after an actionRequest

[David Sean Taylor]

On Thursday, April 1, 2004, at 11:20  PM, <[EMAIL PROTECTED]> wrote:

David Sean Taylor wrote:
On Thursday, April 1, 2004, at 12:34  PM, <[EMAIL PROTECTED]> wrote:

I just noticed that a portlet render method is called twice as result
of an
ActionRequest.
That shouldn't happen.
Im in the middle of refactoring and componentizing the navigation and
URL code, so its very likely things will break.
Im putting in unit tests around all the components
Very much appreciate your help here, but please bear with me for a few
days while I transition the code to a more manageable state
and decouple the navigational state from Pluto's implementation.
I know. I haven't much time left though for my Struts portlet 
framework so I
will delve into it
myself also. I will report back anything important I encounter if you 
don't
mind :-)

Sure. I hope to find some time today.
Will be back 'in the office' Monday, will give it my full attention 
then.

Have you tried debugging with Eclipse 3.0? It handles multithreading
nicely.
Well, yeah, I'm using Eclipse 3 now but I'm still getting used to it 
as I
come from IntelliJ
(painfully missing a few fine features now and then).

Or try changing the aggregator component's algorithm to single
threaded to make debugging easier
That's a good hint, didn't think of that. Is it configurable or do I 
have to
modify the code for it?
I'll check it out.

see portal/src/webapp/WEB-INF/conf/assembly/jetspeed.groovy:

strategy = 0

(We need a constant there)

This is partically troublesome as I'm currently trying to implement
Struts
as a Jetspeed portlet in which I perform Struts action  processing
from processAction and Struts view rendering from doView.
This sounds very interesting.
Will this be a general solution that you plan on contributing to J2?
I think a Jetspeed/Struts portlet application framework is a valuable
contribution.
Sure, I'll contribute it to Jetspeed (I already promised so before).

How much of a general solution it will be I don't know yet. There will 
be
some restrictions for Struts usage mainly because of portlet 
restrictions in
general.
Furthermore, I'm not trying to port existing standalone Struts 
applications
but to
provide a framework for new Struts porlet development based on the 
current
head
version of Struts (well, I'm currently using the non-released Struts 
1.2
version).
As test case though I'm using the Struts MessageReader example.

Perfect.

I'm not sure yet though if I should submit it to Jetspeed as a whole
or partly also to Struts (if they are interested).
This will be part Jetspeed adaption and part Struts 
modifications/extensions
to allow Struts work within a Portlet (mainly a specialized
RequestProcessor, handling of URL's and delayed view rendering).

Perhaps commit a part of it to Struts, and a part to Jetspeed.
Or perhaps as a sub-project under portals or jetspeed-2, under 
application frameworks


Hopefully someone has an idea?

Yes, Im pretty much dedicated to working on cleaning up this part of
the code over the next week.
Great. With a bit of luck I will be able to get a basic, first version 
of
the Struts Portlet framework for J2 up and running by then.

Look forward to it!

--
David Sean Taylor
Bluesunrise Software
[EMAIL PROTECTED]
[office]   +01 707 773-4646
[mobile] +01 707 529 9194


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]