Hi,
At the moment you can only inject HTTP servlet objects into fields :
@Context HttpServletRequest r;
It would be very easy to update the runtime to have them also injected as
parameters too...
Cheers, Sergey
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
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
