openwebbeans-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r881113 - in /websites/staging/openwebbeans/trunk/content: ./ cdi_explained.html
Date Fri, 04 Oct 2013 09:16:47 GMT
Author: buildbot
Date: Fri Oct  4 09:16:47 2013
New Revision: 881113

Staging update by buildbot for openwebbeans

    websites/staging/openwebbeans/trunk/content/   (props changed)

Propchange: websites/staging/openwebbeans/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Oct  4 09:16:47 2013
@@ -1 +1 @@

Modified: websites/staging/openwebbeans/trunk/content/cdi_explained.html
--- websites/staging/openwebbeans/trunk/content/cdi_explained.html (original)
+++ websites/staging/openwebbeans/trunk/content/cdi_explained.html Fri Oct  4 09:16:47 2013
@@ -74,11 +74,80 @@
         <div id="OwbContent_" class="wiki-content">
-<h1 id="openwebbeans-faq">OpenWebBeans FAQ</h1>
-- where does OWB differ from the CDI-1.0 spec
-- what is the default EL version used in OWB
-- how can I provide own plugins if there is a new spec part (e.g EL-3.0) I like to support</p>
+<h1 id="what-can-openwebbeans-as-cdi-container-do-for-you">What can OpenWebBeans as
CDI container do for you?</h1>
+<h2 id="an-introduction-to-cdi">An introduction to CDI</h2>
+<p>Contexts and Dependency Injection for Java a.k.a. CDI is a JavaEE specification
with the number JSR-299.
+Apache OpenWebBeans implements this standard. This page will give you an introduction to
features of 
+CDI in general. We will add a special hint whenever a feature is ambiguous in the specification

+and OpenWebBeans implements it in a certain way which might be different on other CDI containers.</p>
+<h2 id="what-is-cdi-at-all">What is CDI at all?</h2>
+<p>Originally developed under the name ‘Web Beans’, the CDI specification
was created 
+to fill the gaps which could not be filled by Enterprise Java Beans (EJB) on the back end,

+and JavaServer Faces (JSF) in the view layer. The first draft targeted only 
+Java Enterprise Edition (Java EE), but during the creation of the specification 
+it became clear that most features were very useful for any Java environment, 
+including Java SE.</p>
+<p>Even if the full name of the specification is </p>
+<p>Contexts and Dependency Injection for the Java Enterprise platform</p>
+<p>this does not mean that CDI applications can only run in JavaEE those days. 
+At least OpenWebBeans provides CDI functionality which also runs in pure Java SE apps like
Swing, JavaFX
+and even Eclipse RCP apps as well.</p>
+<h3 id="relation-to-jsr-330">Relation to JSR-330</h3>
+<p>A half year before the CDI specification became final, other communities 
+(Spring and guice) had begun an effort to specify the basics of injection as </p>
+<p>“JSR-330: Dependency Injection for Java” (nicknamed “AtInject”).
+<p>Considering that it did not make sense to provide a new dependency injection container

+without collaborating on the actual injection API, the AtInject and CDI expert groups 
+worked closely together to ensure a common solution across dependency injection frameworks.
+<p>As a result, CDI uses the annotations from the AtInject specification, 
+meaning that every CDI implementation fully implements the AtInject specification, 
+just like Guice and Spring. </p>
+<p>CDI and AtInject are both included in Java Enterprise Edition 6 (JSR-316) 
+and thus nowadays an integral part of almost every Java Enterprise Edition server.</p>
+<h2 id="cdi-features">CDI features</h2>
+<p>Before we go on to dive into some code, let’s take a quick look at some key
CDI features:</p>
+<p>Type Safety: Instead of injecting objects by a (string) name, 
+CDI uses the Java type to resolve injections. When the type is not sufficient, 
+a Qualifier annotation can be used. This allows the compiler to easily detect errors, 
+and provides easy refactoring.</p>
+<p>POJOs: Almost every Java object can be injected by CDI! 
+This includes EJBs, JNDI resources, Persistence Units and Persistence Contexts, 
+as well as any object which previously would have been created by a factory method.</p>
+<p>Extensibility: Every CDI container can enhance its functionality 
+by using portable “Extensions”. The attribute “portable” means that 
+those CDI Extensions can run on every CDI container and Java EE 6 server, 
+no matter which vendor. This is accomplished by a well-specified 
+SPI (Service Provider Interface) which is part of the JSR-299 specification.</p>
+<p>Interceptors: It has never been easier to write your own Interceptors. 
+Because of the portable behaviour of JSR-299, they now also run on every 
+EE 6-certified server and on all standalone CDI containers.</p>
+<p>Decorators: These allow to dynamically extend existing interface 
+implementations with business aspects.</p>
+<p>Events: CDI specifies a type-safe mechanism to send 
+and receive events with loose coupling.</p>
+<p>Unified EL integration: EL-2.2 opens a new horizon 
+in regard of flexibility and functionality. 
+CDI provides out-of-the-box support for it!</p>

View raw message