From Richard.Fanning at FINEOS.com Tue Jul 29 09:31:55 2014 From: Richard.Fanning at FINEOS.com (Richard Fanning) Date: Tue, 29 Jul 2014 13:31:55 +0000 Subject: [bv-dev] Feature Suggestion :: Implicit constraints Message-ID: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> Hi there, We are starting to use bean validation in our product and something we would like to do is what I've coined as "implicit constraints". I'd like to run this by the mailing list and get your thoughts on this as a potential feature in the spec. The use case we have is we have a "DateTime" object which represents Date & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for us has some constraints 1) The DateTime cannot me before LOW_DATE --> 01-01-1970 00:00:00 2) The DateTime cannot me after HIGH_DATE --> 31-12-2150 23:59:59 Not sure of the exact history of these constraints but it would seem like we are trying to invent a new y2k :) These constraints were enforced prior to our usage of Bean Validation as these were burnt into the setter of generated POJO's (domain objects) but now that we are moving from generated domain objects to JPA style POJO's we'd like to use Bean Validation to apply the same constraints. Assume we have an object which has a DateTime property as shown below public class TestObject { private DateTime myDateTime; public DateTime getMyDateTime() { return myDateTime; } public void setMyDateTime(DateTime myDateTime) { this.myDateTime = myDateTime; } } We'd like if developers did not need to add an annotation all DateTime properties to constrain with the implicit constraints.. i.e. @Date private DateTime myDateTime; In our opinion this annotation serves no additional purpose and would be an extra onus on the developer to add this so they ensure the value meets internal DateTime criteria. Looking at the 1.1 spec I cannot see any way of applying constraints without annotating (well you can use HV XML but that would need to be done for all fields).. Is that correct. I've managed to implement "implicit constraints" by using non-standard Hibernate Validator API's (i.e. using reflection I added an additional MetaDataProvider which added ConstrainedElements ( to the BeanConfiguration)). I can share this on GitHub is anyone is interested in taking a look. Appreciate any feedback you might have. Thanks Rich __________________________________________________________ FINEOS Corporation is the global brand name of FINEOS Corporation and its affiliated group companies worldwide. The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com __________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/93649f43/attachment-0001.html From emmanuel at hibernate.org Tue Jul 29 09:46:21 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 29 Jul 2014 15:46:21 +0200 Subject: [bv-dev] Feature Suggestion :: Implicit constraints In-Reply-To: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> References: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> Message-ID: <572CE4CF-C523-4F24-A1B7-9FCF27ADEAD1@hibernate.org> Interesting, I would say that remain pretty uncommon as far as use case frequency goes. On an unrelated project I work on, we have introduce a relatively similar notion of registrable constraints (bridges in that project) per property return type. We could definitely try and bring that idea to Hibernate Validator and see how many people use it before moving it to BV. That would still be better than you hacking your way int he guts of Hibernate Validator :) Emmanuel On 29 Jul 2014, at 15:31, Richard Fanning wrote: > Hi there, > > We are starting to use bean validation in our product and something we would like to do is what I?ve coined as ?implicit constraints?. I?d like to run this by the mailing list and get your thoughts on this as a potential feature in the spec. > > The use case we have is we have a ?DateTime? object which represents Date & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for us has some constraints > > The DateTime cannot me before LOW_DATE ? 01-01-1970 00:00:00 > The DateTime cannot me after HIGH_DATE ? 31-12-2150 23:59:59 > > Not sure of the exact history of these constraints but it would seem like we are trying to invent a new y2kJ > > These constraints were enforced prior to our usage of Bean Validation as these were burnt into the setter of generated POJO?s (domain objects) but now that we are moving from generated domain objects to JPA style POJO?s we?d like to use Bean Validation to apply the same constraints. > > Assume we have an object which has a DateTime property as shown below > > public class TestObject { > > private DateTime myDateTime; > > public DateTime getMyDateTime() { > return myDateTime; > } > > public void setMyDateTime(DateTime myDateTime) { > this.myDateTime = myDateTime; > } > > } > > We?d like if developers did not need to add an annotation all DateTime properties to constrain with the implicit constraints.. i.e. > > @Date > private DateTime myDateTime; > > In our opinion this annotation serves no additional purpose and would be an extra onus on the developer to add this so they ensure the value meets internal DateTime criteria. > > Looking at the 1.1 spec I cannot see any way of applying constraints without annotating (well you can use HV XML but that would need to be done for all fields).. Is that correct. > > I?ve managed to implement ?implicit constraints? by using non-standard Hibernate Validator API?s (i.e. using reflection I added an additional MetaDataProvider which added ConstrainedElements ( to the BeanConfiguration)). I can share this on GitHub is anyone is interested in taking a look. > > Appreciate any feedback you might have. > > Thanks > > Rich > > > __________________________________________________________ > FINEOS Corporation is the global brand name of FINEOS Corporation and its affiliated > group companies worldwide. > > The information contained in this e-mail is confidential, may be privileged and is intended > only for the use of the recipient named above. If you are not the intended recipient or a > representative of the intended recipient, you have received this e-mail in error and must > not copy, use or disclose the contents of this e-mail to anybody else. > > If you have received this e-mail in error, please notify the sender immediately by return > e-mail and permanently delete the copy you received. This e-mail has been swept for > computer viruses. However, you should carry out your own virus checks. > Registered in Ireland, No. 205721. http://www.FINEOS.com > __________________________________________________________ > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/d1ff8c58/attachment.html From gunnar at hibernate.org Tue Jul 29 09:53:28 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 29 Jul 2014 15:53:28 +0200 Subject: [bv-dev] Feature Suggestion :: Implicit constraints In-Reply-To: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> References: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> Message-ID: Hi, 2014-07-29 15:31 GMT+02:00 Richard Fanning : > Hi there, > > We are starting to use bean validation in our product and something we > would like to do is what I?ve coined as ?implicit constraints?. I?d like to > run this by the mailing list and get your thoughts on this as a potential > feature in the spec. > > The use case we have is we have a ?DateTime? object which represents Date > & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for > us has some constraints > > > 1. The DateTime cannot me before LOW_DATE ? 01-01-1970 00:00:00 > 2. The DateTime cannot me after HIGH_DATE ? 31-12-2150 23:59:59 > > > Not sure of the exact history of these constraints but it would seem like > we are trying to invent a new y2k J > > These constraints were enforced prior to our usage of Bean Validation as > these were burnt into the setter of generated POJO?s (domain objects) but > now that we are moving from generated domain objects to JPA style POJO?s > we?d like to use Bean Validation to apply the same constraints. > Assume we have an object which has a DateTime property as shown below > > *public* *class* TestObject { > > *private* DateTime myDateTime; > > *public* DateTime getMyDateTime() { > *return* myDateTime; > } > > *public* *void* setMyDateTime(DateTime myDateTime) { > *this*.myDateTime = myDateTime; > } > > } > > We?d like if developers did not need to add an annotation all DateTime > properties to constrain with the implicit constraints.. i.e. > > @Date > *private* DateTime myDateTime; > > In our opinion this annotation serves no additional purpose and would be > an extra onus on the developer to add this so they ensure the value meets > internal DateTime criteria. > > Looking at the 1.1 spec I cannot see any way of applying constraints > without annotating (well you can use HV XML but that would need to be done > for all fields).. Is that correct. > Yes, the spec defines constraint declaration via annotations and XML. Hibernate Validator in addition has a (public) API for programmatic constraint declaration. > > I?ve managed to implement ?implicit constraints? by using non-standard > Hibernate Validator API?s (i.e. using reflection I added an additional > MetaDataProvider which added ConstrainedElements ( to the > BeanConfiguration)). I can share this on GitHub is anyone is interested in > taking a look. > You should better use the HV constraint API for this [1]. You could inspect your beans using reflection and define a @Date constraint for each DateTime property you find. MetaDataProvider et al. are internal APIs which may change without notice between releases. Standardizing this API might be a useful addition as it allows to implement cases as yours in a portable manner. Not sure whether the spec should explicitly support this requirement, as it may be very specific. Appreciate any feedback you might have. > > Thanks > > Rich > --Gunnar [1] http://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html_single/#section-programmatic-api > > > > __________________________________________________________ > FINEOS Corporation is the global brand name of FINEOS Corporation and its > affiliated > group companies worldwide. > > The information contained in this e-mail is confidential, may be > privileged and is intended > only for the use of the recipient named above. If you are not the intended > recipient or a > representative of the intended recipient, you have received this e-mail in > error and must > not copy, use or disclose the contents of this e-mail to anybody else. > > If you have received this e-mail in error, please notify the sender > immediately by return > e-mail and permanently delete the copy you received. This e-mail has been > swept for > computer viruses. However, you should carry out your own virus checks. > Registered in Ireland, No. 205721. http://www.FINEOS.com > __________________________________________________________ > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/3403cf4e/attachment-0001.html From Richard.Fanning at FINEOS.com Tue Jul 29 12:01:11 2014 From: Richard.Fanning at FINEOS.com (Richard Fanning) Date: Tue, 29 Jul 2014 16:01:11 +0000 Subject: [bv-dev] Feature Suggestion :: Implicit constraints In-Reply-To: References: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> Message-ID: <1C51ABCFD4E48546A90547438B7654C1010B29C858@EXCHANGE-DB.FINEOS.com> Hi guys, Thanks for the responses. You?re probably both correct in that this is an uncommon use case.. Another scenario in our company where we thought this feature might be useful was again around the area of defaults. So for example a String property on an @Entity would not need to define any @Size but a sensible default (255) would apply akin to JPA providers [1] But we?d still like to get ConstraintViolations during validation phase rather than some JPA/DB errors complaining about the strings length. Anywho using the programmatic HV API is certainly a better approach than ?hacking my into the guts of HV? albeit they pretty well organized guts ? I guess a take away for the Bean Validations EG might be that the HV programmatic constraints API has it?s uses and would be useful as part of JSR SPEC. Thanks for your time. Rich [1] http://stackoverflow.com/questions/7509769/how-to-increase-length-of-a-string-in-mysql-while-mapping-using-jpa From: beanvalidation-dev-bounces at lists.jboss.org [mailto:beanvalidation-dev-bounces at lists.jboss.org] On Behalf Of Gunnar Morling Sent: 29 July 2014 14:53 To: beanvalidation-dev List Subject: Re: [bv-dev] Feature Suggestion :: Implicit constraints Hi, 2014-07-29 15:31 GMT+02:00 Richard Fanning >: Hi there, We are starting to use bean validation in our product and something we would like to do is what I?ve coined as ?implicit constraints?. I?d like to run this by the mailing list and get your thoughts on this as a potential feature in the spec. The use case we have is we have a ?DateTime? object which represents Date & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for us has some constraints 1. The DateTime cannot me before LOW_DATE --> 01-01-1970 00:00:00 2. The DateTime cannot me after HIGH_DATE --> 31-12-2150 23:59:59 Not sure of the exact history of these constraints but it would seem like we are trying to invent a new y2k ? These constraints were enforced prior to our usage of Bean Validation as these were burnt into the setter of generated POJO?s (domain objects) but now that we are moving from generated domain objects to JPA style POJO?s we?d like to use Bean Validation to apply the same constraints. Assume we have an object which has a DateTime property as shown below public class TestObject { private DateTime myDateTime; public DateTime getMyDateTime() { return myDateTime; } public void setMyDateTime(DateTime myDateTime) { this.myDateTime = myDateTime; } } We?d like if developers did not need to add an annotation all DateTime properties to constrain with the implicit constraints.. i.e. @Date private DateTime myDateTime; In our opinion this annotation serves no additional purpose and would be an extra onus on the developer to add this so they ensure the value meets internal DateTime criteria. Looking at the 1.1 spec I cannot see any way of applying constraints without annotating (well you can use HV XML but that would need to be done for all fields).. Is that correct. Yes, the spec defines constraint declaration via annotations and XML. Hibernate Validator in addition has a (public) API for programmatic constraint declaration. I?ve managed to implement ?implicit constraints? by using non-standard Hibernate Validator API?s (i.e. using reflection I added an additional MetaDataProvider which added ConstrainedElements ( to the BeanConfiguration)). I can share this on GitHub is anyone is interested in taking a look. You should better use the HV constraint API for this [1]. You could inspect your beans using reflection and define a @Date constraint for each DateTime property you find. MetaDataProvider et al. are internal APIs which may change without notice between releases. Standardizing this API might be a useful addition as it allows to implement cases as yours in a portable manner. Not sure whether the spec should explicitly support this requirement, as it may be very specific. Appreciate any feedback you might have. Thanks Rich --Gunnar [1] http://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html_single/#section-programmatic-api __________________________________________________________ FINEOS Corporation is the global brand name of FINEOS Corporation and its affiliated group companies worldwide. The information contained in this e-mail is confidential, may be privileged and is intended only for the use of the recipient named above. If you are not the intended recipient or a representative of the intended recipient, you have received this e-mail in error and must not copy, use or disclose the contents of this e-mail to anybody else. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the copy you received. This e-mail has been swept for computer viruses. However, you should carry out your own virus checks. Registered in Ireland, No. 205721. http://www.FINEOS.com __________________________________________________________ _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/6e170d5c/attachment-0001.html From mbenson at apache.org Tue Jul 29 12:09:28 2014 From: mbenson at apache.org (Matt Benson) Date: Tue, 29 Jul 2014 11:09:28 -0500 Subject: [bv-dev] Feature Suggestion :: Implicit constraints In-Reply-To: <1C51ABCFD4E48546A90547438B7654C1010B29C858@EXCHANGE-DB.FINEOS.com> References: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> <1C51ABCFD4E48546A90547438B7654C1010B29C858@EXCHANGE-DB.FINEOS.com> Message-ID: I don't think this use case is so uncommon. I was doing this years ago with custom extensions to Apache BVal. I suppose there is no reason one couldn't generate XML in response to a reflective examination of a set of classes and bootstrap a validator using the result, but that does seem cumbersome compared to a custom API. Matt On Tue, Jul 29, 2014 at 11:01 AM, Richard Fanning < Richard.Fanning at fineos.com> wrote: > Hi guys, > > > > Thanks for the responses. You?re probably both correct in that this is an > uncommon use case.. > > > > Another scenario in our company where we thought this feature might be > useful was again around the area of defaults. So for example a String > property on an @Entity would not need to define any @Size but a sensible > default (255) would apply akin to JPA providers [1] > > > > But we?d still like to get ConstraintViolations during validation phase > rather than some JPA/DB errors complaining about the strings length. > > > > Anywho using the programmatic HV API is certainly a better approach than > ?hacking my into the guts of HV? albeit they pretty well organized guts J > > > > I guess a take away for the Bean Validations EG might be that the HV > programmatic constraints API has it?s uses and would be useful as part of > JSR SPEC. > > > > Thanks for your time. > > > > Rich > > > > [1] > http://stackoverflow.com/questions/7509769/how-to-increase-length-of-a-string-in-mysql-while-mapping-using-jpa > > > > > > *From:* beanvalidation-dev-bounces at lists.jboss.org [mailto: > beanvalidation-dev-bounces at lists.jboss.org] *On Behalf Of *Gunnar Morling > *Sent:* 29 July 2014 14:53 > *To:* beanvalidation-dev List > *Subject:* Re: [bv-dev] Feature Suggestion :: Implicit constraints > > > > Hi, > > > > 2014-07-29 15:31 GMT+02:00 Richard Fanning : > > Hi there, > > > > We are starting to use bean validation in our product and something we > would like to do is what I?ve coined as ?implicit constraints?. I?d like to > run this by the mailing list and get your thoughts on this as a potential > feature in the spec. > > > > The use case we have is we have a ?DateTime? object which represents Date > & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for > us has some constraints > > > > 1. The DateTime cannot me before LOW_DATE ? 01-01-1970 00:00:00 > > 2. The DateTime cannot me after HIGH_DATE ? 31-12-2150 23:59:59 > > > > Not sure of the exact history of these constraints but it would seem like > we are trying to invent a new y2k J > > > > These constraints were enforced prior to our usage of Bean Validation as > these were burnt into the setter of generated POJO?s (domain objects) but > now that we are moving from generated domain objects to JPA style POJO?s > we?d like to use Bean Validation to apply the same constraints. > > Assume we have an object which has a DateTime property as shown below > > > > *public* *class* TestObject { > > > > *private* DateTime myDateTime; > > > > *public* DateTime getMyDateTime() { > > *return* myDateTime; > > } > > > > *public* *void* setMyDateTime(DateTime myDateTime) { > > *this*.myDateTime = myDateTime; > > } > > > > } > > > > We?d like if developers did not need to add an annotation all DateTime > properties to constrain with the implicit constraints.. i.e. > > > > @Date > > *private* DateTime myDateTime; > > > > In our opinion this annotation serves no additional purpose and would be > an extra onus on the developer to add this so they ensure the value meets > internal DateTime criteria. > > > > Looking at the 1.1 spec I cannot see any way of applying constraints > without annotating (well you can use HV XML but that would need to be done > for all fields).. Is that correct. > > > > Yes, the spec defines constraint declaration via annotations and XML. > Hibernate Validator in addition has a (public) API for programmatic > constraint declaration. > > > > I?ve managed to implement ?implicit constraints? by using non-standard > Hibernate Validator API?s (i.e. using reflection I added an additional > MetaDataProvider which added ConstrainedElements ( to the > BeanConfiguration)). I can share this on GitHub is anyone is interested in > taking a look. > > > > You should better use the HV constraint API for this [1]. You could > inspect your beans using reflection and define a @Date constraint for each > DateTime property you find. MetaDataProvider et al. are internal APIs which > may change without notice between releases. > > > > Standardizing this API might be a useful addition as it allows to > implement cases as yours in a portable manner. Not sure whether the spec > should explicitly support this requirement, as it may be very specific. > > > > Appreciate any feedback you might have. > > > > Thanks > > > Rich > > > > --Gunnar > > > > [1] > http://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html_single/#section-programmatic-api > > > > > > > > __________________________________________________________ > FINEOS Corporation is the global brand name of FINEOS Corporation and its > affiliated > group companies worldwide. > > The information contained in this e-mail is confidential, may be > privileged and is intended > only for the use of the recipient named above. If you are not the intended > recipient or a > representative of the intended recipient, you have received this e-mail in > error and must > not copy, use or disclose the contents of this e-mail to anybody else. > > If you have received this e-mail in error, please notify the sender > immediately by return > e-mail and permanently delete the copy you received. This e-mail has been > swept for > computer viruses. However, you should carry out your own virus checks. > Registered in Ireland, No. 205721. http://www.FINEOS.com > __________________________________________________________ > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/673af11b/attachment-0001.html From emmanuel at hibernate.org Tue Jul 29 12:10:18 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Tue, 29 Jul 2014 18:10:18 +0200 Subject: [bv-dev] Feature Suggestion :: Implicit constraints In-Reply-To: <1C51ABCFD4E48546A90547438B7654C1010B29C858@EXCHANGE-DB.FINEOS.com> References: <1C51ABCFD4E48546A90547438B7654C1010B29B696@EXCHANGE-DB.FINEOS.com> <1C51ABCFD4E48546A90547438B7654C1010B29C858@EXCHANGE-DB.FINEOS.com> Message-ID: <989C6AF1-8B9B-4327-9BB8-E05144CC72CC@hibernate.org> On 29 Jul 2014, at 18:01, Richard Fanning wrote: > > Another scenario in our company where we thought this feature might be useful was again around the area of defaults. So for example a String property on an @Entity would not need to define any @Size but a sensible default (255) would apply akin to JPA providers [1] > > But we?d still like to get ConstraintViolations during validation phase rather than some JPA/DB errors complaining about the strings length. Actually, I?ve been trying to convince the JPA EG to do the opposite. The @Column(lengh) would be guessed by @Size(max=200) to avoid repetition. But I have had some resistance on this approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140729/90b7bba0/attachment.html