Modified: websites/staging/deltaspike/trunk/content/retired/jsf.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/jsf.html (original)
+++ websites/staging/deltaspike/trunk/content/retired/jsf.html Sat Aug 1
21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>JSF</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#multi-window-handling">Multi-Window Handling</a><ul>
<li><a href="#intro">Intro</a><ul>
@@ -209,37 +220,37 @@
</ul>
</div>
<hr />
-<h1 id="multi-window-handling">Multi-Window Handling</h1>
-<h2 id="intro">Intro</h2>
-<h3 id="historic-considerations">Historic Considerations</h3>
+<h1 id="multi-window-handling">Multi-Window Handling<a class="headerlink"
href="#multi-window-handling" title="Permanent link">¶</a></h1>
+<h2 id="intro">Intro<a class="headerlink" href="#intro" title="Permanent
link">¶</a></h2>
+<h3 id="historic-considerations">Historic Considerations<a class="headerlink"
href="#historic-considerations" title="Permanent link">¶</a></h3>
<p>Until the end of the 1990s web browsers are usually single threaded and
only had one window. But in the last years browsers supporting multiple windows
or even tab became the standard. Since those days lots of efforts went into
uniquely identifying a single browser window on the server side. Sadly browser
windows still lack of a native windowId, thus maintaining web application data
in @SessionScoped backing beans is still used in most of the cases.</p>
-<h3 id="how-jsf-2-changed-the-world">How JSF-2 changed the world</h3>
+<h3 id="how-jsf-2-changed-the-world">How JSF-2 changed the world<a
class="headerlink" href="#how-jsf-2-changed-the-world" title="Permanent
link">¶</a></h3>
<p>The MyFaces Orchestra community did a good summary about the various ways
to handle multiple window support in JSF Applications. Those findings are still
valid and up to date, but the environmental conditions have changed slightly
since then.
<br />
It is easy to pass a windowId around with a POST request, but it gets tricky
with GET requests. Due to the new JSF-2 ability to use bookmarkable URLs and
deep links, a typical JSF-2 application contains much more GET links than we
used to see in JSF-1, thus we have far more href links to cope with.</p>
-<h3 id="standard-windowid-handling">Standard windowId Handling</h3>
+<h3 id="standard-windowid-handling">Standard windowId Handling<a
class="headerlink" href="#standard-windowid-handling" title="Permanent
link">¶</a></h3>
<p>With a classical approach we would not be able to simply add a windowId
parameter to such links because if the user would open the link in a new
browser window or tab, we would carry the windowId - and thus the window scope
- over to the new browser tab/window. The classic solution was to omit the
windowId for all GET links, but by doing this we would now loose the window
scope far too often with JSF-2!
<br />
Marios summary also contains a method to prevent this problem by storing a
value directly in the browser window via JavaScript. Usually this is rendered
and executed in the same page as the user form. See the "Post-render window
detection" paragraph for a more detailed description.
The major downside of this solution is that we might already pollute 'foreign'
beans (and destroy their information) while rendering the page, which means
this is not feasible as general solution.</p>
-<h2 id="available-modes">Available modes</h2>
-<h3 id="clientwindow">CLIENTWINDOW</h3>
+<h2 id="available-modes">Available modes<a class="headerlink"
href="#available-modes" title="Permanent link">¶</a></h2>
+<h3 id="clientwindow">CLIENTWINDOW<a class="headerlink" href="#clientwindow"
title="Permanent link">¶</a></h3>
<p>Each GET request results in an intermediate small html page which checks if
the browser tab fits the requested windowId. <br/>
When the windowId is valid, a unique token (called <code>dsRid</code>) will be
generated for the current request and added to the URL. <br/>
In addition a cookie with with the dsRid/windowId will be added. On the server
side, the verified windowId will be extracted from the cookie.
<br/>
For POST request detection, the windowId will be added as hidden input to all
forms.</p>
-<h5 id="advantage">Advantage</h5>
+<h5 id="advantage">Advantage<a class="headerlink" href="#advantage"
title="Permanent link">¶</a></h5>
<ul>
<li>Covers all edge cases</li>
</ul>
-<h5 id="disadvantage">Disadvantage</h5>
+<h5 id="disadvantage">Disadvantage<a class="headerlink" href="#disadvantage"
title="Permanent link">¶</a></h5>
<ul>
<li>Having the windowhandler.html site rendered between requests sometimes
leads to some 'flickering' if the destination page takes some time to load. The
browser first renders our windowhandler and only after that the original page
will get loaded. <br/>
This effect may be minimized by branding the windowhandler.html page and
providing an own one with a bgcolor which matches your application.<br/>
For html-5 aware browsers we also got rid of this flickering by storing away a
'screenshot' of the first page in onclick() and immediately restore this
'screenshot' on the intermediate windowhandler.html page. Technically we do
this by storing away the <body> and css information into the html5 localStorage
and restore them on the intermediate page. We also introduced a WindowConfig
which is able to parse a request and decide upon the UserAgent or any other
information if a client will get an intermediate page or if he gets the result
page directly.</li>
</ul>
-<h4 id="change-windowhandlerhtml">Change windowhandler.html</h4>
+<h4 id="change-windowhandlerhtml">Change windowhandler.html<a
class="headerlink" href="#change-windowhandlerhtml" title="Permanent
link">¶</a></h4>
<p>To customize the look & feel of the windowhandler.html, you can simply
provide a own via:</p>
<div class="codehilite"><pre><span class="nd">@Specializes</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">MyClientWindowConfig</span> <span class="kd">extends</span> <span
class="n">DefaultClientWindowConfig</span>
@@ -254,58 +265,58 @@ For html-5 aware browsers we also got ri
<p><br/></p>
-<h3 id="lazy">LAZY</h3>
+<h3 id="lazy">LAZY<a class="headerlink" href="#lazy" title="Permanent
link">¶</a></h3>
<p>Always appends the windowId to all, from JSF generated, URLs.<br/>
On the first GET request without a windowId, it will generate a new windowId
and redirect, with the windowId in the URL, to the same view again.<br/>
The current windowId will be stored in the <code>window.name</code> variable
on the client side. <br/>
For all further requests, a lazy check will be performed to check if the
windowId in the URL is matching with the <code>window.name</code>.
If it's not matching, the view will be refreshed with the right windowId in
the URL.</p>
-<h5 id="advantage_1">Advantage</h5>
+<h5 id="advantage_1">Advantage<a class="headerlink" href="#advantage_1"
title="Permanent link">¶</a></h5>
<ul>
<li>No windowhandler.html / loading screen required</li>
</ul>
-<h5 id="disadvantage_1">Disadvantage</h5>
+<h5 id="disadvantage_1">Disadvantage<a class="headerlink"
href="#disadvantage_1" title="Permanent link">¶</a></h5>
<ul>
<li>It could happen that 2 tabs will share the same windowId for 1 request
because the <code>LAZY</code> mode will check lazily, after rendering the view,
if the windowId matches the <code>window.name</code>. Therefore it could happen
that @ViewAccessScoped or other scopes will unintentionally be destroyed.</li>
</ul>
-<h4 id="workflow-example">Workflow example</h4>
-<h5 id="first-get-request-with-windowid">First GET request with windowId</h5>
+<h4 id="workflow-example">Workflow example<a class="headerlink"
href="#workflow-example" title="Permanent link">¶</a></h4>
+<h5 id="first-get-request-with-windowid">First GET request with windowId<a
class="headerlink" href="#first-get-request-with-windowid" title="Permanent
link">¶</a></h5>
<ul>
<li>Renders the view</li>
<li>Stores the windowId as <code>window.name</code> on the client side</li>
</ul>
-<h5 id="first-get-request-without-windowid">First GET request without
windowId</h5>
+<h5 id="first-get-request-without-windowid">First GET request without
windowId<a class="headerlink" href="#first-get-request-without-windowid"
title="Permanent link">¶</a></h5>
<ul>
<li>Redirect to the same view with a new windowId in the URL</li>
<li>Renders the view</li>
<li>Stores the windowId as <code>window.name</code> on the client side</li>
</ul>
-<h5 id="further-get-request-with-windowid">Further GET request with
windowId</h5>
+<h5 id="further-get-request-with-windowid">Further GET request with windowId<a
class="headerlink" href="#further-get-request-with-windowid" title="Permanent
link">¶</a></h5>
<ul>
<li>Renders the view</li>
<li>Checks if the requested windowId matches the <code>window.name</code></li>
<li>If it does not match, reload the URL with the right windowId taken from
<code>window.name</code></li>
</ul>
-<h5 id="further-get-request-without-windowid">Further GET request without
windowId</h5>
+<h5 id="further-get-request-without-windowid">Further GET request without
windowId<a class="headerlink" href="#further-get-request-without-windowid"
title="Permanent link">¶</a></h5>
<ul>
<li>Redirect to the same view with a new windowId in the URL</li>
<li>Renders the view</li>
<li>If it does not match, reload the URL with the right windowId taken from
<code>window.name</code></li>
</ul>
-<h3 id="none">NONE</h3>
+<h3 id="none">NONE<a class="headerlink" href="#none" title="Permanent
link">¶</a></h3>
<p>Any window or browser tab detection will be disabled for the current
request.<br/>
Scopes like @WindowScoped, @GroupedConversationScoped or @ViewAccessScoped
will not work.
This is also the default mode if the current request doesn't support
Javascript or if the user agent is a bot/crawler.</p>
-<h3 id="delegated">DELEGATED</h3>
+<h3 id="delegated">DELEGATED<a class="headerlink" href="#delegated"
title="Permanent link">¶</a></h3>
<p>Delegates the complete window handling to the new JSF 2.2 ClientWindow (if
not disabled).</p>
-<h3 id="custom">CUSTOM</h3>
+<h3 id="custom">CUSTOM<a class="headerlink" href="#custom" title="Permanent
link">¶</a></h3>
<p>Enables to use an complete own
<code>org.apache.deltaspike.jsf.spi.scope.window.ClientWindow</code>
implementation.</p>
-<h2 id="configuration">Configuration</h2>
-<h3 id="dswindowid">ds:windowId</h3>
+<h2 id="configuration">Configuration<a class="headerlink"
href="#configuration" title="Permanent link">¶</a></h2>
+<h3 id="dswindowid">ds:windowId<a class="headerlink" href="#dswindowid"
title="Permanent link">¶</a></h3>
<p>The component <code>ds:windowId</code>
(<code>xmlns:ds="http://deltaspike.apache.org/jsf";</code>) is required to
enable the full control of the DeltaSpike window handling.<br/>
It will import and render the required script parts for both <code>LAZY</code>
and <code>CLIENTWINDOW</code> mode.<br/>
The best way, to apply it for all views, is to add this component to all of
your templates.</p>
-<h3 id="dsdisableclientwindow">ds:disableClientWindow</h3>
+<h3 id="dsdisableclientwindow">ds:disableClientWindow<a class="headerlink"
href="#dsdisableclientwindow" title="Permanent link">¶</a></h3>
<p>Similiar to JSF 2.2' <code>disableClientWindow</code> attribute,
<code>ds:disableClientWindow</code> provides the ability to disable the
rendering of the windowId to all links of all child components:</p>
<div class="codehilite"><pre><span
class="nt"><ds:disableClientWindow></span>
<span class="nt"><h:link</span> <span class="na">value=</span><span
class="s">"Link without windowId"</span> <span
class="na">outcome=</span><span class="s">"target.xhtml"</span> <span
class="nt">/></span>
@@ -314,7 +325,7 @@ The best way, to apply it for all views,
</pre></div>
-<h3 id="switch-mode">Switch Mode</h3>
+<h3 id="switch-mode">Switch Mode<a class="headerlink" href="#switch-mode"
title="Permanent link">¶</a></h3>
<p>To switch the mode, just provide a
<code>org.apache.deltaspike.jsf.api.config.JsfModuleConfig</code> and overwrite
<code>#getDefaultWindowMode</code>:</p>
<div class="codehilite"><pre><span class="nd">@Specializes</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">MyJsfModuleConfig</span> <span class="kd">extends</span> <span
class="n">JsfModuleConfig</span>
@@ -328,7 +339,7 @@ The best way, to apply it for all views,
</pre></div>
-<h3 id="provide-a-custom-clientwindow">Provide a custom ClientWindow</h3>
+<h3 id="provide-a-custom-clientwindow">Provide a custom ClientWindow<a
class="headerlink" href="#provide-a-custom-clientwindow" title="Permanent
link">¶</a></h3>
<p>If you would like to provide an custom
<code>org.apache.deltaspike.jsf.spi.scope.window.ClientWindow</code>
implementation, you can just do it e.g. via CDI alternatives:</p>
<div class="codehilite"><pre><span class="nd">@ApplicationScoped</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">MyClientWindow</span> <span class="kd">implements</span> <span
class="n">ClientWindow</span>
@@ -351,14 +362,14 @@ The best way, to apply it for all views,
</pre></div>
-<h2 id="based-scopes">Based Scopes</h2>
+<h2 id="based-scopes">Based Scopes<a class="headerlink" href="#based-scopes"
title="Permanent link">¶</a></h2>
<ul>
<li>@WindowScoped</li>
<li>@ViewAccessScoped</li>
<li>@GroupedConversationScoped</li>
</ul>
-<h1 id="scopes">Scopes</h1>
-<h2 id="windowscoped">@WindowScoped</h2>
+<h1 id="scopes">Scopes<a class="headerlink" href="#scopes" title="Permanent
link">¶</a></h1>
+<h2 id="windowscoped">@WindowScoped<a class="headerlink" href="#windowscoped"
title="Permanent link">¶</a></h2>
<p>The window-scope is like a session per window. That means that the data is
bound to a window/tab and it not shared between windows (like the session scope
does). Usually you need the window-scope instead of the session-scope. There
aren't a lot of use-cases which need shared data between windows.</p>
<div class="codehilite"><pre><span class="nd">@WindowScoped</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">PreferencesBean</span> <span class="kd">implements</span> <span
class="n">Serializable</span>
@@ -368,7 +379,7 @@ The best way, to apply it for all views,
</pre></div>
-<h2 id="viewaccessscoped-since-06">@ViewAccessScoped (since 0.6)</h2>
+<h2 id="viewaccessscoped-since-06">@ViewAccessScoped (since 0.6)<a
class="headerlink" href="#viewaccessscoped-since-06" title="Permanent
link">¶</a></h2>
<p>In case of conversations you have to un-scope beans manually (or they will
be terminated automatically after a timeout). However, sometimes you need beans
with a lifetime which is as long as needed and as short as possible - which are
terminated automatically (as soon as possible). In such an use-case you can use
this scope. The simple rule is, as long as the bean is referenced by a page -
the bean will be available for the next page (if it's used again the bean will
be forwarded again). It is important that it's based on the view-id of a page
(it isn't based on the request) so e.g. Ajax requests <b>don't</b> trigger a
cleanup if the request doesn't access all view-access scoped beans of the page.
That's also the reason for the name @<em>View</em>AccessScoped.</p>
<div class="codehilite"><pre><span class="nd">@ViewAccessScoped</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">WizardBean</span> <span class="kd">implements</span> <span
class="n">Serializable</span>
@@ -380,11 +391,11 @@ The best way, to apply it for all views,
<p>Hint: <br/>
@ViewAccessScoped beans are best used in conjunction with the
<code>CLIENTWINDOW</code> window handling, which ensures a clean browser-tab
separation without touching the old windowId. Otherwise a 'open in new tab' on
a page with a @ViewAccessScoped bean might cause the termination (and
re-initialization) of that bean.</p>
-<h2 id="groupedconversationscoped-since-06">@GroupedConversationScoped (since
0.6)</h2>
+<h2 id="groupedconversationscoped-since-06">@GroupedConversationScoped (since
0.6)<a class="headerlink" href="#groupedconversationscoped-since-06"
title="Permanent link">¶</a></h2>
<p>See <a href="#grouped-conversations">(Grouped-)Conversations</a></p>
-<h2 id="viewscoped">@ViewScoped</h2>
+<h2 id="viewscoped">@ViewScoped<a class="headerlink" href="#viewscoped"
title="Permanent link">¶</a></h2>
<p>DeltaSpike provides an CDI context for the JSF 2.0/2.1
@javax.faces.bean.ViewScoped. You can simply annotate your bean with
@javax.faces.bean.ViewScoped and @Named.</p>
-<h2 id="jsf-20-scopes">JSF 2.0 Scopes</h2>
+<h2 id="jsf-20-scopes">JSF 2.0 Scopes<a class="headerlink"
href="#jsf-20-scopes" title="Permanent link">¶</a></h2>
<p>JSF 2.0 introduced new annotations as well as a new scope - the View Scope.
CODI allows to use all the CDI mechanisms in beans annotated with:</p>
<ul>
<li>javax.faces.bean.ApplicationScoped</li>
@@ -394,7 +405,7 @@ The best way, to apply it for all views,
</ul>
<p>Furthermore, the managed-bean annotation (javax.faces.bean.ManagedBean) is
mapped to @Named from CDI.</p>
<p>All these annotations are mapped automatically. So you won't face issues,
if you import a JSF 2 annotation instead of the corresponding CDI
annotation.</p>
-<h1 id="integration-with-deltaspike-type-safe-messages">Integration with
DeltaSpike type-safe messages</h1>
+<h1 id="integration-with-deltaspike-type-safe-messages">Integration with
DeltaSpike type-safe messages<a class="headerlink"
href="#integration-with-deltaspike-type-safe-messages" title="Permanent
link">¶</a></h1>
<p>You can use <a href="core.html#messages-i18n">DeltaSpike type-safe
messages</a> with JSF to provide i18n messages and test to an JSF
appplicaton.</p>
<p>JSF module is also capable to use messages provided through
<message-bundle> in faces-config.xml file. The <message-bundle> element allows
you to override JSF default messages (Section 2.5.2.4 of the JSF specification
contains the list of all JSF default messages that could be override.).</p>
<p>DeltaSpike can also reuse the same file to provide type-safe messages so
you don't have to use the naming convention nor
<code>@MessageContextConfig</code>. If there is a config for supported locales
it will be checked as well and fallback to the configured default locale.</p>
@@ -447,8 +458,8 @@ The best way, to apply it for all views,
</pre></div>
-<h1 id="type-safe-view-configs">Type-safe View-Configs</h1>
-<h2 id="intro_1">Intro</h2>
+<h1 id="type-safe-view-configs">Type-safe View-Configs<a class="headerlink"
href="#type-safe-view-configs" title="Permanent link">¶</a></h1>
+<h2 id="intro_1">Intro<a class="headerlink" href="#intro_1" title="Permanent
link">¶</a></h2>
<p>Type-safe view-configs are static configs which can be used in combination
with every view-technology which is based on Java.
Currently DeltaSpike itself provides an integration for JSF, however, the
basic concepts are independent of it.
(Since DeltaSpike provides the default integration only for JSF, the whole
documentation for view-configs is located here.)</p>
@@ -457,7 +468,7 @@ In case of the JSF integration it's poss
Beyond configuring view (/pages) via this concept, it's also possible to use
the (view-)config classes for type-safe navigation.
Since it's std. Java, you can benefit from any Java-IDE and you don't need
special IDE-Addons to use it efficiently.</p>
<p>Even the concepts provided by modules (of DeltaSpike itself) are based on
the basic API provided by the Core. So it's possible to introduce custom
concepts the same way DeltaSpike itself does.</p>
-<h2 id="motivation">Motivation</h2>
+<h2 id="motivation">Motivation<a class="headerlink" href="#motivation"
title="Permanent link">¶</a></h2>
<p>Instead of learning the concepts and rules of view-configs provided by
DeltaSpike, it might be easier for simple demos to just type some simple(r)
strings.
So why should you use something which is slightly more work
<strong>initially</strong>?</p>
<p><strong>The short answer is:</strong></p>
@@ -486,9 +497,9 @@ So why should you use something which is
<li>It's possible to validate the config (if the corresponding path (view or
folder) really exists (after v0.5 it's done out-of-the-box)</li>
</ul>
<p>If you are still not convinced, you just have to try it. You will see how
your daily workflow benefits from it pretty soon.</p>
-<h2 id="bean-discovery-mode-annotated">Bean-discovery-mode annotated</h2>
+<h2 id="bean-discovery-mode-annotated">Bean-discovery-mode annotated<a
class="headerlink" href="#bean-discovery-mode-annotated" title="Permanent
link">¶</a></h2>
<p>CDI 1.1 introduced a concept called bean-discovery-mode. If you would like
to use the mode <code>annotated</code>, please have a look at the hint at <a
href="#viewconfigroot">@ViewConfigRoot</a></p>
-<h2 id="basic-api-usages">Basic API usages</h2>
+<h2 id="basic-api-usages">Basic API usages<a class="headerlink"
href="#basic-api-usages" title="Permanent link">¶</a></h2>
<p>While reading this section keep the following simple rules in mind:
<ul>
<li>Meta-data gets inherited along the path of Java inheritance</li>
@@ -575,7 +586,7 @@ One of those annotations provided by the
</pre></div>
-<h3 id="file-view-and-folder-folder-paths">File (@View) and Folder (@Folder)
paths</h3>
+<h3 id="file-view-and-folder-folder-paths">File (@View) and Folder (@Folder)
paths<a class="headerlink" href="#file-view-and-folder-folder-paths"
title="Permanent link">¶</a></h3>
<p><code>@View</code> as well as <code>@Folder</code> are optional annotations.
<code>@Folder</code> is only needed for using a different folder-name or for
marking folder configs if they don't inherit from
<code>org.apache.deltaspike.core.api.config.view.ViewConfig</code>
<strong>nor</strong> have a view-config for a page nested into them (like
Pages.Wizard1.Step1).
If it isn't used explicitly, it gets added automatically (so you can query the
meta-data at runtime even in cases you haven't placed the annotations
explicitly).
@@ -612,7 +623,7 @@ Whereas <code>@Folder</code> gets added
<li>/pages/wizard1/step1.xhtml</li>
</ul>
<p>To customize it you can use <code>@Folder#name</code>,
<code>@View#basePath</code>, <code>@View#name</code> and
<code>@View#extension</code> (or you register custom <code>NameBuilder</code>s
inline or globally).</p>
-<h4 id="foldername">@Folder#name</h4>
+<h4 id="foldername">@Folder#name<a class="headerlink" href="#foldername"
title="Permanent link">¶</a></h4>
<p>The rules are pretty simple. You will get what you write. There are only
two additional features:</p>
<ul>
<li>You don't have to care about duplicated '/' (e.g.
/folder1//folder2/step1.xhtml would get corrected auto. to
/folder1/folder2/step1.xhtml)</li>
@@ -643,7 +654,7 @@ Whereas <code>@Folder</code> gets added
<li>/w1/step1.xhtml</li>
<li>/pages/w2/step1.xhtml</li>
</ul>
-<h4 id="view">@View</h4>
+<h4 id="view">@View<a class="headerlink" href="#view" title="Permanent
link">¶</a></h4>
<p>The same naming rules apply to <code>@View#basePath</code>. However, it's
only valid to be used at view-config nodes which represent pages (-> classes
and not interfaces).
On interfaces always use <code>@Folder</code> (<code>@View#basePath</code>
will get ignored there).</p>
<div class="codehilite"><pre><span class="kd">interface</span> <span
class="nc">Pages</span>
@@ -705,10 +716,10 @@ On interfaces always use <code>@Folder</
<p>It leads to the same paths, but in addition <code>@View#navigation</code>
gets inherited along the inheritance path.</p>
-<h3 id="navigation-parameters">Navigation Parameters</h3>
+<h3 id="navigation-parameters">Navigation Parameters<a class="headerlink"
href="#navigation-parameters" title="Permanent link">¶</a></h3>
<p>Since the view-config is static, an approach to add parameters is needed.
The following part shows different possibilities to add parameters which end up
in the final URL after '?' (in case of the integration with JSF).
It isn't needed to add all (types of) parameters that way. Some get added
autom. based on special meta-data (e.g. <code>@View#navigation</code> and
<code>@View#viewParams</code>). Instead of adding
<code>"faces-redirect=true"</code> manually it's done for you as soon as you
are using <code>@View(navigation = REDIRECT)</code>. The same goes for
<code>"includeViewParams=true"</code> and <code>@View(viewParams =
INCLUDE)</code>.</p>
-<h4 id="static-configuration-via-navigationparameter">Static Configuration via
@NavigationParameter</h4>
+<h4 id="static-configuration-via-navigationparameter">Static Configuration via
@NavigationParameter<a class="headerlink"
href="#static-configuration-via-navigationparameter" title="Permanent
link">¶</a></h4>
<p>In some cases it's needed to add an information in any case. So you can
annotate the view-config class with <code>@NavigationParameter</code>.
Supported values are static strings or EL-expressions.</p>
<div class="codehilite"><pre><span class="kd">public</span> <span
class="kd">interface</span> <span class="nc">Pages</span> <span
class="kd">extends</span> <span class="n">ViewConfig</span>
<span class="o">{</span>
@@ -746,7 +757,7 @@ It isn't needed to add all (types of) pa
</pre></div>
-<h4 id="dynamic-configuration-via-navigationparametercontext">Dynamic
Configuration via NavigationParameterContext</h4>
+<h4 id="dynamic-configuration-via-navigationparametercontext">Dynamic
Configuration via NavigationParameterContext<a class="headerlink"
href="#dynamic-configuration-via-navigationparametercontext" title="Permanent
link">¶</a></h4>
<p>Instead of using parameters in a static fashion (as shown above), it's also
possible to add them dynamically (e.g. in case of special conditions).</p>
<div class="codehilite"><pre><span class="nd">@Named</span>
<span class="nd">@SessionScoped</span>
@@ -771,7 +782,7 @@ It isn't needed to add all (types of) pa
</pre></div>
-<h3 id="security-integration-via-secured">Security Integration via
@Secured</h3>
+<h3 id="security-integration-via-secured">Security Integration via @Secured<a
class="headerlink" href="#security-integration-via-secured" title="Permanent
link">¶</a></h3>
<p>This annotation is a custom view-meta-data provided by the Security-module
which allows to integrate 3rd party frameworks (or custom approaches) to secure
pages as well as whole folders.
You can annotate specific parts or a marker-interface.
<code>CustomAccessDecisionVoter</code> used in the following example can be any
implementation of
<code>org.apache.deltaspike.security.api.authorization.AccessDecisionVoter</code>
and needs to be a std. CDI bean which means you can use dependecy-injection to
trigger any kind of security check.
All parts which inherit from <code>SecuredPages</code>
(<code>Pages.Admin</code>, <code>Pages.Admin.Index</code> and
<code>Pages.Admin.Home</code>) are protected by
<code>CustomAccessDecisionVoter</code>.<br/></p>
@@ -832,7 +843,7 @@ All parts which inherit from <code>Secur
</pre></div>
-<h3 id="view-controller-callbacks-via-viewcontrollerref">View-Controller
Callbacks via @ViewControllerRef</h3>
+<h3 id="view-controller-callbacks-via-viewcontrollerref">View-Controller
Callbacks via @ViewControllerRef<a class="headerlink"
href="#view-controller-callbacks-via-viewcontrollerref" title="Permanent
link">¶</a></h3>
<p>This annotation is a custom view-meta-data provided by the JSF-module which
allows to configure beans which should act as view-controllers. That means they
can use view-controller callbacks like <code>@InitView</code>,
<code>@PreViewAction</code>, <code>@PreRenderView</code> and
<code>@PostRenderView</code>. The following example shows the usage of
<code>@PreRenderView</code>.</p>
<div class="codehilite"><pre><span class="c1">//@View //optional</span>
<span class="nd">@ViewControllerRef</span><span class="o">(</span><span
class="n">MyPageController</span><span class="o">.</span><span
class="na">class</span><span class="o">)</span>
@@ -872,7 +883,7 @@ All parts which inherit from <code>Secur
</pre></div>
-<h3 id="referencing-views-via-viewref">Referencing Views via @ViewRef</h3>
+<h3 id="referencing-views-via-viewref">Referencing Views via @ViewRef<a
class="headerlink" href="#referencing-views-via-viewref" title="Permanent
link">¶</a></h3>
<p>With <code>@ViewControllerRef#value</code> you can annotate a view-config
class to bind (/reference) a controller to it. <code>@ViewRef#config</code>
allows the same in the other direction.
Use an existing view-config to reference one or many view/s.</p>
<p>That means e.g.</p>
@@ -898,7 +909,7 @@ Use an existing view-config to reference
<p>leads to the invocation of the pre-render-view logic before
/pages/page1.xhtml gets rendered (and
it won't be called for other pages).</p>
-<h3 id="using-the-optional-viewnavigationhandler">Using the (optional)
ViewNavigationHandler</h3>
+<h3 id="using-the-optional-viewnavigationhandler">Using the (optional)
ViewNavigationHandler<a class="headerlink"
href="#using-the-optional-viewnavigationhandler" title="Permanent
link">¶</a></h3>
<p>With JSF you typically navigate with the action-method bound to a
command-component.
However, also JSF supports manual navigation via
<code>javax.faces.application.NavigationHandler</code>.
With <code>ViewNavigationHandler</code> DeltaSpike provides an equivalent
optimized for type-safe view-configs which is easier to use (and can be used
also for other (supported) view technology).</p>
@@ -923,7 +934,7 @@ With <code>ViewNavigationHandler</code>
<p>Also in this case (optional) meta-data will be used for the navigation
process, since <code>ViewNavigationHandler</code> just delegates to the active
navigation-handler (of JSF).</p>
-<h3 id="configuring-a-default-error-view">Configuring a Default Error-View</h3>
+<h3 id="configuring-a-default-error-view">Configuring a Default Error-View<a
class="headerlink" href="#configuring-a-default-error-view" title="Permanent
link">¶</a></h3>
<p>It's possible to mark one view-config class as default error-view. That
means in case of errors it will be used as navigation target automatically.
Furthermore, it's also possible to use it in your code instead of hardcoding
your error-view across the whole application.</p>
<p>In case of</p>
@@ -970,10 +981,10 @@ Furthermore, it's also possible to use i
<p>However, in case of JSF you have to ensure that you are at a valid point in
the JSF request-lifecycle for a navigation, because invocation gets transformed
to a std. (implicit) JSF navigation.</p>
-<h3 id="using-matches">Using @Matches</h3>
+<h3 id="using-matches">Using @Matches<a class="headerlink"
href="#using-matches" title="Permanent link">¶</a></h3>
<p>This annotation is currently not integrated.
[TODO]</p>
-<h3 id="using-viewconfigresolver">Using ViewConfigResolver</h3>
+<h3 id="using-viewconfigresolver">Using ViewConfigResolver<a
class="headerlink" href="#using-viewconfigresolver" title="Permanent
link">¶</a></h3>
<p>If you would like to query view-meta-data yourself (for whatever reason),
you can do that with <code>ViewConfigResolver</code>.</p>
<div class="codehilite"><pre><span class="nd">@RequestScoped</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">ApiDemoBean</span>
@@ -1018,9 +1029,9 @@ Furthermore, it's also possible to use i
<p>For folders it's optional to implement the <code>ViewConfig</code>
interface, therefore you see 2 different types of API.
<code>#getConfigDescriptor</code> as the general API and
<code>#getViewConfigDescriptor</code> which is specific for pages (which have
to implement the <code>ViewConfig</code> interface).</p>
<p><strong>Besides</strong> translating a config class to the final path of
the folder or page, it's possible to get the implicitly as well as explicitly
configured (view-)meta-data and get and/or execute configured callbacks.</p>
-<h2 id="advanced-api-usages">Advanced API usages</h2>
+<h2 id="advanced-api-usages">Advanced API usages<a class="headerlink"
href="#advanced-api-usages" title="Permanent link">¶</a></h2>
<p>[TODO]</p>
-<h3 id="creating-custom-meta-data-via-viewmetadata">Creating Custom Meta-Data
via @ViewMetaData</h3>
+<h3 id="creating-custom-meta-data-via-viewmetadata">Creating Custom Meta-Data
via @ViewMetaData<a class="headerlink"
href="#creating-custom-meta-data-via-viewmetadata" title="Permanent
link">¶</a></h3>
<p>This meta-annotation allows to create custom view-meta-data which can be
used for view-configs. Per default meta-data of a lower level overrides
meta-data on a higher level which has the same type. That can be customized via
annotating the final annotation as a whole via
<code>@Aggregated(true)</code>.</p>
<div class="codehilite"><pre><span class="nd">@ViewMetaData</span>
<span class="nd">@interface</span> <span class="n">InfoPage</span>
@@ -1039,7 +1050,7 @@ Furthermore, it's also possible to use i
</pre></div>
-<h3 id="creating-custom-meta-data-via-stereotype">Creating Custom Meta-Data
via @Stereotype</h3>
+<h3 id="creating-custom-meta-data-via-stereotype">Creating Custom Meta-Data
via @Stereotype<a class="headerlink"
href="#creating-custom-meta-data-via-stereotype" title="Permanent
link">¶</a></h3>
<p>Like with CDI itself you can encapsulate multiple view meta-data annotation
in one annotation.</p>
<p>e.g.:</p>
<div class="codehilite"><pre><span class="nd">@Target</span><span
class="o">({</span><span class="n">TYPE</span><span class="o">})</span>
@@ -1055,7 +1066,7 @@ Furthermore, it's also possible to use i
<p>Instead of using the same combination of annotations in multiple places,
you can use the stereotype annotation.
If you query the meta-data at runtime (see
<code>ViewConfigDescriptor#getMetaData</code>), you can access
<code>@Secured</code> as well as <code>@View</code> (in the example above).
however, you won't see <code>@MySecuredView</code> itself at runtime, because
stereotype annotations are per default transparent.</p>
<p>Since v1.0.1+ it's possible to access such stereotype annotations as well,
once you annotate them with <code>@ViewMetaData</code>.</p>
-<h3 id="creating-custom-callbacks-via-viewmetadata">Creating Custom Callbacks
via @ViewMetaData</h3>
+<h3 id="creating-custom-callbacks-via-viewmetadata">Creating Custom Callbacks
via @ViewMetaData<a class="headerlink"
href="#creating-custom-callbacks-via-viewmetadata" title="Permanent
link">¶</a></h3>
<p>Via a custom ConfigPreProcessor it's possible to register custom callbacks
dynamically.
The following listing shows a view-config which adds a simple callback
including the corresponding <code>ConfigPreProcessor</code> and
<code>ExecutableCallbackDescriptor</code>.</p>
<div class="codehilite"><pre><span class="nd">@ViewMetaData</span><span
class="o">(</span><span class="n">preProcessor</span> <span class="o">=</span>
<span class="n">MySecured</span><span class="o">.</span><span
class="na">AnnotationPreProcessor</span><span class="o">.</span><span
class="na">class</span><span class="o">)</span>
@@ -1103,37 +1114,37 @@ The following listing shows a view-confi
<p>It's also possible do register different callback-types per view-meta-data.
An example can be found at <code>ViewControllerRef</code> which registers
different callback-types for <code>InitView</code>, <code>PreViewAction</code>,
<code>PreRenderView</code> and <code>PostRenderView</code>. In this case it's
needed to use the type of the callback (= class of the annotation) as
additional parameter for <code>#getExecutableCallbackDescriptor</code>.</p>
-<h3 id="creating-custom-inline-meta-data-via-inlineviewmetadata">Creating
Custom inline Meta-Data via @InlineViewMetaData</h3>
+<h3 id="creating-custom-inline-meta-data-via-inlineviewmetadata">Creating
Custom inline Meta-Data via @InlineViewMetaData<a class="headerlink"
href="#creating-custom-inline-meta-data-via-inlineviewmetadata"
title="Permanent link">¶</a></h3>
<p>This annotation can be used for view-meta-data which can be placed on other
classes than view-config-classes. It's used e.g. for <code>@ViewRef</code>.
Via a <code>TargetViewConfigProvider</code> it's possible to point to the
view-config the meta-data should get applied to and via
<code>InlineMetaDataTransformer</code> it's possible to convert it to a
different meta-data-representation (which allows that at runtime you only have
to support one side since the inline-meta-data was converted to the same
meta-data representation which is used for the normal view-meta-data).</p>
-<h2 id="path-validation">Path-Validation</h2>
+<h2 id="path-validation">Path-Validation<a class="headerlink"
href="#path-validation" title="Permanent link">¶</a></h2>
<p>DeltaSpike (after v0.5) validates your configs out-of-the-box. The
application will fail to start, if there is an invalid config (e.g. a
view-config without a corresponding view).
Right now the validation is restricted to folders and view-ids with .xhtml or
.jsp as suffix. Other view-ids (e.g. *.faces) don't get checked. In such cases
a custom validator can be used (e.g. based on
<code>ViewConfigPathValidator</code>).</p>
<p>To disable the view-config (path) validation, add a
<code>ClassDeactivator</code> which restricts
<code>org.apache.deltaspike.jsf.impl.config.view.ViewConfigPathValidator</code>.</p>
-<h2 id="view-config-spi">View-Config SPI</h2>
+<h2 id="view-config-spi">View-Config SPI<a class="headerlink"
href="#view-config-spi" title="Permanent link">¶</a></h2>
<p>[TODO]</p>
-<h3 id="configdescriptorvalidator">ConfigDescriptorValidator</h3>
+<h3 id="configdescriptorvalidator">ConfigDescriptorValidator<a
class="headerlink" href="#configdescriptorvalidator" title="Permanent
link">¶</a></h3>
<p>Allows to validate the final view-config descriptors before they get
deployed.
Since the config-descriptor contains e.g. the final path, it's also possible
to validate if the corresponding file exists.
Use <code>@ViewConfigRoot</code> to configure 1-n validators.</p>
-<h3 id="confignodeconverter">ConfigNodeConverter</h3>
+<h3 id="confignodeconverter">ConfigNodeConverter<a class="headerlink"
href="#confignodeconverter" title="Permanent link">¶</a></h3>
<p>Allows to provide custom strategies to process the nodes of the built
config-tree.
Use <code>@ViewConfigRoot</code> to configure a custom converter.</p>
-<h3 id="configpreprocessor">ConfigPreProcessor</h3>
+<h3 id="configpreprocessor">ConfigPreProcessor<a class="headerlink"
href="#configpreprocessor" title="Permanent link">¶</a></h3>
<p>Allows to change the found meta-data (e.g. replace default values,
callbacks,...) or the <code>ViewConfigNode</code> itself.</p>
-<h3 id="inlinemetadatatransformer">InlineMetaDataTransformer</h3>
+<h3 id="inlinemetadatatransformer">InlineMetaDataTransformer<a
class="headerlink" href="#inlinemetadatatransformer" title="Permanent
link">¶</a></h3>
<p>Allows to transform an annotation annotated with
<code>@InlineViewMetaData</code> to an annotation annotated with
<code>@ViewMetaData</code>.
This transformer is optional and only needed if it should result in the same
at runtime, but the inline-meta-data needs a different syntax via a different
annotation (compared to the view-config meta-data).
See e.g. <code>@ViewRef</code> vs. <code>@ViewControllerRef</code>.</p>
-<h3 id="targetviewconfigprovider">TargetViewConfigProvider</h3>
+<h3 id="targetviewconfigprovider">TargetViewConfigProvider<a
class="headerlink" href="#targetviewconfigprovider" title="Permanent
link">¶</a></h3>
<p>Allows to provide a custom reference to <code>ViewConfig</code> classes
(see e.g. <code>@InlineViewMetaData</code> and <code>@ViewRef</code>)</p>
-<h3 id="viewconfiginheritancestrategy">ViewConfigInheritanceStrategy</h3>
+<h3 id="viewconfiginheritancestrategy">ViewConfigInheritanceStrategy<a
class="headerlink" href="#viewconfiginheritancestrategy" title="Permanent
link">¶</a></h3>
<p>Allows to customize the inheritance-strategy for meta-data.
E.g. inheritance via std. java inheritance vs. inheritance via nested
interfaces.
Use <code>@ViewConfigRoot</code> to configure a custom
inheritance-strategy.</p>
-<h3 id="viewconfignode">ViewConfigNode</h3>
+<h3 id="viewconfignode">ViewConfigNode<a class="headerlink"
href="#viewconfignode" title="Permanent link">¶</a></h3>
<p>Node-type used for building the meta-data-tree during the bootstrapping
process.</p>
-<h3 id="viewconfigroot">@ViewConfigRoot</h3>
+<h3 id="viewconfigroot">@ViewConfigRoot<a class="headerlink"
href="#viewconfigroot" title="Permanent link">¶</a></h3>
<p>Optional annotation which allows to provide custom implementations.
Only annotate one <code>ViewConfig</code> class which represents the root
node.</p>
<p>If you are using CDI 1.1+ with bean-discovery-mode <code>annotated</code>,
you can use <code>@ViewConfigRoot</code> in combination with
<code>@ApplicationScoped</code> as marker annotations. Since DeltaSpike 1.0.1
this combination allows to add all nested interfaces and classes and therefore
no additional annotations (required by bean-discovery-mode
<code>annotated</code>) are needed.
@@ -1147,11 +1158,11 @@ Minimal example:</p>
</pre></div>
-<h2 id="activation-of-custom-naming-conventions">Activation of custom naming
conventions</h2>
+<h2 id="activation-of-custom-naming-conventions">Activation of custom naming
conventions<a class="headerlink"
href="#activation-of-custom-naming-conventions" title="Permanent
link">¶</a></h2>
<p>DeltaSpike allows to customize the default naming convention via
<code>View.DefaultBasePathBuilder</code> and/or
<code>View.DefaultFileNameBuilder</code> and/or
<code>View.DefaultExtensionBuilder</code>.
It's possible to change it for one usage via <code>View.basePathBuilder</code>
and/or <code>View.fileNameBuilder</code> and/or
<code>View.extensionBuilder</code> or globally via the config mechanism
provided by DeltaSpike.
The same is supported for folders via
<code>Folder.DefaultFolderNameBuilder</code>. In this case changing only one
usage is possible via <code>Folder.folderNameBuilder</code>.</p>
-<h1 id="grouped-conversations">(Grouped-)Conversations</h1>
+<h1 id="grouped-conversations">(Grouped-)Conversations<a class="headerlink"
href="#grouped-conversations" title="Permanent link">¶</a></h1>
<p>Available with all versions after 0.5.</p>
<p>DeltaSpike conversations are based on the window-scope. Therefore, don't
forget to add the <code>ds:windowId</code>
(<code>xmlns:ds="http://deltaspike.apache.org/jsf";</code>) component in case of
<code>ClientWindowConfig#CLIENTWINDOW</code> to your page(/template) and ensure
that the window-handling works properly (otherwise conversations won't work
correctly).
The base principle is similar to CODI-Conversations. CODI users just have to
ensure that they have to add <code>ds:windowId</code> and the names are
slightly different.</p>
@@ -1248,7 +1259,7 @@ If you have an use-case (e.g. a wizard)
</pre></div>
-<h2 id="terminating-conversations">Terminating Conversations</h2>
+<h2 id="terminating-conversations">Terminating Conversations<a
class="headerlink" href="#terminating-conversations" title="Permanent
link">¶</a></h2>
<p>You can inject the conversation via <code>@Inject</code> and use it to
terminate the conversation immediately or you inject the
<code>GroupedConversationManager</code> which can be used to terminate a given
conversation (group). All conversations within a window are closed autom., once
<code>WindowContext#closeWindow</code> gets called for the window.</p>
<p>Example - Injecting and using the current conversation:</p>
<div class="codehilite"><pre><span class="nd">@GroupedConversationScoped</span>
@@ -1352,7 +1363,7 @@ If you have an use-case (e.g. a wizard)
<p>Hint:
DeltaSpike conversations get closed/restarted immediately instead of keeping
them until the end of the request like std. conversations do, because the
behaviour of std. conversations breaks a lot of use-cases. However, if you
really need to keep them until the end of the request, you can close them in a
<code>@PostRenderView</code> callback.</p>
-<h2 id="sub-conversation-groups">Sub-Conversation-Groups</h2>
+<h2 id="sub-conversation-groups">Sub-Conversation-Groups<a class="headerlink"
href="#sub-conversation-groups" title="Permanent link">¶</a></h2>
<p>Due to the parallel conversation concept of DeltaSpike there is no need of
something like nested conversations. Just use them in parallel and terminate
them in a fine-granular way as soon as you don't need them any longer. As
described above, you can terminate a whole conversation-group. However,
sometimes it's essential to have subgroups if you need to end just a part of an
use-case instead of all beans related to an use-case.
A sub-group is just a class or an interface used to identify a bunch of beans
within a group. To terminate such a sub-group, it's just needed to pass the
class/interface to the corresponding API for terminating a conversation. The
sub-group gets detected autom. and instead of terminating a whole
conversation-group, the beans of the sub-group get un-scoped.</p>
<p>Example - Explicitly listing beans of a sub-group:</p>
@@ -1411,13 +1422,13 @@ A sub-group is just a class or an interf
<p>In the listing above all beans which implement the Wizard interface will be
closed as soon as you close the ImplicitSubGroup.</p>
-<h1 id="injection-in-jsf-artifacts-todo">Injection in JSF Artifacts (TODO)</h1>
-<h2 id="converter-validator">Converter & Validator</h2>
-<h2 id="phaselistener">PhaseListener</h2>
-<h1 id="event-broadcasting">Event broadcasting</h1>
-<h2 id="beforejsfrequest-afterjsfrequest-todo">BeforeJsfRequest /
AfterJsfRequest (TODO)</h2>
-<h2 id="beforephase-afterphase-todo">BeforePhase / AfterPhase (TODO)</h2>
-<h2 id="jsf-systemevents">JSF SystemEvents</h2>
+<h1 id="injection-in-jsf-artifacts-todo">Injection in JSF Artifacts (TODO)<a
class="headerlink" href="#injection-in-jsf-artifacts-todo" title="Permanent
link">¶</a></h1>
+<h2 id="converter-validator">Converter & Validator<a class="headerlink"
href="#converter-validator" title="Permanent link">¶</a></h2>
+<h2 id="phaselistener">PhaseListener<a class="headerlink"
href="#phaselistener" title="Permanent link">¶</a></h2>
+<h1 id="event-broadcasting">Event broadcasting<a class="headerlink"
href="#event-broadcasting" title="Permanent link">¶</a></h1>
+<h2 id="beforejsfrequest-afterjsfrequest-todo">BeforeJsfRequest /
AfterJsfRequest (TODO)<a class="headerlink"
href="#beforejsfrequest-afterjsfrequest-todo" title="Permanent
link">¶</a></h2>
+<h2 id="beforephase-afterphase-todo">BeforePhase / AfterPhase (TODO)<a
class="headerlink" href="#beforephase-afterphase-todo" title="Permanent
link">¶</a></h2>
+<h2 id="jsf-systemevents">JSF SystemEvents<a class="headerlink"
href="#jsf-systemevents" title="Permanent link">¶</a></h2>
<p>Following JSF SystemEvents can be observed via CDI:</p>
<ul>
<li>javax.faces.event.PostConstructApplicationEvent</li>
@@ -1436,10 +1447,10 @@ A sub-group is just a class or an interf
</pre></div>
-<h1 id="intergration-with-exception-control-since-06">Intergration with
Exception Control (since 0.6)</h1>
+<h1 id="intergration-with-exception-control-since-06">Intergration with
Exception Control (since 0.6)<a class="headerlink"
href="#intergration-with-exception-control-since-06" title="Permanent
link">¶</a></h1>
<p>Whenever a unhandled exception occurs within the JSF lifecycle, our JSF
ExceptionHandler provides a integration to the DeltaSpike Exception Control.</p>
-<h2 id="examples">Examples</h2>
-<h3 id="basic">Basic</h3>
+<h2 id="examples">Examples<a class="headerlink" href="#examples"
title="Permanent link">¶</a></h2>
+<h3 id="basic">Basic<a class="headerlink" href="#basic" title="Permanent
link">¶</a></h3>
<div class="codehilite"><pre><span class="nd">@ExceptionHandler</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">ApplicationExceptionHandler</span>
<span class="o">{</span>
@@ -1454,7 +1465,7 @@ A sub-group is just a class or an interf
</pre></div>
-<h3 id="redirect">Redirect</h3>
+<h3 id="redirect">Redirect<a class="headerlink" href="#redirect"
title="Permanent link">¶</a></h3>
<div class="codehilite"><pre><span class="nd">@ExceptionHandler</span>
<span class="kd">public</span> <span class="kd">class</span> <span
class="nc">ApplicationExceptionHandler</span>
<span class="o">{</span>
@@ -1472,7 +1483,7 @@ A sub-group is just a class or an interf
</pre></div>
-<h2 id="using-a-custom-qualifier-for-jsf-exceptions">Using a custom qualifier
for JSF Exceptions</h2>
+<h2 id="using-a-custom-qualifier-for-jsf-exceptions">Using a custom qualifier
for JSF Exceptions<a class="headerlink"
href="#using-a-custom-qualifier-for-jsf-exceptions" title="Permanent
link">¶</a></h2>
<p>In some cases, it's required to differentiate exceptions from JSF and
normal exceptions.
This is possible via a CDI qualifier:</p>
<div class="codehilite"><pre><span class="nd">@Target</span><span
class="o">({</span> <span class="n">ElementType</span><span
class="o">.</span><span class="na">TYPE</span><span class="o">,</span> <span
class="n">ElementType</span><span class="o">.</span><span
class="na">PARAMETER</span> <span class="o">})</span>
@@ -1509,7 +1520,7 @@ This is possible via a CDI qualifier:</p
</pre></div>
-<h1 id="double-submit-prevention">Double-Submit prevention</h1>
+<h1 id="double-submit-prevention">Double-Submit prevention<a
class="headerlink" href="#double-submit-prevention" title="Permanent
link">¶</a></h1>
<p>To avoid that the same content of a form gets submitted and therefore
processed multiple times, it's possible to use the tag
<code><ds:preventDoubleSubmit/></code>.
As usual for DeltaSpike JSF-tags, the <code>ds</code> namespace is
<code>http://deltaspike.apache.org/jsf</code>. Just add this tag within every
JSF form-tag, you would like to safeguard.</p>
<div class="codehilite"><pre><span class="nt"><html</span> <span
class="na">xmlns=</span><span
class="s">"http://www.w3.org/1999/xhtml"</span>
@@ -1528,9 +1539,9 @@ As usual for DeltaSpike JSF-tags, the <c
</pre></div>
-<h1 id="support-of-ear-deployments">Support of EAR deployments</h1>
+<h1 id="support-of-ear-deployments">Support of EAR deployments<a
class="headerlink" href="#support-of-ear-deployments" title="Permanent
link">¶</a></h1>
<p>Before using features described by this page, please ensure that you are
aware of <a
href="https://issues.apache.org/jira/browse/DELTASPIKE-335";>DELTASPIKE-335</a>
and the corresponding impact.</p>
-<h1 id="hints">Hints</h1>
+<h1 id="hints">Hints<a class="headerlink" href="#hints" title="Permanent
link">¶</a></h1>
<p>Using errorView, DefaultErrorView or ViewNavigationHandler will fail with
Weld versions below 1.1.10 due to <a
href="https://issues.jboss.org/browse/WELD-1178";>WELD-1178</a>.</p>
</div>
</div>
@@ -1538,7 +1549,7 @@ As usual for DeltaSpike JSF-tags, the <c
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/migration-guide.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/migration-guide.html
(original)
+++ websites/staging/deltaspike/trunk/content/retired/migration-guide.html Sat
Aug 1 21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>Migrate from MyFaces CODI-Core to DeltaSpike</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#apache-myfaces-codi-to-apache-deltaspike">Apache MyFaces CODI to
Apache DeltaSpike</a><ul>
@@ -118,47 +129,47 @@
</ul>
</div>
<hr />
-<h1 id="introduction">Introduction</h1>
-<h1 id="apache-myfaces-codi-to-apache-deltaspike">Apache MyFaces CODI to
Apache DeltaSpike</h1>
-<h2 id="example-overview">Example Overview</h2>
+<h1 id="introduction">Introduction<a class="headerlink" href="#introduction"
title="Permanent link">¶</a></h1>
+<h1 id="apache-myfaces-codi-to-apache-deltaspike">Apache MyFaces CODI to
Apache DeltaSpike<a class="headerlink"
href="#apache-myfaces-codi-to-apache-deltaspike" title="Permanent
link">¶</a></h1>
+<h2 id="example-overview">Example Overview<a class="headerlink"
href="#example-overview" title="Permanent link">¶</a></h2>
<ul>
<li><a href="http://s.apache.org/xA";>Fullstack CODI to DeltaSpike @
os890</a></li>
</ul>
-<h2 id="basically-unchanged-parts">Basically unchanged parts</h2>
+<h2 id="basically-unchanged-parts">Basically unchanged parts<a
class="headerlink" href="#basically-unchanged-parts" title="Permanent
link">¶</a></h2>
<p>Here you can see features which were added and the concept itself didn't
change (only the packages, config keys,...)</p>
-<h3 id="project-stage">Project-stage</h3>
+<h3 id="project-stage">Project-stage<a class="headerlink"
href="#project-stage" title="Permanent link">¶</a></h3>
<p>Only the config key changed [TODO]</p>
-<h3 id="deactivatable-and-classdeactivator">Deactivatable and
ClassDeactivator</h3>
+<h3 id="deactivatable-and-classdeactivator">Deactivatable and
ClassDeactivator<a class="headerlink"
href="#deactivatable-and-classdeactivator" title="Permanent
link">¶</a></h3>
<p>The concept hasn't changed.</p>
-<h3 id="codiconfig">CodiConfig</h3>
+<h3 id="codiconfig">CodiConfig<a class="headerlink" href="#codiconfig"
title="Permanent link">¶</a></h3>
<p>The concept hasn't changed.</p>
-<h3 id="annotation-literals">Annotation literals</h3>
+<h3 id="annotation-literals">Annotation literals<a class="headerlink"
href="#annotation-literals" title="Permanent link">¶</a></h3>
<p>The concept hasn't changed. We just added further implementations.</p>
-<h3 id="beanmanagerprovider">BeanManagerProvider</h3>
+<h3 id="beanmanagerprovider">BeanManagerProvider<a class="headerlink"
href="#beanmanagerprovider" title="Permanent link">¶</a></h3>
<p>The concept hasn't changed. We just splitted the functionality. The util
methods are available in BeanProvider and their name and signature have been
unified.</p>
-<h2 id="extended-concepts">Extended concepts</h2>
+<h2 id="extended-concepts">Extended concepts<a class="headerlink"
href="#extended-concepts" title="Permanent link">¶</a></h2>
<p>Here you can see features which were added and the concept itself changed a
bit or got merged with concepts from Seam3</p>
-<h3 id="configuredvalueresolver">ConfiguredValueResolver</h3>
+<h3 id="configuredvalueresolver">ConfiguredValueResolver<a class="headerlink"
href="#configuredvalueresolver" title="Permanent link">¶</a></h3>
<p>Here we added more flexibility (esp. re-ordering the default lookup
mechanisms). See <code>ConfigResolver</code>, <code>ConfigSourceProvider</code>
and <code>ConfigSource</code>.</p>
-<h3 id="projectstageactivated-and-expressionactivated">ProjectStageActivated
and ExpressionActivated</h3>
+<h3 id="projectstageactivated-and-expressionactivated">ProjectStageActivated
and ExpressionActivated<a class="headerlink"
href="#projectstageactivated-and-expressionactivated" title="Permanent
link">¶</a></h3>
<p>We merged them with a feature of Seam3 and now it's called
<code>@Exclude</code>. That means the basic functionality is still in place
(nothing was removed), but the logic is now inverse.</p>
-<h3 id="defaultannotation">DefaultAnnotation</h3>
+<h3 id="defaultannotation">DefaultAnnotation<a class="headerlink"
href="#defaultannotation" title="Permanent link">¶</a></h3>
<p>(In progress) We merge it with a similar helper of Seam-Solder to provide
custom values for annotation attributes.</p>
-<h2 id="postponed-concepts">Postponed concepts</h2>
+<h2 id="postponed-concepts">Postponed concepts<a class="headerlink"
href="#postponed-concepts" title="Permanent link">¶</a></h2>
<p>We couldn't agree on these features. If you find them useful, please
contact the mailing-list. If we see that users need it for reasons we might
haven't seen so far, we will discuss it again.</p>
-<h3 id="beannames">BeanNames</h3>
-<h2 id="dropped-concepts">Dropped concepts</h2>
-<h3 id="java-15-support">Java 1.5 Support</h3>
-<h2 id="jsf-module">JSF Module</h2>
-<h3 id="type-safe-view-config">Type-safe view config</h3>
+<h3 id="beannames">BeanNames<a class="headerlink" href="#beannames"
title="Permanent link">¶</a></h3>
+<h2 id="dropped-concepts">Dropped concepts<a class="headerlink"
href="#dropped-concepts" title="Permanent link">¶</a></h2>
+<h3 id="java-15-support">Java 1.5 Support<a class="headerlink"
href="#java-15-support" title="Permanent link">¶</a></h3>
+<h2 id="jsf-module">JSF Module<a class="headerlink" href="#jsf-module"
title="Permanent link">¶</a></h2>
+<h3 id="type-safe-view-config">Type-safe view config<a class="headerlink"
href="#type-safe-view-config" title="Permanent link">¶</a></h3>
<ul>
<li>Changed names</li>
<li>Annotations are optional</li>
</ul>
<p>... ([TODO])</p>
-<h1 id="jboss-seam2-to-apache-deltaspike">JBoss Seam2 to Apache DeltaSpike</h1>
+<h1 id="jboss-seam2-to-apache-deltaspike">JBoss Seam2 to Apache DeltaSpike<a
class="headerlink" href="#jboss-seam2-to-apache-deltaspike" title="Permanent
link">¶</a></h1>
<p>[TODO]</p>
-<h1 id="jboss-seam3-to-apache-deltaspike">JBoss Seam3 to Apache DeltaSpike</h1>
+<h1 id="jboss-seam3-to-apache-deltaspike">JBoss Seam3 to Apache DeltaSpike<a
class="headerlink" href="#jboss-seam3-to-apache-deltaspike" title="Permanent
link">¶</a></h1>
<p>[TODO]</p>
</div>
</div>
@@ -166,7 +177,7 @@
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/new-committer.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/new-committer.html
(original)
+++ websites/staging/deltaspike/trunk/content/retired/new-committer.html Sat
Aug 1 21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>New Committer</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#introduction">Introduction</a><ul>
<li><a href="#invitation-to-become-a-project-committer">Invitation to become a
project Committer</a></li>
@@ -93,12 +104,12 @@
</ul>
</div>
<hr />
-<h1 id="introduction">Introduction</h1>
-<h2 id="invitation-to-become-a-project-committer">Invitation to become a
project Committer</h2>
+<h1 id="introduction">Introduction<a class="headerlink" href="#introduction"
title="Permanent link">¶</a></h1>
+<h2 id="invitation-to-become-a-project-committer">Invitation to become a
project Committer<a class="headerlink"
href="#invitation-to-become-a-project-committer" title="Permanent
link">¶</a></h2>
<p>If a person contributes an sufficient amount of code or documentation to
our project she might get picked up as a committer to our project.
As soon as the PMC is confident that you are a great addition to the team, one
of the PMC members start will start an internal DISCUSS thread and later on an
internal VOTE.</p>
-<h1 id="pmc">PMC</h1>
-<h2 id="votes">Votes</h2>
+<h1 id="pmc">PMC<a class="headerlink" href="#pmc" title="Permanent
link">¶</a></h1>
+<h2 id="votes">Votes<a class="headerlink" href="#votes" title="Permanent
link">¶</a></h2>
<p>To: private list
CC: private incubator list</p>
<div class="codehilite"><pre><span class="p">[</span><span
class="n">VOTE</span><span class="p">]</span> <span class="p">...</span> <span
class="n">becoming</span> <span class="n">a</span> <span
class="n">committer</span>
@@ -203,7 +214,7 @@ To: private list</p>
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/news.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/news.html (original)
+++ websites/staging/deltaspike/trunk/content/retired/news.html Sat Aug 1
21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>Apache DeltaSpike News</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#overview">Overview</a><ul>
<li><a href="#13th-release-120-30112014">13th Release (1.2.0)
(30.11.2014)</a></li>
@@ -127,94 +138,94 @@
</ul>
</div>
<hr />
-<h1 id="overview">Overview</h1>
-<h2 id="13th-release-120-30112014">13th Release (1.2.0) (30.11.2014)</h2>
+<h1 id="overview">Overview<a class="headerlink" href="#overview"
title="Permanent link">¶</a></h1>
+<h2 id="13th-release-120-30112014">13th Release (1.2.0) (30.11.2014)<a
class="headerlink" href="#13th-release-120-30112014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 13th release
(v1.2.0).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.2.0";>release notes</a>
contains 22 JIRA tickets.</p>
-<h2 id="new-pmc-member-20112014">New PMC Member (20.11.2014)</h2>
+<h2 id="new-pmc-member-20112014">New PMC Member (20.11.2014)<a
class="headerlink" href="#new-pmc-member-20112014" title="Permanent
link">¶</a></h2>
<p>Thomas Andraschko joined our PMC.</p>
-<h2 id="12th-release-110-01112014">12th Release (1.1.0) (01.11.2014)</h2>
+<h2 id="12th-release-110-01112014">12th Release (1.1.0) (01.11.2014)<a
class="headerlink" href="#12th-release-110-01112014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 12th release
(v1.1.0).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.1.0";>release notes</a>
contains 24 JIRA tickets.</p>
-<h2 id="dukes-choice-award-28092014">Duke's Choice Award (28.09.2014)</h2>
+<h2 id="dukes-choice-award-28092014">Duke's Choice Award (28.09.2014)<a
class="headerlink" href="#dukes-choice-award-28092014" title="Permanent
link">¶</a></h2>
<p>We won a <a
href="https://blogs.oracle.com/java/entry/2014_duke_s_choice_award";>Duke's
Choice Award</a>!</p>
-<h2 id="11th-release-103-21092014">11th Release (1.0.3) (21.09.2014)</h2>
+<h2 id="11th-release-103-21092014">11th Release (1.0.3) (21.09.2014)<a
class="headerlink" href="#11th-release-103-21092014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 11th release
(v1.0.3).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.0.3";>release notes</a>
contains 20 JIRA tickets.</p>
-<h2 id="10th-release-102-17082014">10th Release (1.0.2) (17.08.2014)</h2>
+<h2 id="10th-release-102-17082014">10th Release (1.0.2) (17.08.2014)<a
class="headerlink" href="#10th-release-102-17082014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 10th release
(v1.0.2).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.0.2";>release notes</a>
contains 15 JIRA tickets.</p>
-<h2 id="9th-release-101-13072014">9th Release (1.0.1) (13.07.2014)</h2>
+<h2 id="9th-release-101-13072014">9th Release (1.0.1) (13.07.2014)<a
class="headerlink" href="#9th-release-101-13072014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 9th release
(v1.0.1).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.0.1";>release notes</a>
contains 18 JIRA tickets.</p>
-<h2 id="8th-release-100-14062014">8th Release (1.0.0) (14.06.2014)</h2>
+<h2 id="8th-release-100-14062014">8th Release (1.0.0) (14.06.2014)<a
class="headerlink" href="#8th-release-100-14062014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 8th release
(v1.0.0).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_1.0.0";>release notes</a>
contains 48 JIRA tickets.</p>
-<h2 id="new-committer-18052014">New Committer (18.05.2014)</h2>
+<h2 id="new-committer-18052014">New Committer (18.05.2014)<a
class="headerlink" href="#new-committer-18052014" title="Permanent
link">¶</a></h2>
<p>Rafael Benevides joined our development community.</p>
-<h2 id="7th-release-07-03052014">7th Release (0.7) (03.05.2014)</h2>
+<h2 id="7th-release-07-03052014">7th Release (0.7) (03.05.2014)<a
class="headerlink" href="#7th-release-07-03052014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 7th release
(v0.7).</p>
<p>The <a href="http://s.apache.org/DS-0.7-RNotes";>release notes</a> contains
35 JIRA tickets.</p>
-<h2 id="6th-release-06-20032014">6th Release (0.6) (20.03.2014)</h2>
+<h2 id="6th-release-06-20032014">6th Release (0.6) (20.03.2014)<a
class="headerlink" href="#6th-release-06-20032014" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 6th release
(v0.6).</p>
<p>The <a href="http://s.apache.org/DS-0.6-RNotes";>release notes</a> contains
102 JIRA tickets.</p>
-<h2 id="new-committer-14122013">New Committer (14.12.2013)</h2>
+<h2 id="new-committer-14122013">New Committer (14.12.2013)<a
class="headerlink" href="#new-committer-14122013" title="Permanent
link">¶</a></h2>
<p>Thomas Andraschko joined our development community.</p>
-<h2 id="5th-release-05-18092013">5th Release (0.5) (18.09.2013)</h2>
+<h2 id="5th-release-05-18092013">5th Release (0.5) (18.09.2013)<a
class="headerlink" href="#5th-release-05-18092013" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the 5th release
(v0.5).</p>
<p>The <a href="http://s.apache.org/DS-0.5-RNotes";>release notes</a> contains
29 JIRA tickets.</p>
-<h2 id="4th-release-04-31052013">4th Release (0.4) (31.05.2013)</h2>
+<h2 id="4th-release-04-31052013">4th Release (0.4) (31.05.2013)<a
class="headerlink" href="#4th-release-04-31052013" title="Permanent
link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the fourth release
(v0.4). This is our first release as a top level project!</p>
<p>The <a href="http://s.apache.org/DS-0.4-RNotes";>release notes</a> contains
a large list of bug fixes and new features.</p>
-<h2 id="graduation-28052013">Graduation (28.05.2013)</h2>
+<h2 id="graduation-28052013">Graduation (28.05.2013)<a class="headerlink"
href="#graduation-28052013" title="Permanent link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce that we have complete
graduation as a top level project.</p>
-<h2 id="3rd-release-03-incubating-22082012">3rd Release (0.3 incubating)
(22.08.2012)</h2>
+<h2 id="3rd-release-03-incubating-22082012">3rd Release (0.3 incubating)
(22.08.2012)<a class="headerlink" href="#3rd-release-03-incubating-22082012"
title="Permanent link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the second release
(v0.3-incubating).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_03incubating";>release notes</a>
contains 104 JIRA tickets.</p>
-<h2 id="new-committer-21082012">New Committer (21.08.2012)</h2>
+<h2 id="new-committer-21082012">New Committer (21.08.2012)<a
class="headerlink" href="#new-committer-21082012" title="Permanent
link">¶</a></h2>
<p>BolesÅaw Dawidowicz joined our development community.</p>
-<h2 id="new-committers-11072012">New Committers (11.07.2012)</h2>
+<h2 id="new-committers-11072012">New Committers (11.07.2012)<a
class="headerlink" href="#new-committers-11072012" title="Permanent
link">¶</a></h2>
<p>Charles Moulliard and Romain Manni-Bucau joined our development
community.</p>
-<h2 id="apache-cms-30052012">Apache CMS (30.05.2012)</h2>
+<h2 id="apache-cms-30052012">Apache CMS (30.05.2012)<a class="headerlink"
href="#apache-cms-30052012" title="Permanent link">¶</a></h2>
<p>The setup of the project-site in Apache CMS started.</p>
-<h2 id="2nd-release-02-incubating-22042012">2nd Release (0.2 incubating)
(22.04.2012)</h2>
+<h2 id="2nd-release-02-incubating-22042012">2nd Release (0.2 incubating)
(22.04.2012)<a class="headerlink" href="#2nd-release-02-incubating-22042012"
title="Permanent link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to announce the second release
(v0.2-incubating).</p>
<p>The <a href="http://s.apache.org/DeltaSpike_02incubating";>release notes</a>
contains 61 JIRA tickets.</p>
-<h2 id="1st-release-01-incubating-10022012">1st Release (0.1 incubating)
(10.02.2012)</h2>
+<h2 id="1st-release-01-incubating-10022012">1st Release (0.1 incubating)
(10.02.2012)<a class="headerlink" href="#1st-release-01-incubating-10022012"
title="Permanent link">¶</a></h2>
<p>The Apache DeltaSpike team is pleased to <a
href="http://s.apache.org/cTt";>announce</a> the first release
(v0.1-incubating).</p>
<p>The first release contains about 5 000 lines of code (including tests and
10 000 including comments).
The <a href="http://s.apache.org/DeltaSpike_01incubating";>release notes</a>
contains 42 JIRA tickets.</p>
-<h2 id="execution-of-integration-tests-with-remote-servers-01022012">Execution
of integration tests with remote servers (01.02.2012)</h2>
+<h2 id="execution-of-integration-tests-with-remote-servers-01022012">Execution
of integration tests with remote servers (01.02.2012)<a class="headerlink"
href="#execution-of-integration-tests-with-remote-servers-01022012"
title="Permanent link">¶</a></h2>
<p>C4J helps us with nightly builds which deploy our integration tests to
remote-servers (AS7 and GF3).</p>
-<h2 id="new-committer-29012012">New Committer (29.01.2012)</h2>
+<h2 id="new-committer-29012012">New Committer (29.01.2012)<a
class="headerlink" href="#new-committer-29012012" title="Permanent
link">¶</a></h2>
<p>Lukasz Lenart joined our development community.</p>
-<h2 id="new-committer-28012012">New Committer (28.01.2012)</h2>
+<h2 id="new-committer-28012012">New Committer (28.01.2012)<a
class="headerlink" href="#new-committer-28012012" title="Permanent
link">¶</a></h2>
<p>Christian Kaltepoth joined our development community.</p>
-<h2 id="new-committer-27012012">New Committer (27.01.2012)</h2>
+<h2 id="new-committer-27012012">New Committer (27.01.2012)<a
class="headerlink" href="#new-committer-27012012" title="Permanent
link">¶</a></h2>
<p>Rudy De Busscher joined our development community.</p>
-<h2 id="nabble-mirror-21012012">Nabble Mirror (21.01.2012)</h2>
+<h2 id="nabble-mirror-21012012">Nabble Mirror (21.01.2012)<a
class="headerlink" href="#nabble-mirror-21012012" title="Permanent
link">¶</a></h2>
<p>Dan Allen created a <a
href="http://s.apache.org/deltaspike-dev_nabble";>Nabble mirror</a> for the
dev-list (based on <a
href="http://incubator.apache.org/mail/deltaspike-dev/";>http://incubator.apache.org/mail/deltaspike-dev/</a>)</p>
-<h2 id="new-committers-13012012">New Committers (13.01.2012)</h2>
+<h2 id="new-committers-13012012">New Committers (13.01.2012)<a
class="headerlink" href="#new-committers-13012012" title="Permanent
link">¶</a></h2>
<p>Dan Allen and Lincoln Baxter III are our first committers after the initial
committers.</p>
-<h2 id="github-mirror-12012012">GitHub Mirror (12.01.2012)</h2>
+<h2 id="github-mirror-12012012">GitHub Mirror (12.01.2012)<a
class="headerlink" href="#github-mirror-12012012" title="Permanent
link">¶</a></h2>
<p>The infra team created our mirror (<a
href="https://github.com/apache/incubator-deltaspike";>https://github.com/apache/incubator-deltaspike</a>)</p>
-<h2 id="creation-of-the-status-page-30122011">Creation of the Status Page
(30.12.2011)</h2>
+<h2 id="creation-of-the-status-page-30122011">Creation of the Status Page
(30.12.2011)<a class="headerlink" href="#creation-of-the-status-page-30122011"
title="Permanent link">¶</a></h2>
<p>We created an initial version of our status page (<a
href="http://incubator.apache.org/guides/website.html";>http://incubator.apache.org/guides/website.html</a>)</p>
-<h2 id="nightly-builds-29122011">Nightly builds (29.12.2011)</h2>
+<h2 id="nightly-builds-29122011">Nightly builds (29.12.2011)<a
class="headerlink" href="#nightly-builds-29122011" title="Permanent
link">¶</a></h2>
<p>The infra team added the GIT plugin to Jenkins and we created build jobs
for nightly builds which get deployed to
https://repository.apache.org/content/groups/snapshots/org/apache/deltaspike/</p>
-<h2 id="sonar-build-29122011">Sonar build (29.12.2011)</h2>
+<h2 id="sonar-build-29122011">Sonar build (29.12.2011)<a class="headerlink"
href="#sonar-build-29122011" title="Permanent link">¶</a></h2>
<p>Gavin McDonald did the Sonar setup (<a
href="https://analysis.apache.org/dashboard/index/org.apache.deltaspike:deltaspike-project";>https://analysis.apache.org/dashboard/index/org.apache.deltaspike:deltaspike-project</a>)</p>
-<h2 id="first-commit-22122011">First Commit (22.12.2011)</h2>
+<h2 id="first-commit-22122011">First Commit (22.12.2011)<a class="headerlink"
href="#first-commit-22122011" title="Permanent link">¶</a></h2>
<p>The infra team created our GIT repository and we made the first commit.</p>
-<h2 id="first-jira-ticket-13122011">First JIRA ticket (13.12.2011)</h2>
+<h2 id="first-jira-ticket-13122011">First JIRA ticket (13.12.2011)<a
class="headerlink" href="#first-jira-ticket-13122011" title="Permanent
link">¶</a></h2>
<p>We created our JIRA project and filed the first ticket.</p>
-<h2 id="first-report-122011-12122011">First report 12.2011 (12.12.2011)</h2>
+<h2 id="first-report-122011-12122011">First report 12.2011 (12.12.2011)<a
class="headerlink" href="#first-report-122011-12122011" title="Permanent
link">¶</a></h2>
<p>We submitted the first report to <a
href="http://wiki.apache.org/incubator/December2011";>http://wiki.apache.org/incubator/December2011</a></p>
-<h2 id="twitter-account">Twitter Account</h2>
+<h2 id="twitter-account">Twitter Account<a class="headerlink"
href="#twitter-account" title="Permanent link">¶</a></h2>
<p>We created our Twitter account @DeltaSpikeTeam</p>
-<h2 id="mailing-lists-8122011">Mailing-lists (8.12.2011)</h2>
+<h2 id="mailing-lists-8122011">Mailing-lists (8.12.2011)<a class="headerlink"
href="#mailing-lists-8122011" title="Permanent link">¶</a></h2>
<p>Matt Benson created our <a
href="https://s.apache.org/Kpg";>mailing-lists</a>.</p>
-<h2 id="vote-closed-7122011">Vote closed (7.12.2011)</h2>
+<h2 id="vote-closed-7122011">Vote closed (7.12.2011)<a class="headerlink"
href="#vote-closed-7122011" title="Permanent link">¶</a></h2>
<p>The vote to join the incubator was closed. There were 8 binding +1 votes, 3
non-binding +1 votes and no -1 votes. In parallel several other folks showed up
and told us that they are interested to join the effort.</p>
<p>We start with the following initial committers (and therefore PPMC
members):</p>
<ul>
@@ -249,9 +260,9 @@ The <a href="http://s.apache.org/DeltaSp
<li>Matt Benson</li>
<li>Matthias Wessendorf</li>
</ul>
-<h2 id="vote-to-join-the-incubator-4122011">Vote to join the Incubator
(4.12.2011)</h2>
+<h2 id="vote-to-join-the-incubator-4122011">Vote to join the Incubator
(4.12.2011)<a class="headerlink" href="#vote-to-join-the-incubator-4122011"
title="Permanent link">¶</a></h2>
<p>Gerhard Petracek started the official <a
href="http://s.apache.org/h8";>vote</a>.</p>
-<h2 id="proposal-30112011">Proposal (30.11.2011)</h2>
+<h2 id="proposal-30112011">Proposal (30.11.2011)<a class="headerlink"
href="#proposal-30112011" title="Permanent link">¶</a></h2>
<p>After some discussions between the teams (of Apache MyFaces CODI, Seam3 and
CDISource), Mark Struberg submitted the <a
href="http://wiki.apache.org/incubator/DeltaSpikeProposal";>proposal</a>. Since
Spike couldn't be used as project-name, we agreed on DeltaSpike as initial code
name (delta because it closes several gaps).</p>
</div>
</div>
@@ -259,7 +270,7 @@ The <a href="http://s.apache.org/DeltaSp
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/partial-bean.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/partial-bean.html
(original)
+++ websites/staging/deltaspike/trunk/content/retired/partial-bean.html Sat Aug
1 21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>Partial-Bean</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul></ul>
</div>
<hr />
@@ -120,7 +131,7 @@ Currently CDI-Interceptors can't be used
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/project-name.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/project-name.html
(original)
+++ websites/staging/deltaspike/trunk/content/retired/project-name.html Sat Aug
1 21:44:56 2015
@@ -80,18 +80,29 @@
<div class="page-title">
<h1>Where the name 'DeltaSpike' comes from</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#existing-suggestions">Existing Suggestions</a></li>
</ul>
</div>
<hr />
-<h1 id="introduction">Introduction</h1>
+<h1 id="introduction">Introduction<a class="headerlink" href="#introduction"
title="Permanent link">¶</a></h1>
<p>Originally we agreed on Spike because it's a first-/nick-name and it's
"related" to dependency injection. However, due to an existing trademark (see
http://www.trademarkia.com) we can't use it. Since the projects aims to close
different types of gaps, the name DeltaSpike came up.
However, it's just the code-name during incubation to get started and we are
looking for a new fancy name. The best choice would be an invented word (like
Hadoop did).</p>
<p><em>You are welcome to add further suggestions or post them to our mailing
list.</em></p>
-<h1 id="existing-suggestions">Existing Suggestions</h1>
+<h1 id="existing-suggestions">Existing Suggestions<a class="headerlink"
href="#existing-suggestions" title="Permanent link">¶</a></h1>
<p>Please note that we can't use some of the following names due to existing
trademarks. However, maybe they lead to new ideas.</p>
<p>The following names came up during the initial discussion:</p>
<ul>
@@ -146,7 +157,7 @@ However, it's just the code-name during
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
Modified: websites/staging/deltaspike/trunk/content/retired/projectstage.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/retired/projectstage.html
(original)
+++ websites/staging/deltaspike/trunk/content/retired/projectstage.html Sat Aug
1 21:44:56 2015
@@ -80,7 +80,18 @@
<div class="page-title">
<h1>DeltaSpike ProjectStage</h1>
</div>
- <div class="toc">
+ <style type="text/css">
+/* The following code is added by mdx_elementid.py
+ It was originally lifted from http://subversion.apache.org/style/site.css */
+/*
+ * Hide class="elementid-permalink", except when an enclosing heading
+ * has the :hover property.
+ */
+.headerlink, .elementid-permalink {
+ visibility: hidden;
+}
+h2:hover > .headerlink, h3:hover > .headerlink, h1:hover > .headerlink,
h6:hover > .headerlink, h4:hover > .headerlink, h5:hover > .headerlink,
dt:hover > .elementid-permalink { visibility: visible }</style>
+<div class="toc">
<ul>
<li><a href="#introduction">Introduction</a><ul>
<li><a href="#custom-project-stages">Custom Project Stages</a></li>
@@ -93,7 +104,7 @@
</ul>
</div>
<hr />
-<h1 id="introduction">Introduction</h1>
+<h1 id="introduction">Introduction<a class="headerlink" href="#introduction"
title="Permanent link">¶</a></h1>
<p>Project stages allow to use implementations depending on the current
environment.
E.g. you can implement a bean which creates sample-data for system tests which
gets activated only in case of project-stage <code>SystemTest</code>.</p>
@@ -121,7 +132,7 @@ project-stages which will be exposed by
</pre></div>
-<h3 id="custom-project-stages">Custom Project Stages</h3>
+<h3 id="custom-project-stages">Custom Project Stages<a class="headerlink"
href="#custom-project-stages" title="Permanent link">¶</a></h3>
<p>It's possible to provide custom project stage implementations.
Therefore, you have to provide an implementation of the
<code>ProjectStageHolder</code> interface.
In this class you nest the custom project-stage implementations which have to
be
@@ -154,7 +165,7 @@ of the <code>ProjectStageHolder</code> i
</pre></div>
-<h2
id="projectstageproducer-for-3rd-party-portable-extensions">ProjectStageProducer
(for 3rd party portable extensions)</h2>
+<h2
id="projectstageproducer-for-3rd-party-portable-extensions">ProjectStageProducer
(for 3rd party portable extensions)<a class="headerlink"
href="#projectstageproducer-for-3rd-party-portable-extensions" title="Permanent
link">¶</a></h2>
<p><code>ProjectStageProducer</code> provides the producer method which allows
to inject the current project-stage.
However, in some cases it's needed to use project-stages also during the
bootstrapping process
of the CDI container and you can't use injection. In such cases you can use
@@ -162,7 +173,7 @@ of the CDI container and you can't use i
This helper also contains helpers for unit-tests - e.g.
<code>#setProjectStage</code>. However,
those methods shouldn't be needed for users
(we just need them for testing different project-stage scenarios).</p>
-<h3 id="setting-the-active-projectstage">Setting the active ProjectStage</h3>
+<h3 id="setting-the-active-projectstage">Setting the active ProjectStage<a
class="headerlink" href="#setting-the-active-projectstage" title="Permanent
link">¶</a></h3>
<p>For setting the ProjectStage which shall get used in your application you
can specify
it in a few ways. The underlying mechanism used to determine the string is the
ConfigResolver.
E.g.:</p>
@@ -174,7 +185,7 @@ E.g.:</p>
<hr>
<footer>
- <p>Copyright © 2011-2014 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
+ <p>Copyright © 2011-2015 The Apache Software Foundation, Licensed
under the Apache License, Version 2.0.</p>
<p>Apache and the Apache feather logo are trademarks of The Apache
Software Foundation.</p>
</footer>
