Re: Apache CODI x JEE7 Glassfish4
I'll try to substitute CODI to DeltaSpike using JEE7/GF4 for test... thanks... I'll return the result here... 2013/10/31 Gerhard Petracek gerhard.petra...@gmail.com i haven't said something different. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de yea, but that is minor tho what CODI can do. LieGrue, strub From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org; Mark Struberg strub...@yahoo.de Sent: Thursday, 31 October 2013, 0:24 Subject: Re: Apache CODI x JEE7 Glassfish4 @mark: the parameter conversationPropagation was added in 1.1. regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/31 Mark Struberg strub...@yahoo.de Nope, we didn't touch @ConversationScoped a bit in CDI-1.1. The main changes in CDI-1.1 have been clarifications. But most of them are already implemented in OWB and Weld, even in the CDI-1.0 targetting versions. There have been a few good Extensions in the Extension area, scanning, etc in CDI-1.1. LieGrue, strub - Original Message - From: Kay Wrobel kay.wro...@gmx.net To: MyFaces Discussion users@myfaces.apache.org Cc: Sent: Wednesday, 30 October 2013, 22:44 Subject: Re: Apache CODI x JEE7 Glassfish4 One could still investigate if @ConversatioScoped has improved in CDI 1.1 and is on par with how CODI 1.0.5 handles it. Again, I am not the right person to discuss that annotation, but it's a thought. On 10/30/2013 04:33 PM, Gerhard Petracek wrote: hi edilmar, apache deltaspike is the official successor of codi/seam/... (including support for ee7+). some parts (including codi-conversations) are still on our list, however, you can try it with [1] (it's the same code - just different packages and based on deltaspike). @kay (and your comment about conversations): std. cdi conversations are available since cdi 1.0 and have many disadvantages compared to codi-conversations. that was the reason for introducing codi-conversations at all (see e.g. [2]) - they are still useful. regards, gerhard [1] http://os890.blogspot.co.at/2013/07/add-on-codi-scopes-for-deltaspike.html [2] http://os890.blogspot.co.at/2011/04/slides-codi-conversations.html http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2013/10/30 Edilmar Alves edili...@gmail.com I think CODI is a great replacement for my actual environment, the only problem is to deploy in GF4. 2013/10/30 Edilmar Alves edili...@gmail.com Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.html http://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.html http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version
Apache CODI x JEE7 Glassfish4
Hi, I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 + Hibernate4.2.6 + JSF2 + RichFaces4.3.4. Then, when I try to deploy in GF4, server.log arises this error, and searching on Internet, some people said this is a problem with CODI, that is not compatible with JEE7 projects. Is this true? If it is not compatible, is there some alternative that makes the same as CODI ConversationScoped for example, that I use in many places in my webapp? [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=36 _ThreadName=admin-listener(5)] [timeMillis: 1375109082206] [levelValue: 1000] [[ Exception during lifecycle processing org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject private org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validator] at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:225) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:131) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:328) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:493) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:356) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674) at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396) at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234) 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.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125) at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152) at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91) at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341) at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101) at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:224) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) at org.glassfish.jersey.internal.Errors.process(Errors.java:315) at org.glassfish.jersey.internal.Errors.process(Errors.java:297) at org.glassfish.jersey.internal.Errors.process(Errors.java:267) at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198) at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946) at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:331) at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:165) at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246) at
Re: Apache CODI x JEE7 Glassfish4
Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not simple to upgrade. 2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial server approved by the enterprise, I can't change for other server. Then, I test version 4 because there are some other functionalities I would like to use from JEE7 in my webapp, but with CODI it is not possible to deploy. 3) I didn't understand the suggestion to use Myfaces 2.2. Has it a replacement for the CODI ConversationScoped, for example? Because this scope is used in many pages of my webapp, the main resource from CODI that I use and need an alternative. I can't use Myfaces, for example, to change Richfaces. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last final release targeting Java EE 6. Unless he wants to incorporated new features that only Java EE 7 can provide, I'd say, stick with what currently works. Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still targets Java EE 6, or JBoss AS 7 which also targets Java EE 6. On 10/30/2013 02:08 PM, Howard W. Smith, Jr. wrote: Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was just/recently released (yesterday, I think). Feel free to give that a try. TomEE and tomcat8 is and/or will be targeting JEE7. is it a requirement to deploy to Glassfish 4, or you just want to deploy to your local machine for testing purposes only? if for testing purposes only, download latest tomee 1.6 snapshot and Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib folder, and give them a try. and if you have any tomee-related questions, please subscribe to tomee user list and ask questions there. they are 'apache', too, and just as helpful there, 'too'. :) On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net wrote: Hi Edilmar. I had the same issues. There are incompatibilities apparently with JSF 2.2 that ships with GlassFish 4. And JSF 2.2 has some much improved CDI features, such as proper @ViewScope. Kay On 10/30/2013 01:03 PM, Edilmar Alves wrote: Hi, I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 + Hibernate4.2.6 + JSF2 + RichFaces4.3.4. Then, when I try to deploy in GF4, server.log arises this error, and searching on Internet, some people said this is a problem with CODI, that is not compatible with JEE7 projects. Is this true? If it is not compatible, is there some alternative that makes the same as CODI ConversationScoped for example, that I use in many places in my webapp? [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=36 _ThreadName=admin-listener(5)] [timeMillis: 1375109082206] [levelValue: 1000] [[ Exception during lifecycle processing org.glassfish.deployment.common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject private org.hibernate.validator.internal.cdi.interceptor.** ValidationInterceptor.validator] at org.glassfish.weld.WeldDeployer.event( WeldDeployer.java:225) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.** java:131) at org.glassfish.internal.data.ApplicationInfo.load(** ApplicationInfo.java:328) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy( ApplicationLifecycle.java:493) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy( ApplicationLifecycle.java:219) at org.glassfish.deployment.admin.DeployCommand.execute(** DeployCommand.java:491) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(** CommandRunnerImpl.java:527) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(** CommandRunnerImpl.java:523) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:356) at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(** CommandRunnerImpl.java:522) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(** CommandRunnerImpl.java:546) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(** CommandRunnerImpl.java:1423) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500( CommandRunnerImpl.java:108) at com.sun.enterprise.v3.admin.CommandRunnerImpl$** ExecutionContext.execute(CommandRunnerImpl.java:1762) at com.sun.enterprise.v3.admin.CommandRunnerImpl$** ExecutionContext.execute(CommandRunnerImpl.java:1674) at org.glassfish.admin.rest.resources.admin
Re: Apache CODI x JEE7 Glassfish4
Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.htmlhttp://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.html http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not simple to upgrade. 2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial server approved by the enterprise, I can't change for other server. Then, I test version 4 because there are some other functionalities I would like to use from JEE7 in my webapp, but with CODI it is not possible to deploy. 3) I didn't understand the suggestion to use Myfaces 2.2. Has it a replacement for the CODI ConversationScoped, for example? Because this scope is used in many pages of my webapp, the main resource from CODI that I use and need an alternative. I can't use Myfaces, for example, to change Richfaces. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last final release targeting Java EE 6. Unless he wants to incorporated new features that only Java EE 7 can provide, I'd say, stick with what currently works. Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still targets Java EE 6, or JBoss AS 7 which also targets Java EE 6. On 10/30/2013 02:08 PM, Howard W. Smith, Jr. wrote: Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was just/recently released (yesterday, I think). Feel free to give that a try. TomEE and tomcat8 is and/or will be targeting JEE7. is it a requirement to deploy to Glassfish 4, or you just want to deploy to your local machine for testing purposes only? if for testing purposes only, download latest tomee 1.6 snapshot and Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib folder, and give them a try. and if you have any tomee-related questions, please subscribe to tomee user list and ask questions there. they are 'apache', too, and just as helpful there, 'too'. :) On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net wrote: Hi Edilmar. I had the same issues. There are incompatibilities apparently with JSF 2.2 that ships with GlassFish 4. And JSF 2.2 has some much improved CDI features, such as proper @ViewScope. Kay On 10/30/2013 01:03 PM, Edilmar Alves wrote: Hi, I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 + Hibernate4.2.6 + JSF2 + RichFaces4.3.4. Then, when I try to deploy in GF4, server.log arises this error, and searching on Internet, some people said this is a problem with CODI, that is not compatible with JEE7 projects. Is this true? If it is not compatible, is there some alternative that makes the same as CODI ConversationScoped for example, that I use in many places in my webapp? [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=36 _ThreadName=admin-listener(5)] [timeMillis: 1375109082206] [levelValue: 1000] [[ Exception during lifecycle processing org.glassfish.deployment.**common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject private org.hibernate.validator.**internal.cdi.interceptor.** ValidationInterceptor.**validator] at org.glassfish.weld.**WeldDeployer.event( WeldDeployer.java:225) at org.glassfish.kernel.event.* *EventsImpl.send(EventsImpl.** java:131
Re: Apache CODI x JEE7 Glassfish4
I think CODI is a great replacement for my actual environment, the only problem is to deploy in GF4. 2013/10/30 Edilmar Alves edili...@gmail.com Hi, I use CODI ConversationScoped and @Inject Conversation because it is better than original CDI implementation. I have many java files using CODI at this time. Then, to go back to CDI, I will have to change many files, and I don't know if the webapp will continue to work 100%, because the management of the Conversation object made by CODI is great, for example it decreases problems like LazyException caused by Hibernate with JSF fields. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Also, you might want to check with RichFaces. I found this blog http://www.bleathem.ca/blog/**2013/09/richfaces-434final-** release-announcement.htmlhttp://www.bleathem.ca/blog/2013/09/richfaces-434final-release-announcement.html and the moderator mentions that full JSF 2.2 support is planned for RichFaces 5. I had some of the same issues with PrimeFaces 3.5 which was incompatible with JSF 2.2 and I had to wait for PrimeFaces 4.0 to come out. On 10/30/2013 03:17 PM, Kay Wrobel wrote: I'm looking at CDI 1.1 spec http://docs.jboss.org/cdi/** spec/1.1/cdi-spec.htmlhttp://docs.jboss.org/cdi/spec/1.1/cdi-spec.html and ot looks like @ConversationScope is already part of CDI 1.1, no CODI needed for that. GlassFish 4 includes CDI 1.1 by way of Weld API 2.0 http://www.cdi-spec.org/**download/ http://www.cdi-spec.org/download/ which is bundled inside the weld-osgi-bundle.jar. On 10/30/2013 02:55 PM, Edilmar Alves wrote: Hi friends, Thanks for help! Look at these situations... 1) Glassfish 3.1.1 and 3.1.2.2 has the same behaviour. But I use in production 3.1.1 because there are many servers using my webapp with this version, and it is not simple to upgrade. 2) I am testing Glassfish 4/JEE7 because Glassfish is the oficial server approved by the enterprise, I can't change for other server. Then, I test version 4 because there are some other functionalities I would like to use from JEE7 in my webapp, but with CODI it is not possible to deploy. 3) I didn't understand the suggestion to use Myfaces 2.2. Has it a replacement for the CODI ConversationScoped, for example? Because this scope is used in many pages of my webapp, the main resource from CODI that I use and need an alternative. I can't use Myfaces, for example, to change Richfaces. 2013/10/30 Kay Wrobel kay.wro...@gmx.net Or he can stick with Glassfish 3.1.2.2, which is GlassFish' last final release targeting Java EE 6. Unless he wants to incorporated new features that only Java EE 7 can provide, I'd say, stick with what currently works. Or try alternatives, such as TomEE 1.5.2 or TomEE 1.6 which still targets Java EE 6, or JBoss AS 7 which also targets Java EE 6. On 10/30/2013 02:08 PM, Howard W. Smith, Jr. wrote: Also, MyFaces 2.2 (beta, which has JavaEE7 JSF2.2 features) was just/recently released (yesterday, I think). Feel free to give that a try. TomEE and tomcat8 is and/or will be targeting JEE7. is it a requirement to deploy to Glassfish 4, or you just want to deploy to your local machine for testing purposes only? if for testing purposes only, download latest tomee 1.6 snapshot and Myfaces 2.2 (beta), drop MyFaces 2.2 api + impl JARs in tomee/lib folder, and give them a try. and if you have any tomee-related questions, please subscribe to tomee user list and ask questions there. they are 'apache', too, and just as helpful there, 'too'. :) On Wed, Oct 30, 2013 at 2:59 PM, Kay Wrobel kay.wro...@gmx.net wrote: Hi Edilmar. I had the same issues. There are incompatibilities apparently with JSF 2.2 that ships with GlassFish 4. And JSF 2.2 has some much improved CDI features, such as proper @ViewScope. Kay On 10/30/2013 01:03 PM, Edilmar Alves wrote: Hi, I have an webapp that runs fine in GF3.1.1 using Weld1.1 + CODI + JPA2 + Hibernate4.2.6 + JSF2 + RichFaces4.3.4. Then, when I try to deploy in GF4, server.log arises this error, and searching on Internet, some people said this is a problem with CODI, that is not compatible with JEE7 projects. Is this true? If it is not compatible, is there some alternative that makes the same as CODI ConversationScoped for example, that I use in many places in my webapp? [2013-07-29T10:44:42.206-0400] [glassfish 4.0] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=36 _ThreadName=admin-listener(5)] [timeMillis: 1375109082206] [levelValue: 1000] [[ Exception during lifecycle processing org.glassfish.deployment.**common.DeploymentException: CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Validator] with qualifiers [@Default] at injection point [[UnbackedAnnotatedField] @Inject private org.hibernate.validator.**internal.cdi.interceptor.** ValidationInterceptor.**validator
