On Nov 7, 2008, at 7:44 PM, Julio Faerman wrote:
> I did most of it, time to get my hands dirty :)
>
> To implement the form bean population, i would require a
> "intercepting" component that could actualy do the trick. What
> component is that that i am looking for?
An implementation of MessageBodyWriter:
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/ext/MessageBodyWriter.html
> Is there a similar thing
> implemented?
>
See the following sample:
http://download.java.net/maven/2/com/sun/jersey/samples/entity-provider/1.0/entity-provider-1.0-project.zip
Paul.
> On Fri, Nov 7, 2008 at 4:41 PM, Craig McClanahan
> <Craig.McClanahan_at_sun.com> wrote:
>> Julio Faerman wrote:
>>
>> Yes, i would like to contribute.
>> But i am currently a jersey user, have never touched the code, so it
>> would take me some delay to get started. If you (or other) could
>> suggest some starting pointers, it would help a lot.
>>
>>
>>
>> Here's what I did to get started:
>>
>> * Grabbed the JAX-RS specification document (pointer at
>> https://jsr311.dev.java.net) and read it. It's not that long,
>> but it's important to understand the portable part of the API
>> that Jersey implements -- and so it's also clear when we
>> are *using* the features of the spec (for example, by supplying
>> extra providers and such) versus implementing them.
>>
>> * I always have the JSR-311 Javadocs open in a browser tab
>> for easy reference.
>>
>> * Check out the source code of Jersey from java.net
>> (instructions are on the website).
>>
>> * Build it locally (you'll need Maven for that).
>> cd jersey
>> mvn clean install
>>
>> * Start browsing the javadocs of the parts I was interested in
>> (mostly
>> jersey-core, jersey-server, and jersey-client).
>>
>> * When I wanted to explore an area in more detail, open up the
>> sources
>> for the unit tests and examine how they use the apis (NetBeans has a
>> nice Maven plugin that lets you open each module as a project).
>>
>> * There are also sample apps that cover some of the interesting
>> portions.
>>
>> * Ask questions on this list, often finding out that Paul and Jakub
>> and
>> others
>> had already implemented pieces of what I needed ... I just didn't
>> know where it was :-).
>>
>> Craig
>>
>>
>> On Fri, Nov 7, 2008 at 7:45 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
>> wrote:
>>
>>
>> Hi,
>> Julio, in a previous email you expressed interest in contributing
>> in this
>> area. Would you be interested in working on 3 & 4? Jeff, are you
>> interested
>> as well? If so Craig, I, yourselves (and others that wish to join)
>> could
>> work in a branch of Jersey and when sufficiently progressed move to
>> the
>> trunk (i would be happy to do the integration).
>> Paul.
>>
>>
>> It seems to me there are five different functional aspects:
>> 1) multipart/* support
>> 2) multipart/form-data support
>> 3) Form beans from application/x-www-form-urlencoded
>> 4) Form beans from multipart/form-data
>> 5) General Java bean processing support.
>> 1) and 2) to be part of the same module, namely "jersey-multipart".
>> 3) an 4) could be part of a "jersey-form" module, which could
>> leverage one
>> or more external modules in 5), some suggestions of which you
>> present below.
>> Thoughts?
>> Paul.
>>
>> For actually doing the population, there's quite a lot of prior art
>> we could
>> look at as starting points, including things like Common BeanUtils
>> (which is
>> what Struts 1.x uses), the various JSF EL implementations (which
>> have to do
>> the same sort of thing), or even how Jersey itself performs
>> injections.
>>
>> Craig
>>
>> On Wed, Nov 5, 2008 at 6:50 PM, Kevin Duffey <andjarnic_at_yahoo.com>
>> wrote:
>>
>>
>> Kind of jumping in half way here.. but I actually recommended
>> someone to use
>> Jersey over other MVC frameworks to build both a MVC and REST
>> capable web
>> app. I like how it's possible to build MVC using Jersey and meanwhile
>> support REST too. Frankly, for my own stuff.. this is how I will
>> proceed
>> from now on.
>>
>> That said, I like the idea of allowing beans populated from form
>> data. I
>> take it Jersey will have to automatically determine that if
>> something like:
>>
>> public Response handleFormData(User user){
>> }
>>
>> where User is NOT a JAXB object..but instead an actual bean...
>> Jersey can
>> determine this correct? I didn't dig deep.. but I thought JAXB
>> objects have
>> various @XmlType annotations in it.. where as a regular bean would
>> have
>> nothing of the sort.. .maybe that would make it easy enough for
>> Jersey to
>> determine it's not a JAXB class. Just a thought... but I would see
>> this as a
>> great addition to allow for a bit more MVC like framework out of
>> Jersey.
>> However... is that starting to take Jersey into a direction of
>> being more
>> than a REST framework... even though it could be... is it trying to
>> be too
>> much? For me.. no.. but I could see how many may argue that Jersey is
>> becoming a bloated framework and not sticking to its core REST
>> capabilities.
>>
>>
>> ________________________________
>> From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
>> To: users_at_jersey.dev.java.net
>> Sent: Tuesday, November 4, 2008 2:16:20 AM
>> Subject: Re: [Jersey] Struts-like population of form beans
>>
>> Hi Jeff,
>> Apologies i forgot to reply on the wiki.
>> We don't support form beans yet, just @FormParam on the parameters
>> of a
>> resource method.
>> I think it is a good idea, for URL encoded or in general for
>> multipart
>> whether it be for form-data or other multi-parts, and it would be
>> good to be
>> part of Jersey. For multipart bean support we build upon Craig's
>> API. It
>> would be good to share bean processing functionality between URL-
>> based and
>> multi-part based beans.
>> Paul.
>> On Nov 4, 2008, at 1:22 AM, Robertson, Jeff wrote:
>>
>> Since we have Craig at our disposal here, I figure I'll bring this
>> up.
>>
>> Before I subscribed to the mailing list, I posted this on the wiki:
>>
>> http://wikis.sun.com/display/Jersey/getting+form+data+as+a+populated+javabean
>>
>> (Note: that code compiled against 0.9. Will not compile with 1.0)
>>
>> Does anyone thing this is something that should be in Jersey and/or
>> JAX-RS?
>> Not my implementation, which I worked on for less than an hour before
>> wikifying it, but the general idea?
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>