Update of /cvsroot/xdoclet/xdoclet/xdocs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11004/xdocs
Modified Files:
envhandling.xml
Log Message:
typo's fixed
Index: envhandling.xml
===================================================================
RCS file: /cvsroot/xdoclet/xdoclet/xdocs/envhandling.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** envhandling.xml 12 Apr 2005 21:10:15 -0000 1.1
--- envhandling.xml 13 Apr 2005 19:38:36 -0000 1.2
***************
*** 22,46 ****
</p>
<p>
! The Service Locator Pattern tries to solve the problem by
having a
! centralized place for the lookups. The big disadvantage of
this pattern
! is each bean must use the same naming for it's environment
properties. Thiy may
! also be a source of very strange behaviour when two bean's
use the same name
! for different things. A possible solution is to use the
physical JNDI-Names
! instead of the names inside the <code>java:comp/env</code>
namespace. It
but it's at the border of the EJB specification because the
beans do no longer
! declare their ejb and resource references.
</p>
<p>
XDoclet makes it now a lot easier to declare and access
environment properties
! and it's even possible that each bean uses it's own naming!
This is done
! by expanding the current tags for declaring environment
properties
! (i.e. <code>@ejb.env-entry</code>, <code>@ejb.ejb-ref</code>)
to field and
! method level. The lookup of the properties is delegated to
the technical
! bean generated with the <code>session</code>,
<code>mdb</code>,
! <code>entitybmp</code> and <code>entitycmp</code> subtask.
This means that the only thing you have to do is to declare a
field or
a abstract method with a XDoclet tag. The
deploymentdescriptor entries and
! the lookup from the JNDI-Tree is generated by XDoclet! The
bean has not a
! single line of JNDI-Code.
</p>
<subsection name="A simple example">
--- 22,46 ----
</p>
<p>
! The Service Locator Pattern tries to solve the problem with a
central object
! for the lookups which does also some caching. A disadvantage
of this pattern is
! that each bean must use the same naming for it's environment
properties. This may
! be the source of very strange behaviour when two bean's use
the same name
! for different things. A possible solution is to use the
physical JNDI names
! instead of the names inside the <code>java:comp/env</code>
namespace. It works
but it's at the border of the EJB specification because the
beans do no longer
! declare proper ejb and resource references.
</p>
<p>
XDoclet makes it now a lot easier to declare and access
environment properties
! and it's fully compliant to the ejb spec!. It's still
possible that each bean
! uses it's own naming. This is done by expanding the current
tags for declaring
! environment properties (i.e. <code>@ejb.env-entry</code>,
<code>@ejb.ejb-ref</code>)
! to field and method level. The lookup of the properties is
delegated to the technical
! bean class generated with the <code>session</code>,
<code>mdb</code>,
! <code>entitybmp</code> or <code>entitycmp</code> subtask.
This means that the only thing you have to do is to declare a
field or
a abstract method with a XDoclet tag. The
deploymentdescriptor entries and
! the lookup from the JNDI tree is generated by XDoclet! Your
bean class has
! not a single line of JNDI lookup code.
</p>
<subsection name="A simple example">
***************
*** 176,182 ****
<p>
The XDoclet-generated class performs the lookup of the
declared environment properties.
! The value is cached for method-level properties. If the
return-type of a method-level
! ejb-reference is the component interface, a automatic
call to the <code>create()</code>
! method of the home-interface was generated!
</p>
</subsection>
--- 176,182 ----
<p>
The XDoclet-generated class performs the lookup of the
declared environment properties.
! The value is directly assigned to field-level properties
and cached for method-level
! properties. For the method-level ejb-reference which has
the component interface as
! return-type, a call to the <code>create()</code> method
of the home interface was generated!
</p>
</subsection>
***************
*** 189,198 ****
</p>
<p>
! This makes it very easy to reference to a stateless
session bean. And it's also the recommended
! way for this because the Home-Interface of a stateless
session bean is most of the time only used
for calling the <code>create()</code> method. But it's
not a good idea to use this feature for
! references to stateful session beans and entity beans
where the Home-Interface plays a bigger role.
! For those bean types, it's recommended that the abstract
method returns the Home-Interface
! instead of the Component-Interface.
</p>
</subsection>
--- 189,197 ----
</p>
<p>
! This makes it very easy to have a reference to a
stateless session bean. And it's also the recommended
! way for this because the home interface of a stateless
session bean is most of the time only used
for calling the <code>create()</code> method. But it's
not a good idea to use this feature for
! references to entity beans where the home-interface plays
a bigger role. For those beans, it's
! recommended that the abstract method returns the home
interface instead of the component interface.
</p>
</subsection>
***************
*** 205,211 ****
<subsection name="Stateful Session Bean Passivation">
<p>
! When a stateful session bean is passivated, the
nvironment properties of the follwing
types are not passivated. They are set to
<code>null</code> in <code>ejbPassivate()</code>
! and re-fetched from the JNDI-Tree in
<code>ejbActivate()</code>.
<ul>
<li><code>@ejb.resource-ref</code></li>
--- 204,210 ----
<subsection name="Stateful Session Bean Passivation">
<p>
! When a stateful session bean is passivated, the
environment properties of the following
types are not passivated. They are set to
<code>null</code> in <code>ejbPassivate()</code>
! and re-fetched from the JNDI tree in
<code>ejbActivate()</code>.
<ul>
<li><code>@ejb.resource-ref</code></li>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
xdoclet-devel mailing list
xdoclet-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
