July 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2218) java.util.ConcurrentModificationException at org.hibernate.pretty.Printer.toString(Printer.java:90)

by rm (JIRA)

java.util.ConcurrentModificationException at org.hibernate.pretty.Printer.toString(Printer.java:90) --------------------------------------------------------------------------------------------------- Key: HHH-2218 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2218 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: Hibernate 3.1.3, spring 2.1.8 on Jboss 4.0.2 with Oracle 10g Reporter: rm Similar issues have been logged since May 2005 and have been marked as 'Fixed' by Gavin especially for Session.toString() related cases. However, I am also facing similar issues in Printer.toString()... The saving grace is that when I set the debug level to INFO, the problem goes away... Am copy/pasting the relevent stacktrace...I have also debugged this on eclipse and the exact location is the call to "new Printer(....)" in AbstractFlushingEventListener.java java.util.ConcurrentModificationException 10:07:28,421 INFO [STDOUT] at java.util.HashMap$HashIterator.nextEntry(HashMap.java:787) 10:07:28,421 INFO [STDOUT] at java.util.HashMap$ValueIterator.next(HashMap.java:817) 10:07:28,421 INFO [STDOUT] at org.hibernate.pretty.Printer.toString(Printer.java:90) 10:07:28,421 INFO [STDOUT] at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:97) 10:07:28,421 INFO [STDOUT] at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:35) 10:07:28,421 INFO [STDOUT] at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:954) 10:07:28,421 INFO [STDOUT] at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1099) 10:07:28,421 INFO [STDOUT] at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) PS: This is my first attempt at logging issues at JIRA. Kindly point out any deficiencies or irregularities in this attempt. -- 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

11 years, 1 month

6
9
0 / 0

[Hibernate-JIRA] Created: (ANN-784) MapBinder.createFormulatedValue() does not honor DB schema name when creating query

by Sven Panko (JIRA)

MapBinder.createFormulatedValue() does not honor DB schema name when creating query ----------------------------------------------------------------------------------- Key: ANN-784 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-784 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.4.0.GA Environment: Hibernate 3.3.0.SP1, PostgresQL 8.3 Reporter: Sven Panko I detected a problem with a ManyToMany mapping using a Map in the following setup: @Entity @Table(name = "entitya", schema = "myschema") class EntityA { ... @ManyToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE }) @MapKey(name = "identifier") @JoinTable(name = "entitya_entityb", schema="myschema", joinColumns = @JoinColumn(name = "entitya_pk"), inverseJoinColumns = @JoinColumn(name = "entityb_pk")) @Cascade( { org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.DELETE_ORPHAN }) @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) private Map<String, EntityB> entityBMap = new HashMap<String, EntityB>(); } @Entity @Table(name = "entityb", schema = "myschema") class EntityB { ... } The SQL generated to load the entityBMap collection contains a subquery in the select clause, which looks like this: select a8.identifier from entityb a8 where a8.pk=entityb0_.entityb_pk (entityb0_.entityb_pk comes from the outer select clause) The problem here is, that entityb in the from clause is not prepended by the schema name "myschema" (the outer query is correctly doing this in the join clause, however). I tracked this down to the createFormulatedValue() method in the MapBinder class; the responsible code snippet is contained in lines 292 - 296: StringBuilder fromAndWhereSb = new StringBuilder( " from " ) .append( associatedClass.getTable().getName() ) //.append(" as ") //Oracle doesn't support it in subqueries .append( " " ) .append( alias ).append( " where " ); associatedClass.getTable().getName() does not return the fully qualified table name, so I think this should look something like this: StringBuilder fromAndWhereSb = new StringBuilder( " from " ); if (associatedClass.getTable().getSchema() != null) { fromAndWhereSb.append(associatedClass.getTable().getSchema()).append('.'); } fromAndWhereSb.append( associatedClass.getTable().getName() ) //.append(" as ") //Oracle doesn't support it in subqueries .append( " " ) .append( alias ).append( " where " ); -- 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

11 years, 1 month

4
3
0 / 0

[Hibernate-JIRA] Created: (HV-373) Investigate XML-based configuration of method-level constraints

by Gunnar Morling (JIRA)

Investigate XML-based configuration of method-level constraints --------------------------------------------------------------- Key: HV-373 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-373 Project: Hibernate Validator Issue Type: Sub-task Components: engine Reporter: Gunnar Morling Assignee: Gunnar Morling Fix For: 4.2.0 -- 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

11 years, 2 months

2
11
0 / 0

[Hibernate-JIRA] Created: (BVAL-199) New convenience methods on Validator: void assertValid(Object o)/assertValidProperty(...)/assertValidValue(...) which throw a runtime ValidationException

by Geoffrey De Smet (JIRA)

New convenience methods on Validator: void assertValid(Object o)/assertValidProperty(...)/assertValidValue(...) which throw a runtime ValidationException --------------------------------------------------------------------------------------------------------------------------------------------------------- Key: BVAL-199 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-199 Project: Bean Validation Issue Type: New Feature Components: spec-general Affects Versions: 1.0 final Reporter: Geoffrey De Smet 90% of the time we want to do: {code} Set<ConstraintViolation<Car>> constraintViolations = validator.validate(car); if (constraintViolations.size() > 0) { throw new MyValidationException(decentErrorMessage); } {code} >From http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single... So why not supply a facade method to make it easy for us developers (especially those migrating from hibernate validator 3)? {code} validator.assertValid(car); {code} That allows the bean validation to standarize the Exception too: a ValidationException (or InvalidStateException or whatever you call it), which is of course a runtime exception. That in turn, allows the front-end frameworks to deal with that exception more cleanly (give the user a clue why the business method failed when it imported that address without a street from an import addresses file). Give special care to the message of that exception. It should clearly state at least 1 of the validations that failed (in english, not i18n) so when we find such an exception in the log we can easily see what caused it. -- 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

11 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (BVAL-225) JSR303 1.1: support resource bundles in constraint annotation packages

by Gabriele Del Prete (JIRA)

JSR303 1.1: support resource bundles in constraint annotation packages ---------------------------------------------------------------------- Key: BVAL-225 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-225 Project: Bean Validation Issue Type: Improvement Affects Versions: 1.1 Reporter: Gabriele Del Prete Attachments: ResourceBundleMessageInterpolator.java (I published this same proposal also on the forum, and copying it here so that it does not get lost) This is a proposal for the new version of JSR 303 (v1.1 ?). The proposal is: modify the default message interpolation algorithm (section 4.3.1.1) so that the validation engine looks for a Resource Bundle called "ValidationMessages" in the constraint annotation's own package. For example, when validating constraint annotation com.gdpcons.constraints.MustEqual, validator should also look for messages in a resource bundle called com.gdpcons.constraints.ValidationMessages. The constraint annotation package ValidationMessages resource bundle should be checked after the "user" ValidationMessages resource bundle, but before the BeanValidation provider's own private ValidationMessages resource bundle, so as to allow users to override the string provided by the constraint annotation resource bundle. This would allow people to write redistributable collections of constraint annotations, since as of today it's not possible to use multiple ValidationMessages resource bundles files (one will override all the others in the classpath); and it would still allow users to override the provided messages just by a new definition for the message key in their own ValidationMessages resource bundle. I've written an example implementation, by modifying Hibernate Validator's own ResourceBundleMessageInterpolator. It seams to work without side effects, and is a very straightforward implementation. See it attached to this issue. -- 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

11 years, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-735) Create a test for HSEARCH-734

by Sanne Grinovero (JIRA)

Create a test for HSEARCH-734 ----------------------------- Key: HSEARCH-735 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-735 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.5 Preventing the NPE reported as HSEARCH-734 was trivial, but we are missing a test for it. -- 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

11 years, 2 months

1
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-209) Upload schema where they are due

by Emmanuel Bernard (JIRA)

Upload schema where they are due -------------------------------- Key: BVAL-209 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-209 Project: Bean Validation Issue Type: Bug Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik Like http://java.sun.com/xml/ns/javaee/ we should have http://jboss.org/xml/ns/javax/validation/configuration should point to a descriptive html page. This page pointing to validation-configuration-1.0.xsd http://jboss.org/xml/ns/javax/validation/mapping should point to a descriptive html page. This page pointing to validation-mapping-1.0.xsd -- 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

11 years, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-211) Consider making javax.validation.ValidatorContext a self-referential generic type

by Gunnar Morling (JIRA)

Consider making javax.validation.ValidatorContext a self-referential generic type --------------------------------------------------------------------------------- Key: BVAL-211 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-211 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.0 final Reporter: Gunnar Morling Priority: Minor It should be investigated whether the interface javax.validation.ValidatorContext could be re-defined as self-referential generic type as follows: {code:java} public interface ValidatorContext <V extends ValidatorContext<V>> { V messageInterpolator(MessageInterpolator messageInterpolator); V traversableResolver(TraversableResolver traversableResolver); V constraintValidatorFactory(ConstraintValidatorFactory factory); Validator getValidator(); } {code} Provider-specific extensions of this interface (such as [HibernateValidatorContext|https://github.com/hibernate/hibernate-validato...]) then wouldn't have to re-define all of ValidatorContext's methods returning their own type (which they currently must do in order to allow for the method chaining pattern to work correctly). Generally this is a breaking change, as existing implementations wouldn't compile with the proposed new version of the interface. But as it is intended to be implemented by BV providers only, this seems acceptable. API users would get a raw type warning if they have variables of type ValidatorContext. This should happen very rarely though, as ValidatorContext typically is only used in chained method calls (with a final getValidator() invocation) but not assigned to a variable. -- 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

11 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-222) Add a ALL group to validate all groups instead of DEFAULT or the selected ones

by Emmanuel Bernard (JIRA)

Add a ALL group to validate all groups instead of DEFAULT or the selected ones ------------------------------------------------------------------------------ Key: BVAL-222 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-222 Project: Bean Validation Issue Type: New Feature Components: spec-general Reporter: Emmanuel Bernard Gerhard #2 it would be nice to have #validateAll or a group called javax.validation.groups.All to validate all groups without knowing the concrete groups. Emmanuel What's the use case they were invoking? ( my favorite mantra :) ) Gerhard i think it was just: if you are using groups for partial validation you might have a wizard and in every step you validate with a different group and they needed the concept instead of collecting all groups manually (e.g. in the service which finally saves the new entry) -> they requested an api for validating every constraint which is available in the given object-graph -> the service can perform a full validation before it processes the data. -- 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

11 years, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-234) Netbeans 7 default generated entity classes conflict with bean validation

by Richard Clarke (JIRA)

Netbeans 7 default generated entity classes conflict with bean validation -------------------------------------------------------------------------- Key: BVAL-234 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-234 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1 Environment: Netbeans 7, Seam 3 under JBOSS AS 7 Reporter: Richard Clarke Priority: Minor When using NetBeans 7 to generate entity classes from a database table, the entity classes are generated with the following annotations... public class Orders implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Basic(optional = false) @NotNull @Column(name = "orderid") private Integer orderid; ..... When persisting, bean validation fails because the autogenerated primary key is null at the time the object is persisted. Netbeans have stated that they wont fix this as they see it as bean validation issue rather than their generated classes. See here: http://netbeans.org/bugzilla/show_bug.cgi?id=197845 Related Forum posting is here... https://forum.hibernate.org/viewtopic.php?f=9&t=1011908 Suggest modifying Bean Validation Pre-Persist to ignore @NotNull if @GeneratedValue exists. Thanks Rich -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

4
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2011