Sorry for the ambiguity, I was referring to the HttpServletRequest. I saw that info earlier but didn't know what kind of parameters you could inject using the @Context parameter. I'll give that a shot. Thanks for all your help.
On Tue, May 13, 2008 at 10:43 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi, > > Have a look please here : > > http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html > > I've added some info on how to create and register a custom reader. The > samples there actually use 0.7 version of api as it is what CXF will support > next, but there's also a link to the 0.6 api there. Ypu may also want to > browse the source and see how various readers are implemented, hopefully you > should be to easily create a custom reader. > > > > > Sergey, > > I'm fairly certain they are in the actual payload. Is there any way > > to get the actual request object and deal with that? > > > > Are you referring to a request input stream or to something like > HttpServletRequest ? If it's the former then you have an option of either > creating a custom reader which will read from that stream and deserialize it > into whatever type is expected in the signature or add InputStream directly > to the signature. If it's latter then you have an option of injecting it > into your application class by annotating a related field with @Context.... > > Hope it helps, Sergey > > > > > > > I know there are > > already libraries that can take a request and split it up. Or perhaps > > is there anything out there now that can split up a byte array or > > input stream into its constituent parts? > > > > I'm also having trouble finding documentation on the MessageReader and > > MessageBodyReader. > > > > -Chris > > > > > > On Thu, May 8, 2008 at 10:09 AM, Sergey Beryozkin > > <[EMAIL PROTECTED]> wrote: > > > > > Hi > > > > > > > > > > > > > > > > Hi Sergey, > > > > Like I mentioned before, I control the client making the request and > > > > can set the content-type of the request to whatever I want. I started > > > > with it as application/octet-stream. Right now I just have an > > > > arbitrary value in there as a test, but I'm going to change it back, > > > > because I think application/octet-stream is correct. > > > > > > > > The extra bytes I'm seeing contain the other parts of the request, > > > > including the content disposition, the content-type, the name, and the > > > > filename. > > > > > > > > > > Are these values contained in the actual payload or are they > represented by > > > HTTP headers ? If it's the latter then I'd surprised if > > > they were passed to the byte[] array, if it's the former then I believe > the > > > only way to strip them off at the moment is to provide a > > > custom MessageBodyReader for a byte[] type which would remove them from > the > > > input stream and then pass to the application. > > > InputStream can be more efficient as an input parameter in this case as > you > > > might be able to filter out (in you custom MessageReader > > > for InputStream) the extra data you don't need. > > > > > > Does it help ? > > > > > > Cheers, Sergey > > > > > > > > > > > > > > > > The thing that makes this request is in Lua, a language I'm > > > > not yet proficient at, so pardon me if I bumble a little. I'm writing > > > > a plugin for Adobe Photoshop Lightroom that will submit photos to my > > > > application. > > > > > > > > -Chris > > > > > > > > > > > > > > > > > ---------------------------- > > > IONA Technologies PLC (registered in Ireland) > > > Registered Number: 171387 > > > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, > Ireland > > > > > > > > > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
