-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 
Author Message
 Post subject: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 1:27 am 
Newbie

Joined: Thu Jul 19, 2007 7:55 pm
Posts: 5
I'm (very) new to JSR303 validation and hibernate validation, basically I don't really know quite what is going on yet :-) Quite excited about the possibilites though being an Eiffel fan from many years ago.

I have a dto class like so

Code:
public final class Identifier implements Serializable
{
    private final String namespace;

    @NotNull
    @Size(min = 1)
    private final String          name;

    public Identifier(String namespace,
                      String name)
    {
        this.namespace = namespace;
        this.name      = name;
    }

    public String getNamespace()
    {
        return namespace;
    }

    public String getName()
    {
        return name;
    }
}


and I use this in a method on a stateless session bean running in jboss 7.1

Code:

@Stateless @LocalBean
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class PatientRecordOperations
{
  ...
    public Identifier addPatient(@NotNull @Valid
                                 Identifier          patientId)
    {
        ...
    }
  ...
}


I was expecting that the patientId parameter would be checked if it is null and also that the name attribute inside the patientId object would also be checked for null and for a string length of greater than 0.

None of the checking seems to be occurring. I must be missing something but I cannot work out what.

JBoss 7.1.1 has hibernate validator 4.2.0.Final included so that is what should be used. The ejb configuration is as shown, there is no XML configuration included with its deployment. I am calling the bean method from an arquillian test case that is also running within the application server so the ejb invocation is a local call but it should be going through all the interceptors (the stack traces I see confirm this).

Any ideas what to try next?

thanks.

P.S. I have tried calling a validator directly using this in the class
Code:
    @Resource
    private Validator validator;

and this in the method
Code:
        Set<ConstraintViolation<Identifier>> cvs = validator.validate(patientId);
        if (!cvs.isEmpty()) throw new Cpf4Exception("bad args");

and the exception is thrown as expected when the name attribute of patientId is an empty string or null.


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 5:45 am 
Hibernate Team
Hibernate Team

Joined: Sat Jan 24, 2009 12:46 pm
Posts: 388
Hi,

As of version 4.2, Hibernate Validator provides an API for method validation, but adding constraints to method parameters does not automatically lead to their validation upon invocation of the constrained method. Instead some integration layer is required to perform the validation.

If your EJBs are CDI managed beans (which they should be as long as you have a beans.xml file in your deployment), you could try to use the Seam Validation module (http://seamframework.org/Seam3/ValidationModule), which applies method validation to CDI beans. Note that you have to annotate your bean with the @AutoValidating
annotation in order to have the validation interceptor kicking in.

Alternatively you could create an EJB interceptor which performs the validation of parameters and return values and register that for your EJB. You could use the implementation of the Seam Validation interceptor as basis (https://github.com/seam/validation/blob/develop/impl/src/main/java/org/jboss/seam/validation/ValidationInterceptor.java#L69).

Note that in Bean Validation 1.1 (as part of Java EE 8) and the reference implementation Hibernate Validator 5 method validation will work out of the box for any constrained methods of CDI managed beans.

--Gunnar

_________________
Visit my blog at http://musingsofaprogrammingaddict.blogspot.com/


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 7:19 am 
Newbie

Joined: Thu Jul 19, 2007 7:55 pm
Posts: 5
Gunnar wrote:
If your EJBs are CDI managed beans (which they should be as long as you have a beans.xml file in your deployment), you could try to use the Seam Validation module (http://seamframework.org/Seam3/ValidationModule), which applies method validation to CDI beans. Note that you have to annotate your bean with the @AutoValidating
annotation in order to have the validation interceptor kicking in.


Hi Gunnar,
Thanks for that, that is what I was missing, how to get it to run the validation.

I do have a beans.xml file in the deployment and I have added seam3's validationmodule (org.jboss.seam.validation:seam-validation:3.1.0.Final) to my ejb jar, added the @AutoValidating to my EJB class but I am still not getting validation.

Not sure what to look for next.


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 10:45 am 
Hibernate Team
Hibernate Team

Joined: Sat Jan 24, 2009 12:46 pm
Posts: 388
Could you describe the structure of your deployment? Also, where is your beans.xml file? I think it should be under META-INF/beans.xml in your EJB JAR, making this JAR a CDI beans archive and thus subject to CDI beans discovery.

--Gunnar

_________________
Visit my blog at http://musingsofaprogrammingaddict.blogspot.com/


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 8:33 pm 
Newbie

Joined: Thu Jul 19, 2007 7:55 pm
Posts: 5
Gunnar wrote:
Could you describe the structure of your deployment? Also, where is your beans.xml file? I think it should be under META-INF/beans.xml in your EJB JAR, making this JAR a CDI beans archive and thus subject to CDI beans discovery.


The ejb jar file is like so:
Code:
META-INF/
META-INF/MANIFEST.MF
au/
au/com/
au/com/infomedix/
au/com/infomedix/cpf4/
au/com/infomedix/cpf4/ds/
au/com/infomedix/cpf4/ds/dto/
au/com/infomedix/cpf4/ds/util/
au/com/infomedix/cpf4/ds/dto/Document$1.class
au/com/infomedix/cpf4/ds/dto/Document$Builder.class
au/com/infomedix/cpf4/ds/dto/Document$DocumentData$Builder.class
au/com/infomedix/cpf4/ds/dto/Document$DocumentData.class
au/com/infomedix/cpf4/ds/dto/Document.class
au/com/infomedix/cpf4/ds/dto/Identifier.class
au/com/infomedix/cpf4/ds/dto/SectionConfiguration.class
au/com/infomedix/cpf4/ds/i18n.properties
au/com/infomedix/cpf4/ds/JcrSession.class
au/com/infomedix/cpf4/ds/JcrSessionInterceptor.class
au/com/infomedix/cpf4/ds/Messages.properties
au/com/infomedix/cpf4/ds/Messages_en.properties
au/com/infomedix/cpf4/ds/PatientRecordOperations.class
au/com/infomedix/cpf4/ds/SectionOperations$1.class
au/com/infomedix/cpf4/ds/SectionOperations.class
au/com/infomedix/cpf4/ds/util/Cpf4JcrMetadata.class
Cpf4JcrSchema.cnd
META-INF/beans.xml
META-INF/maven/
META-INF/maven/au.com.infomedix.cpf4/
META-INF/maven/au.com.infomedix.cpf4/documentstore-core/
META-INF/maven/au.com.infomedix.cpf4/documentstore-core/pom.xml
META-INF/maven/au.com.infomedix.cpf4/documentstore-core/pom.properties


this is then packaged into an ear file like so:

Code:
/lib/
/lib/httpcore-4.2.1.jar
/lib/jackson-mapper-asl-1.9.2.jar
/lib/antlr-2.7.7.jar
/lib/commons-lang3-3.1.jar
/lib/asm-commons-3.2.jar
/lib/hamcrest-library-1.2.1.jar
/lib/slf4j-api-1.6.1.jar
/lib/seam-validation-api-3.1.0.Final.jar
/lib/commons-codec-1.6.jar
/lib/hamcrest-core-1.2.1.jar
/lib/solder-logging-3.1.0.Final.jar
/lib/shrinkwrap-api-1.0.0-cr-1.jar
/lib/tagsoup-1.2.1.jar
/lib/groovy-1.8.4.jar
/lib/validation-api-1.0.0.GA.jar
/lib/commons-logging-1.1.1.jar
/lib/shrinkwrap-resolver-api-maven-1.0.0-beta-7.jar
/lib/rest-assured-1.7.2.jar
/lib/gettext-commons-0.9.6.jar
/lib/hibernate-validator-4.2.0.Beta2.jar
/lib/httpmime-4.2.1.jar
/lib/httpclient-4.2.1.jar
/lib/seam-validation-3.1.0.Final.jar
/lib/shrinkwrap-resolver-api-1.0.0-beta-7.jar
/lib/asm-tree-3.2.jar
/lib/solder-api-3.1.0.Final.jar
/lib/solder-impl-3.1.0.Final.jar
/lib/core-util-1.0-SNAPSHOT.jar
/lib/asm-3.2.jar
/lib/commons-collections-3.2.1.jar
/lib/jackson-core-asl-1.9.2.jar
/lib/asm-util-3.2.jar
/lib/asm-analysis-3.2.jar
/documentstore-service-1.0-SNAPSHOT.war
/META-INF/
/META-INF/jboss-deployment-structure.xml
/TestDocumentStoreService.war
/documentstore-core-1.0-SNAPSHOT.jar


I've just noticed that for some reason I am getting a hibernate-validator jar included in the ear file lib directory which is not correct as that is a service provided by a module in jboss as 7.1.1. Not sure if that would cause a problem or not. I will attempt to exclude it.

-- Edit: I excluded the hibernate-validator from the ear file's lib directory and the results are the same, no validation.


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Wed Mar 06, 2013 10:20 pm 
Newbie

Joined: Thu Jul 19, 2007 7:55 pm
Posts: 5
I captured a stack trace from within my ejb method as this should show what interceptors are involved in the call from the client to the ejb method. The trace goes from my client call (at the bottom) to the ejb method (at the top)

I cannot see any evidence of a validation interceptor in the trace (not that I would know what to look for)

Code:
java.lang.Throwable
        at au.com.infomedix.cpf4.ds.PatientRecordOperations.addPatient(PatientRecordOperations.java:260)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor. processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:114)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:125)
        at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:135)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
        at au.com.infomedix.cpf4.ds.JcrSessionInterceptor.handleSession(JcrSessionInterceptor.java:49)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor. processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:123)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
        at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:82)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304)
        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
        at au.com.infomedix.cpf4.ds.PatientRecordOperations$$$view2.addPatient(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:264)
        at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
        at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
        at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:260)
        at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:111)
        at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105)
        at au.com.infomedix.cpf4.ds.PatientRecordOperations$Proxy$_$$_Weld$Proxy$.addPatient(PatientRecordOperations$Proxy$_$$_Weld$Proxy$.java)
        at au.com.infomedix.cpf4.ds.DocumentStoreOperationsIT.testAddDeletePatient(DocumentStoreOperationsIT.java:215)


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Thu Mar 07, 2013 4:20 pm 
Hibernate Team
Hibernate Team

Joined: Sat Jan 24, 2009 12:46 pm
Posts: 388
Hi,

hmm, I can see no apparent error (apart from Hibernate Validator being part of the deployment, which is as you say not required). Could you try to inject a Validator using @Inject instead of @Resource? If that works, your bean definitely is a CDI managed bean, and the interceptor should kick in.

Have you also registered the interceptor in beans.xml (I forgot to mention that, also check out the Seam Validation guide: http://docs.jboss.org/seam/3/validation/snapshot/reference/en-US/html_single/#validation-method-validation)?

--Gunnar

_________________
Visit my blog at http://musingsofaprogrammingaddict.blogspot.com/


Top
 Profile  
 
 Post subject: Re: method parameter validation and cascade
PostPosted: Thu Mar 07, 2013 6:25 pm 
Newbie

Joined: Thu Jul 19, 2007 7:55 pm
Posts: 5
Gunnar wrote:
Have you also registered the interceptor in beans.xml (I forgot to mention that, also check out the Seam Validation guide: http://docs.jboss.org/seam/3/validation/snapshot/reference/en-US/html_single/#validation-method-validation)?


Bingo!

That is what I was missing.

Thanks for the help, most appreciated.

regards,
brian wallis...


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 8 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.