Hi Gabo
Hi Sergey,
Sorry for the troubles. It's a red herring, something to do with the securities set by our Sys Admin. I see the the transactions
recorded as:
222.127.215.98 - - [25/Jan/2010:04:40:53 +0000] "POST /MyService/?comment=test
HTTP/1.1" 401 0
222.127.215.98 - - [25/Jan/2010:04:40:53 +0000] "POST /MyService/?comment=test
HTTP/1.1" 400 116
But the transaction still goes into my app. It is just odd that even if the interceptor retrieves the HttpMethod as POST, the
method selection somehow gets a GET:
So do you still get a @GET annotated method invoked even when HttpMethod=POST ?
Does not look like a red herring to me :-).
2010-01-25 04:40:53,397 [INFO ][ee-2][ RestInHandler] - exchange at end:
{password=89f2b9fbd6c6b2c0e5ab90ce18adc0e9, org.apache.cxf.binding.binding=org.apache.cxf.binding.xml.xmlbind...@192322e,
HttpMethod=POST, transactiosnType=ReST, org.apache.cxf.bus=org.apache.cxf.bus.cxfbusi...@11ca33b, ...
Again, my apologies for this.
No problems :-), I'm still confused a bit. Is the resource class code you posted in the first message of this thread close enough to
the actual code that you use ? I'd like to do a test and see what is being invoked...
thanks, Sergey
Gabo
Sergey Beryozkin wrote:
Hi
Hi All,
Found the cause for most. Still an odd error though. So here is the cause:
The service explicitely says @Consumes("text/xml") , while my client specified:
RequestEntity re = new FileRequestEntity(
new File("somefile.txt"),
"application/xml; charset=ISO-8859-1");
After changing this to text/xml. POST and DELETE succeeded.
OK...
Remaining issue:
1. Why was no exception thrown?
2. Why did it revert to GET?
I'll need some help here. Can you verify it is GET ? Any chance you can attach
a simple test case to a JIRA ?
I honestly do not see POST being mapped to GET happening....Does request get
modified somehow by some interceptor ?
cheers, Sergey
3. PUT still requires that basic authentication, although I would be checking with our SysAdmin. I think this would be server
specific.
Gabo
