Re: [hibernate-dev] Branch 3.3 build fails
I see this failure off-and-on as well. IIRC it has to do with that test not properly cleaning up after itself. I've never been able to pinpoint the exact cause in order to fix it - Steve Ebersole Project Lead http://hibernate.org st...@hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebers...@jboss.com steve.ebers...@redhat.com On Thu, 2009-01-22 at 10:57 -0800, Steve Kuo wrote: > I'm trying to build branch 3.3 using Maven and Java 1.5. I've followed the > Maven build instructions (http://www.hibernate.org/422.html) exactly. When I > build it fails on: > > Results : > > Tests in error: > > testSessionFactoryCreationTime(org.hibernate.test.cfg.ConfigurationPerformanceTest) > > Tests run: 1402, Failures: 0, Errors: 1, Skipped: 0 > > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] There are test failures. > > Am I missing something? > Thanks, Steve > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [UPDATED] implement criteria API query of collection-of-components and collection-of-values
Hi,
Although I've gotten feedback that this won't necessarily be included
as-is, or against current versions etc., since I have to update it as I
track newer Hibernate core versions (we use this modification
internally), I figure it might be of use or interest to the dev.
community.
This is the updated patch, against 3.3.1GA
Changes from last time include:
* rediffed against 3.3.1
* change to slf4j for logging
* fix the crude hack in CriteriaJoinWalker to what seems to be the
correct implementation. The issue here is complicated and not-at-all
understood by me completely.
The method in question, generateTableAlias, seems to do (at least) two
things in the CriteriaJoinWalker, one of which is to update the internal
'userAlias' list based on whether the Joinable 'consumesEntityAlias'.
This behavior needed to remain completely unmodified, which my previous
patch did not do. However, the reason I needed to modify this is that
some Joinables which DO NOT 'conumeEntityAlias' still need to provide an
SQL alias for the table.
Deciding which ones, exactly, need to do this was complicated, and I'm
not sure this is currently correct.
However, it now passes the test suite, which it didn't before.
Thanks,
David
diff --exclude='*~' --exclude='*.orig' -ru hibernate-distribution-3.3.1.GA.orig/project/core/src/main/java/org/hibernate/hql/ast/util/SessionFactoryHelper.java hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/hql/ast/util/SessionFactoryHelper.java
--- hibernate-distribution-3.3.1.GA.orig/project/core/src/main/java/org/hibernate/hql/ast/util/SessionFactoryHelper.java 2008-09-10 14:19:59.0 -0400
+++ hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/hql/ast/util/SessionFactoryHelper.java 2009-01-16 15:40:27.0 -0500
@@ -235,7 +235,7 @@
* @param role The collection role for whcih to retrieve the property mapping.
* @return The property mapping.
*/
- private PropertyMapping getCollectionPropertyMapping(String role) {
+public PropertyMapping getCollectionPropertyMapping(String role) {
return ( PropertyMapping ) collectionPropertyMappingByRole.get( role );
}
Only in hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/loader/criteria: ComponentCollectionCriteriaInfoProvider.java
Only in hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/loader/criteria: CriteriaInfoProvider.java
diff --exclude='*~' --exclude='*.orig' -ru hibernate-distribution-3.3.1.GA.orig/project/core/src/main/java/org/hibernate/loader/criteria/CriteriaJoinWalker.java hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/loader/criteria/CriteriaJoinWalker.java
--- hibernate-distribution-3.3.1.GA.orig/project/core/src/main/java/org/hibernate/loader/criteria/CriteriaJoinWalker.java 2008-09-10 14:19:59.0 -0400
+++ hibernate-distribution-3.3.1.GA/project/core/src/main/java/org/hibernate/loader/criteria/CriteriaJoinWalker.java 2009-01-20 10:04:51.0 -0500
@@ -40,11 +40,15 @@
import org.hibernate.persister.entity.Joinable;
import org.hibernate.persister.entity.OuterJoinLoadable;
import org.hibernate.persister.entity.Queryable;
+import org.hibernate.persister.collection.CollectionPersister;
import org.hibernate.type.AssociationType;
import org.hibernate.type.Type;
import org.hibernate.type.TypeFactory;
import org.hibernate.util.ArrayHelper;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
/**
* A JoinWalker for Criteria queries.
*
@@ -52,6 +56,7 @@
* @author Gavin King
*/
public class CriteriaJoinWalker extends AbstractEntityJoinWalker {
+private static final Logger logger = LoggerFactory.getLogger(CriteriaJoinWalker.class);
//TODO: add a CriteriaImplementor interface
// this class depends directly upon CriteriaImpl in the impl package...
@@ -175,19 +180,48 @@
( (Queryable) getPersister() ).filterFragment( getAlias(), getEnabledFilters() );
}
- protected String generateTableAlias(int n, String path, Joinable joinable) {
- if ( joinable.consumesEntityAlias() ) {
- final Criteria subcriteria = translator.getCriteria(path);
- String sqlAlias = subcriteria==null ? null : translator.getSQLAlias(subcriteria);
- if (sqlAlias!=null) {
-userAliasList.add( subcriteria.getAlias() ); //alias may be null
-return sqlAlias; //EARLY EXIT
+ protected String generateTableAlias(int n, String path, Joinable joinable) {
+ logger.debug("generateTableAlias n="+n+" path="+path+" joinable="+joinable);
+
+ // it's complicated as to when to return the sqlAlias designated by the 'path'.
+ // the issue is that for a collection-of-entity, the walker navigates the same
+ // path twice, once for the collection, once for the entity. the Joinable will
+ // be different for each, and the collection Joinable (probably a BasicCollectionPersister)
+ // will _NOT_ consume the alias, and also should _NOT_ assign an SQL alias.
+ // the second
[hibernate-dev] [Bean Validation] Type-safe Validator and resolution algorithm
Today, ConstraintValidator accepts Object and the implementation is
responsible for handling the casting and raise an exception if the
type is not supported.
The idea is to get type-safe validator and a discovery mechanism to
associate a validator to a given runtime type being validated. The
resolution is not 100% complete, you might end up with:
- no valid validator
- no way to decide between two or more validators
and get exceptions at runtime.
I would really like feedback on it as we could arrange some of these
rules to not fail (at least in the latter case):
- do we want this type-safe + auto resolution algorithm strategy or
should we stick with the untyped solution
- do we want to fail in case of ambiguity or rather choose the first
compatible provider?
Personally I find the feature quite elegant and the metadata can be
used by tools to warn a user if a constraint does not match the static
type it is applied on.
API and declaration
A more typesafe proposal would be:
public interface ConstraintValidator {
void initialize(A annotation);
boolean isValid(T object, ConstraintValidationContext context);
}
public class StringSizeValidator implements ConstraintValidatorString> {
...
}
public class CollectionSizeValidator implements
ConstraintValidator {
...
}
public class MapSizeValidator implements ConstraintValidatorMap> {
...
}
public class ArraySizeValidator implements ConstraintValidatorObject[]> {
...
}
@Constraint(validatedBy={
StringSizeValidator.class, CollectionSizeValidator.class,
MapSizeValidator.class, ArraySizeValidator.class} )
public @interface Size { ... }
We then need to decide at runtime, which validator needs to be executed.
Here is a proposed algorithm heavily based on the Java Language
Specification (boy it's hard to read it).
Resolution algorithm
The type T of a ConstraintValidator must not make direct use of
generics itself.
This is because the algorithm compare the actual type at runtime and
such notion would be lost. So you can do ConstraintValidatorCollection> but not ConstraintValidator>.
For a given runtime object t of type T about to be validated for a
given constraint:
if t is null the first validator in the array of available validators
is used.
otherwise
A validator accepting U is said to be compliant with the type T if T
is a subtype of U according to the JLS chapter 4.10.
If no compliant validator is found for T, a
UnexpectedTypeForConstraint exception is raised.
If a validator is taking the responsibility to dispatch types (ie
ConstraintValidator), it must use the same exception in
the same circumstances.
If one compliant validator is found, it is used.
If more than one compliant validator is found, the one with the most
specific parameter is used. The informal intuition is that one
parameter is more specific than another if any assignment handled by
the first parameter could be passed on to the other one without a
compile-time type error.
Of a given type T, a compliant validator accepting U is considered
maximally specific if no other T compliant validator accepting V is
such as V is a strict subtype of U. String subtype is defined by JSL
chapter 4.10.
If more than one maximally specific validator is found, a
AmbiguousValidatorException is raised.
WDYT?___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
