10 Replies Latest reply on Dec 26, 2009 10:00 PM by dan.j.allen

    Missing ValidatorFactory?

    chriskriel.chris.kriel.vcontractor.co.za

      Hi, I am trying JBoss-6.0.0.M1 with no modifications or any additional distributions (like Weld). I have one class with one property and no annotations. I want to see how it is being deployed in JBoss. The jar that I deploy only contains this one class and META-INF/beans.xml. What else do I need at minimum because I get the below exception.


      Thanks,
      Chris.


      11:26:14,734 ERROR [AbstractKernelController] Error installing to PreReal: name=vfsfile:/C:/cygwin/home/chris/java/jboss-6.0.0.M1/server/all/deploy/x.beans-001/ state=PostClassLoader mode=Manual requiredState=PreReal
      org.jboss.deployers.spi.DeploymentException: Missing ValidatorFactory attachment in deployment: AbstractVFSDeploymentContext@341098{vfsfile:/C:/cygwin/home/chris/java/jboss-6.0.0.M1/server/all/deploy/x.beans-001/}
              at org.jboss.weld.integration.deployer.env.WeldBootstrapDeployer.createValidationServices(WeldBootstrapDeployer.java:126)
              at org.jboss.weld.integration.deployer.env.WeldBootstrapDeployer.deployInternal(WeldBootstrapDeployer.java:75)
              at org.jboss.weld.integration.deployer.env.AbstractBootstrapInfoDeployer.deploy(AbstractBootstrapInfoDeployer.java:66)

        • 1. Re: Missing ValidatorFactory?
          nickarls

          Strange, it seems to fail to pick up Bean Validations. You have validation-api.jar and hibernate-core.jar in the usual places? Tried with a fresh download of AS to make sure there hasn't been any corruption?

          • 2. Re: Missing ValidatorFactory?
            chriskriel.chris.kriel.vcontractor.co.za

            Hi, downloaded again - no curruption. Both validation.jar and hibernate-core.jar are there. I must be doing something wrong. What is meant by ValidatorFactory attachement?

            • 3. Re: Missing ValidatorFactory?
              nickarls

              Try dropping in the numberguess.war and after that start giving us your deployment archive structure. The server hands over a EE 6 survival pack with required services to the application - BV integration is one of them

              • 4. Re: Missing ValidatorFactory?
                dan.j.allen

                I notice you are using the all profile of JBoss AS. Could you try the default profile. It could be a problem with the all profile. Most of us stick with the default or web profile.

                • 5. Re: Missing ValidatorFactory?
                  chriskriel.chris.kriel.vcontractor.co.za

                  numberguess.war works when I drop it in. I have tried another small class in a jar with a META-INF/beans.xml empty file included. This does not cause any exceptions when dropped in but there is no visible sign that it is being deployed. Is it only deployed when it used/started/required?


                  There is no difference in the results I am getting between using all or default. The reason for using all is that I have an EJB3 CORBA Client Service that I want to integrate with CDI based beans.


                  Rather then persuing this issue I should first try to understand a bit more. I am new to JEE, JBoss and CDI.


                  Can somebody please align the concepts below for me? Weld adds to the many containers injecting and intercepting things and I am not sure which is going to do what when.


                  The first basic question is if more than one container can manage the same bean/component? Or, according to my assumptions, every bean is managed by only one container and any interaction betweens two beans in different containers is only possible if the two containers can collaborate to enable this interaction?


                  The microcontainer is driven by ..jboss-beans.xml files (I assume), so for every bean defined in these files the microcontainer will act as the container? Do you have an architecture of containers within containers in general, and specifically where the microcontainer manages Weld?


                  My next assumption is that any jar, war, etc which contains a beans.xml file will be managed only by the CDI implementation and not also by another container, right? Does it then follow that Weld must also act as an EJB3 container for beans managed by it?


                  I have EJB3 services/singletons (annotated with @Service). Must I remove the @Service annotations and have Weld manage them as an @ApplicationScoped beans? Can they also implement a @Management interface to be visible in the JMX Console?


                  Is there an architecture diagram available that shows the relationships between the different containers which includes CDI?


                  At this point I think I have demonstrated enough my confusion (for a start).

                  • 6. Re: Missing ValidatorFactory?
                    dan.j.allen

                    Rather then pursuing this issue I should first try to understand a bit more. I am new to JEE, JBoss and CDI.


                    Welcome. It's a fun new world to explore ;)



                    Can somebody please align the concepts below for me? Weld adds to the many containers injecting and intercepting things and I am not sure which is going to do what when.


                    I'll give it a stab.



                    The first basic question is if more than one container can manage the same bean/component? Or, according to my assumptions, every bean is managed by only one container and any interaction betweens two beans in different containers is only possible if the two containers can collaborate to enable this interaction?


                    Sure, more than one container can manage the same bean class. But those containers are going to have to coordinate if they want to be able to use the same bean instance (otherwise, they both end up creating independent instances and this can just lead to confusion).


                    In Java EE, there is exactly one bean container, and that is the Java EE container. CDI knows about every managed bean and maintains it's own registry. I'll address EJBs later down. In a servlet container, Weld is your bean container, adhering to the semantics of CDI. Weld has to step in and do this because, by definition, a servlet container does not provide a bean container (it's just an impl of the servlet spec, after all).



                    The microcontainer is driven by ..jboss-beans.xml files (I assume), so for every bean defined in these files the microcontainer will act as the container? Do you have an architecture of containers within containers in general, and specifically where the microcontainer manages Weld?


                    Yikes, I won't really be worrying about the microcontainer. That is really an implementation detail of JBoss AS. That is, unless you are actually using that deep level of integration. Weld provides an integration bridge which is what hooks CDI into the JBoss AS runtime, but really you shouldn't be worrying about that level. You should be up in the CDI realm (higher level).



                    My next assumption is that any jar, war, etc which contains a beans.xml file will be managed only by the CDI implementation and not also by another container, right? Does it then follow that Weld must also act as an EJB3 container for beans managed by it?


                    So first, yes, the CDI implementation should be registering all of your beans, not any other container. Now, you can have a portable extension to CDI that picks up beans from another container and allows them to act dually as CDI beans and whatever that container is. For instance, let's say you have Spring beans. With an CDI Spring extension, it's possible that CDI will consult the Spring bean registry and dually register those beans as CDI beans. Then the extension coordinates the hand-off when a method is invoked (CDI -> Spring).


                    As for EJB, CDI has deep integration w/ EJB. So any EJB session bean is also a CDI bean. All this means is that CDI allows it to be injected into other beans, but what you are injecting is the raw, native EJB client reference. So there is no dual container here, but CDI is certainly participating in the wiring.



                    I have EJB3 services/singletons (annotated with @Service). Must I remove the @Service annotations and have Weld manage them as an @ApplicationScoped beans? Can they also implement a @Management interface to be visible in the JMX Console?


                    Assuming you are talking about Spring's @Service, yes, I would just make them either @ApplicationScoped or @Singleton (EJB 3.1). If you are considering CDI, you should be strongly considering dropping Spring (for those beans at least). There will likely be a CDI-Spring portable extension in the future, but it hasn't been created yet.



                    Is there an architecture diagram available that shows the relationships between the different containers which includes CDI?


                    Good question. We probably need to create (or track down) one. I'll take that as an action item for our doc initiative.



                    At this point I think I have demonstrated enough my confusion (for a start).


                    Hey, that's why we have forums. Hopefully I got you started. I'd be glad for some other people to jump in and provide other perspectives.

                    • 7. Re: Missing ValidatorFactory?
                      chriskriel.chris.kriel.vcontractor.co.za

                      I really appreciate the careful attention to my questions - I will need to chew a bit on the answers for a while though.



                      Assuming you are talking about Spring's @Service, yes, I would just make them either @ApplicationScoped or @Singleton (EJB 3.1). If you are considering CDI, you should be strongly considering dropping Spring (for those beans at least). There will likely be a CDI-Spring portable extension in the future, but it hasn't been created yet.

                      No this is a JBOSS specific (org.jboss.ejb3....) annotation. Using this annotation will cause JBOSS to effectively run the bean as a singleton service and automagically install an MBean based on a JBOSS specific @Management annotated interface (which can also implemented by the same @Service annotated bean). No deployment descriptors required - very nice. I would like to try and still use this feature but augment it with CDI injections. And if there are CDI annotations with the same utilty that I can use to make it portable then that would be even better.


                      I find it difficult to work out which jars to use with CDI and Weld and based on my current background the grouping of the annotations is not intuitive. For example, @Inject is not in the same package as @Produces or even the same jar. How to make sense out of it - can you refer me to some documentation on this?


                      • 8. Re: Missing ValidatorFactory?
                        dan.j.allen

                        Assuming you are talking about Spring's @Service, yes, I would just make them either @ApplicationScoped or @Singleton (EJB 3.1). If you are considering CDI, you should be strongly considering dropping Spring (for those beans at least). There will likely be a CDI-Spring portable extension in the future, but it hasn't been created yet.

                        No this is a JBOSS specific (org.jboss.ejb3....) annotation. Using this annotation will cause JBOSS to effectively run the bean as a singleton service and automagically install an MBean based on a JBOSS specific @Management annotated interface (which can also implemented by the same @Service annotated bean). No deployment descriptors required - very nice. I would like to try and still use this feature but augment it with CDI injections. And if there are CDI annotations with the same utilty that I can use to make it portable then that would be even better.


                        Ah, my bad. I see what you are saying now. You know, I have to admit, I honestly don't know what happens in this case. That would be a really great FAQ to have because it does cross technology stacks somewhat. You may want to take that to the JBoss AS or microcontainer forums. Don't give up on finding the answer ;)



                        I find it difficult to work out which jars to use with CDI and Weld and based on my current background the grouping of the annotations is not intuitive. For example, @Inject is not in the same package as @Produces or even the same jar. How to make sense out of it - can you refer me to some documentation on this?


                        When you deploy to JBoss AS, you shouldn't need any JARs in your WAR at all. The CDI implementation (Weld) is provided by the server. When you are developing, you need the CDI API (http://repo2.maven.org/maven2/javax/enterprise/cdi-api/1.0/) on your classpath for compiling.


                        As for the Java package organization, that really came down to politics in the JCP. That's just the way it is. If you need to see all the classes, check out the Java EE API JavaDoc (http://java.sun.com/javaee/6/docs/api/).


                        Hopefully that gets you further along. Let me know if there is anything else confusing you. And remember, if you have a question, others might have it too, so let's try to turn answers into FAQs where possible.

                        • 9. Re: Missing ValidatorFactory?
                          alesj


                          Assuming you are talking about Spring's @Service, yes, I would just make them either @ApplicationScoped or @Singleton (EJB 3.1). If you are considering CDI, you should be strongly considering dropping Spring (for those beans at least). There will likely be a CDI-Spring portable extension in the future, but it hasn't been created yet.

                          No this is a JBOSS specific (org.jboss.ejb3....) annotation. Using this annotation will cause JBOSS to effectively run the bean as a singleton service and automagically install an MBean based on a JBOSS specific @Management annotated interface (which can also implemented by the same @Service annotated bean). No deployment descriptors required - very nice. I would like to try and still use this feature but augment it with CDI injections. And if there are CDI annotations with the same utilty that I can use to make it portable then that would be even better.


                          Ah, my bad. I see what you are saying now. You know, I have to admit, I honestly don't know what happens in this case. That would be a really great FAQ to have because it does cross technology stacks somewhat. You may want to take that to the JBoss AS or microcontainer forums. Don't give up on finding the answer ;)

                          http://www.jboss.org/ejb3/docs/reference/build/reference/en/html/jboss_extensions.html

                          • 10. Re: Missing ValidatorFactory?
                            dan.j.allen

                            This thread got a little off track from the original question. It turns out, Aslak Knusten hit the same bug while developing Arquillian (JBoss' new in-container testing framework). He figured out that the root of the problem is invalid metadata in the bean validation deployer in JBoss AS 6.0.0.M1. See the following thread for details and a fix:


                            http://community.jboss.org/thread/69486


                            Making the fix is easy. You can expect it to be fixed out of the box in 6.0.0.M2 (or better).