Update 4.0.2.GA to 4.1.0.Final - problem with GroupsType API

lobomcduck · **Joined:** Tue Aug 24, 2010 3:56 am **Posts:** 8

We implemented the hibernate framework (hibernate-validator-4.0.2.GA.jar) in our system and we can create constraints and inject them on runtime into the validation framework per XML. Below the code fragment where we create the GroupsType:

Code:

GroupsType groupsType = new GroupsType();
for (final ConstraintGroupModel cgm : source)
{
     groupsType.getValue().add(new JAXBElement<String>( //
               new QName("http://jboss.org/xml/ns/javax/validation/mapping", "value"), //  
               String.class, // 
               constraintDao.getTargetClass(cgm).getName()));
}

With (hibernate-validator-4.1.0.Final.jar) the method signature for groupsType.getValue().add(...) changed. Instead of JAXBElement, now Strings are valid.

See:
API GroupsType 4.0.1
API GroupsType 4.1

Question:
What should I now add to the list? The class name of the group?

This would be the example as annotation in a java class:

Code:

 @Max( value = 3, groups = MyGroup.class )
 int myValue = 0;

What should I use now as String for groupsType.getValue().add(String) ?
"MyGroup" or "MyGroup.class"? Or something like "value = MyGroup.class" ?

Gunnar · **Joined:** Sat Jan 24, 2009 12:46 pm **Posts:** 388

Now that's an interesting use case. If I understand right, you are trying to add constraints to your model dynamically on the fly? Have you checked out the new programmatic constraint API introduced with HV 4.1 already? This might be helpful for you, as you can use it to add constraints in a pretty type-safe way as in the following example:

Code:

ConstraintMapping mapping = new ConstraintMapping();

mapping
    .type(Order.class)
        .property("customer", ElementType.FIELD)
            .constraint(NotNullDef.class)
            .groups(MyGroup.class)
        .property("orderLines", ElementType.FIELD)
            .constraint(SizeDef.class)
                .min(1)
                .message("An order must contain at least one order line")
    .type(Customer.class)
        .property("name", ElementType.FIELD)
            .constraint(NotNullDef.class); 

AFAICS the JAXB types are primarily generated for parsing XML constraint mapping files in HV, though using them for creating such files is an interesting idea, too. The change of the generated types is caused by HV-272, part of which was an update of the JAXB version used.

To answer you question: within XML files groups must be specified using their fully-qualified class name, as outlined in the BV spec section 7.1.3. ("Converting the string representation of a value"). But please note, that the JAXB types are currently not considered as part of HV's public API, so changes as the one you reported are not too likely but might happen at any time.

If you decide to give the programmatic API a try I'd be very interested in your feedback :-)

lobomcduck · **Joined:** Tue Aug 24, 2010 3:56 am **Posts:** 8

Gunnar wrote:

Code:

ConstraintMapping mapping = new ConstraintMapping();

mapping
    .type(Order.class)
        .property("customer", ElementType.FIELD)
            .constraint(NotNullDef.class)
            .groups(MyGroup.class)
        .property("orderLines", ElementType.FIELD)
            .constraint(SizeDef.class)
                .min(1)
                .message("An order must contain at least one order line")
    .type(Customer.class)
        .property("name", ElementType.FIELD)
            .constraint(NotNullDef.class); 

If you decide to give the programmatic API a try I'd be very interested in your feedback :-)

Some thoughts about that:

In our system the user can create (on runtime) different products and also different constraints. As an example, first lots of products are added and afterwards the user add a MinConstraint to the attribute code for type product . After saving the min constraint the following code is (will be) executed

Code:

ConstraintMapping mapping = getConstraintMappingFromSomewhere();
mapping.type(currentConstraint.getType())
              .property(currentConstraint.getQualifier(), ElementType.FIELD)
              .constraint(currentConstraint.getAnnotationClass());

So far, so nice. This fragment also works wenn adding another constraint to the same class.
But what when the user want to modify or remove an existing one?

I think first I have to get all defined constraints with

Code:

Class clazz = getClassWhereTheConstraintsAreDefined();
List constraintsOfTheGivenType = mapping.getConstraintConfig().get(clazz);

and then find and modify the constraint.
What I miss (or didn't find yet) in an easy access to defined constraints. Nevertheless the validation framework is (always) reloaded after modifying any constraints.

On a additional thought I'll convert somehow our constraint types into a ConstraintDef object. :)