It doesn't... it's always null. I must be missing something obvious.
Here's my entire service class:
package collective.services.backdrop;
import javax.servlet.http.HttpServletRequest;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.ProduceMime;
import javax.ws.rs.core.Context;
import collective.dataaccess.assetupload.UploadProfileAccessor;
import com.widen.common.logging.LogFacade;
@ProduceMime(value="text/xml")
@Path("/backdropservice/")
public class BackdropService
{
@Context
private HttpServletRequest request;
public BackdropService(){}
@GET
@Path("/profiles/")
public WSUploadProfileCollection getProfiles()
{
return new
WSUploadProfileCollection(UploadProfileAccessor.getInstance().getPhotoProfiles());
}
@GET
@Path("/something/{message}/")
public Something getSomething(@PathParam("message") String txt)
{
return new Something(txt);
}
@POST
@Path("/upload/")
public WSUploadResponse postUpload(byte[] bytes)
{
LogFacade.log.info("post upload request: " + request);
return new WSUploadResponse();
}
}
On Tue, May 13, 2008 at 3:35 PM, Beryozkin, Sergey
<[EMAIL PROTECTED]> wrote:
> It's injected in the context of the current invocation.
> So if you should have have something like this :
>
> @Path("/bar")
> class BackdropService {
>
> private @Context HttpServletRequest requestObject;
>
> @POST
> Response upload(byte[] bytes) {
> // requestObject represents the current request object
> }
> }
>
> This should work...
>
> Cheers, Sergey
>
>
>
> -----Original Message-----
> From: Chris Norris [mailto:[EMAIL PROTECTED]
> Sent: 13 May 2008 21:18
> To: [email protected]
> Subject: Re: JAX-RS and application/octet POST requests
>
> Do I need to set up my config differently?
>
> <jaxrs:server id="backdropService" address="/backdrop/">
> <jaxrs:serviceBeans>
> <bean class="collective.services.backdrop.BackdropService" />
> </jaxrs:serviceBeans>
> </jaxrs:server>
>
>
> On Tue, May 13, 2008 at 12:56 PM, Chris Norris
> <[EMAIL PROTECTED]> wrote:
> > That still seems to be null in my POST method. When/how should it get
> > populated?
> >
> > On Tue, May 13, 2008 at 11:31 AM, Sergey Beryozkin
> >
> >
> > <[EMAIL PROTECTED]> wrote:
> > > 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
> > >
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
