You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Stefan Hepper <st...@hursley.ibm.com> on 2004/04/26 18:38:57 UTC
Re: redirect after processAction - new spec clearification
Hi,
please find a new spec clearification doc that now states the following:
Request Attribute
The specification states that request attributes are objects associated
with a portlet during a single portlet request. While not stated
explicitly, the intent of the spec is that portlet developers can not
assume that attributes are shared between action and render requests.
Resolution
PLT.11.1.3 Request Attributes
[This section supplements section PLT.11.1.3 Request Attributes on page
44 in the Portlet 1.0 specification, add the text]
Request attributes are objects associated with a portlet during a single
portlet request. Portlet can not assume that attributes are shared
between action and render requests.
http://jcp.org/aboutJava/communityprocess/final/jsr168/Portlet_Specification_Errata.html#issue10
This should clearify this topic now.
Stefan
Re: redirect after processAction - new spec clearification
Posted by Julien Viet <ju...@jboss.com>.
what about ThreadLocal ? (set in action, used in render, cleared in a
servlet filter)
On Apr 27, 2004, at 7:06 AM, Rickard Öberg wrote:
> David H. DeWolf wrote:
>> Excuse me if this has already been asked. I've been out of the loop
>> for about a month b/c of some deadlines in my day job. I've been
>> attempting to get caught up, but may have missed something. . .
>> 1) Would you please explain how this is impractical? I saw a request
>> for a use case which required such request attribute behavior but
>> never saw any responses (besides error handling). Did I miss them or
>> have they not been presented?
>
> I never presented any because at the time I was (and still am)
> extremely busy.
>
> Anyway, here goes. The impractical aspect has already been mentioned
> in this thread, but here goes again: it is common that action phases
> built using the Model-2/MVC paradigm (we're using WebWork) construct
> complex results in the form of Java objects. The errata restricts the
> communication possibilities between the action and render phase so
> that only render parameters and the session are viable options. Render
> parameters are strings, and are hence out of the question. Which
> leaves the session. I have two main gripes with using the session for
> this purpose:
> 1) If the action adds a complex result object and the render phase
> uses it, is the render phase supposed to clear it from the session? If
> yes, then a reload of the page won't work, which has been stated to be
> one of the good things about this design. If no, then there will
> probably never be a "good" time to clear it, hence will stay in the
> session forever.
>
> 2) In a clustered environment with load-balancing any change to a
> session is typically replicated to the other nodes. Typically this
> isn't much of a problem since the session is most often used for stuff
> that deals with more semi-long lived state. But in this case it is
> being used for the normal operation of requests, which is an immense
> increase in usage. This is coincidentally why I said it won't scale,
> i.e. the session is abused in such a way that the overhead of action
> requests (especially in a clustered environment) will be too high.
>
>> 2) Why do you state that portlets will now "not scale". It is my
>> assumption that any object you put in the session as a replacement
>> for a shared request attribute will be cleaned up immediately after
>> use (just as a request attribute would have been - albeit
>> automatically by the container) and thus have a very short lifecycle.
>> If so, what is the negative impact that you see?
>
> If this is the case, then:
> a) a reload of the page won't work, which has been stated as a good
> feature of this design
> b) the session will indeed be abused in a clustered environment with
> the effects as described above.
>
>> Thanks for the clarification of your concern,
>
> No probs, I hope it is clear now.
>
> But we all have different requirements. Maybe getting a scalable
> environment which is practical to develop for is only on my own
> agenda. Feel free to disagree with any of the above.
>
> regards,
> Rickard
>
Re: redirect after processAction - new spec clearification
Posted by "David H. DeWolf" <dd...@apache.org>.
Rickard Öberg wrote:
> I have one simple usecase which breaks with the given errata: a form is
> posted to an action, and the input data does not pass validation. For
> each field in the form the tuple <id,value,error message> needs to be
> communicated to the rendering phase so that it can present the form
> again along with appropriate error messages. Communicating this
> information through rendering parameters does not work (value may be
> Java object), and using session does not work (it might work in
> development, but not in production for mentioned reasons).
I don't understand why renderParameters won't work here. The value,
even if it is converted to a POJO at some point in the action, still
originally came from an html form - which somehow was able to display
the values as Strings in the first case.
>
> If you want more specific usecases I can fix that, but the general
> problem is when the action phase needs to communicate complex Java
> objects to the rendering.
I understand what you're saying, I was just arguing that there are
multiple ways to do this. I was under the (mislead) impression that you
were arguing that the only two ways to do this were through shared
request attributes or through the session.
>
>> In this case, no matter if you add the object to the request as an
>> attribute or to the session and clear it before returning from the
>> request, a refresh "won't work" if you are depending on that object
>> being present for the render.
>
>
> Exactly, but one supposed feature of the suggested errata is that it
> works for refreshes. It doesn't. So, since neither of the two models
> support refresh, why not go with the one that makes it easier to code
> *AND* doesn't have the impact on session management that
> not-shared-attribtues implies.
I agree it's easier to code. At the same time, I've seen many pieces of
crappy code that were "easier to code" - and thus, simplicity doesn't
seem to be enough of an argument for me. I think simplicity is an
advantage of a design, but it's not necessarily a reason for choosing a
design.
Also, I can't help but wonder if the reason why it appears as though the
refresh won't work if implemented as designed is b/c we're attempting to
fit your design (the render needing complex objects from the action)
into the porltet specification's design (where the render displays based
upon renderParameters) - and perhaps the two aren't compatible in the
way you are thinking they are.
On the other hand, I do think that the earlier conversation about the
redirect enabling the back button is incorrect. The fact is that all
the redirect does is push another record on the browser's history stack.
Thus, hitting the back button twice would cause the original problem
that not implementing with the redirect would have caused.
>> . . .
>
> Which doesn't change anything in this case, since the errata proposes
> one "user request" (e.g. a form submit) be split into two physical
> servlet requests (with one redirect in the middle). Whether attributes
> are replicated after *servlet* request finishes or on each attribute set
> doesn't change a thing.
I didn't see this in the errata. I did see it in the mail archives
though. That said, I think this technique is only one possible solution
(and in my humble opinion it may not be the best).
> Absolutely, one could persist them in a database, or just hold them in a
> static variable in some class. But then you are making quite a lot of
> assumptions about the design (static->no clustering or at least sticky
> sessions, database->there is a database in the first place).
>
> There's a ton of ways to "make it work", but my point is that it is only
> complicating something to the n'th degree which would be stupendously
> trivial to do if attributes were shared.
I can see how request attribute sharing may be more simple. While I
also agree that in most cases simple is a huge advantage, I don't think
it's a reason to choose a design.
Whether you have a clustered environment, sticky session, a database, or
not, there are still many, many, ways to implement the desired outcome.
Granted, most (if not all) will be more difficult to implement than
using request attributes.
>
> You are asking for cases where request attributes cannot be shared.
> Well, since not sharing attributes requires a more complex
> implementation I would suggest that the proper question is: what
> usecases are there where request attributes may not be shared?
Quite frankly, I don't think there is any situation in which sharing
request attributes would cause problems. The benefit that most people
in favor of the errata would provide is that it encourages (if not
mandates) what they consider to be good design.
It's my understanding that the expert group has decided to implement the
portlet specification in a way the enforces certain design principals
which they felt were "ideal". I would argue that perhaps it's not the
design principals they chose that are the problem but rather the choice
to enforce a "subjective" design.
If the specification mandated that portlet developers must use
RequestAttributes for render/action communication, it's my guess that
there would probably just as many people complaining about that choice.
IMHO a specification should allow interoperability - not dictate design.
>
>
> Absolutely, but see above. You are suggesting that this stuff is more or
> less an "implementation detail" of writing portlets, i.e. shuffling the
> problem from the portlet container onto the portlet developer. And for
> what gain? Well, as it appears: nothing.
Again, some would argue that it enforces good design. And quite frankly,
that's the only benefit I see.
>
> That is why I am terribly upset with this.
I can see why. Not many people like having design dictated to them!
Once again, I think that is the error in all of this -- not the design
itself.
David
Re: redirect after processAction - new spec clearification
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Dennis Thrysøe wrote:
| Actually I'm having a hard time thinking of anything very useful to use
| request attributes for in an action request, if they don't live beyond
| that request
rite.
| , since I don't think passing the request on to other components would
| be very common anyway. But that's only speculation.
I think this is rather common - at least I do it sometimes, if not often
(in servlet environments, that is) - look at the attributes as some kind
of ThreadLocal thingy.
| So the only really meaningful thing request attributes can be used for
| is for passing values from render() to JSPs and such?
This is what I assumed that stuff was for, even though I'm not quite sure
how they subsequently would be accessed (by the JSPs../Servlets)
I must admit that I'm not very deep into the API yet - so everthing I say
might be totally far off!
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
Re: redirect after processAction - new spec clearification
Posted by Dennis Thrysøe <dt...@conscius.com>.
Rickard Öberg wrote:
> You are asking for cases where request attributes cannot be shared.
> Well, since not sharing attributes requires a more complex
> implementation I would suggest that the proper question is: what
> usecases are there where request attributes may not be shared?
This is an interesting observation. What is the advantage of *not*
sharing request attributes between the action and render requests?
I interpret the errata such that it is compliant to share the request
attrbibutes if the portlet container implementation thinks this is the
best, but that the portlet shouldn't count on this behaviour. This is
what I'd do, as this apparently complies with the spec., makes life
easier for portlet developers (albeit at a signifigant portability cost)
and doesn't really "cost" anything.
Actually I'm having a hard time thinking of anything very useful to use
request attributes for in an action request, if they don't live beyond
that request, since I don't think passing the request on to other
components would be very common anyway. But that's only speculation.
So the only really meaningful thing request attributes can be used for
is for passing values from render() to JSPs and such?
-dennis
Re: redirect after processAction - new spec clearification
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 27 Apr 2004, Rickard Öberg wrote:
| > I agree with some posters that you'd have problems here anyways - if you
| > need that "complex object", then you will have to use sessions.
|
| Nope. If request sharing works then that'd work.
| request.setAttribute("result", value) in action and
| request.getAttribute("result") in render. Doesn't get any simpler than that.
That's what I assumed you meant, and that's what I refer to in the next
paragraph:
|
| > I mean,
| > what happens even in the simple case where you have two portlets on the
| > same page, both with such a form - and then the one submits, and gets 8
| > errors. Then the other submits, and gets 4 errors: how are you supposed to
| > still show the 8 errors from in the first portlet? (The argument is just
| > as valid even if the other portlet doesn't have a form, just a simple
| > action-link -or whatever- that will make the portal page reload). Remeber
| > that each portlet acts as a servlet - to keep such objects across several
| > renderings, you -will- have to establish a session..
|
| Agree, that won't work well. But I'd personally live with that limitation.
|
I -don't- understand that you will live with that limitation: I mean, the
user will see his data, or the error-messages, -once-, right? Any refresh,
triggered by either actual reload (user clicking reload), or by user
clicking on -ANYTHING- within the portal not on that portlet, including
any link in any other portlet, posting any other form (in any portlet,
incl. the one we're talking about), switching portal-page, or -WHATEVER-,
will clear the data and the feedback from the system?
-I- couldn't live with that. Neither as a coder, and MOST DEFINATELY not
as a user!! ;)
| As with all software engineering it's always and only about tradeoffs.
| Plain and simple.
Well - the tradeoffs you're suggesting seems to me WAY to heavy.
|
| > However, it might be that your form-handling stuff only needs the object
| > to -construct- its error-strings, and don't need the object (just the
| > strings or whatever) on subsequent renderings?
|
| Nope, the rendering does need the object.
Okay, then my above assumptions hold - and I can't understand that you're
"living with it"! :)
Btw, I totally agree with you..! It should be possible to send complex
objects between those two phases - it seems unneccesary that it isn't
allowed - but not because of the reasons you state!!
;)
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
Re: redirect after processAction - new spec clearification
Posted by Rickard Öberg <ri...@dreambean.com>.
Endre Stølsvik wrote:
> | Exactly, but one supposed feature of the suggested errata is that it
> | works for refreshes. It doesn't. So, since neither of the two models
> | support refresh, why not go with the one that makes it easier to code
> | *AND* doesn't have the impact on session management that
> | not-shared-attribtues implies.
>
> Why doesn't it work for refreshes?
From a previous post I sent:
"If the action adds a complex result object and the render phase uses
it, is the render phase supposed to clear it from the session? If yes,
then a reload of the page won't work, which has been stated to be one of
the good things about this design. If no, then there will probably never
be a "good" time to clear it, hence will stay in the session forever.
[.. hence causing "memory leaks" in the session]
I suppose it depends on your definition of "works", but IMO the above is
an example of "doesn't work".
> I actually found the "render
> parameters" thingy good. Have you read WSRP? They have something called
> "navigational parameters" (or whatever), which maps to the render
> parameters, and are supposed to work for bookmarks, reload and history.
Render parameters for managing render states is quite useful, and I have
no gripes with that. I do have gripes with using render parameters for
communicating between command and view in an MVC design (which
action/render should be mapped to).
> What attributes are you referring to (this is most probably a stupid
> question, but please)? Is it render -parameters-?
If you read the whole thread it will be obvious, but the short version
is that we're discussing "request attributesm and the action and render
phases" and whether they (request attributes) are shared or not between
these phases.
> One thing: Could you hook back "to the servlet environement", and use some
> of those features to pass your object?
Please read the whole thread. It will explain this and much more.
> Also, there of course -is- a possibility of having an external entity
> handle your objects: use a static class with a HashMap and good synching,
> and pass some randomly generated string in the action pass, then fetch the
> stuff back again in the render pass. Null them out on fetch.
As I said in the previous post:
"Absolutely, one could persist them in a database, or just hold them in
a static variable in some class. But then you are making quite a lot of
assumptions about the design (static->no clustering or at least sticky
sessions, database->there is a database in the first place).
There's a ton of ways to "make it work", but my point is that it is only
complicating something to the n'th degree which would be stupendously
trivial to do if attributes were shared."
> If it -is possible- that the render pass of a portlet won't be done
> even if the action pass was done (should be in my opinion), then you'd
> have to have some reaper Thread going - sux.
And worse: the "Null them out on fetch" doesn't work either because
render URL's are supposed to be bookmarkfriendly and browser-refresh
friendly. If you null the object then a refresh will lead to "Sorry, but
there is no data available to perform this request at this time", or
similar.
> However - you do have the problem of what to do on the next reload, or
> even if just some other Portlet was sent the action: the object wouldn't
> be there.
Agree, as above.
> I agree with some posters that you'd have problems here anyways - if you
> need that "complex object", then you will have to use sessions.
Nope. If request sharing works then that'd work.
request.setAttribute("result", value) in action and
request.getAttribute("result") in render. Doesn't get any simpler than that.
> I mean,
> what happens even in the simple case where you have two portlets on the
> same page, both with such a form - and then the one submits, and gets 8
> errors. Then the other submits, and gets 4 errors: how are you supposed to
> still show the 8 errors from in the first portlet? (The argument is just
> as valid even if the other portlet doesn't have a form, just a simple
> action-link -or whatever- that will make the portal page reload). Remeber
> that each portlet acts as a servlet - to keep such objects across several
> renderings, you -will- have to establish a session..
Agree, that won't work well. But I'd personally live with that limitation.
As with all software engineering it's always and only about tradeoffs.
Plain and simple.
> However, it might be that your form-handling stuff only needs the object
> to -construct- its error-strings, and don't need the object (just the
> strings or whatever) on subsequent renderings?
Nope, the rendering does need the object.
/Rickard
Re: redirect after processAction - new spec clearification
Posted by Endre Stølsvik <En...@Stolsvik.com>.
..
| Exactly, but one supposed feature of the suggested errata is that it
| works for refreshes. It doesn't. So, since neither of the two models
| support refresh, why not go with the one that makes it easier to code
| *AND* doesn't have the impact on session management that
| not-shared-attribtues implies.
Why doesn't it work for refreshes? I actually found the "render
parameters" thingy good. Have you read WSRP? They have something called
"navigational parameters" (or whatever), which maps to the render
parameters, and are supposed to work for bookmarks, reload and history.
What attributes are you referring to (this is most probably a stupid
question, but please)? Is it render -parameters-?
One thing: Could you hook back "to the servlet environement", and use some
of those features to pass your object?
Also, there of course -is- a possibility of having an external entity
handle your objects: use a static class with a HashMap and good synching,
and pass some randomly generated string in the action pass, then fetch the
stuff back again in the render pass. Null them out on fetch.
If it -is possible- that the render pass of a portlet won't be done
even if the action pass was done (should be in my opinion), then you'd
have to have some reaper Thread going - sux.
However - you do have the problem of what to do on the next reload, or
even if just some other Portlet was sent the action: the object wouldn't
be there.
I agree with some posters that you'd have problems here anyways - if you
need that "complex object", then you will have to use sessions. I mean,
what happens even in the simple case where you have two portlets on the
same page, both with such a form - and then the one submits, and gets 8
errors. Then the other submits, and gets 4 errors: how are you supposed to
still show the 8 errors from in the first portlet? (The argument is just
as valid even if the other portlet doesn't have a form, just a simple
action-link -or whatever- that will make the portal page reload). Remeber
that each portlet acts as a servlet - to keep such objects across several
renderings, you -will- have to establish a session..
However, it might be that your form-handling stuff only needs the object
to -construct- its error-strings, and don't need the object (just the
strings or whatever) on subsequent renderings?
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
Re: redirect after processAction - new spec clearification
Posted by Rickard Öberg <ri...@dreambean.com>.
David H. DeWolf wrote:
>> I never presented any because at the time I was (and still am)
>> extremely busy.
>
> Understand! I'm right there with you! When you have a change pass along
> a usecase and it might either help me understand your position or help
> someone else come up with an alternate design to help you.
I have one simple usecase which breaks with the given errata: a form is
posted to an action, and the input data does not pass validation. For
each field in the form the tuple <id,value,error message> needs to be
communicated to the rendering phase so that it can present the form
again along with appropriate error messages. Communicating this
information through rendering parameters does not work (value may be
Java object), and using session does not work (it might work in
development, but not in production for mentioned reasons).
If you want more specific usecases I can fix that, but the general
problem is when the action phase needs to communicate complex Java
objects to the rendering.
> Even if you were to assume that the assumption about this being good
> design were incorrect, how does the sharing of request attributes change
> this behavior? It they were sharable, all request attributes would be
> removed by the container once the request has returned.
Correct.
> In this case,
> no matter if you add the object to the request as an attribute or to the
> session and clear it before returning from the request, a refresh "won't
> work" if you are depending on that object being present for the render.
Exactly, but one supposed feature of the suggested errata is that it
works for refreshes. It doesn't. So, since neither of the two models
support refresh, why not go with the one that makes it easier to code
*AND* doesn't have the impact on session management that
not-shared-attribtues implies.
> What am I missing? Can you help explain how this clarification of the
> spec changes this situation.
As above. It's a case of finding the lesser evil :-)
> If no, then there will probably never
>
>> be a "good" time to clear it, hence will stay in the session forever.
>>
>> 2) In a clustered environment with load-balancing any change to a
>> session is typically replicated to the other nodes. Typically this
>> isn't much of a problem since the session is most often used for stuff
>> that deals with more semi-long lived state. But in this case it is
>> being used for the normal operation of requests, which is an immense
>> increase in usage. This is coincidentally why I said it won't scale,
>> i.e. the session is abused in such a way that the overhead of action
>> requests (especially in a clustered environment) will be too high.
>
>
> I can't claim to be an expert on the way servlet containers handle
> replication over a clustered environment, but I do wonder if most
> containers replicate upon each individual binding or not (I'll show my
> ignorance by stating that perhaps they are replicated after the request
> has been serviced???).
Which doesn't change anything in this case, since the errata proposes
one "user request" (e.g. a form submit) be split into two physical
servlet requests (with one redirect in the middle). Whether attributes
are replicated after *servlet* request finishes or on each attribute set
doesn't change a thing.
> That said, if this is a concern and you assume
> that replication occurs upon every binding, aren't there alternative
> ways to replicate request attribute sharing (other than by binding to
> the session)? I can thing of several ways of caching these "complex"
> objects which you are talking about and retrieving them (looking them
> up) using a simple render parameter.
Absolutely, one could persist them in a database, or just hold them in a
static variable in some class. But then you are making quite a lot of
assumptions about the design (static->no clustering or at least sticky
sessions, database->there is a database in the first place).
There's a ton of ways to "make it work", but my point is that it is only
complicating something to the n'th degree which would be stupendously
trivial to do if attributes were shared.
You are asking for cases where request attributes cannot be shared.
Well, since not sharing attributes requires a more complex
implementation I would suggest that the proper question is: what
usecases are there where request attributes may not be shared?
> I'm still not sure that you'd want to do this, since you'd have to make
> sure that every subsequent reload/refresh had access to that same cache
> - and like you said, how would you know when to clean the cache up.
Exactly.
> However, if there is a reason to implement a portlet in this manner I
> think there are other ways to do it (besides Attribute Sharing).
Absolutely, but see above. You are suggesting that this stuff is more or
less an "implementation detail" of writing portlets, i.e. shuffling the
problem from the portlet container onto the portlet developer. And for
what gain? Well, as it appears: nothing.
That is why I am terribly upset with this.
> Very true that we all have our own requirements, however I think that
> there are ways to reach scalability that you haven't explored yet.
And I would happily be educated about ways to get the proposed design to
scale with regard to session clustering. I can't see how it would work,
but that doesn't mean it's impossible (naturally).
> In
> fact, it's my guess that using render parameters in the way in which
> they were designed would be even more scalable, but once again, I can't
> say this in confidence without knowing a specific use case.
Scalable: yes, absolutely. Useful: no, not really. In simple portlets
and tutorials, sure, but not in complex portlets where non-strings are
passed from action to render (or from "command" to "view" in MVC lingo).
> Don't get
> me wrong, I'm not saying your design is necisarily bad, I'm just saying
> that there may be alternate approaches which you have not yet
> considered. At the same time, there may be restrictions that I haven't
> considered as well.
>
> I think the issue here is that the expert group has chosen to implement
> a specification which encourages good design practices-- or at least ONE
> good design. It seems as though there are different ideas of whether
> this "good design" is the "best design" - but there's no way to get the
> world agree on a single a design is there? :)
Absolutely. However, I would argue, based on the presented discussion,
that the proposed design isn't even "good design". On the contrary, it
is a bad design which doesn't even accomplish what it was supposed to
accomplish (e.g. allowing browser refresh).
/Rickard
Re: redirect after processAction - new spec clearification
Posted by "David H. DeWolf" <dd...@apache.org>.
Rickard Öberg wrote:
> David H. DeWolf wrote:
>
>> Excuse me if this has already been asked. I've been out of the loop
>> for about a month b/c of some deadlines in my day job. I've been
>> attempting to get caught up, but may have missed something. . .
>>
>> 1) Would you please explain how this is impractical? I saw a request
>> for a use case which required such request attribute behavior but
>> never saw any responses (besides error handling). Did I miss them or
>> have they not been presented?
>
>
> I never presented any because at the time I was (and still am) extremely
> busy.
Understand! I'm right there with you! When you have a change pass along
a usecase and it might either help me understand your position or help
someone else come up with an alternate design to help you.
>
> Anyway, here goes. The impractical aspect has already been mentioned in
> this thread, but here goes again: it is common that action phases built
> using the Model-2/MVC paradigm (we're using WebWork) construct complex
> results in the form of Java objects. The errata restricts the
> communication possibilities between the action and render phase so that
> only render parameters and the session are viable options. Render
> parameters are strings, and are hence out of the question. Which leaves
> the session. I have two main gripes with using the session for this
> purpose:
> 1) If the action adds a complex result object and the render phase uses
> it, is the render phase supposed to clear it from the session? If yes,
> then a reload of the page won't work, which has been stated to be one of
> the good things about this design.
Even if you were to assume that the assumption about this being good
design were incorrect, how does the sharing of request attributes change
this behavior? It they were sharable, all request attributes would be
removed by the container once the request has returned. In this case,
no matter if you add the object to the request as an attribute or to the
session and clear it before returning from the request, a refresh "won't
work" if you are depending on that object being present for the render.
What am I missing? Can you help explain how this clarification of the
spec changes this situation.
If no, then there will probably never
> be a "good" time to clear it, hence will stay in the session forever.
>
> 2) In a clustered environment with load-balancing any change to a
> session is typically replicated to the other nodes. Typically this isn't
> much of a problem since the session is most often used for stuff that
> deals with more semi-long lived state. But in this case it is being used
> for the normal operation of requests, which is an immense increase in
> usage. This is coincidentally why I said it won't scale, i.e. the
> session is abused in such a way that the overhead of action requests
> (especially in a clustered environment) will be too high.
I can't claim to be an expert on the way servlet containers handle
replication over a clustered environment, but I do wonder if most
containers replicate upon each individual binding or not (I'll show my
ignorance by stating that perhaps they are replicated after the request
has been serviced???). That said, if this is a concern and you assume
that replication occurs upon every binding, aren't there alternative
ways to replicate request attribute sharing (other than by binding to
the session)? I can thing of several ways of caching these "complex"
objects which you are talking about and retrieving them (looking them
up) using a simple render parameter.
I'm still not sure that you'd want to do this, since you'd have to make
sure that every subsequent reload/refresh had access to that same cache
- and like you said, how would you know when to clean the cache up.
However, if there is a reason to implement a portlet in this manner I
think there are other ways to do it (besides Attribute Sharing).
>
>> 2) Why do you state that portlets will now "not scale". It is my
>> assumption that any object you put in the session as a replacement for
>> a shared request attribute will be cleaned up immediately after use
>> (just as a request attribute would have been - albeit automatically by
>> the container) and thus have a very short lifecycle. If so, what is
>> the negative impact that you see?
>
>
> If this is the case, then:
> a) a reload of the page won't work, which has been stated as a good
> feature of this design
> b) the session will indeed be abused in a clustered environment with the
> effects as described above.
>
>> Thanks for the clarification of your concern,
>
>
> No probs, I hope it is clear now.
>
> But we all have different requirements. Maybe getting a scalable
> environment which is practical to develop for is only on my own agenda.
Very true that we all have our own requirements, however I think that
there are ways to reach scalability that you haven't explored yet. In
fact, it's my guess that using render parameters in the way in which
they were designed would be even more scalable, but once again, I can't
say this in confidence without knowing a specific use case. Don't get
me wrong, I'm not saying your design is necisarily bad, I'm just saying
that there may be alternate approaches which you have not yet
considered. At the same time, there may be restrictions that I haven't
considered as well.
I think the issue here is that the expert group has chosen to implement
a specification which encourages good design practices-- or at least ONE
good design. It seems as though there are different ideas of whether
this "good design" is the "best design" - but there's no way to get the
world agree on a single a design is there? :)
> Feel free to disagree with any of the above.
>
> regards,
> Rickard
Thanks for challenging assumptions!
David
>
>
Re: redirect after processAction - new spec clearification
Posted by Rickard Öberg <ri...@dreambean.com>.
David H. DeWolf wrote:
> Excuse me if this has already been asked. I've been out of the loop for
> about a month b/c of some deadlines in my day job. I've been attempting
> to get caught up, but may have missed something. . .
>
> 1) Would you please explain how this is impractical? I saw a request
> for a use case which required such request attribute behavior but never
> saw any responses (besides error handling). Did I miss them or have
> they not been presented?
I never presented any because at the time I was (and still am) extremely
busy.
Anyway, here goes. The impractical aspect has already been mentioned in
this thread, but here goes again: it is common that action phases built
using the Model-2/MVC paradigm (we're using WebWork) construct complex
results in the form of Java objects. The errata restricts the
communication possibilities between the action and render phase so that
only render parameters and the session are viable options. Render
parameters are strings, and are hence out of the question. Which leaves
the session. I have two main gripes with using the session for this purpose:
1) If the action adds a complex result object and the render phase uses
it, is the render phase supposed to clear it from the session? If yes,
then a reload of the page won't work, which has been stated to be one of
the good things about this design. If no, then there will probably never
be a "good" time to clear it, hence will stay in the session forever.
2) In a clustered environment with load-balancing any change to a
session is typically replicated to the other nodes. Typically this isn't
much of a problem since the session is most often used for stuff that
deals with more semi-long lived state. But in this case it is being used
for the normal operation of requests, which is an immense increase in
usage. This is coincidentally why I said it won't scale, i.e. the
session is abused in such a way that the overhead of action requests
(especially in a clustered environment) will be too high.
> 2) Why do you state that portlets will now "not scale". It is my
> assumption that any object you put in the session as a replacement for a
> shared request attribute will be cleaned up immediately after use (just
> as a request attribute would have been - albeit automatically by the
> container) and thus have a very short lifecycle. If so, what is the
> negative impact that you see?
If this is the case, then:
a) a reload of the page won't work, which has been stated as a good
feature of this design
b) the session will indeed be abused in a clustered environment with the
effects as described above.
> Thanks for the clarification of your concern,
No probs, I hope it is clear now.
But we all have different requirements. Maybe getting a scalable
environment which is practical to develop for is only on my own agenda.
Feel free to disagree with any of the above.
regards,
Rickard
Re: redirect after processAction - new spec clearification
Posted by "David H. DeWolf" <dd...@apache.org>.
Excuse me if this has already been asked. I've been out of the loop for
about a month b/c of some deadlines in my day job. I've been attempting
to get caught up, but may have missed something. . .
1) Would you please explain how this is impractical? I saw a request
for a use case which required such request attribute behavior but never
saw any responses (besides error handling). Did I miss them or have
they not been presented?
2) Why do you state that portlets will now "not scale". It is my
assumption that any object you put in the session as a replacement for a
shared request attribute will be cleaned up immediately after use (just
as a request attribute would have been - albeit automatically by the
container) and thus have a very short lifecycle. If so, what is the
negative impact that you see?
Thanks for the clarification of your concern,
David
Rickard Öberg wrote:
> Stefan Hepper wrote:
>
>> Hi,
>> please find a new spec clearification doc that now states the following:
>>
>> Request Attribute
>> The specification states that request attributes are objects
>> associated with a portlet during a single portlet request. While not
>> stated explicitly, the intent of the spec is that portlet developers
>> can not assume that attributes are shared between action and render
>> requests.
>> Resolution
>> PLT.11.1.3 Request Attributes
>>
>> [This section supplements section PLT.11.1.3 Request Attributes on
>> page 44 in the Portlet 1.0 specification, add the text]
>> Request attributes are objects associated with a portlet during a
>> single portlet request. Portlet can not assume that attributes are
>> shared between action and render requests.
>>
>> http://jcp.org/aboutJava/communityprocess/final/jsr168/Portlet_Specification_Errata.html#issue10
>>
>> This should clearify this topic now.
>
>
> It does, and it sucks.
>
> In practice it means that we will most likely drop the idea of using
> Pluto as our portal container implementation. This rule is simply way
> too impractical (as outlined), and we don't care if our portlets don't
> work in other portals.
>
> On the bright side, at least it makes portlets theoretically more
> portable. Won't scale, because of the additional session usage, but they
> are portable.
>
> /Rickard
>
>
Re: redirect after processAction - new spec clearification
Posted by Rickard Öberg <ri...@dreambean.com>.
Stefan Hepper wrote:
> Hi,
> please find a new spec clearification doc that now states the following:
>
> Request Attribute
> The specification states that request attributes are objects associated
> with a portlet during a single portlet request. While not stated
> explicitly, the intent of the spec is that portlet developers can not
> assume that attributes are shared between action and render requests.
> Resolution
> PLT.11.1.3 Request Attributes
>
> [This section supplements section PLT.11.1.3 Request Attributes on page
> 44 in the Portlet 1.0 specification, add the text]
> Request attributes are objects associated with a portlet during a single
> portlet request. Portlet can not assume that attributes are shared
> between action and render requests.
>
> http://jcp.org/aboutJava/communityprocess/final/jsr168/Portlet_Specification_Errata.html#issue10
>
> This should clearify this topic now.
It does, and it sucks.
In practice it means that we will most likely drop the idea of using
Pluto as our portal container implementation. This rule is simply way
too impractical (as outlined), and we don't care if our portlets don't
work in other portals.
On the bright side, at least it makes portlets theoretically more
portable. Won't scale, because of the additional session usage, but they
are portable.
/Rickard