On Jun 11, 2010, at 11:48 PM, Muhra Daniel wrote:
> Hi,
>
> The tip with jersey-multipart did the trick. Now it works as
> expected. Thanks a lot!
>
Great. I wish i knew what was wrong :-)
Paul.
> Cheers,
> Daniel
>
> Am 11.06.2010 um 17:25 schrieb Paul Sandoz:
>
>> Hi,
>>
>> That is odd because if you enable tracing and logging the trace
>> headers should be output in the logged response.
>>
>> I do notice you are using @FormParam with "multipart/form-data"
>> this functionality has been deprecated and removed in 1.3-SNAPSHOT
>> (you will get something in the log saying it has been disabled).
>> The reason for this is that overloading parameters for "application/
>> x-www-form-urlencoded" and "multipart/form-data" causes issues.
>>
>> You need to include a dependency on the jersey-multipart module [1]
>> and use @FormDataParam:
>>
>> https://jersey.dev.java.net/nonav/apidocs/latest/contribs/jersey-multipart/com/sun/jersey/multipart/FormDataParam.html
>>
>> public String updateWeWall( /*byte[] in, File imageFile,*/
>> @HeaderParam("login") String login, @HeaderParam("password") String
>> password, @FormDataParam("image") File image ) {
>>
>> Paul.
>>
>> [1] https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html
>> #d4e1618
>>
>> On Jun 11, 2010, at 11:34 AM, Muhra Daniel wrote:
>>
>>> Hi,
>>>
>>> So, one after another. First my server code:
>>>
>>> @POST
>>> @Consumes( MediaType.MULTIPART_FORM_DATA )
>>> @Produces(MediaType.TEXT_PLAIN)
>>> public String updateWeWall( /*byte[] in, File imageFile,*/
>>> @HeaderParam("login") String login, @HeaderParam("password")
>>> String password, @FormParam("image") File image ) {
>>>
>>> Account a = Account.accountList.get(login);
>>>
>>> if( a != null && a.validatePassword(password) ){
>>> a.getWewall().image = image;
>>> return "WeWall successfully updated";
>>> }
>>> else
>>> return "WeWall update failed: Connection to Account refused";
>>> }
>>>
>>> Nothing fancy, just receiving and storing the image file.
>>> Btw. I do the logging by adding the following lines to the
>>> constructor of the Ressource:
>>>
>>> try {
>>> handler = new FileHandler("/Users/daniel/test.log");
>>>
>>> Logger
>>> .getLogger
>>> ("com
>>> .sun
>>> .jersey.api.container.filter.LoggingFilter").addHandler(handler);
>>> } catch (SecurityException e) {
>>>
>>> <test.log>
>>> // TODO Auto-generated catch block
>>> e.printStackTrace();
>>>
>>> (Somehow copy and post from Eclipse gives some weird results...)
>>> Is this correct, or would you propose another way to do the logging?
>>>
>>> I'm also using Version 1.2 of Jersey, and added the trace stuff to
>>> the web.xml
>>> This time I was able to copy it the messages from the console, but
>>> there doesn't seem to be anything new. (The output to the file
>>> seems still the same).
>>> So attached is the copied output from the console. Hope, this
>>> helps a bit.
>>>
>>> Daniel
>>>
>>>
>>> Am 11.06.2010 um 09:52 schrieb Paul Sandoz:
>>>
>>>>
>>>> On Jun 11, 2010, at 7:41 AM, Paul Sandoz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> What version of Jersey are you using?
>>>>>
>>>>> On Jun 10, 2010, at 11:54 PM, Muhra Daniel wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> So I finally managed to do some logging. Strange enough, the
>>>>>> logger seems to put it into the file only after doing the
>>>>>> upload request twice.
>>>>>> Anyhow, I attached the file.
>>>>>
>>>>> I think the log output may be merging with some other output,
>>>>> printing out an XML document.
>>>>>
>>>>
>>>> Doh, i see now you are using the XML logging output with the
>>>> messages embedded as XML content.
>>>>
>>>> Also can you share you server-side code, specifically the method
>>>> signature of the resource method that consumes the message?
>>>>
>>>> Paul.
>>>>
>>>>> In the log i see a 400 response for a first request.
>>>>>
>>>>> Then i see a second POST request.
>>>>>
>>>>> 2 > POST http://localhost:8080/de.wewall.first/rest/wewall
>>>>> 2 > host: localhost:8080
>>>>> 2 > password: toor
>>>>> 2 > login: root
>>>>> 2 > user-agent: RESTApplication 1.0 rv:1 (Macintosh; Mac OS X
>>>>> 10.6.3; de_DE)
>>>>> 2 > accept-encoding: gzip
>>>>> 2 > content-type: multipart/form-data; charset=utf-8;
>>>>> boundary=0xKhTmLbOuNdArY
>>>>> 2 > content-length: 742865
>>>>> 2 > connection: keep-alive
>>>>> 2 >
>>>>> --0xKhTmLbOuNdArY^M
>>>>> Content-Disposition: form-data; name="image"; filename="file"^M
>>>>> Content-Type: application/octet-stream^M
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> --0xKhTmLbOuNdArY--^M
>>>>>
>>>>> and a response of:
>>>>>
>>>>> 2 < 400
>>>>> 2 <
>>>>>
>>>>> To the naked eye the client data looks correct.
>>>>>
>>>>>
>>>>>> Btw, I mentioned smaller pictures are being accepted, but the
>>>>>> file was corrupted. Well, it seems like Jersey puts not only
>>>>>> the payload into the file, but also the desciptive part of the
>>>>>> form-data. In this case I would have:
>>>>>>
>>>>>> Content-Disposition: form-data; name="image"; filename="file"
>>>>>> Content-Type: application/octet-stream
>>>>>>
>>>>>> Why is that the case?
>>>>>
>>>>> Jersey is not doing that, the client is. Those are the headers
>>>>> related to MIME body parts of a the multipart/form-data message.
>>>>>
>>>>>
>>>>>> And why do some images fail to upload (at least if I don't
>>>>>> parse them manually)?
>>>>>
>>>>> I really do not know.
>>>>>
>>>>> Some sort of parsing exception may be occurring.
>>>>>
>>>>> I am not sure what version of Jersey you are using. If you are
>>>>> using Jersey 1.2 you can enable tracing and Jersey should log
>>>>> exceptions it is mapping to responses. Add the following init-
>>>>> param:
>>>>>
>>>>> <init-param>
>>>>> <param-name>com.sun.jersey.config.feature.Trace"</param-
>>>>> name>
>>>>> <param-value>true</param-value>
>>>>> </init-param>
>>>>>
>>>>> If not using Jersey 1.2 then you will need to register an
>>>>> ExceptionMapper<WebApplicationException> to log the exception.
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>>> And thanks for all the effort. I really appreciate your help.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>> <test.log>
>>>>>> Am 09.06.2010 um 06:34 schrieb Paul Sandoz:
>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> JDK logging is utilized. The logger name is the same name as
>>>>>>> the class:
>>>>>>>
>>>>>>> com.sun.jersey.api.container.filter.LoggingFilter
>>>>>>>
>>>>>>> so you could configure JDK logging to redirect that output to
>>>>>>> a file. JDK logging is a bit of a pain to configure though.
>>>>>>>
>>>>>>> What web/app server are you using? usually they log output to
>>>>>>> a file.
>>>>>>>
>>>>>>>
>>>>>>> Another approach is to declare a ResourceConfig for the
>>>>>>> application and explicitly register an of LoggingFilter by
>>>>>>> adding it to the following:
>>>>>>>
>>>>>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ResourceConfig.html
>>>>>>> #getContainerRequestFilters%28%29
>>>>>>>
>>>>>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/core/ResourceConfig.html
>>>>>>> #getContainerResponseFilters%28%29
>>>>>>>
>>>>>>> that instance can be created with it's own logging filter that
>>>>>>> redirects to a file.
>>>>>>>
>>>>>>> Paul.
>>>>>>>
>>>>>>> On Jun 9, 2010, at 1:15 AM, Muhra Daniel wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sorry for the late reply, but currently I'm very busy.
>>>>>>>> I tried to invoke the logger, but I haven'T found out, how to
>>>>>>>> redirect the output to a file. For the console, the output is
>>>>>>>> currently too much.
>>>>>>>>
>>>>>>>> I also noticed that smaller images (4Kb gif converted to TIF)
>>>>>>>> seem to be acceptable for the server. But still the File
>>>>>>>> representation seems to be invalid.
>>>>>>>> Bigger files trigger an error on the server side, saying the
>>>>>>>> request is syntactically incorrect.
>>>>>>>>
>>>>>>>> But for now, can someone tell me how to redirect the logger
>>>>>>>> output to a file. I invoked it by:
>>>>>>>>
>>>>>>>> <init-param>
>>>>>>>> <param-
>>>>>>>> name>com.sun.jersey.spi.container.ContainerRequestFilters</
>>>>>>>> param-name>
>>>>>>>> <param-
>>>>>>>> value>com.sun.jersey.api.container.filter.LoggingFilter</
>>>>>>>> param-value>
>>>>>>>> </init-param>
>>>>>>>> <init-param>
>>>>>>>> <param-
>>>>>>>> name>com.sun.jersey.spi.container.ContainerResponseFilters</
>>>>>>>> param-name>
>>>>>>>> <param-
>>>>>>>> value>com.sun.jersey.api.container.filter.LoggingFilter</
>>>>>>>> param-value>
>>>>>>>> </init-param>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>> Am 07.06.2010 um 13:32 schrieb Paul Sandoz:
>>>>>>>>
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> Can you enable server-side logging:
>>>>>>>>>
>>>>>>>>> https://jersey.dev.java.net/nonav/apidocs/latest/jersey/com/sun/jersey/api/container/filter/LoggingFilter.html
>>>>>>>>>
>>>>>>>>> I would like to see the all of the client request, including
>>>>>>>>> the headers.
>>>>>>>>>
>>>>>>>>> What version of Jersey are you using?
>>>>>>>>>
>>>>>>>>> What is the log output from the server side?
>>>>>>>>>
>>>>>>>>> Paul.
>>>>>>>>>
>>>>>>>>> On Jun 7, 2010, at 1:16 AM, Muhra Daniel wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Currently I'm trying to upload an image to my server.
>>>>>>>>>> Unfortunately the server denies to accept the request,
>>>>>>>>>> claiming it's syntactically incorrect.
>>>>>>>>>> A usual request would look like this:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --0xKhTmLbOuNdArY
>>>>>>>>>> Content-Disposition: form-data; name="login"
>>>>>>>>>>
>>>>>>>>>> peer
>>>>>>>>>> --0xKhTmLbOuNdArY
>>>>>>>>>> Content-Disposition: form-data; name="password"
>>>>>>>>>>
>>>>>>>>>> reep
>>>>>>>>>> --0xKhTmLbOuNdArY
>>>>>>>>>> Content-Disposition: form-data; name="image"; filename="file"
>>>>>>>>>> Content-Type: application/octet-stream
>>>>>>>>>>
>>>>>>>>>> MM
>>>>>>>>>> $ннн
>>>>>>>>>> ...
>>>>>>>>>> н
>>>>>>>>>>
>>>>>>>>>> --0xKhTmLbOuNdArY--
>>>>>>>>>>
>>>>>>>>>> The service which is invoked is defined as follows:
>>>>>>>>>>
>>>>>>>>>> @POST
>>>>>>>>>> @Consumes( MediaType.MULTIPART_FORM_DATA )
>>>>>>>>>> @Produces(MediaType.TEXT_PLAIN)
>>>>>>>>>> public String uploadImage(@FormParam("login") String login,
>>>>>>>>>> @FormParam("password") String password, @FormParam("image")
>>>>>>>>>> File image) {
>>>>>>>>>> ... process file...
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The question now is, where the error lies. Is my service
>>>>>>>>>> wrong (most likely), or is the POST request somehow
>>>>>>>>>> incorrect. The request is made using a framework called
>>>>>>>>>> ASIHTTPRequest. I also tried to use byte[] instead of file,
>>>>>>>>>> but that doesn't work either.
>>>>>>>>>> Every help is appreciated.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>>>> For additional commands, e-mail: users-
>>>>>>>>> help_at_jersey.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>