-
1. Re: Missing ValidatorFactory?
nickarls Dec 10, 2009 12:18 PM (in response to chriskriel.chris.kriel.vcontractor.co.za)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 Dec 10, 2009 3:05 PM (in response to 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 Dec 10, 2009 8:35 PM (in response to chriskriel.chris.kriel.vcontractor.co.za)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 Dec 12, 2009 7:53 AM (in response to chriskriel.chris.kriel.vcontractor.co.za)I notice you are using the
all
profile of JBoss AS. Could you try thedefault
profile. It could be a problem with theall
profile. Most of us stick with thedefault
orweb
profile. -
5. Re: Missing ValidatorFactory?
chriskriel.chris.kriel.vcontractor.co.za Dec 12, 2009 11:28 PM (in response to 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
ordefault
. The reason for usingall
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 Dec 13, 2009 12:42 AM (in response to chriskriel.chris.kriel.vcontractor.co.za)
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 Dec 13, 2009 1:37 PM (in response to 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 Dec 13, 2009 6:26 PM (in response to chriskriel.chris.kriel.vcontractor.co.za)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 Dec 17, 2009 3:31 PM (in response to chriskriel.chris.kriel.vcontractor.co.za)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 Dec 26, 2009 10:00 PM (in response to chriskriel.chris.kriel.vcontractor.co.za)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).