[jboss-cvs] JBossAS SVN: r104851 - projects/snowdrop/branches/enterprise/Snowdrop_1.0_User_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon May 17 02:53:38 EDT 2010
Author: laubai
Date: 2010-05-17 02:53:38 -0400 (Mon, 17 May 2010)
New Revision: 104851
Modified:
projects/snowdrop/branches/enterprise/Snowdrop_1.0_User_Guide/en-US/Configuration.xml
Log:
Finished first pass of Snowdrop 1.0 User Guide.
Modified: projects/snowdrop/branches/enterprise/Snowdrop_1.0_User_Guide/en-US/Configuration.xml
===================================================================
--- projects/snowdrop/branches/enterprise/Snowdrop_1.0_User_Guide/en-US/Configuration.xml 2010-05-17 06:47:07 UTC (rev 104850)
+++ projects/snowdrop/branches/enterprise/Snowdrop_1.0_User_Guide/en-US/Configuration.xml 2010-05-17 06:53:38 UTC (rev 104851)
@@ -13,7 +13,7 @@
</para>
<section>
- <title>Application Context Support in the VFS</title>
+ <title>VFS-enabled Application Contexts</title>
<para>
The <filename>snowdrop-vfs.jar</filename> library supports resource
@@ -21,7 +21,7 @@
</para>
<para>
- When the Spring Framework performs resource scanning, it assumes that
+ When the Spring framework performs resource scanning, it assumes that
resources are either from a directory or a packaged JAR, and treats
any URLs it encounters accordingly.
</para>
@@ -40,7 +40,7 @@
<variablelist>
<varlistentry>
- <term>org.jboss.spring.vfs.context.VFSClassPathXmlApplicationContext</term>
+ <term><classname>org.jboss.spring.vfs.context.VFSClassPathXmlApplicationContext</classname></term>
<listitem>
<para>
Replaces the Spring
@@ -105,7 +105,7 @@
<para>
For changing the type of application context created by the
DispatcherServlet, use the contextClass parameter again, but this time
- on the <literal>DispatcherServlet</literal> definition (emphasized
+ on the <classname>DispatcherServlet</classname> definition (emphasized
portion again):
</para>
@@ -124,18 +124,19 @@
</init-param>
</emphasis></servlet></programlisting>
- <para>
+ <!--<para>
Both configurations can be seen at work in the web-scanning
sample.
- </para>
+ </para>-->
- <?dbfo-need height="5in" ?>
+ <!--<?dbfo-need height="5in" ?>-->
- <note>
+ <important>
+ <title>Important: <exceptionname>ZipException</exceptionname></title>
<para>
- In general, it is a good idea to pay attention to this error. If
- encountered while the application is starting, you definitely need to
- replace the default ApplicationContext with one of the VFS-enabled
+ If you encounter the <exceptionname>ZipException</exceptionname> when
+ attempting to start the application, you need to replace the default
+ <classname>ApplicationContext</classname> with one of the VFS-enabled
implementations.
</para>
@@ -143,63 +144,77 @@
...
at org.springframework.core.io.support.PathMatchingResourcePatternResolver
.doFindPathMatchingJarResources(PathMatchingResourcePatternResolver.java:448)</programlisting>
- </note>
+ </important>
</section>
<section>
<title>Load-time weaving</title>
<para>
- In order to perform load-time weaving for the application classes
- in Spring (either for using load-time support for AspectJ or for JPA
- support), the Spring framework needs to install its own transformers in
- the classloader. In certain cases (like for JBoss 5.x), a
- classloader-specific LoadTimeWeaver is necessary. The functionalities
- described in this chapter are included in the snowdrop-weaving.jar
- file.
+ Load-time weaving support is provided by the
+ <filename>snowdrop-weaving.jar</filename> library.
</para>
<para>
- To that effect, if a load-time weaver needs to be defined in the
- www Spring application context, use the JBoss5LoadTimeWeaver class, as
- follows:
+ To perform load-time weaving for the application classes in Spring
+ (either for using load-time support for AspectJ or for JPA support),
+ the Spring framework needs to install its own transformers in
+ the classloader. For JBoss Enterprise Application Platform,
+ JBoss Enterprise Web Platform and JBoss Enterprise Web Server,
+ a classloader-specific <classname>LoadTimeWeaver</classname> is necessary.
</para>
- <programlisting language="Java"><context:load-time-weaver weaver-class="org.jboss.instrument.classloading.JBoss5LoadTimeWeaver"/></programlisting>
+ <para>
+ Define the <classname>JBoss5LoadTimeWeaver</classname> in the
+ <literal>www</literal> Spring application context as shown here:
+ </para>
+
+ <programlisting language="Java"><context:load-time-weaver
+ weaver-class="org.jboss.instrument.classloading.JBoss5LoadTimeWeaver"/></programlisting>
</section>
<section>
<title>The Spring Deployer</title>
<para>
- The role of the Spring Deployer is to allow the bootstrapping of a
- Spring application context, binding it in JNDI and using it for
- providing Spring-configured business object instances.
+ The role of the Spring deployer is to allow you to bootstrap a
+ Spring application context, bind it in JNDI, and use it to
+ provide Spring-configured business object instances.
</para>
<section>
<title>JBoss + Spring + EJB 3.0 Integration</title>
<para>
- This distribution contains a JBoss Deployer that supports Spring
- packaging in JBoss. What this means is that you can create JAR
- archives with a <filename>META-INF/jboss-spring.xml</filename> file
- and your Spring bean factories will automatically be deployed. Also
- supported in this distribution is EJB 3.0 integration. You can deploy
- Spring archives and be able to inject beans created in these
- deployment directly into an EJB using a @Spring annotation.
+ Snowdrop contains a JBoss deployer that supports Spring
+ packaging in JBoss Enterprise Application Platform,
+ JBoss Enterprise Web Platform and JBoss Enterprise Web Server.
+ This means it is possible to create JAR archives with a
+ <filename>META-INF/jboss-spring.xml</filename> file to have your
+ Spring bean factories deploy automatically.
</para>
+
+ <para>
+ EJB 3.0 integration is also supported. You can deploy Spring archives
+ and inject beans created in these deployments directly into an EJB by
+ using the <varname>@Spring</varname> annotation.
+ </para>
</section>
<section>
<title>Installation</title>
<para>
- For installing the Snowdrop deployer, unzip the
- jboss-spring-deployer.zip file in
- JBOSS_HOME/server/<configuration>/deployers. The distribution
- you are installing from may or may not contain the Spring jars. If the
- archive does not contain the Spring jars, please include the following
+ To install the Snowdrop JBoss deployer, unzip the
+ <filename>jboss-spring-deployer.zip</filename> in the
+ <filename>$JBOSS_HOME/server/$PROFILE/deployers</filename> directory of
+ your JBoss Enterprise Application Platform or JBoss Enterprise Web Platform
+ installation.
+ </para>
+
+ <!--<para>
+ Your distribution of Snowdrop may not include the Spring JARs.
+ If your archive does not contain the Spring jars, please include the following
files from the Spring 2.5.6.SEC01 distribution:
</para>
@@ -215,16 +230,16 @@
<listitem>
<para>spring-core.jar.</para>
</listitem>
- </itemizedlist>
+ </itemizedlist>-->
</section>
<section>
<title>Spring deployments</title>
<para>
- You can create Spring deployments that work much in the same way
- .sar's, .war's, .ear's, .har's, and .rar's work. Using the JBoss
- Spring deployer you can create Spring jars:
+ You can create Spring deployments that work similarly to JARs, EARs, and WARs
+ with the JBoss Spring deployer. Spring JARs are created with the following
+ structure:
</para>
<screen>my-app.jar/
@@ -236,25 +251,24 @@
jboss-spring.xml</screen>
<para>
- So, my-app.JAR is a jar that contains classes, like any other
- JAR and a jboss-spring.xml file in the META-INF/ of the jar. This
- jboss-spring.xml file is like any other Spring xml file. By default,
- the JBoss Spring Deployer will register this bean factory defined in
- the XML file into JNDI. It will be registered in a non-serialized form
- so you don't have to worry about JNDI serialization! The default JNDI
- name will be the short name of the deployment file. So in this
- example, the bean factory described in the
- <filename>META-INF/jboss-spring.xml</filename> file will be registered
- under the "my-app" JNDI name.
+ <filename>my-app.jar</filename> is a JAR that contains classes. A
+ <filename>jboss-spring.xml</filename> file exists in the
+ <filename>META-INF</filename> directory of the JAR. By default, the
+ JBoss Spring deployer registers the bean factory defined in
+ <filename>jboss-spring.xml</filename> into JNDI in a non-serialized
+ form. The default JNDI name is the short name of the deployment file —
+ in this case, <literal>my-app</literal>.
</para>
<para>
- Alternatively, you do not have to create an archive. You can put
- your jar libraries under server/<config-name>/lib and just put
- an XML file of the form: <name>-spring.xml into the JBoss deploy
- directory. For example, my-app-spring.xml. Again, the JNDI name will
- be by default, the short name of the XML file, in the case
- my-app-spring.xml will produce a JNDI binding of "my-app".
+ You do not have to create an archive. Instead, you can place your JAR
+ libraries under <filename>$JBOSS_HOME/server/$PROFILE/lib</filename> and
+ add an XML file of the form <literal><name>-spring.xml</literal>,
+ for example, <filename>my-app-spring.xml</filename>, into the
+ <filename>deploy</filename> directory of your JBoss Enterprise Application
+ Platform or JBoss Enterprise Web Platform installation. The default JNDI
+ name will be the short name of the XML file; in this case,
+ <literal>my-app</literal>.
</para>
</section>
@@ -262,11 +276,14 @@
<title>Deployment</title>
<para>
- Once you have created a <emphasis>.spring</emphasis> archive (or
- a .jar) or a <emphasis>-spring.xml</emphasis> file, all you have to do
- is put it in the JBoss deploy/ directory and it will be deployed into
- the JBoss runtime. You can also embed these deployments inside an EAR,
- EJB-JAR, SAR, etc. as JBoss supports nested archives.
+ Once you have created a <filename>.jar</filename> or a
+ <!--.spring file info here-->
+ <emphasis>-spring.xml</emphasis> file, copy it into the
+ <filename>deploy</filename> directory of your JBoss Enterprise Application
+ Platform or JBoss Enterprise Web Platform installation to deploy
+ it into the JBoss runtime. You can also embed these deployments in an
+ EAR, EJB-SAR, SAR, etc. since JBoss Enterprise Application Platform and
+ JBoss Enterprise Web Platform support nested archives.
</para>
</section>
@@ -278,7 +295,7 @@
description element of the Spring XML.
</para>
- <?dbfo-need height="5in" ?>
+ <!--<?dbfo-need height="5in" ?>-->
<programlisting language="XML"><beans>
<description>BeanFactory=(MyApp)</description>
@@ -287,7 +304,7 @@
</beans></programlisting>
<para>
- MyApp will be used as the JNDI name in this example.
+ <literal>MyApp</literal> will be used as the JNDI name in this example.
</para>
</section>
@@ -298,7 +315,7 @@
Sometimes you want your deployed Spring bean factory to be able
to reference beans deployed in another Spring deployment. You can do
this by declaring a parent bean factory in the description element in
- the Spring XML.
+ the Spring XML, like so:
</para>
<programlisting language="XML"><beans>
@@ -311,10 +328,10 @@
<title>Injection into EJBs</title>
<para>
- Once an ApplicationContext has been successfully bootstrapped,
- the Spring beans defined in it can be used for injection into EJBs. To
- that end, the EJBs must be intercepted with the
- SpringLifecycleInterceptor, as in the following example:
+ Once an <classname>ApplicationContext</classname> has been successfully bootstrapped,
+ the Spring beans defined in it can be used for injection into EJBs.
+ To do this, the EJBs must be intercepted with the
+ <classname>SpringLifecycleInterceptor</classname>, as in the following example:
</para>
<programlisting>@Stateless
@@ -328,9 +345,10 @@
}</programlisting>
<para>
- In this example, the EJB InjectedEjbImpl will be injected with
- the bean named 'springBean', defined in the ApplicationContext
- previously described in sections 3.3 and 3.5.
+ In this example, the EJB <classname>InjectedEjbImpl</classname> will be
+ injected with the bean named <literal>springBean</literal>, which is defined in
+ the <classname>ApplicationContext</classname><!-- described in
+ <xref linkend="3.3"/> and <xref linkend="3.5"/>-->.
</para>
</section>
</section>
More information about the jboss-cvs-commits
mailing list