Hi Ed... Don't forget that EL has String-based "type coercion" and then there's the basic PropertyEditor stuff from java.beans. Beans binding (JSR 295) was expected to have some notion of conversion IIRC, and that's only the JCP stuff. Spring and others have done conversion frameworks as well, with what are arguably varying degrees of success. I think it's possible to do good, fully-featured Java object conversion, but that (a) it's bigger than can comfortably fit in Bean Validation and (b) it's a shame to limit the feature to conversion when the more generic term "transformation" can encompass the closely-related concept of object *copying*. Shameless self-promotion: see the Therian library [1]. Docs are more or less nonexistent as of now, but Therian provides transformation plumbing so that you can say, e.g.: public Bar convertToBar(@NotNull Foo foo) { final Bar result = therianContext.eval(Convert.to(Bar.class, Positions.readOnly(foo)); return result; } I conceived Therian when I was working with JSF so TherianContext extends ELContext. My goal was that it should be easy to plug Therian into JSF for conversions. I haven't actually gotten around to trying this yet, but Therian was based on my experience as a user and developer of the older Morph transformation (etc.) library, and having found it quite easy to plug my Morph transformations into JSF, I don't anticipate any difficulty. Personally, I like Therian's design, but I am also aware that some will find it a bit unwieldy (in the unlikely event that anyone ever even learns of its existence ;P ). I would hope that any broader JSR would be interface-based so as not to preclude the like of Therian being plugged in as a potential implementation, but I can tell you I am exhausted just imagining a specification negotiation in the object transformation space. br, Matt [1] https://github.com/mbenson/therian [2] http://morph.sourceforge.net/ On Fri, Jul 12, 2013 at 3:27 PM, Edward Burns <edward.burns(a)oracle.com&gt;wrote:

Hi, I also think a dedicated spec would make sense, but it should be made sure that BV and such a new spec work nicely together. In the wider field of object conversion (i.e. not only binding user "input" to typed models, but converting/copying between any JavaBeans) there a some candidates which might benefit from such a spec, be it generic mapping libraries such as Orika [1] or solutions based on compile-time code generation such as my own project MapStruct [2]. 2013/7/15 Emmanuel Bernard <emmanuel(a)hibernate.org Right, both can be required. That's why e.g. JFace databinding has several validation phases, before and after conversion. I think BV as of today would be helpful mostly in the second step as it is centered around properly typed properties. Any other adherence? I think reporting/messaging is one, i.e. you'd typically want to report conversion and validation errors in a similar manner to the user (using the same kind of "decoration", maybe using something like a "property path"), maybe retrieve messages from the same bundle etc. Configuration in general may be another integration point, e.g. it might be useful to have some kind of shared XML descriptor which allows to add constraints and conversion rules for an attribute in a unified manner. --Gunnar [1] http://code.google.com/p/orika/ [2] http://mapstruct.org/ Emmanuel > On 12 juil. 2013, at 22:27, Edward Burns <edward.burns(a)oracle.com&gt; wrote: > > Hello Volunteers, > > > I've been viewing Emmanuel's videos about BV 1.1 and whenever he talks > > about Bean Validation and JAX-RS, such as this > > > @Path("/user") > > class UserResource { > > > @Post > > @Consumes("application/x-www-form-urlencoded") > > public void register( > > @NotEmpty @FormParam("firstname") String firstname, > > @NotEmpty @FormParam("lastname") String lastname, > > @NotNull @Email @FormParam("email") String email) { ... } > > } > > > I have to ask myself, isn't this missing something? What about > > conversion? > > > Before Bean Validation, JSF brought type conversion *and* validation to > > the table. Now that Bean Validation provides the validation part for > > all of JavaEE, isn't it time we think about the other part: type > > conversion? > > > JSF has an elaborate conversion system with by-type conventions and also > > the ability to manually declare that specific converters should be used > > for specific values. It's not a far cry to realize that we don't need > > to limit ourselves to "String" for these arguments and there is a lot we > > could do to enable arbitrary types and have Bean Validation handle the > > conversion on the way in. > > > JAX-RS also has the javax.ws.rs.ext.ParamConverter facility, which > > solves the conversion problem in a JAX-RS specific way. > > > Here we have two specs that do conversion. I think it might be useful > > to realize that type conversion is really just the first part of > > validation, and therefore falls under the responsibility of Bean > > Validation. > > > Is this worth pursuing? > > > Ed > > > -- > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev