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
>>>
>>
>