Okay, so now I have access to the HttpServletRequest, which is great. But it seems to have been modified somewhat by the time I get it. I'm using the Apache Commons FileUpload to try and extract the file from the POST request.
If I write a simple HttpServlet that processes a POST request from a form with a file, FileUpload can extract the file from the HttpServletRequest. When I use CXF, the request seems like it has already been parsed and FileUpload can't get to the file. I've been running through the CXF code to see if I can figure out what's happened to the request by the time it's injected into my service, but I can't figure it out. -Chris On Wed, May 14, 2008 at 11:05 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi Chris > > I've got confused a bit, sorry :-) > > JAX-RS spec says about @Context when referring to servlet containers, but it > also refers to @Resource in another section (though without explicitly > suggessting what types can be injected). So we'll need to support @Context > for these types too, but in meantime please rely on @Resource, as we already > support it... > > I'll update the documentation > > Thanks a lot, Sergey > >> Alright, I think I have this figured out. Sergey and the >> documentation have said to use the @Context annotation, but looking at >> the JAXRSUtils class, it seems that the @Resource annotation should be >> used. >> >> The JAXRSUtils class has two methods, createHttpContextValue and >> createServletResourceValue, that inject the values for the Context and >> Resource annotations, respectively. You can see from there what kinds >> of values you can inject: >> @Context: UriInfo, HttpHeaders, Request, SecurityContext >> @Resource: HttpServletRequest, HttpServletResponse, ServletContext >> >> If I'm correct on this, then the documentation here should be updated: >> http://cwiki.apache.org/CXF20DOC/jax-rs-jsr-311.html >> >> Sergey, does this seem correct to you? >> >> -Chris >> >> On Wed, May 14, 2008 at 8:52 AM, Chris Norris >> <[EMAIL PROTECTED]> wrote: >>> >>> 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 >>> > >>> > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
