Apply parentheses consistently within <methodname/>
Prior to change, there were 175 instances of <methodname/> elements including parentheses (e.g.: <methodname>foo()</methodname>, and 36 instances without. Now all 211 instances include parentheses for consistency.
This commit is contained in:
Chris Beams
parent
e3400f77c9
commit
abf523698c
|
|
@ -370,11 +370,11 @@ PetStoreServiceImpl service = context.getBean("petStore", PetStoreServiceImpl.cl
|
|||
List userList service.getUsernameList();
|
||||
</programlisting>
|
||||
|
||||
<para>You use <methodname>getBean</methodname> to retrieve instances of
|
||||
<para>You use <methodname>getBean()</methodname> to retrieve instances of
|
||||
your beans. The <interfacename>ApplicationContext</interfacename>
|
||||
interface has a few other methods for retrieving beans, but ideally your
|
||||
application code should never use them. Indeed, your application code
|
||||
should have no calls to the <methodname>getBean</methodname> method at
|
||||
should have no calls to the <methodname>getBean()</methodname> method at
|
||||
all, and thus no dependency on Spring APIs at all. For example, Spring's
|
||||
integration with web frameworks provides for dependency injection for
|
||||
various web framework classes such as controllers and JSF-managed
|
||||
|
|
@ -512,7 +512,7 @@ List userList service.getUsernameList();
|
|||
<interfacename>ApplicationContext</interfacename> implementations also
|
||||
permit the registration of existing objects that are created outside the
|
||||
container, by users. This is done by accessing the ApplicationContext's
|
||||
BeanFactory via the method <methodname>getBeanFactory</methodname> which
|
||||
BeanFactory via the method <methodname>getBeanFactory()</methodname> which
|
||||
returns the BeanFactory implementation
|
||||
<classname>DefaultListableBeanFactory</classname>.
|
||||
<classname>DefaultListableBeanFactory</classname> supports this
|
||||
|
|
@ -4408,7 +4408,7 @@ dataSource.url=jdbc:mysql:mydb</programlisting>
|
|||
<interfacename>FactoryBean</interfacename> instance itself, not the bean
|
||||
it produces, you preface the bean id with the ampersand symbol
|
||||
<literal>&</literal> (without quotes) when calling the
|
||||
<methodname>getBean</methodname> method of the
|
||||
<methodname>getBean()</methodname> method of the
|
||||
<interfacename>ApplicationContext</interfacename>. So for a given
|
||||
<interfacename>FactoryBean</interfacename> with an id of
|
||||
<literal>myBean</literal>, invoking <literal>getBean("myBean")</literal>
|
||||
|
|
@ -5525,9 +5525,9 @@ public class FactoryMethodComponent {
|
|||
}</programlisting>
|
||||
|
||||
<para>This class is a Spring component that has application-specific
|
||||
code contained in its <methodname>doWork</methodname> method. However,
|
||||
code contained in its <methodname>doWork()</methodname> method. However,
|
||||
it also contributes a bean definition that has a factory method
|
||||
referring to the method <methodname>publicInstance</methodname>. The
|
||||
referring to the method <methodname>publicInstance()</methodname>. The
|
||||
<literal>@Bean</literal> annotation identifies the factory method and
|
||||
other bean definition properties, such as a qualifier value through the
|
||||
<classname>@Qualifier</classname> annotation. Other method level
|
||||
|
|
|
|||
|
|
@ -431,8 +431,8 @@
|
|||
<classname>ConnectionFactory</classname> interface,
|
||||
<classname>SingleConnectionFactory102</classname>, based on the JMS
|
||||
1.0.2 API that will return the same <classname>Connection</classname> on
|
||||
all <methodname>createConnection</methodname> calls and ignore calls to
|
||||
<methodname>close</methodname>. You will need to set the boolean
|
||||
all <methodname>createConnection()</methodname> calls and ignore calls to
|
||||
<methodname>close()</methodname>. You will need to set the boolean
|
||||
property <property>pubSubDomain</property> to indicate which messaging
|
||||
domain is used as <classname>SingleConnectionFactory102</classname> will
|
||||
always explicitly differentiate between a
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@
|
|||
<classname>JDOExceptions</classname> itself, preferably via delegating to
|
||||
<classname>SessionFactoryUtils</classname>'
|
||||
<methodname>convertHibernateAccessException(..)</methodname> or
|
||||
<methodname>convertJdoAccessException</methodname> methods respectively.
|
||||
<methodname>convertJdoAccessException()</methodname> methods respectively.
|
||||
These methods convert the exceptions to ones that are compatible with the
|
||||
exceptions in the <literal>org.springframework.dao</literal> exception
|
||||
hierarchy. As <classname>JDOExceptions</classname> are unchecked, they can
|
||||
|
|
|
|||
|
|
@ -290,11 +290,11 @@ boolean result = exp.getValue(context, Boolean.class); // evaluates to true</pr
|
|||
|
||||
<para>The <classname>StandardEvaluationContext</classname> is where you
|
||||
may specify the root object to evaluate against via the method
|
||||
<methodname>setRootObject</methodname> or passing the root object into
|
||||
<methodname>setRootObject()</methodname> or passing the root object into
|
||||
the constructor. You can also specify variables and functions that
|
||||
will be used in the expression using the methods
|
||||
<methodname>setVariable</methodname> and
|
||||
<methodname>registerFunction</methodname>. The use of variables and
|
||||
<methodname>setVariable()</methodname> and
|
||||
<methodname>registerFunction()</methodname>. The use of variables and
|
||||
functions are described in the language reference sections <link
|
||||
linkend="expressions-ref-variables">Variables</link> and <link lang=""
|
||||
linkend="expressions-ref-functions">Functions</link>. The
|
||||
|
|
|
|||
|
|
@ -1036,7 +1036,7 @@ public class ExecuteAnUpdate {
|
|||
<section id="jdbc-auto-genereted-keys">
|
||||
<title>Retrieving auto-generated keys</title>
|
||||
|
||||
<para>An <methodname>update</methodname> convenience method supports<!--Give name of this method. Also indicate *what* is acquiring the primary keys. TR: Changed to *retrieval*.
|
||||
<para>An <methodname>update()</methodname> convenience method supports<!--Give name of this method. Also indicate *what* is acquiring the primary keys. TR: Changed to *retrieval*.
|
||||
The name of the method is *update*.--> the retrieval of primary keys generated
|
||||
by the database. This support is part of the JDBC 3.0 standard; see
|
||||
Chapter 13.6 of the specification for details. The method takes a
|
||||
|
|
|
|||
|
|
@ -160,8 +160,8 @@
|
|||
<classname>ConnectionFactory</classname> interface,
|
||||
<classname>SingleConnectionFactory</classname>, that will return the
|
||||
same <classname>Connection</classname> on all
|
||||
<methodname>createConnection</methodname> calls and ignore calls to
|
||||
<methodname>close.</methodname> This is useful for testing and
|
||||
<methodname>createConnection()</methodname> calls and ignore calls to
|
||||
<methodname>close()</methodname>. This is useful for testing and
|
||||
standalone environments so that the same connection can be used for
|
||||
multiple <classname>JmsTemplate</classname> calls that may span any
|
||||
number of transactions. <classname>SingleConnectionFactory</classname>
|
||||
|
|
@ -284,7 +284,7 @@
|
|||
<para>This message listener container is the simpler of the two
|
||||
standard flavors. It creates a fixed number of JMS sessions and
|
||||
consumers at startup, registers the listener using the standard JMS
|
||||
<methodname>MessageConsumer.setMessageListener</methodname> method,
|
||||
<methodname>MessageConsumer.setMessageListener()</methodname> method,
|
||||
and leaves it up the JMS provider to perform listener callbacks.
|
||||
This variant does not allow for dynamic adaption to runtime demands or
|
||||
for participation in externally managed transactions. Compatibility-wise,
|
||||
|
|
@ -425,8 +425,8 @@ public class JmsQueueSender {
|
|||
<para>In order to facilitate the sending of domain model objects, the
|
||||
<classname>JmsTemplate</classname> has various send methods that take a
|
||||
Java object as an argument for a message's data content. The overloaded
|
||||
methods <methodname>convertAndSend</methodname> and
|
||||
<methodname>receiveAndConvert</methodname> in
|
||||
methods <methodname>convertAndSend()</methodname> and
|
||||
<methodname>receiveAndConvert()</methodname> in
|
||||
<classname>JmsTemplate</classname> delegate the conversion process to an
|
||||
instance of the <literal>MessageConverter</literal> interface. This
|
||||
interface defines a simple contract to convert between Java objects and
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ public interface Marshaller {
|
|||
</informaltable>
|
||||
<note>
|
||||
<para>
|
||||
Although the <methodname>marshal</methodname> method accepts a plain object as its first
|
||||
Although the <methodname>marshal()</methodname> method accepts a plain object as its first
|
||||
parameter, most <classname>Marshaller</classname> implementations cannot handle arbitrary
|
||||
objects. Instead, an object class must be mapped in a mapping file, marked with an annotation,
|
||||
registered with the marshaller, or have a common base class. Refer to the further sections
|
||||
|
|
@ -218,9 +218,9 @@ public class Settings {
|
|||
</para>
|
||||
<para>
|
||||
The application class uses this bean to store its settings. Besides a main method, the class has two
|
||||
methods: <methodname>saveSettings</methodname> saves the settings bean to a file named
|
||||
<filename>settings.xml</filename>, and <methodname>loadSettings</methodname> loads these settings again. A
|
||||
<methodname>main</methodname> method constructs a Spring application context, and calls these two methods.
|
||||
methods: <methodname>saveSettings()</methodname> saves the settings bean to a file named
|
||||
<filename>settings.xml</filename>, and <methodname>loadSettings()</methodname> loads these settings again. A
|
||||
<methodname>main()</methodname> method constructs a Spring application context, and calls these two methods.
|
||||
<programlisting language="java"><![CDATA[
|
||||
import java.io.FileInputStream;
|
||||
import java.io.FileOutputStream;
|
||||
|
|
|
|||
|
|
@ -1399,9 +1399,9 @@ if (HttpStatus.SC_CREATED == post.getStatusCode()) {
|
|||
<para>The names of <classname>RestTemplate</classname> methods follow a
|
||||
naming convention, the first part indicates what HTTP method is being
|
||||
invoked and the second part indicates what is returned. For example, the
|
||||
method <methodname>getForObject</methodname> will perform a GET, convert
|
||||
method <methodname>getForObject()</methodname> will perform a GET, convert
|
||||
the HTTP response into an object type of your choice and return that
|
||||
object. The method <methodname>postForLocation</methodname> will do a
|
||||
object. The method <methodname>postForLocation()</methodname> will do a
|
||||
POST, converting the given object into a HTTP request and return the
|
||||
response HTTP Location header where the newly created object can be
|
||||
found. In case of an exception processing the HTTP request, an exception
|
||||
|
|
@ -1414,13 +1414,13 @@ if (HttpStatus.SC_CREATED == post.getStatusCode()) {
|
|||
<interfacename>HttpMessageConverter</interfacename> instances.
|
||||
Converters for the main mime types are registered by default, but you
|
||||
can also write your own converter and register it via the
|
||||
<methodname>messageConverters</methodname> bean property. The default
|
||||
<methodname>messageConverters()</methodname> bean property. The default
|
||||
converter instances registered with the template are
|
||||
<classname>ByteArrayHttpMessageConverter</classname>,
|
||||
<classname>StringHttpMessageConverter</classname>,
|
||||
<classname>FormHttpMessageConverter</classname> and
|
||||
<classname>SourceHttpMessageConverter</classname>. You can override
|
||||
these defaults using the <methodname>messageConverters</methodname> bean
|
||||
these defaults using the <methodname>messageConverters()</methodname> bean
|
||||
property as would be required if using the
|
||||
<classname>MarshallingHttpMessageConverter</classname> or
|
||||
<classname>MappingJacksonHttpMessageConverter</classname>.</para>
|
||||
|
|
@ -1499,11 +1499,11 @@ URI location = template.postForLocation(uri, booking, "1");
|
|||
<title>Dealing with request and response headers</title>
|
||||
|
||||
<para>Besides the methods described above, the <classname>RestTemplate</classname>
|
||||
also has the <methodname>exchange</methodname> method, which can be
|
||||
also has the <methodname>exchange()</methodname> method, which can be
|
||||
used for arbitrary HTTP method execution based on the <classname>HttpEntity</classname>
|
||||
class.</para>
|
||||
|
||||
<para>Perhaps most importantly, the <methodname>exchange</methodname>
|
||||
<para>Perhaps most importantly, the <methodname>exchange()</methodname>
|
||||
method can be used to add request headers and read response headers.
|
||||
For example:</para>
|
||||
|
||||
|
|
@ -1527,9 +1527,9 @@ String body = response.getBody();</programlisting>
|
|||
<title>HTTP Message Conversion</title>
|
||||
|
||||
<para>Objects passed to and returned from the methods
|
||||
<methodname>getForObject</methodname>,
|
||||
<methodname>postForLocation</methodname>, and
|
||||
<methodname>put</methodname> are converted to HTTP requests and from
|
||||
<methodname>getForObject()</methodname>,
|
||||
<methodname>postForLocation()</methodname>, and
|
||||
<methodname>put()</methodname> are converted to HTTP requests and from
|
||||
HTTP responses by <interfacename>HttpMessageConverters</interfacename>.
|
||||
The <interfacename>HttpMessageConverter</interfacename> interface is
|
||||
shown below to give you a better feel for its functionality</para>
|
||||
|
|
|
|||
|
|
@ -1192,9 +1192,9 @@ public interface Parser<T> {
|
|||
<para> To create your own Formatter, simply implement the Formatter
|
||||
interface above. Parameterize T to be the type of object you wish to
|
||||
format, for example, <classname>java.util.Date</classname>. Implement
|
||||
the <methodname>print</methodname> operation to print an instance of T
|
||||
the <methodname>print()</methodname> operation to print an instance of T
|
||||
for display in the client locale. Implement the
|
||||
<methodname>parse</methodname> operation to parse an instance of T from
|
||||
<methodname>parse()</methodname> operation to parse an instance of T from
|
||||
the formatted representation returned from the client locale. Your
|
||||
Formatter should throw a ParseException or IllegalArgumentException if a
|
||||
parse attempt fails. Take care to ensure your Formatter implementation
|
||||
|
|
@ -1273,10 +1273,10 @@ public interface AnnotationFormatterFactory<A extends Annotation> {
|
|||
<para> Parameterize A to be the field annotationType you wish to associate
|
||||
formatting logic with, for example
|
||||
<code>org.springframework.format.annotation.DateTimeFormat</code>. Have
|
||||
<methodname>getFieldTypes</methodname> return the types of fields the
|
||||
annotation may be used on. Have <methodname>getPrinter</methodname>
|
||||
<methodname>getFieldTypes()</methodname> return the types of fields the
|
||||
annotation may be used on. Have <methodname>getPrinter()</methodname>
|
||||
return a Printer to print the value of an annotated field. Have
|
||||
<methodname>getParser</methodname> return a Parser to parse a
|
||||
<methodname>getParser()</methodname> return a Parser to parse a
|
||||
clientValue for an annotated field. </para>
|
||||
|
||||
<para> The example AnnotationFormatterFactory implementation below binds
|
||||
|
|
|
|||
Loading…
Reference in New Issue