Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix typos (SPR-7339)

Browse Source
This commit is contained in:
Chris Beams
2010-08-07 13:57:23 +00:00
parent 5ce4cada53
commit d97f899bee
17 changed files with 85 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
spring-framework-reference/src/ejb.xml
View File

@@ -279,7 +279,8 @@ public void setMyComponent(MyComponent myComponent) {
</para>
<para>
Consider an example Stateless Session bean which actually delegates
the implementation to a plain java service object. We have the business interface:
the implementation to a plain java service object. We have the business
interface:
</para>
<programlisting language="java"><![CDATA[public interface MyComponent {
public void myMethod(...);
@@ -335,24 +336,27 @@ public void setMyComponent(MyComponent myComponent) {
passivated and reactivated as part of their lifecycle, and which use a
non-serializable container instance (which is the normal case) will have
to manually call <literal>unloadBeanFactory()</literal> and
<literal>loadBeanFactory</literal> from <literal>ejbPassivate</literal>
and <literal>ejbActivate</literal>, respectively, to unload and reload the
<literal>loadBeanFactory()</literal> from <literal>ejbPassivate()</literal>
and <literal>ejbActivate()</literal>, respectively, to unload and reload the
BeanFactory on passivation and activation, since it can not be saved by
the EJB container.
</para>
<para>
The default behavior of the <classname>ContextJndiBeanFactoryLocator</classname>
classes which is to load an <classname>ApplicationContext</classname> for the
use of the EJB is adequate for some situations. However, it is problematic when
the <classname>ApplicationContext</classname> is loading a number
of beans, or the initialization of those beans is time consuming or memory
intensive (such as a Hibernate <classname>SessionFactory</classname> initialization, for
example), since every EJB will have their own copy. In this case, the user
may want to override the default <classname>ContextJndiBeanFactoryLocator</classname>
usage and use another <classname>BeanFactoryLocator</classname> variant, such as the
<classname>ContextSingletonBeanFactoryLocator</classname> which can load and use a
shared container to be used by multiple EJBs or other clients. Doing this is relatively
simple, by adding code similar to this to the EJB:
The default behavior of the
<classname>ContextJndiBeanFactoryLocator</classname> class is to load an
<classname>ApplicationContext</classname> for use by an EJB, and is
adequate for some situations. However, it is problematic when the
<classname>ApplicationContext</classname> is loading a number of beans,
or the initialization of those beans is time consuming or memory
intensive (such as a Hibernate <classname>SessionFactory</classname>
initialization, for example), since every EJB will have their own copy.
In this case, the user may want to override the default
<classname>ContextJndiBeanFactoryLocator</classname> usage and use
another <classname>BeanFactoryLocator</classname> variant, such as the
<classname>ContextSingletonBeanFactoryLocator</classname> which can load
and use a shared container to be used by multiple EJBs or other clients.
Doing this is relatively simple, by adding code similar to this to the
EJB:
</para>
<programlisting language="java"><![CDATA[ /**
* Override default BeanFactoryLocator implementation