cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Juffer <andre.juf...@oulu.fi>
Subject Re: [cocoon3] @Context Request request
Date Mon, 31 Oct 2011 11:20:54 GMT
On 10/31/2011 01:17 PM, Steven Dolg wrote:
> Am 31.10.2011 12:00, schrieb Andre Juffer:
>> Steven,
>>
>> I have a number of REST resources all working just fine. It is just 
>> this image upload thing that is not working correctly. I can add to 
>> my previous email that I am using dojo 1.6.1 on the client to create 
>> the POST request.
>
> Should have worded that more carefully. :/
> My advice was not to abandon Cocoon / Jersey completely.
>
> I just feel that it helps tremendously to reduce the complexity of the 
> solution, when you can't figure out why something's not working as 
> expected.
> Reducing the number of "parts" (in this case frameworks) of your 
> solution is usually the easiest way to eliminate complexity.
>
> Once you get the simple solution to work you either already know why 
> it didn't work in the first place or you can go back to adding your 
> target technologies one by one and see which introduces the problem.


I got your point. I will try this:

http://docs.codehaus.org/display/JETTY/File+Upload+in+jetty6

(no cocoon, no jersey)

and adapt it to work with commons fileupload.

>
>>
>> And, yes, jetty is a common servlet engine and should not cause any 
>> particular problem. I did read somewhere that during uploading files, 
>> each file may be temporally stored in some location on the server 
>> (the actual location is controlled by the web server and/or servlet 
>> engine) before control is passed on to, in my case, the ImageResource.
>>
>> Thanks for your help,
>> André
>>
>> On 10/31/2011 12:40 PM, Steven Dolg wrote:
>>> Am 31.10.2011 11:29, schrieb Andre Juffer:
>>>> Steven,
>>>>
>>>> thanks for the reply.
>>>>
>>>> The purpose of the request is to upload an image file. With commons 
>>>> fileupload this is straightforward, but it requires direct access 
>>>> to HttpServletRequest. I did understand that HttpServletRequest is 
>>>> an interface of course.
>>>>
>>>> With commons fileupload, one would do something like
>>>>
>>>> FileItemFactory factory = new DiskFileItemFactory();
>>>> ServletFileUpload upload = new ServletFileUpload(factory);
>>>> List<FileItem> items = upload.parseRequest(request);
>>>>
>>>> Here, 'request' must be (an implementation of) HttpServletRequest. 
>>>> One of 'items' would contain the image.
>>>>
>>>> If I use
>>>>
>>>> public Response uploadImage(@Context Request request)
>>>>
>>>> the type of 'request' is 
>>>> com.sun.jersey.spi.container.ContainerRequest, which will not work 
>>>> with 'upload.parseRequest(request)' above. The ContainerRequest 
>>>> does not implement HttpServletRequest. Following your email, one 
>>>> should see for 'request' a HttpServletRequest? I would agree with 
>>>> this, given the statement at the jersey website "When deploying a 
>>>> JAX-RS application using servlet then ServletConfig, 
>>>> ServletContext, HttpServletRequest and HttpServletResponse are 
>>>> available using @Context.".
>>>>
>>>> With
>>>>
>>>> public Response uploadImage(@Context HttpServletRequest request)
>>>>
>>>> the type of request is some proxy (this is the name of an 
>>>> implementing class, something like $Proxy38).
>>>>
>>>> In any case, i -did- use public Response uploadImage(@Context 
>>>> HttpServletRequest request) and noticed that the request is empty 
>>>> (that is, the List<FileItem>  above is empty). That is, no image 
>>>> file is available, although it was sent correctly (checked with 
>>>> Firebug).
>>>>
>>>> So, my conclusion was that something is not working correctly and 
>>>> that's why I was wondering about the type of request. The POST 
>>>> request on the client was something like
>>>>
>>>> http://localhost:8888/eap/rest/image
>>>>
>>>> with jetty as the servlet engine. I cannot be sure what happens in 
>>>> between sending the request and the handling by 
>>>> 'ImageResource.uploadImage(..)'.
>>>
>>> I'm sorry, but I'm not familiar with commons-fileupload and not very 
>>> familiar with Jersey.
>>> All I can say is that your problem is (probably) not within Cocoon.
>>>
>>> Using some rather uncommon Servlet-Container is a good source for 
>>> obscure problems, but Jetty is very common and should work fine.
>>>
>>> At this time I can only advise you to check the documentation for 
>>> commons-fileupload an maybe try to get it working with a very simple 
>>> servlet without any Cocoon, Jersey and any other framework at all.
>>>
>>>>
>>>>
>>>> One thing, though (just occurred to me while preparing this email): 
>>>> I did use
>>>>
>>>> List<FileItem> items = upload.parseRequest(request);
>>>>
>>>> which possibly should be
>>>>
>>>> List items = upload.parseRequest(request);
>>>>
>>>> (so no generics). The version of fileupload I use is 1.2.1 (if I 
>>>> correctly remember), but I will look into this this evening.
>>>
>>> Generics cannot have an effect on this.
>>> At worst you would receive a ClassCastException at runtime, but it 
>>> cannot alter the result in any way.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Andre
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>


-- 
Andre H. Juffer              | Phone: +358-8-553 1161
Biocenter Oulu and           | Fax: +358-8-553-1141
Department of Biochemistry   | Email: andre.juffer@oulu.fi
University of Oulu, Finland  | WWW: www.biochem.oulu.fi/Biocomputing/
StrucBioCat                  | WWW: www.strucbiocat.oulu.fi
Triacle Biocomputing         | WWW: www.triacle-bc.com


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message