You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrp4j-dev@portals.apache.org by Xiaobo Yang <xi...@gmail.com> on 2006/02/28 18:03:18 UTC
file upload issue
Hi, recently I had a look at the file upload issue and got something here to
say.
1. A normal file upload portlet normals makes use of jakarta commons
FileUpload to support RFC 1867 (Form-based File UPload in HTML). This works
fine as a normal JSR 168 portlet, but not remote portlet because currently
in WSRP4J, there is no such data transferred from consumer to producer.
2. I have managed to transfer data (Base64 encoded) and extra information
such as file name etc. as Extension from consumer to producer using
PerformBlockingInteraction -> InteractionParams -> UploadContext[].
Question: Is there any better approach to trasnfer such data?
3. Producer now faces an issue to make remote file upload portlet work.
Approach 1: Reconstruct HttpServletRequest and set correct mime-type,
content-type... Is it possible?
Approach 2: Extract data in UploadContext[] and attach to parameter map so
that they can be retrieved in file upload portlet. But this requires
modification of the portlet. I did this by modifying PortletInvokerImpl.java
.
Any comment? Thanks.
PS. How about file download?
Xiaobo
Re: file upload issue
Posted by Xiaobo Yang <xi...@gmail.com>.
For file upload, ideally, it should be good to construct a
HttpServletRequest object which simulates the original one sent from user's
browser to consumer with "enctype" set as "multipart/form-data" etc. Then
append data user uploaded. I am not sure whether this is possible or not. If
so, then there is no need to modify the file upload portlet at all.
For file download, if the file can not be published as an URL resource, what
shall we do? Currently I redirect to a servlet to do file download in a
portlet and it works fine. But since there is no support of redirect in
wsrp4j now this does not work.
Xiaobo
On 3/1/06, Subbu Allamaraju <su...@gmail.com> wrote:
>
> I'm not a WSRP4J dev, but can answer these questions from the spec's point
> of view.
>
> The right way (per the spec, that is) to send the uploaded data is to use
> one or more UploadContext elements in the manner you tried.
>
> It is possible to recreate the request on the producer end using the
> UploadContext elements. Note that some consumers may split the uploaded data
> into individual parts and send those as seperate UploadContext. So, the
> producer needs to be able to account for either one or several UploadContext
> elements.
>
> However, this is not the most efficient form of transferring uploaded data
> across the wire since it can easily cause OutOfMemory errors. However, WSRP
> does not support attachment specs like SwA, MTOM/XOP at this time.
>
> On your question for downloads, you can use resource URLs in WSRP to
> create links to download documents. In JSR168, these URLs map to URLs
> created using encodeURL() method.
>
> Subbu
>
>
> On 2/28/06, Xiaobo Yang <xi...@gmail.com> wrote:
> >
> > Hi, recently I had a look at the file upload issue and got something
> > here to say.
> >
> > 1. A normal file upload portlet normals makes use of jakarta commons
> > FileUpload to support RFC 1867 (Form-based File UPload in HTML). This works
> > fine as a normal JSR 168 portlet, but not remote portlet because currently
> > in WSRP4J, there is no such data transferred from consumer to producer.
> >
> > 2. I have managed to transfer data (Base64 encoded) and extra
> > information such as file name etc. as Extension from consumer to producer
> > using PerformBlockingInteraction -> InteractionParams -> UploadContext[].
> > Question: Is there any better approach to trasnfer such data?
> >
> > 3. Producer now faces an issue to make remote file upload portlet work.
> > Approach 1: Reconstruct HttpServletRequest and set correct mime-type,
> > content-type... Is it possible?
> > Approach 2: Extract data in UploadContext[] and attach to parameter map
> > so that they can be retrieved in file upload portlet. But this requires
> > modification of the portlet. I did this by modifying
> > PortletInvokerImpl.java.
> >
> > Any comment? Thanks.
> >
> > PS. How about file download?
> >
> > Xiaobo
> >
>
>
>
> --
> ------------------------------
> http://www.subbu.org
>
Re: file upload issue
Posted by Subbu Allamaraju <su...@gmail.com>.
I'm not a WSRP4J dev, but can answer these questions from the spec's point
of view.
The right way (per the spec, that is) to send the uploaded data is to use
one or more UploadContext elements in the manner you tried.
It is possible to recreate the request on the producer end using the
UploadContext elements. Note that some consumers may split the uploaded data
into individual parts and send those as seperate UploadContext. So, the
producer needs to be able to account for either one or several UploadContext
elements.
However, this is not the most efficient form of transferring uploaded data
across the wire since it can easily cause OutOfMemory errors. However, WSRP
does not support attachment specs like SwA, MTOM/XOP at this time.
On your question for downloads, you can use resource URLs in WSRP to create
links to download documents. In JSR168, these URLs map to URLs created using
encodeURL() method.
Subbu
On 2/28/06, Xiaobo Yang <xi...@gmail.com> wrote:
>
> Hi, recently I had a look at the file upload issue and got something here
> to say.
>
> 1. A normal file upload portlet normals makes use of jakarta commons
> FileUpload to support RFC 1867 (Form-based File UPload in HTML). This works
> fine as a normal JSR 168 portlet, but not remote portlet because currently
> in WSRP4J, there is no such data transferred from consumer to producer.
>
> 2. I have managed to transfer data (Base64 encoded) and extra information
> such as file name etc. as Extension from consumer to producer using
> PerformBlockingInteraction -> InteractionParams -> UploadContext[].
> Question: Is there any better approach to trasnfer such data?
>
> 3. Producer now faces an issue to make remote file upload portlet work.
> Approach 1: Reconstruct HttpServletRequest and set correct mime-type,
> content-type... Is it possible?
> Approach 2: Extract data in UploadContext[] and attach to parameter map so
> that they can be retrieved in file upload portlet. But this requires
> modification of the portlet. I did this by modifying
> PortletInvokerImpl.java.
>
> Any comment? Thanks.
>
> PS. How about file download?
>
> Xiaobo
>
--
------------------------------
http://www.subbu.org