Java EE Parameter Constraint Configuration strange behaviour

Question

Im trying to add a parameter constraint configuration (a bean validation) on the create and edit method of the standrd AbstractFacade (as generated by NetBeans).

So I tried:

@Override
public void create(@WkTeilnahmePlanedResult  WkTeilnahme entity) {
   super.create(entity);
}

This returned the message

A method overriding another method must not alter the parameter constraint configuration when deploying it to Glassfish 4

So next try was

  @Override
  public void create(WkTeilnahme entity) {
    checkedCreate(entity);
  }


  private void checkedCreate(@WkTeilnahmePlanedResult WkTeilnahme entity) {
    super.create(entity);
  }

which deploys without any problems ... but the validator is never called.

Can you tell me why?

BTW:

  @Override
  public void create(WkTeilnahme entity) {
    throw new UnsupportedOperationException(
            "Create not supported! Use checkedCreate() instead!");
  }


  public void checkedCreate(@WkTeilnahmePlanedResult WkTeilnahme entity) {
    super.create(entity);
  }

This works but isn't really very cool!

Answer 1

Regarding your first attempt, it does not work, because Bean Validation constraints must follow the Liskov Substitution Principle. See also the relevant Bean Validation specification section - http://beanvalidation.org/1.1/spec/#constraintdeclarationvalidationprocess-methodlevelconstraints-inheritance

From the specification:

Very informally speaking, the Liskov substitution principle says that where a given type T is used, it should be possible to replace T with a sub-type S of T ("Behavioral subtyping"). If S overrides/implements a method from T and S would strengthen the method's preconditions (e.g. by adding parameter constraints) this principle would be violated as client code working correctly against T might fail when working against S. Also if S overrides/implements a method from T and S weakens the method's postconditions this principle would be violated. However S may strengthen the method's postconditions (by adding return value constraints), as client code working against T still will work against S.

I think your second example should actually work, however, I am not familiar with the NetBeans AbstractFacade. My guess is that the call to checkedCreate(entity); is not going via a proxies instance and hence is not intercepted. Maybe you could post the full code for the involved classes? What type of class contains these methods? A session bean?

Answer 2

I faced the same problem.

My code was like this:

public interface SomeService{
    List<Object> getObjects(Integer id);
}

public class SomeServiceImpl implements SomeService{
    @Override
    public List<Object> getObjects(@NotNull Integer id) { ... }
}

I added the same annotation to the service and the problem has been soled:

public interface SomeService{
    List<Object> getObjects(@NotNull Integer id);
}