forwarding this email to hibernate-dev to get some more feedback.
Here are some of my thoughts. The method level validation is suggested in
Appendix C of the Bean Validation specification. The method signatures
there all return a set of ConstraintViolations.
The question is how binding these signatures are.
Root bean and property path are indeed questionable for method level
validation. By extending ConstraintViolation you still have to deal with
these values. Maybe instead of
extending we should have a new interface MethodConstraintViolation.
Emmanuel, do you have some more feedback on what was discussed regarding
------- Forwarded message -------
From: "Gunnar Morling" <gunnar.morling(a)googlemail.com>
To: "Hardy Ferentschik" <hibernate(a)ferentschik.de>
while working on method-level validation I wondered how to represent the
failing validation of method parameters. I think
javax.validation.ConstraintViolation in its current form is only partly
suitable for the needs of parameter/return value validation:
* The concept of property path seems not to fit right. How would the
property path look for a failing parameter constraint? One could come up
with something like "MyBean.MyMethod(String,Int).Parameters" but I
can't say I'd like that
* The concept of a root bean does only fit partly. I think one would need
a safe reference to the "root method" and the parameter index. A direct
reference to the class hosting the validated method seems only partly
useful (and could anytimes be retrieved from a Method reference).
I therefore prototyped this into this direction:
* Created a MethodConstraintViolation that extends ConstraintViolation by
adding fields the causing method and the parameter index (one surely would
add a flag or something in case of return value validation)
* In case a constraint directly at one of a method's parameters fail,
ConstraintViolation#rootBean and propertyPath are null (but method and
parameterIndex are set)
* In case a "cascading" constraint fails (meaning in this context, a
parameter is annotated with @Valid and the referenced bean has constraints
itself which in turn fail), method and parameterIndex are set, rootBean
and propertyPath refer to parameter bean itself, *not* the class hosting
the validated method
WDYT, is this the right way to go? Maybe we should brainstorm a bit on IRC?
After some tries, here's my workflow for applying commits from the 3.6 branch to the master branch:
1. Commit to 3.6 :)
2. Create patches for the commits using git format-patch commit sha/range etc. This will produce numbered patches.
3. Switch to master
4. Modify the patches using the following script:
for file in $*
sed 's/\/envers\//\/hibernate-envers\//' < $file > mod_$file
(substitute envers with the appropriate module)
5. Apply the patches using git am <file>
Not very straightforward, but works. And maybe somebody will find a better way :)
it seems we failed to properly warn users to use the new Solr packages
you prepared ;
I was going to open an issue for this to hopefully have it included in
the release, but it seems
I'm too late to mark it for the release of monday.
Could you please reopen and add a warning in the docs before releasing it?
I hope it's possible as it seems quite critical, otherwise please
mention it in the release
1 - https://forum.hibernate.org/viewtopic.php?f=9&t=1007904
how to perform integration test of Hibernate core on the db matrix or on another db instead of the default H2?
is it possible on the master codebase? i know steve were working on it some time ago, but can't find anything in the current source.
On 26 oct. 2010, at 15:17, Kiran Narasareddy wrote:
> BTW, is there some doc or some architecture design reading which can help me understand the flow, code better?
We might have some on the wiki ( http://community.jboss.org/en/hibernate ) but generally no, there is no architectural documentation. We believe in the code being the doc. And the benefit is that it's always up to date :)
That being said, Hibernate Core and Search have an architecture section in their reference documentation to understand how the big blocks relate to each other.
> I did clone the git repo of hibernate core, but couldn't import it into eclipse ('gradle eclipse' didn't work n couldn't find pom.xml for hibernate core ) .
Hibernate master is using Gradle whereas the legacy branches use Maven.
That being said, I imagine that gradle eclipse thingy should work. Can you jump on IRC (freenode #hibernate-dev) to speed up the trial-fix process. We should get this fixed and are working on it in several fronts.
> Will clone the Hibernate search repo now.It's using maven right?
yes we use maven
> Coz the hibernate core main repo is using gradle and I messed up with that.
> Kiran Narasareddy
I am very much interested in contributing to the Hibernate Community.
Steve asked me to introduce myself on the dev mailing list, so here I am..
I am Kiran Narasareddy (21 yrs). I live in Pune, Maharashtra, India. I
completed my BTech in Information Technology, this May from College Of
Engineering, Pune (COEP) <http://www.coep.org.in>, one of the Top
Premier Engineering Colleges in India.
I am Java Developer, working extensively in Java for the past 2 years.
I am part of a StartUp, namely Amura Marketing Technologies Pvt.
I (along with my batchmates) started it in March last year. We are a
Internet Marketing / Products company. Some of our products include CRM
(built from scratch), Live Chat tool.
About Me :
Well, JAVA is my first love. I love Cars(my suzuki swift), am a gadget
freak, and love exploring apis in my free-time. I also work in Ruby with
Rails, as and when needed.
Amura Marketing Technologies Pvt. Ltd.
www.amuratech.com | @knarasareddy <http://twitter.com/knarasareddy>