diff --git a/faq/what-is-beans-xml-and-why-do-i-need-it.asciidoc b/faq/what-is-beans-xml-and-why-do-i-need-it.asciidoc index 202db17..b1b75b3 100644 --- a/faq/what-is-beans-xml-and-why-do-i-need-it.asciidoc +++ b/faq/what-is-beans-xml-and-why-do-i-need-it.asciidoc @@ -3,7 +3,7 @@ title: What is +beans.xml+ and why do I need it? author: Dan Allen layout: faq --- -The +beans.xml+ file is know as the bean archive descriptor. This answer addresses the purpose of this file and why it is needed. +The +beans.xml+ file is known as the bean archive descriptor. This answer addresses the purpose of this file and why it is needed. == The minimal bean descriptor diff --git a/faq/where-is-the-xsd-for-beans-xml-located.asciidoc b/faq/where-is-the-xsd-for-beans-xml-located.asciidoc index c8112ed..32e5814 100644 --- a/faq/where-is-the-xsd-for-beans-xml-located.asciidoc +++ b/faq/where-is-the-xsd-for-beans-xml-located.asciidoc @@ -5,4 +5,6 @@ layout: faq --- You can find the XSD for beans.xml at the following location: -http://docs.jboss.org/cdi/beans_1_0.xsd +CDI 1.0: http://java.sun.com/xml/ns/javaee/beans_1_0.xsd + +CDI 1.1: http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd \ No newline at end of file diff --git a/faq/why-does-my-normal-scoped-bean-not-get-instantiated-immediately.asciidoc b/faq/why-does-my-normal-scoped-bean-not-get-instantiated-immediately.asciidoc index 947e3c9..cc24011 100644 --- a/faq/why-does-my-normal-scoped-bean-not-get-instantiated-immediately.asciidoc +++ b/faq/why-does-my-normal-scoped-bean-not-get-instantiated-immediately.asciidoc @@ -3,4 +3,4 @@ title: Why does my normal scoped bean not get instantiated immediately? author: Pete Muir layout: faq --- -A CDI implementation may choose to lazily instantiate a normal scoped bean. If you inject a shorter-lived bean into a longer lived bean (e.g. session scoped into application scoped) then there is no obvious bean to instantiate at this point - depending on the active session for the thread a different bean instance will be injected. +A CDI implementation may choose to lazily instantiate a normal scoped bean. If you inject a shorter-lived bean into a longer-lived bean (e.g. session scoped into application scoped) then there is no obvious bean to instantiate at this point - depending on the active session for the thread a different bean instance will be injected. diff --git a/faq/why-is-the-constructor-invoked-twice-when-a-normal-scoped-bean-is-created.asciidoc b/faq/why-is-the-constructor-invoked-twice-when-a-normal-scoped-bean-is-created.asciidoc index cbb427c..baecd10 100644 --- a/faq/why-is-the-constructor-invoked-twice-when-a-normal-scoped-bean-is-created.asciidoc +++ b/faq/why-is-the-constructor-invoked-twice-when-a-normal-scoped-bean-is-created.asciidoc @@ -5,7 +5,7 @@ layout: faq --- For every normal-scoped bean there is a proxy, and you are seeing the instantiation of two objects: one is the actual bean instance, the other one is the proxy. Both likely invoke the default constructor. -It's generally considered a bad idea to do initialization in class construction code. Instead, when using managed beans (objects managed by the EE container) you should perform initialisation in a `@PostConstruct` or `@Inject` annotated method. +It's generally considered a bad idea to do initialization in class construction code. Instead, when using managed beans (objects managed by the Java EE container) you should perform initialization in a `@PostConstruct` or `@Inject` annotated method. [source,java] ---- diff --git a/faq/why-is-veto-a-best-practice-for-persistent-jpa-entities.asciidoc b/faq/why-is-veto-a-best-practice-for-persistent-jpa-entities.asciidoc index dc8f36b..e66595e 100644 --- a/faq/why-is-veto-a-best-practice-for-persistent-jpa-entities.asciidoc +++ b/faq/why-is-veto-a-best-practice-for-persistent-jpa-entities.asciidoc @@ -1,16 +1,16 @@ --- -title: Why is @Veto a best practice for persistent (JPA) entities? +title: Why is @Vetoed a best practice for persistent (JPA) entities? author: Ove Ranheim layout: faq --- -Adding the +@Vetoed+ annotation to all persistent entities is considered a best practice in most cases. The purpose of this annotation is to prevent the BeanManager from managing an entity as a Bean. This feature from CDI 1.1. +Adding the +@Vetoed+ annotation to all persistent entities is considered a best practice in most cases. The purpose of this annotation is to prevent the BeanManager from managing an entity as a CDI Bean. This feature is from CDI 1.1. -When an entity is annotated +@Veto+ no injections will take place. The reasoning behind this is to prevent the BeanManager to perform operations that may cause the JPA provider to break. +When an entity is annotated +@Vetoed+ no injections will take place. The reasoning behind this is to prevent the BeanManager to perform operations that may cause the JPA provider to break. [source,java] ---- @Entity -@Veto +@Vetoed public class Foo { /* This will not be respected by the BeanManager */ @Inject @@ -22,7 +22,7 @@ public class Foo { } ---- -All JPA persistent entities should be marked with +@Vetoed+ as this will prevent the CDI attempting to manage the lifecycle of the object, and makes it very clear that the object is not managed by CDI. You should do the same for +MappedSuperclass+, +Embedded+, +ModelListeners+ etc. +All JPA persistent entities should be marked with +@Vetoed+ as this will prevent the CDI attempting to manage the lifecycle of the object, and makes it very clear that the object is not managed by CDI. You should do the same for +MappedSuperclass+, +Embedded+ etc. You can also annotate a +package-info.java+ to veto all beans in the package.