Yes, that works! Is there a place in the documentation where that kind of information is discussed? I'd love to know more about what's going on.
Thanks so much, Sergey. You've been a great help to me. -Chris On Thu, May 15, 2008 at 8:57 AM, Sergey Beryozkin <[EMAIL PROTECTED]> wrote: > Hi Chris > > in your signature you have a byte[] parameter and this is causing an input > stream be processed by a BinaryReader... > So if you prefer to rely on a servlet request object then you to have a > function accepting void. > Another alternative is to have in InputStream in your signature, it would be > the same stream you will get from a servlet request object... > > Cheers, Sergey > > ----- Original Message ----- From: "Chris Norris" > <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Thursday, May 15, 2008 2:51 PM > Subject: Re: JAX-RS and application/octet POST requests > > >> 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 >>> > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland >
