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.
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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
