February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7081) "Second pass" information can get lost during configuration if a component has a nested component, leading to ConcurrentModificationException during configuration.

by Philip Newton (JIRA)

"Second pass" information can get lost during configuration if a component has a nested component, leading to ConcurrentModificationException during configuration. ------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-7081 URL: https://hibernate.onjira.com/browse/HHH-7081 Project: Hibernate ORM Issue Type: Bug Components: annotations, core Affects Versions: 3.6.8 Reporter: Philip Newton I have an environment with an entity A which contains a map of components/elements B. Each B has a component C which refers (many-to-one) to an entity D. During configuration and second-pass compile, I get this call sequence: Configuration.originalSecondPassCompile at line 1716 calls MapBinder$1(CollectionSecondPass).doSecondPass doSecondPass at line 65 calls MapBinder$1.secondPass secondPass at line 113 calls MapBinder(CollectionBinder).bindStarToManySecondPass bindStarToManySecondPass at line 710 calls MapBinder(CollectionBinder).bindManyToManySecondPass bindManyToManySecondpass at line 1380 calls AnnotationBinder.fillComponent with parameter inSecondPass := true fillComponent at line 2336 calls AnnotationBinder.fillComponent and passes on inSecondPass := true fillComponent at line 2433 calls AnnotationBinder.processElementAnnotations and passes on inSecondPass := true processElementAnnotations at line 2021 calls AnnotationBinder.bindComponent ----------> the "inSecondPass" information is lost here! bindComponent at line 2285 calls AnnotationBinder.fillComponent with parameter inSecondPass := false fillComponent at line 2336 calls AnnotationBinder.fillComponent fillComponent at line 2433 calls AnnotationBinder.processElementAnnotations processElementAnnotations at line 1600 calls AnnotationBinder.bindManyToOne bindManyToOne at line 2695 checks the value of "inSecondPass", which should be true but is false here due to the value being lost in the call to bindComponent above. It then adds an "FkSecondPass" object with mappings.addSecondPass. When that whole call stack returns to Configuration.originalSecondPassCompile, the call to itr.hasNext() crashes with a ConcurrentModificationException, because the list of second pass items was modified during iteration. If nested components are allowed and if such nested components are allowed to have references to entities, then the "inSecondPass" information may not get lost when the nested component is bound! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7080) Sql translation problem with spring repository

by deng hui (JIRA)

Sql translation problem with spring repository ----------------------------------------------- Key: HHH-7080 URL: https://hibernate.onjira.com/browse/HHH-7080 Project: Hibernate ORM Issue Type: Bug Environment: spring-mvc-3.1.0.RELEASE, spring-data-jpa-1.1.0.SNAPSHOT hibernate-entitymanager-4.0.1.FINAL Reporter: deng hui if we define a spring repository like: {code} public interface OrganizationRepository extends CrudRepository<Organization, Long> { @Query("select o from Organization o where o.name like '?1'") List<Organization> findByNameLike(String pattern); @Query("select o.name from Organization o where o.name like ?1 ") List<String> findCompanyName(String name); } {code} then we call it in a controller: {code} @Controller @RequestMapping("/organization") public class OrganizationController { @Autowired private OrganizationRepository organizationRepository; @RequestMapping(value="/names", method=RequestMethod.GET) public @ResponseBody List<String> getCompanyNameList(@RequestParam String term) { List<String> companyNames=organizationRepository.findCompanyName(term); return companyNames; } } {code} the controller always failed at query parameter translation and we got a debug info as: {code} 2012-02-18 13:20:19,739 DEBUG: select organizati0_.name as col_0_0_ from Organization organizati0_ where organizati0_.name like ? >>> org.hibernate.engine.jdbc.spi.SqlStatementLogger.logStatement(SqlStatementLogger.java:104) Hibernate: select organizati0_.name as col_0_0_ from Organization organizati0_ where organizati0_.name like ? {code} after trace the setup of application I find these 2 queries in repository have already been compiled in advance by class QueryTranslatorImpl as: {code} select organizati0_.id as id7_, organizati0_.createTime as createTime7_, organizati0_.creator_id as creator6_7_, organizati0_.privileges as privileges7_, organizati0_.state_id as state7_7_, organizati0_.updateTime as updateTime7_, organizati0_.updator_id as updator8_7_, organizati0_.manager_id as manager9_7_, organizati0_.name as name7_ from Organization organizati0_ where organizati0_.name like '?1' {code} and {code} select organizati0_.name as col_0_0_ from Organization organizati0_ where organizati0_.name like ? {code} wondering why one *?* and another *?1*, will these debug info show the final sql after parameter translation? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Deleted: (HHH-7077) Introduce LogicalNamingStrategy

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-7077?page=com.atlassian.jira.plug... ] Steve Ebersole deleted HHH-7077: -------------------------------- > Introduce LogicalNamingStrategy > ------------------------------- > > Key: HHH-7077 > URL: https://hibernate.onjira.com/browse/HHH-7077 > Project: Hibernate ORM > Issue Type: New Feature > Reporter: Steve Ebersole > Assignee: Steve Ebersole > > In an effort to tame the legacy NamingStrategy interface, part of that process is to split it up into logical and physical naming strategies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7078) Introduce PhysicalNamingStrategy

by Steve Ebersole (JIRA)

Introduce PhysicalNamingStrategy -------------------------------- Key: HHH-7078 URL: https://hibernate.onjira.com/browse/HHH-7078 Project: Hibernate ORM Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 5.0.0 In an effort to tame the legacy NamingStrategy interface, part of that process is to split it up into logical and physical naming strategies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7077) Introduce LogicalNamingStrategy

by Steve Ebersole (JIRA)

Introduce LogicalNamingStrategy ------------------------------- Key: HHH-7077 URL: https://hibernate.onjira.com/browse/HHH-7077 Project: Hibernate ORM Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole In an effort to tame the legacy NamingStrategy interface, part of that process is to split it up into logical and physical naming strategies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7079) Deprecate NamingStrategy

by Steve Ebersole (JIRA)

Deprecate NamingStrategy ------------------------ Key: HHH-7079 URL: https://hibernate.onjira.com/browse/HHH-7079 Project: Hibernate ORM Issue Type: Deprecation Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 5.0.0 See HHH-7077 and HHH-7078 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7075) Use the term 'composition' to refer to components/embeddables

by Steve Ebersole (JIRA)

Use the term 'composition' to refer to components/embeddables ------------------------------------------------------------- Key: HHH-7075 URL: https://hibernate.onjira.com/browse/HHH-7075 Project: Hibernate ORM Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7050) Add TableSpecification.getLogicalName()

by Gail Badner (JIRA)

Add TableSpecification.getLogicalName() --------------------------------------- Key: HHH-7050 URL: https://hibernate.onjira.com/browse/HHH-7050 Project: Hibernate ORM Issue Type: Task Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7076) Split 'type resolution' back out into separate class

by Steve Ebersole (JIRA)

Split 'type resolution' back out into separate class ---------------------------------------------------- Key: HHH-7076 URL: https://hibernate.onjira.com/browse/HHH-7076 Project: Hibernate ORM Issue Type: Bug Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole the concept of type resolution used to live in a separate class, but was pulled into Binder. It should get split back out again. The difference is that this will simply be a delegate that Binder uses as it processes the attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HV-509) Property path is wrong for cascaded validation of class-level constraints

by Gunnar Morling (JIRA)

Property path is wrong for cascaded validation of class-level constraints ------------------------------------------------------------------------- Key: HV-509 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-509 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0.Final Reporter: Gunnar Morling Fix For: 4.3.0.next If a bean is validated which has a collection-typed member annotated with {{@Valid}} and of a type which itself has a class-level constraint, then the property pathes of the violations of that class-level constraint are wrong. The following shows an example: {code:java} public class FooTest { @ValidFoo private static class Foo {} @Constraint(validatedBy = { ValidFooValidator.class }) @Target({ TYPE }) @Retention(RUNTIME) public @interface ValidFoo { String message() default "{ValidFoo.message}"; Class<?>[] groups() default { }; Class<? extends Payload>[] payload() default { }; } public static class ValidFooValidator implements ConstraintValidator<ValidFoo, Foo> { public void initialize(ValidFoo annotation) {} public boolean isValid(Foo foo, ConstraintValidatorContext context) { return false; } } private static class Bar { @Valid private List<Foo> foos = Arrays.asList(new Foo(), new Foo()); } @Test public void testBar() { Validator validator = Validation.buildDefaultValidatorFactory().getValidator(); Set<ConstraintViolation<Bar>> violations = validator.validate(new Bar()); //fails as pathes currently are "foos[1]", "foos[1]" ConstraintViolationAssert.assertCorrectPropertyPaths(violations, "foos[0]", "foos[1]"); } } {code} The cause seems to be that the same {{PathImpl}} instance is used within both violations. When the 2nd violation is created, the index of the shared {{PathImpl}} instance originally created for the first violation is set from 0 to 1. I think this can be circumvented by creating a copy of the path in the constructor of {{ConstraintValidatorContextImpl}}. Forum reference: https://forum.hibernate.org/viewtopic.php?f=9&t=1011952 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2012