From abhijit.sarcar at gmail.com Tue Feb 11 01:56:58 2014 From: abhijit.sarcar at gmail.com (Abhijit Sarkar) Date: Tue, 11 Feb 2014 01:56:58 -0500 Subject: [bv-dev] RESTEasy, CDI, embedded Jetty, bean validation is ignored Message-ID: Hi, I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to embedded Jetty. What I can't seem to get working is bean validation. The documentation says that adding 'resteasy-validator-provider-11' along with hibernate validator dependencies (hibernate-validator, hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean validation is simply ignored by RESTEasy. I curiously also get the following message in the logs: plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory I tried registering Hibernate InjectingConstraintValidatorFactory in META-INF/validation.xml but it depends on a BeanManager being injected and blows up at runtime. What can I do to get this working? RESTEasy 3.0.6.Final Weld servlet 2.1.2.Final Hibernate validator 5.0.3.Final Jetty embedded 9.1.1.v20140108 * Also asked on RESTEasy mailing list Regards, Abhijit -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140211/f224bc82/attachment-0001.html From hardy at hibernate.org Tue Feb 11 04:57:46 2014 From: hardy at hibernate.org (Hardy Ferentschik) Date: Tue, 11 Feb 2014 10:57:46 +0100 Subject: [bv-dev] RESTEasy, CDI, embedded Jetty, bean validation is ignored In-Reply-To: References: Message-ID: <4E23137D-D918-4B2D-B80A-2DA8B3BE506F@hibernate.org> Hi Abhijit, first off, this is the wrong mailing list to ask. This mailing list is for development of the Bean Validation specification. You seem to have a problem with the reference implementation of Hibernate Validator and/or its integration into other frameworks. You could try the hibernate-dev mailing list, but I think you are not providing yet enough information to get a helpful answer there either. I would try to include more context - add example code, log messages and potential stack traces. You could set the logging level to debug and see whether you get some more helpful information or you could even try to step through the code with a debugger to get a better understanding where things go wrong. Last but not least, I would then post to Stackoverflow to reach a broader audience. ?Hardy On 11 Jan 2014, at 07:56, Abhijit Sarkar wrote: > Hi, > I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to embedded Jetty. What I can't seem to get working is bean validation. The documentation says that adding 'resteasy-validator-provider-11' along with hibernate validator dependencies (hibernate-validator, hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean validation is simply ignored by RESTEasy. I curiously also get the following message in the logs: > > plugins.validation.ValidatorContextResolver - Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory > > I tried registering Hibernate InjectingConstraintValidatorFactory in META-INF/validation.xml but it depends on a BeanManager being injected and blows up at runtime. > > What can I do to get this working? > > RESTEasy 3.0.6.Final > Weld servlet 2.1.2.Final > Hibernate validator 5.0.3.Final > Jetty embedded 9.1.1.v20140108 > > * Also asked on RESTEasy mailing list > > Regards, > Abhijit > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From abhijit.sarcar at gmail.com Tue Feb 11 19:29:27 2014 From: abhijit.sarcar at gmail.com (Abhijit Sarkar) Date: Tue, 11 Feb 2014 19:29:27 -0500 Subject: [bv-dev] RESTEasy, CDI, embedded Jetty, bean validation is ignored In-Reply-To: <4E23137D-D918-4B2D-B80A-2DA8B3BE506F@hibernate.org> References: <4E23137D-D918-4B2D-B80A-2DA8B3BE506F@hibernate.org> Message-ID: Did what you suggested. Hope someone will help. http://stackoverflow.com/questions/21694596/resteasy-cdi-embedded-jetty-bean-validation-is-ignored Thanks. On Tue, Feb 11, 2014 at 4:57 AM, Hardy Ferentschik wrote: > Hi Abhijit, > > first off, this is the wrong mailing list to ask. This mailing list is for > development of the Bean Validation specification. > You seem to have a problem with the reference implementation of Hibernate > Validator and/or its integration into other frameworks. > > You could try the hibernate-dev mailing list, but I think you are not > providing yet enough information to get a helpful answer there either. > > I would try to include more context - add example code, log messages and > potential stack traces. You could set the logging level > to debug and see whether you get some more helpful information or you > could even try to step through the code with a debugger to > get a better understanding where things go wrong. Last but not least, I > would then post to Stackoverflow to reach a broader audience. > > ?Hardy > > > On 11 Jan 2014, at 07:56, Abhijit Sarkar wrote: > > > Hi, > > I've a Groovy project where I use RESTEasy with CDI (Weld) and deploy to > embedded Jetty. What I can't seem to get working is bean validation. The > documentation says that adding 'resteasy-validator-provider-11' along with > hibernate validator dependencies (hibernate-validator, > hibernate-validator-cdi, javax.el-api, javax.el) is enough. But the bean > validation is simply ignored by RESTEasy. I curiously also get the > following message in the logs: > > > > plugins.validation.ValidatorContextResolver - Unable to find CDI > supporting ValidatorFactory. Using default ValidatorFactory > > > > I tried registering Hibernate InjectingConstraintValidatorFactory in > META-INF/validation.xml but it depends on a BeanManager being injected and > blows up at runtime. > > > > What can I do to get this working? > > > > RESTEasy 3.0.6.Final > > Weld servlet 2.1.2.Final > > Hibernate validator 5.0.3.Final > > Jetty embedded 9.1.1.v20140108 > > > > * Also asked on RESTEasy mailing list > > > > Regards, > > Abhijit > > _______________________________________________ > > 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/20140211/82db1614/attachment.html From marcos_antonio_ps at hotmail.com Mon Feb 24 12:23:42 2014 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Mon, 24 Feb 2014 20:23:42 +0300 Subject: [bv-dev] Configure validation constraints at runtime Message-ID: Hello, everybody! I don't know it this feature was already proposed before. Anyway, here it goes: It would be nice if future specifications add the possibility to configure (add, modify, delete) constraints dinamically, more or less like Hibernate Validator does. Is there any plan to support this? Marcos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20140224/bd79cb33/attachment.html From emmanuel at hibernate.org Mon Feb 24 13:00:35 2014 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 24 Feb 2014 19:00:35 +0100 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: References: Message-ID: <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> Hi We don't have a defined roadmap for the future of Bean Validation. But that would be a nice addition in my opinion. What's your use case for it? Emmanuel > On 24 f?vr. 2014, at 18:23, Marcos Antonio wrote: > > Hello, everybody! > > I don't know it this feature was already proposed before. Anyway, here it goes: > > It would be nice if future specifications add the possibility to configure (add, modify, delete) constraints dinamically, more or less like Hibernate Validator does. > > Is there any plan to support this? > > Marcos > _______________________________________________ > 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/20140224/99ff2ab4/attachment.html From marcos_antonio_ps at hotmail.com Mon Feb 24 13:29:16 2014 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Mon, 24 Feb 2014 21:29:16 +0300 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> References: , <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> Message-ID: Hello, Emmanuel. I'm glad that you liked the suggestion. My use case is this: I'm working in my own framework to create applications. In this framework the majority of things is configurable in the client. So if a client want to change something in the application to fit his needs, I can configure this for him there without the need to change and compile the application (Internally these configurations are stored in a relational database). Amont the things that are configurable on the client are formats. So in my framework I have, for example, a @Mask annotation that I defined that I can use like this in a bean. @Mask("(##) ####-####") public String getPhoneNumber() { ??? return _phoneNumber; } As you may have guessed, everything in the application that displays this property (including editable fields) will be formated with the mask (format) above. But if some client want to change the format for this particular phone number (or even lots of phone numbers that share the same format) I can configure this only for him, without changing the default format applied on the bean. I also have defined other custom annotations for formats like @Minimo and @Maximo (for @Min and @Max - sorry they are in Portuguese, otherwise they would conflict with the standard ones) and @TamanhoMaximo (for @Length). So I noticed that there are some similarities between my formats and the ones provided by the bean validation specification. Think of this example: @TamanhoMaximo(50) @Length(50) public String getName() { ??? return _name; } There are some kind of redundancy here. Why not just have the @Length annotation and have my fremework 'derive' my similar custom annotation from the @Length annotation. Yes I could do that, but the problem is that I can no longer configure the length of the 'name' property on the client, because there's no way I can make the bean validation to see the new value. So I have to stick to this: @TamanhoMaximo(50) public String getName() { ??? return _name; } and let my bean unprotected when updates are applied to it without a GUI. If I could configure the bean validation constraints at runtime I could have this: @Length(50) public String getName() { ??? return _name; } and I would have to best of both worlds. Hope I expressed myself clearly. Marcos PS.: Now one could argue that annotations like @Min, @Max, and @Length have nothing to do with format. But I think that in my case they have to do in the sense their constraints have to be reflected in a text field when the user is editing. Anyway this is not the main point here. ------------------ From: emmanuel at hibernate.org Date: Mon, 24 Feb 2014 19:00:35 +0100 Subject: Re: [bv-dev] Configure validation constraints at runtime To: beanvalidation-dev at lists.jboss.org; marcos_antonio_ps at hotmail.com HiWe don't have a defined roadmap for the future of Bean Validation. But that would be a nice addition in my opinion.? What's your use case for it? Emmanuel On 24 f?vr. 2014, at 18:23, Marcos Antonio wrote: Hello, everybody! I don't know it this feature was already proposed before. Anyway, here it goes: It would be nice if future specifications add the possibility to configure (add, modify, delete) constraints dinamically, more or less like Hibernate Validator does. Is there any plan to support this? Marcos _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From marcos_antonio_ps at hotmail.com Mon Feb 24 13:37:31 2014 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Mon, 24 Feb 2014 21:37:31 +0300 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: References: , , <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org>, Message-ID: Sorry. A minor correction. In my last reply I meant @Size, not @Length. Marcos ---------------------------------------- > From: marcos_antonio_ps at hotmail.com > To: beanvalidation-dev at lists.jboss.org > Date: Mon, 24 Feb 2014 21:29:16 +0300 > Subject: Re: [bv-dev] Configure validation constraints at runtime > > Hello, Emmanuel. > > I'm glad that you liked the suggestion. > > My use case is this: > > I'm working in my own framework to create applications. In this framework the majority of things is configurable in the client. So if a client want to change something in the application to fit his needs, I can configure this for him there without the need to change and compile the application (Internally these configurations are stored in a relational database). > > Amont the things that are configurable on the client are formats. So in my framework I have, for example, a @Mask annotation that I defined that I can use like this in a bean. > > @Mask("(##) ####-####") > public String getPhoneNumber() > { > return _phoneNumber; > } > > As you may have guessed, everything in the application that displays this property (including editable fields) will be formated with the mask (format) above. But if some client want to change the format for this particular phone number (or even lots of phone numbers that share the same format) I can configure this only for him, without changing the default format applied on the bean. > > I also have defined other custom annotations for formats like @Minimo and @Maximo (for @Min and @Max - sorry they are in Portuguese, otherwise they would conflict with the standard ones) and @TamanhoMaximo (for @Length). So I noticed that there are some similarities between my formats and the ones provided by the bean validation specification. Think of this example: > > @TamanhoMaximo(50) > @Length(50) > public String getName() > { > return _name; > } > > There are some kind of redundancy here. Why not just have the @Length annotation and have my fremework 'derive' my similar custom annotation from the @Length annotation. Yes I could do that, but the problem is that I can no longer configure the length of the 'name' property on the client, because there's no way I can make the bean validation to see the new value. So I have to stick to this: > > @TamanhoMaximo(50) > public String getName() > { > return _name; > } > > and let my bean unprotected when updates are applied to it without a GUI. If I could configure the bean validation constraints at runtime I could have this: > > @Length(50) > public String getName() > { > return _name; > } > > and I would have to best of both worlds. > > Hope I expressed myself clearly. > > Marcos From marcos_antonio_ps at hotmail.com Mon Feb 24 19:38:59 2014 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Tue, 25 Feb 2014 03:38:59 +0300 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> References: , <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> Message-ID: Let me try to be a bit more clear. Consider this entity: @Entity public class Employee { private String _name; // ... @Size(min = 1, max = 50) public String getName() { return _name; } // ... } If some client of mine asked me to change the name of the employees to accept 70 characters because 50 is not enough anymore I have to change my application for all clients. But if the bean validation specification allowed me to configure the constraints dinamically I could do this configuration on a cliente basis. All I had to do was to change the database structure for the specific column, register this fact in some table of mine and in the application startup my application would check for changes and configure the corresponding bean constraint. With static constraints (as it is today) we don't have this flexibility. Marcos ---------------------------- From: emmanuel at hibernate.org Date: Mon, 24 Feb 2014 19:00:35 +0100 Subject: Re: [bv-dev] Configure validation constraints at runtime To: beanvalidation-dev at lists.jboss.org; marcos_antonio_ps at hotmail.com Hi We don't have a defined roadmap for the future of Bean Validation. But that would be a nice addition in my opinion. What's your use case for it? Emmanuel From mbenson at apache.org Mon Feb 24 20:51:20 2014 From: mbenson at apache.org (Matt Benson) Date: Mon, 24 Feb 2014 19:51:20 -0600 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: References: <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> Message-ID: I would be interested in getting dynamic constraint functionality into the BV spec. Between what Hibernate Validator offers and what is supported by the dynamic add-on for Apache BVal it shouldn't take us much to agree on an API. Matt On Feb 24, 2014 6:39 PM, "Marcos Antonio" wrote: > Let me try to be a bit more clear. > Consider this entity: > > @Entity > public class Employee > { > private String _name; > > // ... > > @Size(min = 1, max = 50) > public String getName() > { > return _name; > } > > // ... > } > > If some client of mine asked me to change the name of the employees to > accept 70 characters because 50 is not enough anymore I have to change my > application for all clients. But if the bean validation specification > allowed me to configure the constraints dinamically I could do this > configuration on a cliente basis. All I had to do was to change the > database structure for the specific column, register this fact in some > table of mine and in the application startup my application would check for > changes and configure the corresponding bean constraint. With static > constraints (as it is today) we don't have this flexibility. > > Marcos > > ---------------------------- > > From: emmanuel at hibernate.org > Date: Mon, 24 Feb 2014 19:00:35 +0100 > Subject: Re: [bv-dev] Configure validation constraints at runtime > To: beanvalidation-dev at lists.jboss.org; marcos_antonio_ps at hotmail.com > > Hi > We don't have a defined roadmap for the future of Bean Validation. But > that would be a nice addition in my opinion. > > What's your use case for it? > > Emmanuel > _______________________________________________ > 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/20140224/f9ad25fd/attachment.html From gunnar at hibernate.org Tue Feb 25 02:44:28 2014 From: gunnar at hibernate.org (Gunnar Morling) Date: Tue, 25 Feb 2014 08:44:28 +0100 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: References: <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org> Message-ID: +1 for adding something like this. Marcos, could you open an issue in our tracker (https://hibernate.atlassian.net/browse/BVAL)? If you don't want to use the current dynamic constraint APIs in HV/Apache BVAL, you might consider to generate XML constraint descriptors based on your configuration. That's a bit more tedious but portable between providers. Slightly related, I see people ask every now and then for a facility for copying constraint definitions between models. Users could build this themselves if aforementioned dynamic constraint definition was possible, or we could add some more high-level support for this. --Gunnar 2014/2/25 Matt Benson > I would be interested in getting dynamic constraint functionality into the > BV spec. Between what Hibernate Validator offers and what is supported by > the dynamic add-on for Apache BVal it shouldn't take us much to agree on an > API. > > Matt > On Feb 24, 2014 6:39 PM, "Marcos Antonio" > wrote: > >> Let me try to be a bit more clear. >> Consider this entity: >> >> @Entity >> public class Employee >> { >> private String _name; >> >> // ... >> >> @Size(min = 1, max = 50) >> public String getName() >> { >> return _name; >> } >> >> // ... >> } >> >> If some client of mine asked me to change the name of the employees to >> accept 70 characters because 50 is not enough anymore I have to change my >> application for all clients. But if the bean validation specification >> allowed me to configure the constraints dinamically I could do this >> configuration on a cliente basis. All I had to do was to change the >> database structure for the specific column, register this fact in some >> table of mine and in the application startup my application would check for >> changes and configure the corresponding bean constraint. With static >> constraints (as it is today) we don't have this flexibility. >> >> Marcos >> >> ---------------------------- >> >> From: emmanuel at hibernate.org >> Date: Mon, 24 Feb 2014 19:00:35 +0100 >> Subject: Re: [bv-dev] Configure validation constraints at runtime >> To: beanvalidation-dev at lists.jboss.org; marcos_antonio_ps at hotmail.com >> >> Hi >> We don't have a defined roadmap for the future of Bean Validation. But >> that would be a nice addition in my opinion. >> >> What's your use case for it? >> >> Emmanuel >> _______________________________________________ >> 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/20140225/318bbe48/attachment.html From marcos_antonio_ps at hotmail.com Tue Feb 25 06:29:42 2014 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Tue, 25 Feb 2014 14:29:42 +0300 Subject: [bv-dev] Configure validation constraints at runtime In-Reply-To: References: , <74315F09-AD70-4FF7-A70A-00B4E4ADD3F1@hibernate.org>, , , Message-ID: Done: https://hibernate.atlassian.net/browse/BVAL-475 Marcos ________________________________ > Date: Tue, 25 Feb 2014 08:44:28 +0100 > From: gunnar at hibernate.org > To: beanvalidation-dev at lists.jboss.org > Subject: Re: [bv-dev] Configure validation constraints at runtime > > +1 for adding something like this. Marcos, could you open an issue in > our tracker (https://hibernate.atlassian.net/browse/BVAL)? > > If you don't want to use the current dynamic constraint APIs in > HV/Apache BVAL, you might consider to generate XML constraint > descriptors based on your configuration. That's a bit more tedious but > portable between providers. > > Slightly related, I see people ask every now and then for a facility > for copying constraint definitions between models. Users could build > this themselves if aforementioned dynamic constraint definition was > possible, or we could add some more high-level support for this. > > --Gunnar > > > > > 2014/2/25 Matt Benson > > > I would be interested in getting dynamic constraint functionality into > the BV spec. Between what Hibernate Validator offers and what is > supported by the dynamic add-on for Apache BVal it shouldn't take us > much to agree on an API. > > Matt > > On Feb 24, 2014 6:39 PM, "Marcos Antonio" > > > wrote: > Let me try to be a bit more clear. > Consider this entity: > > @Entity > public class Employee > { > private String _name; > > // ... > > @Size(min = 1, max = 50) > public String getName() > { > return _name; > } > > // ... > } > > If some client of mine asked me to change the name of the employees to > accept 70 characters because 50 is not enough anymore I have to change > my application for all clients. But if the bean validation > specification allowed me to configure the constraints dinamically I > could do this configuration on a cliente basis. All I had to do was to > change the database structure for the specific column, register this > fact in some table of mine and in the application startup my > application would check for changes and configure the corresponding > bean constraint. With static constraints (as it is today) we don't have > this flexibility. > > Marcos > > ---------------------------- > > From: emmanuel at hibernate.org > Date: Mon, 24 Feb 2014 19:00:35 +0100 > Subject: Re: [bv-dev] Configure validation constraints at runtime > To: > beanvalidation-dev at lists.jboss.org; > marcos_antonio_ps at hotmail.com > > Hi > We don't have a defined roadmap for the future of Bean Validation. But > that would be a nice addition in my opinion. > > What's your use case for it? > > Emmanuel > _______________________________________________ > 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 > > > _______________________________________________ beanvalidation-dev > mailing list beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev