November 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-35) constraintDescriptor.getConstraintImplementation() is no longer there

by Emmanuel Bernard (JIRA)

constraintDescriptor.getConstraintImplementation() is no longer there --------------------------------------------------------------------- Key: BVAL-35 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-35 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Should we call the ConstraintFactory each time we need an implementation? factory.getInstance( descrptor.getConstraintClass() ); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (BVAL-70) default MessageResolver is instanciated in Validator<T>, it should not

by Emmanuel Bernard (JIRA)

default MessageResolver is instanciated in Validator<T>, it should not ---------------------------------------------------------------------- Key: BVAL-70 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-70 Project: Bean Validation Issue Type: Improvement Components: ri-general Reporter: Emmanuel Bernard Seems to be a left over from a previous life. The default MR is instanciated by the VFBuilder and passed to the VF. That's the only area it should be instanciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-2) Is there a difference between the implicit default group given by {} and the explcitly specified group "default"?

by Hardy Ferentschik (JIRA)

Is there a difference between the implicit default group given by {} and the explcitly specified group "default"? ----------------------------------------------------------------------------------------------------------------- Key: BVAL-2 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-2 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Hardy Ferentschik The question is why is the the default value for groups not "default" instead of the empty array? I think the it would be more explicit to use "default". Also if I do not specify a group and hence the default (empty array) applies, what does the corresponding ConstraintDescriptor.getGroups() return? An empty array or "default"? Or are we saying that the default group is to be treated separately from the explicitly specified group 'default'? Emmanuel's reasoning behind the empty array was to keep it simple for annotation developers, one less thing to remember and typo to do. However, if we decide to treat the empty array and "default' the same way, I would opt for a explicit "default" string. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-18) Validator<A>.validate(b) where b:B and B extends A should validate B. Metadata APIs are specific to A

by Emmanuel Bernard (JIRA)

Validator<A>.validate(b) where b:B and B extends A should validate B. Metadata APIs are specific to A ----------------------------------------------------------------------------------------------------- Key: BVAL-18 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-18 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-27) Avoid the use of raw types including in the test suite as much as possible

by Emmanuel Bernard (JIRA)

Avoid the use of raw types including in the test suite as much as possible -------------------------------------------------------------------------- Key: BVAL-27 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-27 Project: Bean Validation Issue Type: Improvement Components: ri-general Reporter: Emmanuel Bernard eg ValidatorBuilder rather than ValidatorBuilder<?> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-16) Has the property passed to validator.validateProperty() be reachable by a valid chain of validation.

by Hardy Ferentschik (JIRA)

Has the property passed to validator.validateProperty() be reachable by a valid chain of validation. ---------------------------------------------------------------------------------------------------- Key: BVAL-16 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-16 Project: Bean Validation Issue Type: Task Components: ri-general, spec-general Reporter: Hardy Ferentschik if you do something like this validateProperty( foo, "prop1.prop2.prop3[3]" ), does this imply that the whole chain is validated? One could just get the value/class for prop[3] and see if there are any validations defined on it or you could actually traverse the whole path and also ensure that prop1 and prop2 are annotated with @Valid. To put it differently, has the property to validated be reachable via a valid 'validation chain'? Somehow it feels to be the right thing to do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-10) Turn ValidatorParser into a MetadataProvider

by Emmanuel Bernard (JIRA)

Turn ValidatorParser into a MetadataProvider -------------------------------------------- Key: BVAL-10 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-10 Project: Bean Validation Issue Type: New Feature Components: ri-general Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik You should turn parser into something more like a MetadataProvider. I removed the getValidators() method from parser and moved it to ValidatorImpl. The parser should not be aware of ValidatorImpl, nor Validator for that matter. The MetadataProvider will be an interface anybody can implement. We will do the annotation version as well as the XML version (and probably some kind of XML overriding annotation version) but one can imagine a Script / Groovy DSLed version, a Programmatic API version and so on. I imagine a MetadataProvider instance can be passed during the building phase to the ValidatorFactory. The same instance would then be shared for all Validators (kind of make sense, you can't parse XML for every single ValdiatorImpl instantiation). That woul mean the parser ode needs ot be reworked to be immutable (at least work in concurrent calls) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-31) Constraint composition

by Emmanuel Bernard (JIRA)

Constraint composition ---------------------- Key: BVAL-31 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-31 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3357) session.clear() takes too long

by Jay Erb (JIRA)

session.clear() takes too long ------------------------------ Key: HHH-3357 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3357 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.6, 3.2.5 Reporter: Jay Erb Clearing a session that contains a large number of Proxies takes a very long time. The reason for this is that null is set on the LazyInitializer when clearing the StatefulPersistenceContext, whenever a new session is set on an AbstractLazyInitializer, a check is done to see if the AbstractLazyInitializer is still attached to its previous session (and correctly throws an exception if it is). This check performs a linear search through all Proxies in the PersistenceContext. Since we're setting the session to null, do we really need to do this expensive linear search? I propose we not perform the linear search if the session being set on the AbstractLazyInitializer is null. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

5
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-151) Use IndexWriter.autocommit false if Lucene 2.3 is used

by Emmanuel Bernard (JIRA)

Use IndexWriter.autocommit false if Lucene 2.3 is used ------------------------------------------------------ Key: HSEARCH-151 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-151 Project: Hibernate Search Issue Type: New Feature Reporter: Emmanuel Bernard -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2008