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 Tim Kettering <ti...@vivakos.com> on 2005/08/12 21:46:48 UTC
RE: Pluto sending POST params in the URL
Hi Pluto developers,
I didn't receive an reply on this email I sent out yesterday yet, but I've
been digging around and I believe I have narrowed down the issue to
something more of a "behavorial" question that I'm asking the Pluto
developers of.
It turns out the problem I was describing below was not occurring when the
browser sends the parameters to the server. In that phase, the POST
parameters are sent correctly. The problem was occurring when the response
URL was sent back to the browser. I am using Spring Framework's Portal MVC
in conjunction with Pluto for our development purposes. Further
investigation of the Spring MVC code shows me that when handling form
submissions, the MVC controller will copy the parameters from the
ActionRequest to the ActionResponse object (this is done to facilitate the
display of errors on a validated form).
So it would appear to me that because the parameters are being copied to the
Response object, the parameters are then being encoded in the response URL
sent back to the browser by Pluto. I have verified this by modifying the
controller code to set the parameters to null at the end of the
ActionResponse handling phase, and certainly enough, Pluto does not return
any encoded parameters.
Normally this would settle the issue for me, but while investigating this
issue, I had consulted w/ Spring Portal MVC developer, John Lewis, and he
told me that while doing development with Gridsphere (another portal
container), he was not seeing any parameters being encoded in the URL, and
he is using the same kind of controllers as I am. So there apparently seems
to be a difference between the two containers in how any parameters set in
ActionResponse should be handled in regard to the URL that is returned to
the browser.
I have not had a chance to review the portlet spec - to see if it covers
what should be done in this situation, but I thought I'd send this follow up
email to the developers, and over the weekend, I will attempt to review the
portlet spec to see if it covers anything on this particular matter.
Hope my explaination is clear, and that someone will be able to say one way
or another whether Pluto or Gridsphere (or neither) is performing as per the
portlet specifications.
Thanks,
-tim
_____
From: Tim Kettering [mailto:tim.kettering@vivakos.com]
Sent: Thursday, August 11, 2005 3:51 PM
To: pluto-user@portals.apache.org
Subject: Pluto sending POST params in the URL
Hi Pluto users,
I'm just writing in to inquire if other Pluto users are seeing what I'm
seeing. I'm currently doing portlet dev with Pluto, and one thing I've
noticed is that even when I am using <form method="POST" . > in my forms,
the parameters in the forms are still being added to the portlet URL after
submission. This doesn't seem to be the proper behavior, and I've searched
around online to see if I could find any answers to this, but turned up
nothing.
I do remember a few years ago, I discovered that certain html could force a
POST to be submitted as GET (not related to portlets) but it was such a
while ago, I can't remember what it was, or whether it's relevant to this -
so I'm hoping that someone here could help provide some insight. Thanks in
advance.
-tim
Re: Pluto sending POST params in the URL
Posted by Ate Douma <at...@douma.nu>.
John Lewis wrote:
> FYI: I just confirmed that I see the same exact behavior in uPortal, so
> this does look like a Pluto issue, not just a Pluto Portal Driver issue.
John,
If you're interested maybe you want to try that out in Jetspeed-2 also?
Although it also uses the Pluto container, we allow you to configure
(currently only on portal-scope) different ways to store request parameters
as well as the portlet state and window mode.
Default, these are all stored in the portal session, but you can change
that to only encoding in the url or only save the request parameters in the session.
And of course, you can easily provide your own solution as almost every
feature and functionality of Jetspeed-2 is configured through springframework.
I expect you will not have your problem with Jetspeed-2 using its default
configuration.
Note: no user or assembler guide has been written yet for this part of the
configuration, so if you'd like to test this out with different url encoders
please let me know and I will gladly help you out.
This feature has been part of Jetspeed-2 for more than a year already so for
quickly testing out this you can use our latest M3 milestone:
http://www.apache.org/dyn/closer.cgi/portals/jetspeed-2
and find the online docs for that here:
http://portals.apache.org/jetspeed-2/M3/
But, of course we have already progressed quite a lot since M3 again, especially
with regard to creating you own custom portal and much improved online docs.
So if you don't mind building it yourself, I'd suggest checking out the source
for the current M4-SNAPSHOT.
Checkout is described here:
http://portals.apache.org/jetspeed-2/source-code.html
And the getting started here:
http://portals.apache.org/jetspeed-2/getting-started.html
Regards,
Ate
>
> John Lewis wrote:
>
>> David,
>>
>> Thank you for your thorough response. I think everything you said
>> makes good sense. I particularly like the idea of supporting either
>> method. In fact, perhaps it's possible to decide automatically by
>> testing the length of the generated URL and then falling back to an
>> alternate method if it has become too long. Thanks again for your
>> support in this.
>>
>> John
>>
>>
>> David H. DeWolf wrote:
>>
>>>
>>> See below:
>>>
>>> John Lewis wrote:
>>>
>>>> This seems like a pretty painful limitation. It is hard enough
>>>> to pass data forward from the action phase to the render phase in a
>>>> portlet, but to now have an additional limitation on how long the
>>>> render parameters can be starts to make things really difficult.
>>>>
>>>> The problem with passing information forward from the action phase
>>>> to the render phase via the session is that there is no way to know
>>>> when the session data can be deleted. Since the portlet can be
>>>> rendered repeatedly, how is the portlet to know when it is done
>>>> using it? If there is no way to know, then we end up leaving
>>>> orphaned data in the session and leaking memory over time until that
>>>> session is finally invalidated.
>>>>
>>>> It also seems like this problem would escalate out of control as
>>>> more and more portlets are displayed on the same page. Let's say we
>>>> have 10 portlets all on the same page -- not an unreasonable
>>>> number. Each of those 10 portlets will have to render itself on
>>>> each request to the portal for that page (let's ignore the issue of
>>>> caching for the moment). When the portal calls the portlet code to
>>>> render each of those 10 portlets, it must deliver the same render
>>>> parameters that it used the last time it rendered each one. If each
>>>> one of those 10 portlets has a few reasonably small render
>>>> parameters set, but all the render parameters for all of the
>>>> portlets are being encoded in the URL, it seems that the URL could
>>>> exceed 4k pretty easily even though each portlet is using a small
>>>> amount of data.
>>>
>>>
>>>
>>>
>>> Point well taken. . .but do remember that at this point the Pluto
>>> portal driver (where the PortalURL implementation is actually
>>> defined) is supposed to be an example of how to embed the container -
>>> not necessarily a production quality portal. That said, I do think
>>> that we want to move towards a more robust solution in the future.
>>>
>>>>
>>>> As far as I know, this limitation is not part of the JSR-168 spec
>>>> and so I imagine that many portlet developers would be surprised by
>>>> this issue when they run into it using Pluto.
>>>>
>>>> I can understand the desire to have the specific render event be
>>>> bookmarkable, but is that really so valuable as to sacrifice the
>>>> ability to send forward a few k of string data from the action phase
>>>> to the render phase via the render parameters?
>>>
>>>
>>>
>>>
>>> I think that depends on your point of view and specific case. Many
>>> portal implementations I have done characterized bookmarkability and
>>> browser back/forward buttons as more important than support for 4k of
>>> parameters. . .probably because they had no need for the 4k.
>>>
>>>>
>>>> Perhaps there is some way that Pluto could check ahead of time if
>>>> the generated URL will be too long and then not put the parameters
>>>> in the URL? I know this limitation does not exist in some other
>>>> JSR-168 implementations, so there must be a good way to avoid this.
>>>>
>>>
>>> I would prefer providing two implementations of the interface - one
>>> which support bookmarking and one which provides an alternate means
>>> for handling render parameters so that they are not limited to 4k.
>>> This will keep each request consistent and allow the deployer to make
>>> an intelligent decision as to which is preferred. I guess the other
>>> option would be to adopt your suggested approach and allow the > 4k
>>> handling to be turned off.
>>>
>>> My preference is to support these in 1.1, not necessarily 1.0.x.
>>>
>>> David
>>>
>>>
>>>> FYI: The reason we are forwarding a large amount of data forward
>>>> from the action phase to the render phase is so that a submitted
>>>> form that does not pass validation can be redisplayed with all the
>>>> previously entered values still in place. I think this is not an
>>>> unreasonable thing to expect to be able to do and is common practice
>>>> in traditional web development.
>>>
>>>
>>>
>>>
>>> Agreed. This is definitely something we want to enhance at some
>>> point in time.
>>>
>>>>
>>>> Let us know what you think. We really appreciate your help with this.
>>>>
>>>> John
>>>>
>>>>
>>>> Stefan Hepper wrote:
>>>>
>>>>> Here is what we do in pluto when new render parameters are set:
>>>>> we create a URL with the new render parameters (and new portlet
>>>>> mode and window state if any are set) and make a redirect to this
>>>>> URL. The reason we do this is that we want to enable
>>>>> bookmarkability and the browser back and forward buttons. Therefore
>>>>> we need to create this new URL that reflects the outcome of the
>>>>> action and send it to the client.
>>>>>
>>>>> What we currently not do is check the size of the parameters or
>>>>> compress them. However, this part of the code is not the pluto
>>>>> container code, but the pluto portal code (the URLProvider). The
>>>>> pluto portal implementation is meant as a sample implementation and
>>>>> not as a production portal and thus has limitations.
>>>>>
>>>>> The size of the URL is limited to 4k by the HTTP spec, but most
>>>>> infrastructures only support 2k. Maybe the parameter gets truncated
>>>>> and therefore you get the exception?
>>>>>
>>>>> What could be done is to store large parameters in the portal
>>>>> session and only keep a ref ID in the URL, which of course would
>>>>> exclude this param from the bookmarkability and back button support.
>>>>>
>>>>> As a general design principal the payload of the render params
>>>>> should be as small as possible. Is there a way you can compress the
>>>>> param value in the portlet?
>>>>>
>>>>> Stefan
>>>>>
>>>>> John Lewis wrote:
>>>>>
>>>>>> Ulrich,
>>>>>>
>>>>>> Tim's problem is happening with use of the Spring Portlet MVC
>>>>>> framework,
>>>>>> for which I am one of the developers. I've been able to reproduce
>>>>>> his
>>>>>> problem, but I am also confused what is causing it.
>>>>>>
>>>>>> The framework does in fact perform an include via the
>>>>>> PortletRequestDispatcher, however this call completes successfully.
>>>>>> In fact, the entire call to the portlet's doDispatch method is
>>>>>> successful
>>>>>> and does not throw any exceptions. It is only afterwards that an
>>>>>> exception occurs.
>>>>>>
>>>>>> Here is the complete stack trace:
>>>>>>
>>>>>> java.lang.ArrayIndexOutOfBoundsException: 4096
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>>>
>>>>>> at org.apache.coyote.Response.action(Response.java:182)
>>>>>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>>>>>> at
>>>>>> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>>>>>>
>>>>>> at
>>>>>> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>>>>>>
>>>>>> at
>>>>>> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>>>>>>
>>>>>> at
>>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>>>
>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor
>>>>>> process
>>>>>> SEVERE: Error finishing response
>>>>>> java.lang.ArrayIndexOutOfBoundsException: 4097
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>>>
>>>>>> at org.apache.coyote.Response.action(Response.java:180)
>>>>>> at
>>>>>> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>>>>>
>>>>>> at
>>>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>>>
>>>>>> at
>>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>>>
>>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>>
>>>>>> This is happening whenever a very large string is passed forward from
>>>>>> action phase to the render phase via the
>>>>>> ActionResponse.setRenderParameter method.
>>>>>>
>>>>>> This problem does not occur in Gridsphere (a different JSR-168
>>>>>> portal),
>>>>>> so there is something different in the implementations of the spec
>>>>>> that
>>>>>> is causing this error.
>>>>>>
>>>>>> Thanks for your help in trying to resolve this.
>>>>>>
>>>>>>
>>>>>> John Lewis
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ulrich Küster wrote:
>>>>>>
>>>>>>>> parameters are sent correctly. The problem was occurring when
>>>>>>>> the response URL was sent back to the browser. I am using
>>>>>>>> Spring Framework’s Portal MVC in conjunction with Pluto for our
>>>>>>>> development purposes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I suppose you are using JSP via the PortletRequestDispatcher's
>>>>>>> include method?
>>>>>>>
>>>>>>> Well, in that case PLT 16.3 states, that
>>>>>>> "Servlets and JSPs included from portlets must be handled as HTTP
>>>>>>> GET requests."
>>>>>>>
>>>>>>> The spec doesn't explain why that is the case so I can't help any
>>>>>>> further. I certainly would be interested in other comments about
>>>>>>> this issue...
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Ulrich Kuester
>
>
>
>
>
>
Re: Pluto sending POST params in the URL
Posted by John Lewis <jl...@arcanumintl.com>.
FYI: I just confirmed that I see the same exact behavior in uPortal, so
this does look like a Pluto issue, not just a Pluto Portal Driver issue.
John Lewis wrote:
> David,
>
> Thank you for your thorough response. I think everything you said makes
> good sense. I particularly like the idea of supporting either method.
> In fact, perhaps it's possible to decide automatically by testing the
> length of the generated URL and then falling back to an alternate method
> if it has become too long. Thanks again for your support in this.
>
> John
>
>
> David H. DeWolf wrote:
>
>>
>> See below:
>>
>> John Lewis wrote:
>>
>>> This seems like a pretty painful limitation. It is hard enough
>>> to pass data forward from the action phase to the render phase in a
>>> portlet, but to now have an additional limitation on how long the
>>> render parameters can be starts to make things really difficult.
>>>
>>> The problem with passing information forward from the action phase to
>>> the render phase via the session is that there is no way to know when
>>> the session data can be deleted. Since the portlet can be rendered
>>> repeatedly, how is the portlet to know when it is done using it? If
>>> there is no way to know, then we end up leaving orphaned data in the
>>> session and leaking memory over time until that session is finally
>>> invalidated.
>>>
>>> It also seems like this problem would escalate out of control as more
>>> and more portlets are displayed on the same page. Let's say we have
>>> 10 portlets all on the same page -- not an unreasonable number.
>>> Each of those 10 portlets will have to render itself on each request
>>> to the portal for that page (let's ignore the issue of caching for
>>> the moment). When the portal calls the portlet code to render each
>>> of those 10 portlets, it must deliver the same render parameters that
>>> it used the last time it rendered each one. If each one of those 10
>>> portlets has a few reasonably small render parameters set, but all
>>> the render parameters for all of the portlets are being encoded in
>>> the URL, it seems that the URL could exceed 4k pretty easily even
>>> though each portlet is using a small amount of data.
>>
>>
>>
>> Point well taken. . .but do remember that at this point the Pluto
>> portal driver (where the PortalURL implementation is actually defined)
>> is supposed to be an example of how to embed the container - not
>> necessarily a production quality portal. That said, I do think that
>> we want to move towards a more robust solution in the future.
>>
>>>
>>> As far as I know, this limitation is not part of the JSR-168 spec and
>>> so I imagine that many portlet developers would be surprised by this
>>> issue when they run into it using Pluto.
>>>
>>> I can understand the desire to have the specific render event be
>>> bookmarkable, but is that really so valuable as to sacrifice the
>>> ability to send forward a few k of string data from the action phase
>>> to the render phase via the render parameters?
>>
>>
>>
>> I think that depends on your point of view and specific case. Many
>> portal implementations I have done characterized bookmarkability and
>> browser back/forward buttons as more important than support for 4k of
>> parameters. . .probably because they had no need for the 4k.
>>
>>>
>>> Perhaps there is some way that Pluto could check ahead of time if the
>>> generated URL will be too long and then not put the parameters in the
>>> URL? I know this limitation does not exist in some other JSR-168
>>> implementations, so there must be a good way to avoid this.
>>>
>>
>> I would prefer providing two implementations of the interface - one
>> which support bookmarking and one which provides an alternate means
>> for handling render parameters so that they are not limited to 4k.
>> This will keep each request consistent and allow the deployer to make
>> an intelligent decision as to which is preferred. I guess the other
>> option would be to adopt your suggested approach and allow the > 4k
>> handling to be turned off.
>>
>> My preference is to support these in 1.1, not necessarily 1.0.x.
>>
>> David
>>
>>
>>> FYI: The reason we are forwarding a large amount of data forward from
>>> the action phase to the render phase is so that a submitted form that
>>> does not pass validation can be redisplayed with all the previously
>>> entered values still in place. I think this is not an unreasonable
>>> thing to expect to be able to do and is common practice in
>>> traditional web development.
>>
>>
>>
>> Agreed. This is definitely something we want to enhance at some point
>> in time.
>>
>>>
>>> Let us know what you think. We really appreciate your help with this.
>>>
>>> John
>>>
>>>
>>> Stefan Hepper wrote:
>>>
>>>> Here is what we do in pluto when new render parameters are set:
>>>> we create a URL with the new render parameters (and new portlet mode
>>>> and window state if any are set) and make a redirect to this URL.
>>>> The reason we do this is that we want to enable bookmarkability and
>>>> the browser back and forward buttons. Therefore we need to create
>>>> this new URL that reflects the outcome of the action and send it to
>>>> the client.
>>>>
>>>> What we currently not do is check the size of the parameters or
>>>> compress them. However, this part of the code is not the pluto
>>>> container code, but the pluto portal code (the URLProvider). The
>>>> pluto portal implementation is meant as a sample implementation and
>>>> not as a production portal and thus has limitations.
>>>>
>>>> The size of the URL is limited to 4k by the HTTP spec, but most
>>>> infrastructures only support 2k. Maybe the parameter gets truncated
>>>> and therefore you get the exception?
>>>>
>>>> What could be done is to store large parameters in the portal
>>>> session and only keep a ref ID in the URL, which of course would
>>>> exclude this param from the bookmarkability and back button support.
>>>>
>>>> As a general design principal the payload of the render params
>>>> should be as small as possible. Is there a way you can compress the
>>>> param value in the portlet?
>>>>
>>>> Stefan
>>>>
>>>> John Lewis wrote:
>>>>
>>>>> Ulrich,
>>>>>
>>>>> Tim's problem is happening with use of the Spring Portlet MVC
>>>>> framework,
>>>>> for which I am one of the developers. I've been able to reproduce his
>>>>> problem, but I am also confused what is causing it.
>>>>>
>>>>> The framework does in fact perform an include via the
>>>>> PortletRequestDispatcher, however this call completes successfully.
>>>>> In fact, the entire call to the portlet's doDispatch method is
>>>>> successful
>>>>> and does not throw any exceptions. It is only afterwards that an
>>>>> exception occurs.
>>>>>
>>>>> Here is the complete stack trace:
>>>>>
>>>>> java.lang.ArrayIndexOutOfBoundsException: 4096
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>>
>>>>> at org.apache.coyote.Response.action(Response.java:182)
>>>>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>>>>> at
>>>>> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>>>>>
>>>>> at
>>>>> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>>>>>
>>>>> at
>>>>> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>>>>>
>>>>> at
>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>>
>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor
>>>>> process
>>>>> SEVERE: Error finishing response
>>>>> java.lang.ArrayIndexOutOfBoundsException: 4097
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>>
>>>>> at org.apache.coyote.Response.action(Response.java:180)
>>>>> at
>>>>> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>>>>
>>>>> at
>>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>>
>>>>> at
>>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>>
>>>>> at java.lang.Thread.run(Thread.java:595)
>>>>>
>>>>> This is happening whenever a very large string is passed forward from
>>>>> action phase to the render phase via the
>>>>> ActionResponse.setRenderParameter method.
>>>>>
>>>>> This problem does not occur in Gridsphere (a different JSR-168
>>>>> portal),
>>>>> so there is something different in the implementations of the spec
>>>>> that
>>>>> is causing this error.
>>>>>
>>>>> Thanks for your help in trying to resolve this.
>>>>>
>>>>>
>>>>> John Lewis
>>>>>
>>>>>
>>>>>
>>>>> Ulrich Küster wrote:
>>>>>
>>>>>>> parameters are sent correctly. The problem was occurring when
>>>>>>> the response URL was sent back to the browser. I am using Spring
>>>>>>> Framework’s Portal MVC in conjunction with Pluto for our
>>>>>>> development purposes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I suppose you are using JSP via the PortletRequestDispatcher's
>>>>>> include method?
>>>>>>
>>>>>> Well, in that case PLT 16.3 states, that
>>>>>> "Servlets and JSPs included from portlets must be handled as HTTP
>>>>>> GET requests."
>>>>>>
>>>>>> The spec doesn't explain why that is the case so I can't help any
>>>>>> further. I certainly would be interested in other comments about
>>>>>> this issue...
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Ulrich Kuester
Re: Pluto sending POST params in the URL
Posted by John Lewis <jl...@arcanumintl.com>.
David,
Thank you for your thorough response. I think everything you said makes
good sense. I particularly like the idea of supporting either method. In
fact, perhaps it's possible to decide automatically by testing the length
of the generated URL and then falling back to an alternate method if it has
become too long. Thanks again for your support in this.
John
David H. DeWolf wrote:
>
> See below:
>
> John Lewis wrote:
>
>> This seems like a pretty painful limitation. It is hard enough
>> to pass data forward from the action phase to the render phase in a
>> portlet, but to now have an additional limitation on how long the
>> render parameters can be starts to make things really difficult.
>>
>> The problem with passing information forward from the action phase to
>> the render phase via the session is that there is no way to know when
>> the session data can be deleted. Since the portlet can be rendered
>> repeatedly, how is the portlet to know when it is done using it? If
>> there is no way to know, then we end up leaving orphaned data in the
>> session and leaking memory over time until that session is finally
>> invalidated.
>>
>> It also seems like this problem would escalate out of control as more
>> and more portlets are displayed on the same page. Let's say we have 10
>> portlets all on the same page -- not an unreasonable number. Each of
>> those 10 portlets will have to render itself on each request to the
>> portal for that page (let's ignore the issue of caching for the
>> moment). When the portal calls the portlet code to render each of
>> those 10 portlets, it must deliver the same render parameters that it
>> used the last time it rendered each one. If each one of those 10
>> portlets has a few reasonably small render parameters set, but all the
>> render parameters for all of the portlets are being encoded in the
>> URL, it seems that the URL could exceed 4k pretty easily even though
>> each portlet is using a small amount of data.
>
>
> Point well taken. . .but do remember that at this point the Pluto portal
> driver (where the PortalURL implementation is actually defined) is
> supposed to be an example of how to embed the container - not
> necessarily a production quality portal. That said, I do think that we
> want to move towards a more robust solution in the future.
>
>>
>> As far as I know, this limitation is not part of the JSR-168 spec and
>> so I imagine that many portlet developers would be surprised by this
>> issue when they run into it using Pluto.
>>
>> I can understand the desire to have the specific render event be
>> bookmarkable, but is that really so valuable as to sacrifice the
>> ability to send forward a few k of string data from the action phase
>> to the render phase via the render parameters?
>
>
> I think that depends on your point of view and specific case. Many
> portal implementations I have done characterized bookmarkability and
> browser back/forward buttons as more important than support for 4k of
> parameters. . .probably because they had no need for the 4k.
>
>>
>> Perhaps there is some way that Pluto could check ahead of time if the
>> generated URL will be too long and then not put the parameters in the
>> URL? I know this limitation does not exist in some other JSR-168
>> implementations, so there must be a good way to avoid this.
>>
>
> I would prefer providing two implementations of the interface - one
> which support bookmarking and one which provides an alternate means for
> handling render parameters so that they are not limited to 4k. This
> will keep each request consistent and allow the deployer to make an
> intelligent decision as to which is preferred. I guess the other option
> would be to adopt your suggested approach and allow the > 4k handling to
> be turned off.
>
> My preference is to support these in 1.1, not necessarily 1.0.x.
>
> David
>
>
>> FYI: The reason we are forwarding a large amount of data forward from
>> the action phase to the render phase is so that a submitted form that
>> does not pass validation can be redisplayed with all the previously
>> entered values still in place. I think this is not an unreasonable
>> thing to expect to be able to do and is common practice in traditional
>> web development.
>
>
> Agreed. This is definitely something we want to enhance at some point
> in time.
>
>>
>> Let us know what you think. We really appreciate your help with this.
>>
>> John
>>
>>
>> Stefan Hepper wrote:
>>
>>> Here is what we do in pluto when new render parameters are set:
>>> we create a URL with the new render parameters (and new portlet mode
>>> and window state if any are set) and make a redirect to this URL. The
>>> reason we do this is that we want to enable bookmarkability and the
>>> browser back and forward buttons. Therefore we need to create this
>>> new URL that reflects the outcome of the action and send it to the
>>> client.
>>>
>>> What we currently not do is check the size of the parameters or
>>> compress them. However, this part of the code is not the pluto
>>> container code, but the pluto portal code (the URLProvider). The
>>> pluto portal implementation is meant as a sample implementation and
>>> not as a production portal and thus has limitations.
>>>
>>> The size of the URL is limited to 4k by the HTTP spec, but most
>>> infrastructures only support 2k. Maybe the parameter gets truncated
>>> and therefore you get the exception?
>>>
>>> What could be done is to store large parameters in the portal session
>>> and only keep a ref ID in the URL, which of course would exclude this
>>> param from the bookmarkability and back button support.
>>>
>>> As a general design principal the payload of the render params should
>>> be as small as possible. Is there a way you can compress the param
>>> value in the portlet?
>>>
>>> Stefan
>>>
>>> John Lewis wrote:
>>>
>>>> Ulrich,
>>>>
>>>> Tim's problem is happening with use of the Spring Portlet MVC
>>>> framework,
>>>> for which I am one of the developers. I've been able to reproduce his
>>>> problem, but I am also confused what is causing it.
>>>>
>>>> The framework does in fact perform an include via the
>>>> PortletRequestDispatcher, however this call completes successfully.
>>>> In fact, the entire call to the portlet's doDispatch method is
>>>> successful
>>>> and does not throw any exceptions. It is only afterwards that an
>>>> exception occurs.
>>>>
>>>> Here is the complete stack trace:
>>>>
>>>> java.lang.ArrayIndexOutOfBoundsException: 4096
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>>>>
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>
>>>> at org.apache.coyote.Response.action(Response.java:182)
>>>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>>>> at
>>>> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>>>>
>>>> at
>>>> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>>>> at
>>>> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>>>>
>>>> at
>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>
>>>> at
>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>
>>>> at
>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>
>>>> at
>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>
>>>> at java.lang.Thread.run(Thread.java:595)
>>>> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor
>>>> process
>>>> SEVERE: Error finishing response
>>>> java.lang.ArrayIndexOutOfBoundsException: 4097
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>>
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>>
>>>> at org.apache.coyote.Response.action(Response.java:180)
>>>> at
>>>> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>>>
>>>> at
>>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>>
>>>> at
>>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>>
>>>> at
>>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>>
>>>> at
>>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>>
>>>> at java.lang.Thread.run(Thread.java:595)
>>>>
>>>> This is happening whenever a very large string is passed forward from
>>>> action phase to the render phase via the
>>>> ActionResponse.setRenderParameter method.
>>>>
>>>> This problem does not occur in Gridsphere (a different JSR-168 portal),
>>>> so there is something different in the implementations of the spec that
>>>> is causing this error.
>>>>
>>>> Thanks for your help in trying to resolve this.
>>>>
>>>>
>>>> John Lewis
>>>>
>>>>
>>>>
>>>> Ulrich Küster wrote:
>>>>
>>>>>> parameters are sent correctly. The problem was occurring when the
>>>>>> response URL was sent back to the browser. I am using Spring
>>>>>> Framework’s Portal MVC in conjunction with Pluto for our
>>>>>> development purposes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I suppose you are using JSP via the PortletRequestDispatcher's
>>>>> include method?
>>>>>
>>>>> Well, in that case PLT 16.3 states, that
>>>>> "Servlets and JSPs included from portlets must be handled as HTTP
>>>>> GET requests."
>>>>>
>>>>> The spec doesn't explain why that is the case so I can't help any
>>>>> further. I certainly would be interested in other comments about
>>>>> this issue...
>>>>>
>>>>> regards,
>>>>>
>>>>> Ulrich Kuester
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Pluto sending POST params in the URL
Posted by "David H. DeWolf" <dd...@apache.org>.
See below:
John Lewis wrote:
> This seems like a pretty painful limitation. It is hard enough
> to pass data forward from the action phase to the render phase in a
> portlet, but to now have an additional limitation on how long the render
> parameters can be starts to make things really difficult.
>
> The problem with passing information forward from the action phase to
> the render phase via the session is that there is no way to know when
> the session data can be deleted. Since the portlet can be rendered
> repeatedly, how is the portlet to know when it is done using it? If
> there is no way to know, then we end up leaving orphaned data in the
> session and leaking memory over time until that session is finally
> invalidated.
>
> It also seems like this problem would escalate out of control as more
> and more portlets are displayed on the same page. Let's say we have 10
> portlets all on the same page -- not an unreasonable number. Each of
> those 10 portlets will have to render itself on each request to the
> portal for that page (let's ignore the issue of caching for the
> moment). When the portal calls the portlet code to render each of those
> 10 portlets, it must deliver the same render parameters that it used the
> last time it rendered each one. If each one of those 10 portlets has a
> few reasonably small render parameters set, but all the render
> parameters for all of the portlets are being encoded in the URL, it
> seems that the URL could exceed 4k pretty easily even though each
> portlet is using a small amount of data.
Point well taken. . .but do remember that at this point the Pluto portal
driver (where the PortalURL implementation is actually defined) is
supposed to be an example of how to embed the container - not
necessarily a production quality portal. That said, I do think that we
want to move towards a more robust solution in the future.
>
> As far as I know, this limitation is not part of the JSR-168 spec and so
> I imagine that many portlet developers would be surprised by this issue
> when they run into it using Pluto.
>
> I can understand the desire to have the specific render event be
> bookmarkable, but is that really so valuable as to sacrifice the ability
> to send forward a few k of string data from the action phase to the
> render phase via the render parameters?
I think that depends on your point of view and specific case. Many
portal implementations I have done characterized bookmarkability and
browser back/forward buttons as more important than support for 4k of
parameters. . .probably because they had no need for the 4k.
>
> Perhaps there is some way that Pluto could check ahead of time if the
> generated URL will be too long and then not put the parameters in the
> URL? I know this limitation does not exist in some other JSR-168
> implementations, so there must be a good way to avoid this.
>
I would prefer providing two implementations of the interface - one
which support bookmarking and one which provides an alternate means for
handling render parameters so that they are not limited to 4k. This
will keep each request consistent and allow the deployer to make an
intelligent decision as to which is preferred. I guess the other option
would be to adopt your suggested approach and allow the > 4k handling to
be turned off.
My preference is to support these in 1.1, not necessarily 1.0.x.
David
> FYI: The reason we are forwarding a large amount of data forward from
> the action phase to the render phase is so that a submitted form that
> does not pass validation can be redisplayed with all the previously
> entered values still in place. I think this is not an unreasonable
> thing to expect to be able to do and is common practice in traditional
> web development.
Agreed. This is definitely something we want to enhance at some point
in time.
>
> Let us know what you think. We really appreciate your help with this.
>
> John
>
>
> Stefan Hepper wrote:
>
>> Here is what we do in pluto when new render parameters are set:
>> we create a URL with the new render parameters (and new portlet mode
>> and window state if any are set) and make a redirect to this URL. The
>> reason we do this is that we want to enable bookmarkability and the
>> browser back and forward buttons. Therefore we need to create this new
>> URL that reflects the outcome of the action and send it to the client.
>>
>> What we currently not do is check the size of the parameters or
>> compress them. However, this part of the code is not the pluto
>> container code, but the pluto portal code (the URLProvider). The pluto
>> portal implementation is meant as a sample implementation and not as a
>> production portal and thus has limitations.
>>
>> The size of the URL is limited to 4k by the HTTP spec, but most
>> infrastructures only support 2k. Maybe the parameter gets truncated
>> and therefore you get the exception?
>>
>> What could be done is to store large parameters in the portal session
>> and only keep a ref ID in the URL, which of course would exclude this
>> param from the bookmarkability and back button support.
>>
>> As a general design principal the payload of the render params should
>> be as small as possible. Is there a way you can compress the param
>> value in the portlet?
>>
>> Stefan
>>
>> John Lewis wrote:
>>
>>> Ulrich,
>>>
>>> Tim's problem is happening with use of the Spring Portlet MVC framework,
>>> for which I am one of the developers. I've been able to reproduce his
>>> problem, but I am also confused what is causing it.
>>>
>>> The framework does in fact perform an include via the
>>> PortletRequestDispatcher, however this call completes successfully.
>>> In fact, the entire call to the portlet's doDispatch method is
>>> successful
>>> and does not throw any exceptions. It is only afterwards that an
>>> exception occurs.
>>>
>>> Here is the complete stack trace:
>>>
>>> java.lang.ArrayIndexOutOfBoundsException: 4096
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>>>
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>
>>> at org.apache.coyote.Response.action(Response.java:182)
>>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>>> at
>>> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>>>
>>> at
>>> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>>> at
>>> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>
>>> at
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>
>>> at
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>
>>> at
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>
>>> at java.lang.Thread.run(Thread.java:595)
>>> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
>>> SEVERE: Error finishing response
>>> java.lang.ArrayIndexOutOfBoundsException: 4097
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>>
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>>>
>>> at org.apache.coyote.Response.action(Response.java:180)
>>> at
>>> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>>
>>> at
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>>
>>> at
>>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>>
>>> at
>>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>>
>>> at
>>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>>
>>> at java.lang.Thread.run(Thread.java:595)
>>>
>>> This is happening whenever a very large string is passed forward from
>>> action phase to the render phase via the
>>> ActionResponse.setRenderParameter method.
>>>
>>> This problem does not occur in Gridsphere (a different JSR-168 portal),
>>> so there is something different in the implementations of the spec that
>>> is causing this error.
>>>
>>> Thanks for your help in trying to resolve this.
>>>
>>>
>>> John Lewis
>>>
>>>
>>>
>>> Ulrich Küster wrote:
>>>
>>>>> parameters are sent correctly. The problem was occurring when the
>>>>> response URL was sent back to the browser. I am using Spring
>>>>> Framework’s Portal MVC in conjunction with Pluto for our
>>>>> development purposes.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I suppose you are using JSP via the PortletRequestDispatcher's
>>>> include method?
>>>>
>>>> Well, in that case PLT 16.3 states, that
>>>> "Servlets and JSPs included from portlets must be handled as HTTP
>>>> GET requests."
>>>>
>>>> The spec doesn't explain why that is the case so I can't help any
>>>> further. I certainly would be interested in other comments about
>>>> this issue...
>>>>
>>>> regards,
>>>>
>>>> Ulrich Kuester
>>>>
>>>
>>>
>>>
>>
>>
>
>
Re: Pluto sending POST params in the URL
Posted by John Lewis <jl...@arcanumintl.com>.
This seems like a pretty painful limitation. It is hard enough
to pass data forward from the action phase to the render phase in a
portlet, but to now have an additional limitation on how long the render
parameters can be starts to make things really difficult.
The problem with passing information forward from the action phase to the
render phase via the session is that there is no way to know when the
session data can be deleted. Since the portlet can be rendered repeatedly,
how is the portlet to know when it is done using it? If there is no way to
know, then we end up leaving orphaned data in the session and leaking
memory over time until that session is finally invalidated.
It also seems like this problem would escalate out of control as more and
more portlets are displayed on the same page. Let's say we have 10 portlets
all on the same page -- not an unreasonable number. Each of those 10
portlets will have to render itself on each request to the portal for that
page (let's ignore the issue of caching for the moment). When the portal
calls the portlet code to render each of those 10 portlets, it must deliver
the same render parameters that it used the last time it rendered each one.
If each one of those 10 portlets has a few reasonably small render
parameters set, but all the render parameters for all of the portlets are
being encoded in the URL, it seems that the URL could exceed 4k pretty
easily even though each portlet is using a small amount of data.
As far as I know, this limitation is not part of the JSR-168 spec and so I
imagine that many portlet developers would be surprised by this issue when
they run into it using Pluto.
I can understand the desire to have the specific render event be
bookmarkable, but is that really so valuable as to sacrifice the ability to
send forward a few k of string data from the action phase to the render
phase via the render parameters?
Perhaps there is some way that Pluto could check ahead of time if the
generated URL will be too long and then not put the parameters in the URL?
I know this limitation does not exist in some other JSR-168
implementations, so there must be a good way to avoid this.
FYI: The reason we are forwarding a large amount of data forward from the
action phase to the render phase is so that a submitted form that does not
pass validation can be redisplayed with all the previously entered values
still in place. I think this is not an unreasonable thing to expect to be
able to do and is common practice in traditional web development.
Let us know what you think. We really appreciate your help with this.
John
Stefan Hepper wrote:
> Here is what we do in pluto when new render parameters are set:
> we create a URL with the new render parameters (and new portlet mode and
> window state if any are set) and make a redirect to this URL. The reason
> we do this is that we want to enable bookmarkability and the browser
> back and forward buttons. Therefore we need to create this new URL that
> reflects the outcome of the action and send it to the client.
>
> What we currently not do is check the size of the parameters or compress
> them. However, this part of the code is not the pluto container code,
> but the pluto portal code (the URLProvider). The pluto portal
> implementation is meant as a sample implementation and not as a
> production portal and thus has limitations.
>
> The size of the URL is limited to 4k by the HTTP spec, but most
> infrastructures only support 2k. Maybe the parameter gets truncated and
> therefore you get the exception?
>
> What could be done is to store large parameters in the portal session
> and only keep a ref ID in the URL, which of course would exclude this
> param from the bookmarkability and back button support.
>
> As a general design principal the payload of the render params should be
> as small as possible. Is there a way you can compress the param value in
> the portlet?
>
> Stefan
>
> John Lewis wrote:
>
>> Ulrich,
>>
>> Tim's problem is happening with use of the Spring Portlet MVC framework,
>> for which I am one of the developers. I've been able to reproduce his
>> problem, but I am also confused what is causing it.
>>
>> The framework does in fact perform an include via the
>> PortletRequestDispatcher, however this call completes successfully.
>> In fact, the entire call to the portlet's doDispatch method is successful
>> and does not throw any exceptions. It is only afterwards that an
>> exception occurs.
>>
>> Here is the complete stack trace:
>>
>> java.lang.ArrayIndexOutOfBoundsException: 4096
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>>
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>> at org.apache.coyote.Response.action(Response.java:182)
>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>> at
>> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>> at
>> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>> at
>> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>
>> at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>
>> at
>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>
>> at
>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>
>> at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>
>> at java.lang.Thread.run(Thread.java:595)
>> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
>> SEVERE: Error finishing response
>> java.lang.ArrayIndexOutOfBoundsException: 4097
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>>
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>> at org.apache.coyote.Response.action(Response.java:180)
>> at
>> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>>
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>
>> at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>>
>> at
>> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>>
>> at
>> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>>
>> at
>> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>>
>> at java.lang.Thread.run(Thread.java:595)
>>
>> This is happening whenever a very large string is passed forward from
>> action phase to the render phase via the
>> ActionResponse.setRenderParameter method.
>>
>> This problem does not occur in Gridsphere (a different JSR-168 portal),
>> so there is something different in the implementations of the spec that
>> is causing this error.
>>
>> Thanks for your help in trying to resolve this.
>>
>>
>> John Lewis
>>
>>
>>
>> Ulrich Küster wrote:
>>
>>>> parameters are sent correctly. The problem was occurring when the
>>>> response URL was sent back to the browser. I am using Spring
>>>> Framework’s Portal MVC in conjunction with Pluto for our development
>>>> purposes.
>>>
>>>
>>>
>>>
>>> I suppose you are using JSP via the PortletRequestDispatcher's
>>> include method?
>>>
>>> Well, in that case PLT 16.3 states, that
>>> "Servlets and JSPs included from portlets must be handled as HTTP GET
>>> requests."
>>>
>>> The spec doesn't explain why that is the case so I can't help any
>>> further. I certainly would be interested in other comments about this
>>> issue...
>>>
>>> regards,
>>>
>>> Ulrich Kuester
>>>
>>
>>
>>
>
>
Re: Pluto sending POST params in the URL
Posted by Stefan Hepper <st...@apache.org>.
Tim,
the spec left the implemention of the render parameter up to the portal
/ portlet container. This allows different vendors to implement
different strategies, or even make them configurable. I don't think that
you can define something in the spec for this topic that would fit for
all use cases. For some applications bookmarkability and support of the
browser buttons are the first priority, for others the support of large
parameters.
On the other hand, I don't think that using render parameters for
storing that amount of data is a good design. The intent of the render
parameters are to provide the portlet with a mechanism to store its view
state.
Stefan
Tim Kettering wrote:
>Stefan,
>
>The issue I am seeing is that in a portlet I am developing, I have about 15
>form fields, two which are text areas. And since this is for a content
>management type input, the textarea could in theory contain quite a large
>amount of text (we intend to allow users to paste in Word documents), so
>even with compression, it could easily exceed 4K.
>
>And in the case of the Spring portlet code, since all request parameters are
>copied to the response object, all of the parameters (including the values
>of the text areas) are copied over, and end up in the URL that is returned
>to the browser.
>
>So what I have been trying to figure out is whether the portlet spec
>actually expects all response parameters to be encoded and made part of the
>URL that is returned to the browser, since the spec is not clear on that
>specific point. It only states that the parameters should be encoded. I
>ask this question because Pluto apparently does this, but the portal
>container that John uses (Gridsphere) does not. So there seems to be two
>different interpretations here.
>
>I understand that you are one of the specification leads, so can you clear
>up one way or another? Thanks!
>
>-tim
>
>-----Original Message-----
>From: Stefan Hepper [mailto:sthepper@apache.org]
>Sent: Wednesday, August 17, 2005 3:00 AM
>To: pluto-dev@portals.apache.org
>Subject: Re: Pluto sending POST params in the URL
>
>Here is what we do in pluto when new render parameters are set:
>we create a URL with the new render parameters (and new portlet mode and
>window state if any are set) and make a redirect to this URL. The reason
>we do this is that we want to enable bookmarkability and the browser
>back and forward buttons. Therefore we need to create this new URL that
>reflects the outcome of the action and send it to the client.
>
>What we currently not do is check the size of the parameters or compress
>them. However, this part of the code is not the pluto container code,
>but the pluto portal code (the URLProvider). The pluto portal
>implementation is meant as a sample implementation and not as a
>production portal and thus has limitations.
>
>The size of the URL is limited to 4k by the HTTP spec, but most
>infrastructures only support 2k. Maybe the parameter gets truncated and
>therefore you get the exception?
>
>What could be done is to store large parameters in the portal session
>and only keep a ref ID in the URL, which of course would exclude this
>param from the bookmarkability and back button support.
>
>As a general design principal the payload of the render params should be
>as small as possible. Is there a way you can compress the param value in
>the portlet?
>
>Stefan
>
>John Lewis wrote:
>
>
>
>>Ulrich,
>>
>>Tim's problem is happening with use of the Spring Portlet MVC framework,
>>for which I am one of the developers. I've been able to reproduce his
>>problem, but I am also confused what is causing it.
>>
>>The framework does in fact perform an include via the
>>PortletRequestDispatcher, however this call completes successfully.
>>In fact, the entire call to the portlet's doDispatch method is successful
>>and does not throw any exceptions. It is only afterwards that an
>>exception occurs.
>>
>>Here is the complete stack trace:
>>
>>java.lang.ArrayIndexOutOfBoundsException: 4096
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
>a:727)
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
>a:618)
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffe
>r.java:497)
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav
>a:1561)
>
>
>> at
>>org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>> at org.apache.coyote.Response.action(Response.java:182)
>> at org.apache.coyote.Response.sendHeaders(Response.java:374)
>> at
>>org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
>> at
>>org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
>> at
>>org.apache.catalina.connector.Response.finishResponse(Response.java:472)
>> at
>>
>>
>>
>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>
>
>> at
>>org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>>
>>
>
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
>ction(Http11Protocol.java:731)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav
>a:526)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo
>rkerThread.java:80)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
>a:684)
>
>
>> at java.lang.Thread.run(Thread.java:595)
>>Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
>>SEVERE: Error finishing response
>>java.lang.ArrayIndexOutOfBoundsException: 4097
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
>a:727)
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffe
>r.java:429)
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav
>a:1550)
>
>
>> at
>>org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
>> at org.apache.coyote.Response.action(Response.java:180)
>> at
>>
>>
>>
>org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffe
>r.java:389)
>
>
>> at
>>org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>>
>>
>
>
>
>> at
>>
>>
>>
>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
>ction(Http11Protocol.java:731)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav
>a:526)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo
>rkerThread.java:80)
>
>
>> at
>>
>>
>>
>org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
>a:684)
>
>
>> at java.lang.Thread.run(Thread.java:595)
>>
>>This is happening whenever a very large string is passed forward from
>>action phase to the render phase via the
>>ActionResponse.setRenderParameter method.
>>
>>This problem does not occur in Gridsphere (a different JSR-168 portal),
>>so there is something different in the implementations of the spec that
>>is causing this error.
>>
>>Thanks for your help in trying to resolve this.
>>
>>
>>John Lewis
>>
>>
>>
>>Ulrich Küster wrote:
>>
>>
>>
>>>>parameters are sent correctly. The problem was occurring when the
>>>>response URL was sent back to the browser. I am using Spring
>>>>Framework’s Portal MVC in conjunction with Pluto for our development
>>>>purposes.
>>>>
>>>>
>>>
>>>I suppose you are using JSP via the PortletRequestDispatcher's
>>>include method?
>>>
>>>Well, in that case PLT 16.3 states, that
>>>"Servlets and JSPs included from portlets must be handled as HTTP GET
>>>requests."
>>>
>>>The spec doesn't explain why that is the case so I can't help any
>>>further. I certainly would be interested in other comments about this
>>>issue...
>>>
>>>regards,
>>>
>>>Ulrich Kuester
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
RE: Pluto sending POST params in the URL
Posted by Tim Kettering <ti...@vivakos.com>.
Stefan,
The issue I am seeing is that in a portlet I am developing, I have about 15
form fields, two which are text areas. And since this is for a content
management type input, the textarea could in theory contain quite a large
amount of text (we intend to allow users to paste in Word documents), so
even with compression, it could easily exceed 4K.
And in the case of the Spring portlet code, since all request parameters are
copied to the response object, all of the parameters (including the values
of the text areas) are copied over, and end up in the URL that is returned
to the browser.
So what I have been trying to figure out is whether the portlet spec
actually expects all response parameters to be encoded and made part of the
URL that is returned to the browser, since the spec is not clear on that
specific point. It only states that the parameters should be encoded. I
ask this question because Pluto apparently does this, but the portal
container that John uses (Gridsphere) does not. So there seems to be two
different interpretations here.
I understand that you are one of the specification leads, so can you clear
up one way or another? Thanks!
-tim
-----Original Message-----
From: Stefan Hepper [mailto:sthepper@apache.org]
Sent: Wednesday, August 17, 2005 3:00 AM
To: pluto-dev@portals.apache.org
Subject: Re: Pluto sending POST params in the URL
Here is what we do in pluto when new render parameters are set:
we create a URL with the new render parameters (and new portlet mode and
window state if any are set) and make a redirect to this URL. The reason
we do this is that we want to enable bookmarkability and the browser
back and forward buttons. Therefore we need to create this new URL that
reflects the outcome of the action and send it to the client.
What we currently not do is check the size of the parameters or compress
them. However, this part of the code is not the pluto container code,
but the pluto portal code (the URLProvider). The pluto portal
implementation is meant as a sample implementation and not as a
production portal and thus has limitations.
The size of the URL is limited to 4k by the HTTP spec, but most
infrastructures only support 2k. Maybe the parameter gets truncated and
therefore you get the exception?
What could be done is to store large parameters in the portal session
and only keep a ref ID in the URL, which of course would exclude this
param from the bookmarkability and back button support.
As a general design principal the payload of the render params should be
as small as possible. Is there a way you can compress the param value in
the portlet?
Stefan
John Lewis wrote:
> Ulrich,
>
> Tim's problem is happening with use of the Spring Portlet MVC framework,
> for which I am one of the developers. I've been able to reproduce his
> problem, but I am also confused what is causing it.
>
> The framework does in fact perform an include via the
> PortletRequestDispatcher, however this call completes successfully.
> In fact, the entire call to the portlet's doDispatch method is successful
> and does not throw any exceptions. It is only afterwards that an
> exception occurs.
>
> Here is the complete stack trace:
>
> java.lang.ArrayIndexOutOfBoundsException: 4096
> at
>
org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
a:727)
>
> at
>
org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
a:618)
>
> at
>
org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffe
r.java:497)
>
> at
>
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav
a:1561)
>
> at
> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
> at org.apache.coyote.Response.action(Response.java:182)
> at org.apache.coyote.Response.sendHeaders(Response.java:374)
> at
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
> at
> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
> at
> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
> at
>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>
> at
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:731)
>
> at
>
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav
a:526)
>
> at
>
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo
rkerThread.java:80)
>
> at
>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:684)
>
> at java.lang.Thread.run(Thread.java:595)
> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error finishing response
> java.lang.ArrayIndexOutOfBoundsException: 4097
> at
>
org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.jav
a:727)
>
> at
>
org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffe
r.java:429)
>
> at
>
org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.jav
a:1550)
>
> at
> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
> at org.apache.coyote.Response.action(Response.java:180)
> at
>
org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffe
r.java:389)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>
> at
>
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:731)
>
> at
>
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav
a:526)
>
> at
>
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo
rkerThread.java:80)
>
> at
>
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:684)
>
> at java.lang.Thread.run(Thread.java:595)
>
> This is happening whenever a very large string is passed forward from
> action phase to the render phase via the
> ActionResponse.setRenderParameter method.
>
> This problem does not occur in Gridsphere (a different JSR-168 portal),
> so there is something different in the implementations of the spec that
> is causing this error.
>
> Thanks for your help in trying to resolve this.
>
>
> John Lewis
>
>
>
> Ulrich Küster wrote:
>
>>> parameters are sent correctly. The problem was occurring when the
>>> response URL was sent back to the browser. I am using Spring
>>> Frameworks Portal MVC in conjunction with Pluto for our development
>>> purposes.
>>
>>
>>
>> I suppose you are using JSP via the PortletRequestDispatcher's
>> include method?
>>
>> Well, in that case PLT 16.3 states, that
>> "Servlets and JSPs included from portlets must be handled as HTTP GET
>> requests."
>>
>> The spec doesn't explain why that is the case so I can't help any
>> further. I certainly would be interested in other comments about this
>> issue...
>>
>> regards,
>>
>> Ulrich Kuester
>>
>
>
>
Re: Pluto sending POST params in the URL
Posted by Stefan Hepper <st...@apache.org>.
Here is what we do in pluto when new render parameters are set:
we create a URL with the new render parameters (and new portlet mode and
window state if any are set) and make a redirect to this URL. The reason
we do this is that we want to enable bookmarkability and the browser
back and forward buttons. Therefore we need to create this new URL that
reflects the outcome of the action and send it to the client.
What we currently not do is check the size of the parameters or compress
them. However, this part of the code is not the pluto container code,
but the pluto portal code (the URLProvider). The pluto portal
implementation is meant as a sample implementation and not as a
production portal and thus has limitations.
The size of the URL is limited to 4k by the HTTP spec, but most
infrastructures only support 2k. Maybe the parameter gets truncated and
therefore you get the exception?
What could be done is to store large parameters in the portal session
and only keep a ref ID in the URL, which of course would exclude this
param from the bookmarkability and back button support.
As a general design principal the payload of the render params should be
as small as possible. Is there a way you can compress the param value in
the portlet?
Stefan
John Lewis wrote:
> Ulrich,
>
> Tim's problem is happening with use of the Spring Portlet MVC framework,
> for which I am one of the developers. I've been able to reproduce his
> problem, but I am also confused what is causing it.
>
> The framework does in fact perform an include via the
> PortletRequestDispatcher, however this call completes successfully.
> In fact, the entire call to the portlet's doDispatch method is successful
> and does not throw any exceptions. It is only afterwards that an
> exception occurs.
>
> Here is the complete stack trace:
>
> java.lang.ArrayIndexOutOfBoundsException: 4096
> at
> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>
> at
> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
>
> at
> org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
>
> at
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
>
> at
> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
> at org.apache.coyote.Response.action(Response.java:182)
> at org.apache.coyote.Response.sendHeaders(Response.java:374)
> at
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
> at
> org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
> at
> org.apache.catalina.connector.Response.finishResponse(Response.java:472)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
>
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>
> at java.lang.Thread.run(Thread.java:595)
> Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
> SEVERE: Error finishing response
> java.lang.ArrayIndexOutOfBoundsException: 4097
> at
> org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
>
> at
> org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
>
> at
> org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
>
> at
> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
> at org.apache.coyote.Response.action(Response.java:180)
> at
> org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
>
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
>
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
>
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
>
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
>
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
>
> at java.lang.Thread.run(Thread.java:595)
>
> This is happening whenever a very large string is passed forward from
> action phase to the render phase via the
> ActionResponse.setRenderParameter method.
>
> This problem does not occur in Gridsphere (a different JSR-168 portal),
> so there is something different in the implementations of the spec that
> is causing this error.
>
> Thanks for your help in trying to resolve this.
>
>
> John Lewis
>
>
>
> Ulrich Küster wrote:
>
>>> parameters are sent correctly. The problem was occurring when the
>>> response URL was sent back to the browser. I am using Spring
>>> Framework’s Portal MVC in conjunction with Pluto for our development
>>> purposes.
>>
>>
>>
>> I suppose you are using JSP via the PortletRequestDispatcher's
>> include method?
>>
>> Well, in that case PLT 16.3 states, that
>> "Servlets and JSPs included from portlets must be handled as HTTP GET
>> requests."
>>
>> The spec doesn't explain why that is the case so I can't help any
>> further. I certainly would be interested in other comments about this
>> issue...
>>
>> regards,
>>
>> Ulrich Kuester
>>
>
>
>
Re: Pluto sending POST params in the URL
Posted by John Lewis <jl...@arcanumintl.com>.
Ulrich,
Tim's problem is happening with use of the Spring Portlet MVC framework,
for which I am one of the developers. I've been able to reproduce his
problem, but I am also confused what is causing it.
The framework does in fact perform an include via the
PortletRequestDispatcher, however this call completes successfully.
In fact, the entire call to the portlet's doDispatch method is successful
and does not throw any exceptions. It is only afterwards that an
exception occurs.
Here is the complete stack trace:
java.lang.ArrayIndexOutOfBoundsException: 4096
at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:618)
at org.apache.coyote.http11.InternalOutputBuffer.sendHeader(InternalOutputBuffer.java:497)
at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1561)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
at org.apache.coyote.Response.action(Response.java:182)
at org.apache.coyote.Response.sendHeaders(Response.java:374)
at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:316)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:277)
at org.apache.catalina.connector.Response.finishResponse(Response.java:472)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:825)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Aug 16, 2005 9:26:04 PM org.apache.coyote.http11.Http11Processor process
SEVERE: Error finishing response
java.lang.ArrayIndexOutOfBoundsException: 4097
at org.apache.coyote.http11.InternalOutputBuffer.write(InternalOutputBuffer.java:727)
at org.apache.coyote.http11.InternalOutputBuffer.sendStatus(InternalOutputBuffer.java:429)
at org.apache.coyote.http11.Http11Processor.prepareResponse(Http11Processor.java:1550)
at org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:918)
at org.apache.coyote.Response.action(Response.java:180)
at org.apache.coyote.http11.InternalOutputBuffer.endRequest(InternalOutputBuffer.java:389)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:862)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:731)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:526)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
This is happening whenever a very large string is passed forward from
action phase to the render phase via the
ActionResponse.setRenderParameter method.
This problem does not occur in Gridsphere (a different JSR-168 portal),
so there is something different in the implementations of the spec that
is causing this error.
Thanks for your help in trying to resolve this.
John Lewis
Ulrich Küster wrote:
>> parameters are sent correctly. The problem was occurring when the
>> response URL was sent back to the browser. I am using Spring
>> Framework’s Portal MVC in conjunction with Pluto for our development
>> purposes.
>
>
> I suppose you are using JSP via the PortletRequestDispatcher's include
> method?
>
> Well, in that case PLT 16.3 states, that
> "Servlets and JSPs included from portlets must be handled as HTTP GET
> requests."
>
> The spec doesn't explain why that is the case so I can't help any
> further. I certainly would be interested in other comments about this
> issue...
>
> regards,
>
> Ulrich Kuester
>
Re: Pluto sending POST params in the URL
Posted by Ulrich Küster <Ul...@uni-jena.de>.
> parameters are sent correctly. The problem was occurring when the
> response URL was sent back to the browser. I am using Spring
> Framework’s Portal MVC in conjunction with Pluto for our development
> purposes.
I suppose you are using JSP via the PortletRequestDispatcher's include
method?
Well, in that case PLT 16.3 states, that
"Servlets and JSPs included from portlets must be handled as HTTP GET
requests."
The spec doesn't explain why that is the case so I can't help any
further. I certainly would be interested in other comments about this
issue...
regards,
Ulrich Kuester