Re: JAX-RS and application/octet POST requests

Sergey Beryozkin Thu, 15 May 2008 08:00:10 -0700

I thought I was keeping confusing you until you finally figured it all out 
yourself about those @Resource annotations :-)

I tried to improve the documentation but still more work needs to be done. The latest JAX-RS specification available at a JSRs sitewould be a good read, even though it's a bit formal....


Cheers, Sergey

----- Original Message -----From: "Chris Norris" <[EMAIL PROTECTED]>

To: <[email protected]>
Sent: Thursday, May 15, 2008 3:46 PM
Subject: Re: JAX-RS and application/octet POST requests

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


----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Re: JAX-RS and application/octet POST requests

Reply via email to