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 >
