Replace <code> with {@code} throughout Javadoc

Issue: SPR-10128
This commit is contained in:
Chris Beams
2012-12-18 14:45:36 +01:00
parent 8597ec25ec
commit 9540d2c81b
1503 changed files with 8001 additions and 8060 deletions

View File

@@ -25,7 +25,7 @@ import org.springframework.beans.factory.wiring.BeanConfigurerSupport;
* pointcut in subaspects.
*
* <p>Subaspects may also need a metadata resolution strategy, in the
* <code>BeanWiringInfoResolver</code> interface. The default implementation
* {@code BeanWiringInfoResolver} interface. The default implementation
* looks for a bean with the same name as the FQN. This is the default name
* of a bean in a Spring container if the id value is not supplied explicitly.
*

View File

@@ -29,8 +29,8 @@ import java.io.Serializable;
* <p>
* There are two cases that needs to be handled:
* <ol>
* <li>Normal object creation via the '<code>new</code>' operator: this is
* taken care of by advising <code>initialization()</code> join points.</li>
* <li>Normal object creation via the '{@code new}' operator: this is
* taken care of by advising {@code initialization()} join points.</li>
* <li>Object creation through deserialization: since no constructor is
* invoked during deserialization, the aspect needs to advise a method that a
* deserialization mechanism is going to invoke. Ideally, we should not
@@ -41,21 +41,21 @@ import java.io.Serializable;
* introduced implementation). There are a few choices for the chosen method:
* <ul>
* <li>readObject(ObjectOutputStream): Java requires that the method must be
* <code>private</p>. Since aspects cannot introduce a private member,
* {@code private}. Since aspects cannot introduce a private member,
* while preserving its name, this option is ruled out.</li>
* <li>readResolve(): Java doesn't pose any restriction on an access specifier.
* <li>readResolve(): Java doesn't pose any restriction on an access specifier.
* Problem solved! There is one (minor) limitation of this approach in
* that if a user class already has this method, that method must be
* <code>public</code>. However, this shouldn't be a big burden, since
* {@code public}. However, this shouldn't be a big burden, since
* use cases that need classes to implement readResolve() (custom enums,
* for example) are unlikely to be marked as &#64;Configurable, and
* in any case asking to make that method <code>public</code> should not
* in any case asking to make that method {@code public} should not
* pose any undue burden.</li>
* </ul>
* The minor collaboration needed by user classes (i.e., that the
* implementation of <code>readResolve()</code>, if any, must be
* <code>public</code>) can be lifted as well if we were to use an
* experimental feature in AspectJ - the <code>hasmethod()</code> PCD.</li>
* implementation of {@code readResolve()}, if any, must be
* {@code public}) can be lifted as well if we were to use an
* experimental feature in AspectJ - the {@code hasmethod()} PCD.</li>
* </ol>
* <p>
@@ -103,17 +103,17 @@ public abstract aspect AbstractInterfaceDrivenDependencyInjectionAspect extends
ConfigurableObject+ && Serializable+ implements ConfigurableDeserializationSupport;
/**
* A marker interface to which the <code>readResolve()</code> is introduced.
* A marker interface to which the {@code readResolve()} is introduced.
*/
static interface ConfigurableDeserializationSupport extends Serializable {
}
/**
* Introduce the <code>readResolve()</code> method so that we can advise its
* Introduce the {@code readResolve()} method so that we can advise its
* execution to configure the object.
*
* <p>Note if a method with the same signature already exists in a
* <code>Serializable</code> class of ConfigurableObject type,
* {@code Serializable} class of ConfigurableObject type,
* that implementation will take precedence (a good thing, since we are
* merely interested in an opportunity to detect deserialization.)
*/

View File

@@ -32,7 +32,7 @@ import org.springframework.beans.factory.wiring.BeanConfigurerSupport;
* annotation to identify which classes need autowiring.
*
* <p>The bean name to look up will be taken from the
* <code>&#64;Configurable</code> annotation if specified, otherwise the
* {@code &#64;Configurable} annotation if specified, otherwise the
* default bean name to look up will be the FQN of the class being configured.
*
* @author Rod Johnson

View File

@@ -22,7 +22,7 @@ package org.springframework.beans.factory.aspectj;
* the use of the &#64;Configurable annotation.
*
* The subaspect of this aspect doesn't need to include any AOP constructs.
* For example, here is a subaspect that configures the <code>PricingStrategyClient</code> objects.
* For example, here is a subaspect that configures the {@code PricingStrategyClient} objects.
* <pre>
* aspect PricingStrategyDependencyInjectionAspect
* extends GenericInterfaceDrivenDependencyInjectionAspect<PricingStrategyClient> {

View File

@@ -18,7 +18,7 @@ package org.springframework.mock.staticmock;
/**
* Annotation-based aspect to use in test build to enable mocking static methods
* on JPA-annotated <code>@Entity</code> classes, as used by Roo for finders.
* on JPA-annotated {@code @Entity} classes, as used by Roo for finders.
*
* <p>Mocking will occur in the call stack of any method in a class (typically a test class)
* that is annotated with the @MockStaticEntityMethods annotation.

View File

@@ -25,7 +25,7 @@ import org.springframework.transaction.interceptor.TransactionAttributeSource;
/**
* Abstract superaspect for AspectJ transaction aspects. Concrete
* subaspects will implement the <code>transactionalMethodExecution()</code>
* subaspects will implement the {@code transactionalMethodExecution()}
* pointcut using a strategy such as Java 5 annotations.
*
* <p>Suitable for use inside or outside the Spring IoC container.