It could be that the injection fails. I'm not running this in tomcat,
it's running in jetty and shouldn't have any security manager
installed. I tried making the field public and that didn't make it
work. I will try tracing through the JAXRSUtils and JAXRSInvoker
classes to see if I can figure out what's going on there.
Thanks,
Chris
On Tue, May 13, 2008 at 4:07 PM, Beryozkin, Sergey
<[EMAIL PROTECTED]> wrote:
> This looks just fine. I may need to write a system test at some point of
> time. But I can definitely see the code which does the injection (it was
> a contribution) and it seems correct.
>
> Can it be that the injection fails ? Is some SecurityManager installed
> in Tomcat ? Can you try, just for a test, to make that field be public
> and see what happens ?
>
> JAXRSUtils.injectServletResourceValues is where it's all happening and
> it's invoked form JAXRSInvoker just before the actual method invocation.
>
> I'm sorry I can't be of much help at this point of time.
>
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Chris Norris [mailto:[EMAIL PROTECTED]
>
> Sent: 13 May 2008 21:48
> To: [email protected]
> Subject: Re: JAX-RS and application/octet POST requests
>
>
>
> 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().getPhotoPr
> ofiles());
> }
>
> @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
> >
>
> ----------------------------
> IONA Technologies PLC (registered in Ireland)
> Registered Number: 171387
> Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
>
