From guillaume.smet at gmail.com Fri Oct 6 10:13:47 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Fri, 6 Oct 2017 16:13:47 +0200 Subject: [bv-dev] TraversableResolver and JPA Message-ID: Hi, A user of Hibernate Validator reported an interesting case here: https://hibernate.atlassian.net/browse/HV-1489 . The fact is that a method implemented in WebLogic is suboptimal but I think there is an interesting point here anyway. In the spec, we say that when we find a JPA implementation in the classpath, we enable the JPATraversableResolver. This adds an overhead even for unmanaged entities as there is no way to tell if an object is a managed entity or a plain bean. In EclipseLink, they override the traversable resolver in the context when validating the object on persist and I think it might be good idea: their JPA resolver is only used when persisting entities and when other objects are validated, the default traversable resolver is used - in the case of our user, it uses our JPATraversableResolver which leads to the issue he reported. There is another advantage to this approach: the TraversableResolver is in the JPA implementation so it can use optimized calls to internal classes, instead of relying on the JPA API. The problem with such an approach is that the user can't override the traversable resolver set by the JPA provider. There is another trade-off: if the user tries to validate an entity outside of the JPA persist listener, it won't use the specific JPA resolver. I wasn't there when this section was added so I'm not sure what was exactly the rationale for it. I think we might have underestimated the overhead of our approach. We have a cache but the cache is per validation call so if you end up validating each object only once per call (and it's probably the most common case), the cache doesn't bring anything to you (except an additional overhead). -- Guillaume From misterm at gmail.com Sun Oct 8 20:49:54 2017 From: misterm at gmail.com (Michael Nascimento) Date: Sun, 8 Oct 2017 21:49:54 -0300 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: References: Message-ID: I think a problem is when you have MyClass, which has an attribute of type MyOtherClass, that finally points to an entity. So we must use the JPATraversableResolver even then to avoid unnecessary initialization. Regards, Michael On Fri, Oct 6, 2017 at 11:13 AM, Guillaume Smet wrote: > Hi, > > A user of Hibernate Validator reported an interesting case here: > https://hibernate.atlassian.net/browse/HV-1489 . > > The fact is that a method implemented in WebLogic is suboptimal but I > think there is an interesting point here anyway. > > In the spec, we say that when we find a JPA implementation in the > classpath, we enable the JPATraversableResolver. This adds an overhead > even for unmanaged entities as there is no way to tell if an object is > a managed entity or a plain bean. > > In EclipseLink, they override the traversable resolver in the context > when validating the object on persist and I think it might be good > idea: their JPA resolver is only used when persisting entities and > when other objects are validated, the default traversable resolver is > used - in the case of our user, it uses our JPATraversableResolver > which leads to the issue he reported. > > There is another advantage to this approach: the TraversableResolver > is in the JPA implementation so it can use optimized calls to internal > classes, instead of relying on the JPA API. > > The problem with such an approach is that the user can't override the > traversable resolver set by the JPA provider. > > There is another trade-off: if the user tries to validate an entity > outside of the JPA persist listener, it won't use the specific JPA > resolver. > > I wasn't there when this section was added so I'm not sure what was > exactly the rationale for it. > > I think we might have underestimated the overhead of our approach. We > have a cache but the cache is per validation call so if you end up > validating each object only once per call (and it's probably the most > common case), the cache doesn't bring anything to you (except an > additional overhead). > > -- > Guillaume > _______________________________________________ > 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/20171008/644dcce2/attachment.html From emmanuel at hibernate.org Mon Oct 9 05:56:32 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 9 Oct 2017 11:56:32 +0200 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: References: Message-ID: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. It would become a very big overhead to load data from the database for validation. > On 6 Oct 2017, at 16:13, Guillaume Smet wrote: > > Hi, > > A user of Hibernate Validator reported an interesting case here: > https://hibernate.atlassian.net/browse/HV-1489 . > > The fact is that a method implemented in WebLogic is suboptimal but I > think there is an interesting point here anyway. > > In the spec, we say that when we find a JPA implementation in the > classpath, we enable the JPATraversableResolver. This adds an overhead > even for unmanaged entities as there is no way to tell if an object is > a managed entity or a plain bean. > > In EclipseLink, they override the traversable resolver in the context > when validating the object on persist and I think it might be good > idea: their JPA resolver is only used when persisting entities and > when other objects are validated, the default traversable resolver is > used - in the case of our user, it uses our JPATraversableResolver > which leads to the issue he reported. > > There is another advantage to this approach: the TraversableResolver > is in the JPA implementation so it can use optimized calls to internal > classes, instead of relying on the JPA API. > > The problem with such an approach is that the user can't override the > traversable resolver set by the JPA provider. > > There is another trade-off: if the user tries to validate an entity > outside of the JPA persist listener, it won't use the specific JPA > resolver. > > I wasn't there when this section was added so I'm not sure what was > exactly the rationale for it. > > I think we might have underestimated the overhead of our approach. We > have a cache but the cache is per validation call so if you end up > validating each object only once per call (and it's probably the most > common case), the cache doesn't bring anything to you (except an > additional overhead). > > -- > Guillaume > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From guillaume.smet at gmail.com Mon Oct 9 10:24:48 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Oct 2017 16:24:48 +0200 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> References: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> Message-ID: OK so we can't really do anything about it. I tuned HV to be a bit more efficient and avoid an additional cache lookup on cascade with the JPA TraversableResolver (the isCascadable() method always returns true so we don't need to cache it). It might be a good idea to discuss with the ORM people to see if we can be a bit more efficient in the Hibernate case. There is a TODO in our code about introducing some specific optimizations. -- Guillaume On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard wrote: > The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. > It would become a very big overhead to load data from the database for validation. From emmanuel at hibernate.org Mon Oct 9 11:00:08 2017 From: emmanuel at hibernate.org (Emmanuel Bernard) Date: Mon, 9 Oct 2017 17:00:08 +0200 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: References: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> Message-ID: <81F14329-1BF5-4FC9-8A59-6DF9753D92BF@hibernate.org> If you can detect that this is not an entity class, then you could cache this information in a bounded cache (weak key). It should help a lot. But I don't think PersistenceUtil has such API and if you use Hibernate specific APIs, you are never guaranteed than you are the only JPA provider in the classpath unless you look for them or the app server tells you. Tricky optimisation. > On 9 Oct 2017, at 16:24, Guillaume Smet wrote: > > OK so we can't really do anything about it. > > I tuned HV to be a bit more efficient and avoid an additional cache > lookup on cascade with the JPA TraversableResolver (the isCascadable() > method always returns true so we don't need to cache it). > > It might be a good idea to discuss with the ORM people to see if we > can be a bit more efficient in the Hibernate case. There is a TODO in > our code about introducing some specific optimizations. > > -- > Guillaume > > On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard > wrote: >> The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. >> It would become a very big overhead to load data from the database for validation. > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev From guillaume.smet at gmail.com Mon Oct 9 11:44:17 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Mon, 9 Oct 2017 17:44:17 +0200 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: <81F14329-1BF5-4FC9-8A59-6DF9753D92BF@hibernate.org> References: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> <81F14329-1BF5-4FC9-8A59-6DF9753D92BF@hibernate.org> Message-ID: Yes, the PersistenceUtil API is pretty basic and you can't do much about that. And you're right about Hibernate not being the only JPA provider in the classpath. I didn't think of this case. What would be possible is to do what WebLogic did ie have a specific TraversableResolver when the validation is triggered by ORM directly. It wouldn't help the case of the other validation calls though. On Mon, Oct 9, 2017 at 5:00 PM, Emmanuel Bernard wrote: > If you can detect that this is not an entity class, then you could cache this information in a bounded cache (weak key). It should help a lot. But I don't think PersistenceUtil has such API and if you use Hibernate specific APIs, you are never guaranteed than you are the only JPA provider in the classpath unless you look for them or the app server tells you. Tricky optimisation. > >> On 9 Oct 2017, at 16:24, Guillaume Smet wrote: >> >> OK so we can't really do anything about it. >> >> I tuned HV to be a bit more efficient and avoid an additional cache >> lookup on cascade with the JPA TraversableResolver (the isCascadable() >> method always returns true so we don't need to cache it). >> >> It might be a good idea to discuss with the ORM people to see if we >> can be a bit more efficient in the Hibernate case. There is a TODO in >> our code about introducing some specific optimizations. >> >> -- >> Guillaume >> >> On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard >> wrote: >>> The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries. >>> It would become a very big overhead to load data from the database for validation. >> _______________________________________________ >> 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 From gunnar at hibernate.org Wed Oct 18 06:04:13 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Wed, 18 Oct 2017 12:04:13 +0200 Subject: [bv-dev] TraversableResolver and JPA In-Reply-To: References: <31C24C7C-8017-4A96-ADD9-7B06E2F7DE66@hibernate.org> <81F14329-1BF5-4FC9-8A59-6DF9753D92BF@hibernate.org> Message-ID: Seems the best and only thing we could do is to talk with JPA spec folks and suggest to add a method to PersistenceUtil for checking wether a given class is an entity type or not. I'd hope JPA is open for such additions given the move to EE4J :) --Gunnar 2017-10-09 17:44 GMT+02:00 Guillaume Smet : > Yes, the PersistenceUtil API is pretty basic and you can't do much about > that. > > And you're right about Hibernate not being the only JPA provider in > the classpath. I didn't think of this case. > > What would be possible is to do what WebLogic did ie have a specific > TraversableResolver when the validation is triggered by ORM directly. > It wouldn't help the case of the other validation calls though. > > On Mon, Oct 9, 2017 at 5:00 PM, Emmanuel Bernard > wrote: > > If you can detect that this is not an entity class, then you could cache > this information in a bounded cache (weak key). It should help a lot. But I > don't think PersistenceUtil has such API and if you use Hibernate specific > APIs, you are never guaranteed than you are the only JPA provider in the > classpath unless you look for them or the app server tells you. Tricky > optimisation. > > > >> On 9 Oct 2017, at 16:24, Guillaume Smet > wrote: > >> > >> OK so we can't really do anything about it. > >> > >> I tuned HV to be a bit more efficient and avoid an additional cache > >> lookup on cascade with the JPA TraversableResolver (the isCascadable() > >> method always returns true so we don't need to cache it). > >> > >> It might be a good idea to discuss with the ORM people to see if we > >> can be a bit more efficient in the Hibernate case. There is a TODO in > >> our code about introducing some specific optimizations. > >> > >> -- > >> Guillaume > >> > >> On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard > >> wrote: > >>> The reason was to be able to validate entities outside of explicit JPA > calls and not cross the lazy loading boundaries. > >>> It would become a very big overhead to load data from the database for > validation. > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20171018/938a2fd0/attachment.html From guillaume.smet at gmail.com Thu Oct 19 07:10:00 2017 From: guillaume.smet at gmail.com (Guillaume Smet) Date: Thu, 19 Oct 2017 13:10:00 +0200 Subject: [bv-dev] New Bean Validation website Message-ID: Hi all! Just a quick note to inform you that we just published the new Bean Validation website. The blog post has it all: http://beanvalidation.org/news/2017/10/19/new-website/ . As usual, feedback welcome! Note: you might still have the old favicon displayed in your tabs, looks like the browser refreshes it when they want :). -- Guillaume From gunnar at hibernate.org Thu Oct 19 16:25:06 2017 From: gunnar at hibernate.org (Gunnar Morling) Date: Thu, 19 Oct 2017 22:25:06 +0200 Subject: [bv-dev] New Bean Validation website In-Reply-To: References: Message-ID: Great work, Guillaume; thanks a lot! All, slightly related, one thing we wanted to have on the website is a list of publicly available 3rd party Bean Validation constraints. If you are aware of any constraint libraries, could you share them here? Thanks! 2017-10-19 13:10 GMT+02:00 Guillaume Smet : > Hi all! > > Just a quick note to inform you that we just published the new Bean > Validation website. > > The blog post has it all: > http://beanvalidation.org/news/2017/10/19/new-website/ . > > As usual, feedback welcome! > > Note: you might still have the old favicon displayed in your tabs, > looks like the browser refreshes it when they want :). > > -- > Guillaume > _______________________________________________ > 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/20171019/79982104/attachment-0001.html