You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Chris Norris <th...@gmail.com> on 2008/05/07 20:00:06 UTC
JAX-RS and application/octet POST requests
I'm trying to enable my service to accept a file. I control the
client making the request, so I can set the content-type to be
anything I want it to be. I'm new to CXF and have a service running
so far that can accept GET requests just fine and send back some XML.
I'm not really sure where to start with this, though. So far I have a
cxf.xml that looks like this:
<jaxrs:server id="backdropService" address="/backdrop/">
<jaxrs:serviceBeans>
<bean class="collective.services.backdrop.BackdropService" />
</jaxrs:serviceBeans>
</jaxrs:server>
My service class looks like this:
@ProduceMime(value="text/xml")
@Path("/backdropservice/")
public class BackdropService
{
public BackdropService(){}
@GET
@Path("/profiles/")
public WSUploadProfileCollection getProfiles()
{
return new WSUploadProfileCollection(UploadProfileAccessor.getInstance().getPhotoProfiles());
}
@GET
@Path("/something/{message}/")
public Something getSomething(@PathParam("message") String txt)
{
return new Something(txt);
}
@POST
@Path("/upload/")
public WSUploadResponse postUpload(Object photo)
{
return new WSUploadResponse();
}
}
The last method is the one I'm working on, but I don't know what sort
of Object to use or where to start looking in the documentation.
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
I've tried doing the following:
@POST
@Path("/upload/")
public WSUploadResponse postUpload(@Context HttpServletRequest request)
The request is always null.
-chris
On Tue, May 13, 2008 at 10:57 AM, Chris Norris
<th...@gmail.com> wrote:
> 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
>
>
> <se...@iona.com> 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
> > > <se...@iona.com> 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
> >
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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 site
would be a good read, even though it's a bit formal....
Cheers, Sergey
----- Original Message -----
From: "Chris Norris" <th...@gmail.com>
To: <us...@cxf.apache.org>
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
> <se...@iona.com> 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"
>> <th...@gmail.com>
>> To: <us...@cxf.apache.org>
>> 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
>>> <se...@iona.com> 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
>>>>> <th...@gmail.com> 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
>>>>>>
>>>>>>
>>>>>> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>>>> >
>>>>>> > Sent: 13 May 2008 21:48
>>>>>> > To: users@cxf.apache.org
>>>>>> > 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
>>>>>> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>>>> > > Sent: 13 May 2008 21:18
>>>>>> > > To: users@cxf.apache.org
>>>>>> > > 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
>>>>>> > > <th...@gmail.com> 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
>>>>>> > > >
>>>>>> > > >
>>>>>> > > > <se...@iona.com> 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
>>>>>> > > > > > <se...@iona.com> 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
>>>>>> > > > > > > > <se...@iona.com> 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
Posted by Chris Norris <th...@gmail.com>.
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
<se...@iona.com> 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"
> <th...@gmail.com>
> To: <us...@cxf.apache.org>
> 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
>> <se...@iona.com> 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
>>>> <th...@gmail.com> 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
>>>>>
>>>>>
>>>>> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>>> >
>>>>> > Sent: 13 May 2008 21:48
>>>>> > To: users@cxf.apache.org
>>>>> > 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
>>>>> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>>> > > Sent: 13 May 2008 21:18
>>>>> > > To: users@cxf.apache.org
>>>>> > > 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
>>>>> > > <th...@gmail.com> 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
>>>>> > > >
>>>>> > > >
>>>>> > > > <se...@iona.com> 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
>>>>> > > > > > <se...@iona.com> 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
>>>>> > > > > > > > <se...@iona.com> 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
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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" <th...@gmail.com>
To: <us...@cxf.apache.org>
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
> <se...@iona.com> 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
>>> <th...@gmail.com> 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
>>>>
>>>>
>>>> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>> >
>>>> > Sent: 13 May 2008 21:48
>>>> > To: users@cxf.apache.org
>>>> > 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
>>>> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>>> > > Sent: 13 May 2008 21:18
>>>> > > To: users@cxf.apache.org
>>>> > > 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
>>>> > > <th...@gmail.com> 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
>>>> > > >
>>>> > > >
>>>> > > > <se...@iona.com> 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
>>>> > > > > > <se...@iona.com> 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
>>>> > > > > > > > <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<se...@iona.com> 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
>> <th...@gmail.com> 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
>>>
>>>
>>> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>> >
>>> > Sent: 13 May 2008 21:48
>>> > To: users@cxf.apache.org
>>> > 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
>>> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>>> > > Sent: 13 May 2008 21:18
>>> > > To: users@cxf.apache.org
>>> > > 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
>>> > > <th...@gmail.com> 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
>>> > > >
>>> > > >
>>> > > > <se...@iona.com> 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
>>> > > > > > <se...@iona.com> 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
>>> > > > > > > > <se...@iona.com> 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
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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
> <th...@gmail.com> 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
>>
>>
>> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>> >
>> > Sent: 13 May 2008 21:48
>> > To: users@cxf.apache.org
>> > 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
>> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>> > > Sent: 13 May 2008 21:18
>> > > To: users@cxf.apache.org
>> > > 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
>> > > <th...@gmail.com> 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
>> > > >
>> > > >
>> > > > <se...@iona.com> 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
>> > > > > > <se...@iona.com> 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
>> > > > > > > > <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<th...@gmail.com> 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
>
>
> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
> >
> > Sent: 13 May 2008 21:48
> > To: users@cxf.apache.org
> > 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
> > <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
> > > Sent: 13 May 2008 21:18
> > > To: users@cxf.apache.org
> > > 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
> > > <th...@gmail.com> 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
> > > >
> > > >
> > > > <se...@iona.com> 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
> > > > > > <se...@iona.com> 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
> > > > > > > > <se...@iona.com> 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
> >
>
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<Se...@iona.com> 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:thechrisproject.lists@gmail.com]
>
> Sent: 13 May 2008 21:48
> To: users@cxf.apache.org
> 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
> <Se...@iona.com> 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:thechrisproject.lists@gmail.com]
> > Sent: 13 May 2008 21:18
> > To: users@cxf.apache.org
> > 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
> > <th...@gmail.com> 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
> > >
> > >
> > > <se...@iona.com> 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
> > > > > <se...@iona.com> 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
> > > > > > > <se...@iona.com> 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
>
RE: JAX-RS and application/octet POST requests
Posted by "Beryozkin, Sergey" <Se...@iona.com>.
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:thechrisproject.lists@gmail.com]
Sent: 13 May 2008 21:48
To: users@cxf.apache.org
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
<Se...@iona.com> 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:thechrisproject.lists@gmail.com]
> Sent: 13 May 2008 21:18
> To: users@cxf.apache.org
> 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
> <th...@gmail.com> 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
> >
> >
> > <se...@iona.com> 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
> > > > <se...@iona.com> 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
> > > > > > <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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().getPhotoProfiles());
}
@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
<Se...@iona.com> 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:thechrisproject.lists@gmail.com]
> Sent: 13 May 2008 21:18
> To: users@cxf.apache.org
> 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
> <th...@gmail.com> 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
> >
> >
> > <se...@iona.com> 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
> > > > <se...@iona.com> 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
> > > > > > <se...@iona.com> 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
>
RE: JAX-RS and application/octet POST requests
Posted by "Beryozkin, Sergey" <Se...@iona.com>.
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:thechrisproject.lists@gmail.com]
Sent: 13 May 2008 21:18
To: users@cxf.apache.org
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
<th...@gmail.com> 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
>
>
> <se...@iona.com> 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
> > > <se...@iona.com> 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
> > > > > <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<th...@gmail.com> 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
>
>
> <se...@iona.com> 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
> > > <se...@iona.com> 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
> > > > > <se...@iona.com> 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
> >
>
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<se...@iona.com> 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
> > <se...@iona.com> 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
> > > > <se...@iona.com> 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
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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
> <se...@iona.com> 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
>> > <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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
<se...@iona.com> 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
> > <se...@iona.com> 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
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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
> <se...@iona.com> 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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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? 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
<se...@iona.com> 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
>
Re: JAX-RS and application/octet POST requests
Posted by Sergey Beryozkin <se...@iona.com>.
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
Re: JAX-RS and application/octet POST requests
Posted by Chris Norris <th...@gmail.com>.
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. 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
On Thu, May 8, 2008 at 4:48 AM, Sergey Beryozkin
<se...@iona.com> wrote:
> Hi Chris
>
>
>
> > Changing the parameters of the post method to be a byte array seemed
> > to make things work much better, but the byte array contains more than
> > just the file I'm sending. Can I set up more parameters to separate
> > things out?
>
> What is the Content-Type of the request ? If it's multipart/* of some sort then you'd likely see more than just
> a byte array being uploaded. If not then what kind of extra bytes you're seeing ?
>
> Cheers, Sergey
>
>
>
>
> >
> > On Wed, May 7, 2008 at 1:00 PM, Chris Norris
> > <th...@gmail.com> wrote:
> >> I'm trying to enable my service to accept a file. I control the
> >> client making the request, so I can set the content-type to be
> >> anything I want it to be. I'm new to CXF and have a service running
> >> so far that can accept GET requests just fine and send back some XML.
> >> I'm not really sure where to start with this, though. So far I have a
> >> cxf.xml that looks like this:
> >>
> >> <jaxrs:server id="backdropService" address="/backdrop/">
> >> <jaxrs:serviceBeans>
> >> <bean class="collective.services.backdrop.BackdropService" />
> >> </jaxrs:serviceBeans>
> >> </jaxrs:server>
> >>
> >> My service class looks like this:
> >>
> >> @ProduceMime(value="text/xml")
> >> @Path("/backdropservice/")
> >> public class BackdropService
> >> {
> >> public BackdropService(){}
> >>
> >> @GET
> >> @Path("/profiles/")
> >> public WSUploadProfileCollection getProfiles()
> >> {
> >> return new WSUploadProfileCollection(UploadProfileAccessor.getInstance().getPhotoProfiles());
> >> }
> >>
> >> @GET
> >> @Path("/something/{message}/")
> >> public Something getSomething(@PathParam("message") String txt)
> >> {
> >> return new Something(txt);
> >> }
> >>
> >> @POST
> >> @Path("/upload/")
> >> public WSUploadResponse postUpload(Object photo)
> >> {
> >> return new WSUploadResponse();
> >> }
> >>
> >> }
> >>
> >>
> >> The last method is the one I'm working on, but I don't know what sort
> >> of Object to use or where to start looking in the documentation.
> >>
>
> ----------------------------
> 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
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Chris
> Changing the parameters of the post method to be a byte array seemed
> to make things work much better, but the byte array contains more than
> just the file I'm sending. Can I set up more parameters to separate
> things out?
What is the Content-Type of the request ? If it's multipart/* of some sort then you'd likely see more than just
a byte array being uploaded. If not then what kind of extra bytes you're seeing ?
Cheers, Sergey
>
> On Wed, May 7, 2008 at 1:00 PM, Chris Norris
> <th...@gmail.com> wrote:
>> I'm trying to enable my service to accept a file. I control the
>> client making the request, so I can set the content-type to be
>> anything I want it to be. I'm new to CXF and have a service running
>> so far that can accept GET requests just fine and send back some XML.
>> I'm not really sure where to start with this, though. So far I have a
>> cxf.xml that looks like this:
>>
>> <jaxrs:server id="backdropService" address="/backdrop/">
>> <jaxrs:serviceBeans>
>> <bean class="collective.services.backdrop.BackdropService" />
>> </jaxrs:serviceBeans>
>> </jaxrs:server>
>>
>> My service class looks like this:
>>
>> @ProduceMime(value="text/xml")
>> @Path("/backdropservice/")
>> public class BackdropService
>> {
>> public BackdropService(){}
>>
>> @GET
>> @Path("/profiles/")
>> public WSUploadProfileCollection getProfiles()
>> {
>> return new WSUploadProfileCollection(UploadProfileAccessor.getInstance().getPhotoProfiles());
>> }
>>
>> @GET
>> @Path("/something/{message}/")
>> public Something getSomething(@PathParam("message") String txt)
>> {
>> return new Something(txt);
>> }
>>
>> @POST
>> @Path("/upload/")
>> public WSUploadResponse postUpload(Object photo)
>> {
>> return new WSUploadResponse();
>> }
>>
>> }
>>
>>
>> The last method is the one I'm working on, but I don't know what sort
>> of Object to use or where to start looking in the documentation.
>>
----------------------------
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
Posted by Chris Norris <th...@gmail.com>.
Changing the parameters of the post method to be a byte array seemed
to make things work much better, but the byte array contains more than
just the file I'm sending. Can I set up more parameters to separate
things out?
On Wed, May 7, 2008 at 1:00 PM, Chris Norris
<th...@gmail.com> wrote:
> I'm trying to enable my service to accept a file. I control the
> client making the request, so I can set the content-type to be
> anything I want it to be. I'm new to CXF and have a service running
> so far that can accept GET requests just fine and send back some XML.
> I'm not really sure where to start with this, though. So far I have a
> cxf.xml that looks like this:
>
> <jaxrs:server id="backdropService" address="/backdrop/">
> <jaxrs:serviceBeans>
> <bean class="collective.services.backdrop.BackdropService" />
> </jaxrs:serviceBeans>
> </jaxrs:server>
>
> My service class looks like this:
>
> @ProduceMime(value="text/xml")
> @Path("/backdropservice/")
> public class BackdropService
> {
> public BackdropService(){}
>
> @GET
> @Path("/profiles/")
> public WSUploadProfileCollection getProfiles()
> {
> return new WSUploadProfileCollection(UploadProfileAccessor.getInstance().getPhotoProfiles());
> }
>
> @GET
> @Path("/something/{message}/")
> public Something getSomething(@PathParam("message") String txt)
> {
> return new Something(txt);
> }
>
> @POST
> @Path("/upload/")
> public WSUploadResponse postUpload(Object photo)
> {
> return new WSUploadResponse();
> }
>
> }
>
>
> The last method is the one I'm working on, but I don't know what sort
> of Object to use or where to start looking in the documentation.
>