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
