[HHH-2930] typos in documentation: datatabase, is send, etc

git-svn-id: https://svn.jboss.org/repos/hibernate/core/trunk@14585 1b8cb986-b30d-0410-93ca-fae66ebed9b2
This commit is contained in:
Diego Plentz 2008-04-28 05:19:53 +00:00
parent 7b727315c5
commit dc61408401
5 changed files with 38 additions and 38 deletions

View File

@ -215,7 +215,7 @@
The instance was once associated with a persistence The instance was once associated with a persistence
context, but that context was closed, or the instance context, but that context was closed, or the instance
was serialized to another process. It has a persistent was serialized to another process. It has a persistent
identity and, perhaps, a corrsponding row in the database. identity and, perhaps, a corresponding row in the database.
For detached instances, Hibernate makes no guarantees For detached instances, Hibernate makes no guarantees
about the relationship between persistent identity and about the relationship between persistent identity and
Java identity. Java identity.
@ -348,7 +348,7 @@
The first two implementations provide a "one session - one database transaction" programming The first two implementations provide a "one session - one database transaction" programming
model, also known and used as <emphasis>session-per-request</emphasis>. The beginning model, also known and used as <emphasis>session-per-request</emphasis>. The beginning
and end of a Hibernate session is defined by the duration of a database transaction. and end of a Hibernate session is defined by the duration of a database transaction.
If you use programatic transaction demarcation in plain JSE without JTA, you are adviced to If you use programmatic transaction demarcation in plain JSE without JTA, you are advised to
use the Hibernate <literal>Transaction</literal> API to hide the underlying transaction system use the Hibernate <literal>Transaction</literal> API to hide the underlying transaction system
from your code. If you use JTA, use the JTA interfaces to demarcate transactions. If you from your code. If you use JTA, use the JTA interfaces to demarcate transactions. If you
execute in an EJB container that supports CMT, transaction boundaries are defined declaratively execute in an EJB container that supports CMT, transaction boundaries are defined declaratively

View File

@ -522,7 +522,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
<para> <para>
You may also enable batch fetching of collections. For example, if each <literal>Person</literal> has You may also enable batch fetching of collections. For example, if each <literal>Person</literal> has
a lazy collection of <literal>Cat</literal>s, and 10 persons are currently loaded in the a lazy collection of <literal>Cat</literal>s, and 10 persons are currently loaded in the
<literal>Sesssion</literal>, iterating through all persons will generate 10 <literal>SELECT</literal>s, <literal>Session</literal>, iterating through all persons will generate 10 <literal>SELECT</literal>s,
one for every call to <literal>getCats()</literal>. If you enable batch fetching for the one for every call to <literal>getCats()</literal>. If you enable batch fetching for the
<literal>cats</literal> collection in the mapping of <literal>Person</literal>, Hibernate can pre-fetch <literal>cats</literal> collection in the mapping of <literal>Person</literal>, Hibernate can pre-fetch
collections: collections:
@ -615,7 +615,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
A different (better?) way to avoid unnecessary column reads, at least for A different (better?) way to avoid unnecessary column reads, at least for
read-only transactions is to use the projection features of HQL or Criteria read-only transactions is to use the projection features of HQL or Criteria
queries. This avoids the need for buildtime bytecode processing and is queries. This avoids the need for buildtime bytecode processing and is
certainly a prefered solution. certainly a preferred solution.
</para> </para>
<para> <para>
@ -760,7 +760,7 @@ Cat fritz = (Cat) iter.next();]]></programlisting>
</programlistingco> </programlistingco>
<para> <para>
Alternatively (preferrably?), you may specify <literal>&lt;class-cache&gt;</literal> and Alternatively (preferably?), you may specify <literal>&lt;class-cache&gt;</literal> and
<literal>&lt;collection-cache&gt;</literal> elements in <literal>hibernate.cfg.xml</literal>. <literal>&lt;collection-cache&gt;</literal> elements in <literal>hibernate.cfg.xml</literal>.
</para> </para>
@ -1124,7 +1124,7 @@ hibernate.cache.use_structured_entries true]]></programlisting>
Sets have a primary key consisting of <literal>&lt;key&gt;</literal> and element Sets have a primary key consisting of <literal>&lt;key&gt;</literal> and element
columns. This may be less efficient for some types of collection element, particularly columns. This may be less efficient for some types of collection element, particularly
composite elements or large text or binary fields; the database may not be able to index composite elements or large text or binary fields; the database may not be able to index
a complex primary key as efficently. On the other hand, for one to many or many to many a complex primary key as efficiently. On the other hand, for one to many or many to many
associations, particularly in the case of synthetic identifiers, it is likely to be just associations, particularly in the case of synthetic identifiers, it is likely to be just
as efficient. (Side-note: if you want <literal>SchemaExport</literal> to actually create as efficient. (Side-note: if you want <literal>SchemaExport</literal> to actually create
the primary key of a <literal>&lt;set&gt;</literal> for you, you must declare all columns the primary key of a <literal>&lt;set&gt;</literal> for you, you must declare all columns
@ -1330,7 +1330,7 @@ server.registerMBean(stats, on); // Register the MBean on the server]]></program
</itemizedlist> </itemizedlist>
<para> <para>
Statistics can be reset programatically using the <literal>clear()</literal> method. Statistics can be reset programmatically using the <literal>clear()</literal> method.
A summary can be sent to a logger (info level) using the <literal>logSummary()</literal> A summary can be sent to a logger (info level) using the <literal>logSummary()</literal>
method. method.
</para> </para>
@ -1367,7 +1367,7 @@ server.registerMBean(stats, on); // Register the MBean on the server]]></program
</itemizedlist> </itemizedlist>
<para> <para>
For exampl,e you can check the cache hit, miss, and put ratio of entities, collections For example, you can check the cache hit, miss, and put ratio of entities, collections
and queries, and the average time a query needs. Beware that the number of milliseconds and queries, and the average time a query needs. Beware that the number of milliseconds
is subject to approximation in Java. Hibernate is tied to the JVM precision, on some is subject to approximation in Java. Hibernate is tied to the JVM precision, on some
platforms this might even only be accurate to 10 seconds. platforms this might even only be accurate to 10 seconds.

View File

@ -59,7 +59,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").list();
</itemizedlist> </itemizedlist>
<para>This will still return Object arrays, but now it will not use <para>This will still return Object arrays, but now it will not use
<literal>ResultSetMetdata</literal> but will instead explicitly get the <literal>ResultSetMetadata</literal> but will instead explicitly get the
ID, NAME and BIRTHDATE column as respectively a Long, String and a Short ID, NAME and BIRTHDATE column as respectively a Long, String and a Short
from the underlying resultset. This also means that only these three from the underlying resultset. This also means that only these three
columns will be returned, even though the query is using columns will be returned, even though the query is using
@ -181,7 +181,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class)
row, a cat and its mother. This will fail since there is a conflict of row, a cat and its mother. This will fail since there is a conflict of
names since they are mapped to the same column names and on some names since they are mapped to the same column names and on some
databases the returned column aliases will most likely be on the form databases the returned column aliases will most likely be on the form
"c.ID", "c.NAME", etc. which are not equal to the columns specificed in "c.ID", "c.NAME", etc. which are not equal to the columns specified in
the mappings ("ID" and "NAME").</para> the mappings ("ID" and "NAME").</para>
<para>The following form is not vulnerable to column name <para>The following form is not vulnerable to column name
@ -206,7 +206,7 @@ sess.createSQLQuery("SELECT ID, NAME, BIRTHDATE FROM CATS").addEntity(Cat.class)
</itemizedlist> </itemizedlist>
<para>The {cat.*} and {mother.*} notation used above is a shorthand for <para>The {cat.*} and {mother.*} notation used above is a shorthand for
"all properties". Alternatively, you may list the columns explicity, but "all properties". Alternatively, you may list the columns explicitly, but
even in this case we let Hibernate inject the SQL column aliases for even in this case we let Hibernate inject the SQL column aliases for
each property. The placeholder for a column alias is just the property each property. The placeholder for a column alias is just the property
name qualified by the table alias. In the following example, we retrieve name qualified by the table alias. In the following example, we retrieve
@ -450,7 +450,7 @@ List pusList = query.setString("name", "Pus%").list(); ]]></programlist
</sql-query>]]></programlisting> </sql-query>]]></programlisting>
<para>You can externalize the resultset mapping informations in a <para>You can externalize the resultset mapping informations in a
<literal>&lt;resultset&gt;</literal> element to either reuse them accross <literal>&lt;resultset&gt;</literal> element to either reuse them across
several named queries or through the several named queries or through the
<literal>setResultSetMapping()</literal> API.</para> <literal>setResultSetMapping()</literal> API.</para>

View File

@ -87,7 +87,7 @@
<para> <para>
The most common pattern in a multi-user client/server application is The most common pattern in a multi-user client/server application is
<emphasis>session-per-request</emphasis>. In this model, a request from the client <emphasis>session-per-request</emphasis>. In this model, a request from the client
is send to the server (where the Hibernate persistence layer runs), a new Hibernate is sent to the server (where the Hibernate persistence layer runs), a new Hibernate
<literal>Session</literal> is opened, and all database operations are executed in this unit <literal>Session</literal> is opened, and all database operations are executed in this unit
of work. Once the work has been completed (and the response for the client has been prepared), of work. Once the work has been completed (and the response for the client has been prepared),
the session is flushed and closed. You would also use a single database transaction to the session is flushed and closed. You would also use a single database transaction to
@ -100,7 +100,7 @@
The challenge lies in the implementation. Hibernate provides built-in management of The challenge lies in the implementation. Hibernate provides built-in management of
the "current session" to simplify this pattern. All you have to do is start a the "current session" to simplify this pattern. All you have to do is start a
transaction when a server request has to be processed, and end the transaction transaction when a server request has to be processed, and end the transaction
before the response is send to the client. You can do this in any way you before the response is sent to the client. You can do this in any way you
like, common solutions are <literal>ServletFilter</literal>, AOP interceptor with a like, common solutions are <literal>ServletFilter</literal>, AOP interceptor with a
pointcut on the service methods, or a proxy/interception container. An EJB container pointcut on the service methods, or a proxy/interception container. An EJB container
is a standardized way to implement cross-cutting aspects such as transaction is a standardized way to implement cross-cutting aspects such as transaction
@ -174,7 +174,7 @@
</para> </para>
<para> <para>
Clearly, we have to use several database transactions to implement the converastion. Clearly, we have to use several database transactions to implement the conversation.
In this case, maintaining isolation of business processes becomes the In this case, maintaining isolation of business processes becomes the
partial responsibility of the application tier. A single conversation partial responsibility of the application tier. A single conversation
usually spans several database transactions. It will be atomic if only one of usually spans several database transactions. It will be atomic if only one of
@ -189,7 +189,7 @@
<para> <para>
<emphasis>Automatic Versioning</emphasis> - Hibernate can do automatic <emphasis>Automatic Versioning</emphasis> - Hibernate can do automatic
optimistic concurrency control for you, it can automatically detect optimistic concurrency control for you, it can automatically detect
if a concurrent modification occured during user think time. Usually if a concurrent modification occurred during user think time. Usually
we only check at the end of the conversation. we only check at the end of the conversation.
</para> </para>
</listitem> </listitem>
@ -212,7 +212,7 @@
<emphasis>session-per-conversation</emphasis> and makes <emphasis>session-per-conversation</emphasis> and makes
even reattachment unnecessary. Automatic versioning is used to isolate even reattachment unnecessary. Automatic versioning is used to isolate
concurrent modifications and the <literal>Session</literal> is usually concurrent modifications and the <literal>Session</literal> is usually
not allowed to be flushed automatically, but explicitely. not allowed to be flushed automatically, but explicitly.
</para> </para>
</listitem> </listitem>
</itemizedlist> </itemizedlist>
@ -348,7 +348,7 @@
<title>Database transaction demarcation</title> <title>Database transaction demarcation</title>
<para> <para>
Datatabase (or system) transaction boundaries are always necessary. No communication with Database (or system) transaction boundaries are always necessary. No communication with
the database can occur outside of a database transaction (this seems to confuse many developers the database can occur outside of a database transaction (this seems to confuse many developers
who are used to the auto-commit mode). Always use clear transaction boundaries, even for who are used to the auto-commit mode). Always use clear transaction boundaries, even for
read-only operations. Depending on your isolation level and database capabilities this might not read-only operations. Depending on your isolation level and database capabilities this might not
@ -370,7 +370,7 @@
<para> <para>
However, it is often desirable to keep your persistence layer portable between non-managed However, it is often desirable to keep your persistence layer portable between non-managed
resource-local environments, and systems that can rely on JTA but use BMT instead of CMT. resource-local environments, and systems that can rely on JTA but use BMT instead of CMT.
In both cases you'd use programmatic transaction demaracation. Hibernate offers a wrapper In both cases you'd use programmatic transaction demarcation. Hibernate offers a wrapper
API called <literal>Transaction</literal> that translates into the native transaction system of API called <literal>Transaction</literal> that translates into the native transaction system of
your deployment environment. This API is actually optional, but we strongly encourage its use your deployment environment. This API is actually optional, but we strongly encourage its use
unless you are in a CMT session bean. unless you are in a CMT session bean.
@ -544,7 +544,7 @@ catch (RuntimeException e) {
}]]></programlisting> }]]></programlisting>
<para> <para>
With CMT, transaction demarcation is done in session bean deployment descriptors, not programatically, With CMT, transaction demarcation is done in session bean deployment descriptors, not programmatically,
hence, the code is reduced to: hence, the code is reduced to:
</para> </para>
@ -569,7 +569,7 @@ catch (RuntimeException e) {
in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set in a CMT session bean, when you configure Hibernate's transaction factory. Remember to also set
<literal>hibernate.transaction.manager_lookup_class</literal>. Furthermore, make sure <literal>hibernate.transaction.manager_lookup_class</literal>. Furthermore, make sure
that your <literal>hibernate.current_session_context_class</literal> is either unset (backwards that your <literal>hibernate.current_session_context_class</literal> is either unset (backwards
compatiblity), or set to <literal>"jta"</literal>. compatibility), or set to <literal>"jta"</literal>.
</para> </para>
<para> <para>
@ -580,7 +580,7 @@ catch (RuntimeException e) {
<literal>Iterator</literal> instances returned by <literal>scroll()</literal> or <literal>Iterator</literal> instances returned by <literal>scroll()</literal> or
<literal>iterate()</literal>. You <emphasis>must</emphasis> release the underlying database <literal>iterate()</literal>. You <emphasis>must</emphasis> release the underlying database
cursor by calling <literal>ScrollableResults.close()</literal> or cursor by calling <literal>ScrollableResults.close()</literal> or
<literal>Hibernate.close(Iterator)</literal> explicity from a <literal>finally</literal> <literal>Hibernate.close(Iterator)</literal> explicitly from a <literal>finally</literal>
block. (Of course, most applications can easily avoid using <literal>scroll()</literal> or block. (Of course, most applications can easily avoid using <literal>scroll()</literal> or
<literal>iterate()</literal> at all from the JTA or CMT code.) <literal>iterate()</literal> at all from the JTA or CMT code.)
</para> </para>
@ -615,8 +615,8 @@ catch (RuntimeException e) {
<para> <para>
Hibernate wraps <literal>SQLException</literal>s thrown while interacting with the database Hibernate wraps <literal>SQLException</literal>s thrown while interacting with the database
in a <literal>JDBCException</literal>. In fact, Hibernate will attempt to convert the eexception in a <literal>JDBCException</literal>. In fact, Hibernate will attempt to convert the exception
into a more meningful subclass of <literal>JDBCException</literal>. The underlying into a more meaningful subclass of <literal>JDBCException</literal>. The underlying
<literal>SQLException</literal> is always available via <literal>JDBCException.getCause()</literal>. <literal>SQLException</literal> is always available via <literal>JDBCException.getCause()</literal>.
Hibernate converts the <literal>SQLException</literal> into an appropriate Hibernate converts the <literal>SQLException</literal> into an appropriate
<literal>JDBCException</literal> subclass using the <literal>SQLExceptionConverter</literal> <literal>JDBCException</literal> subclass using the <literal>SQLExceptionConverter</literal>
@ -674,7 +674,7 @@ catch (RuntimeException e) {
Hibernate can at least control data access operations, ensuring that database Hibernate can at least control data access operations, ensuring that database
level deadlocks and queries with huge result sets are limited by a defined level deadlocks and queries with huge result sets are limited by a defined
timeout. In a managed environment, Hibernate can delegate transaction timeout timeout. In a managed environment, Hibernate can delegate transaction timeout
to JTA. This functioanlity is abstracted by the Hibernate to JTA. This functionality is abstracted by the Hibernate
<literal>Transaction</literal> object. <literal>Transaction</literal> object.
</para> </para>
@ -762,7 +762,7 @@ session.close();]]></programlisting>
<para> <para>
Clearly, manual version checking is only feasible in very trivial circumstances Clearly, manual version checking is only feasible in very trivial circumstances
and not practical for most applications. Often not only single instances, but and not practical for most applications. Often not only single instances, but
complete graphs of modified ojects have to be checked. Hibernate offers automatic complete graphs of modified objects have to be checked. Hibernate offers automatic
version checking with either an extended <literal>Session</literal> or detached instances version checking with either an extended <literal>Session</literal> or detached instances
as the design paradigm. as the design paradigm.
</para> </para>
@ -866,7 +866,7 @@ session.close();]]></programlisting>
<para> <para>
Again, Hibernate will check instance versions during flush, throwing an Again, Hibernate will check instance versions during flush, throwing an
exception if conflicting updates occured. exception if conflicting updates occurred.
</para> </para>
<para> <para>
@ -893,7 +893,7 @@ session.close();]]></programlisting>
even timestamps. In both cases, versioning can't rely on a particular column in a table. even timestamps. In both cases, versioning can't rely on a particular column in a table.
To force a version check without a version or timestamp property mapping, with a To force a version check without a version or timestamp property mapping, with a
comparison of the state of all fields in a row, turn on <literal>optimistic-lock="all"</literal> comparison of the state of all fields in a row, turn on <literal>optimistic-lock="all"</literal>
in the <literal>&lt;class&gt;</literal> mapping. Note that this concepetually only works in the <literal>&lt;class&gt;</literal> mapping. Note that this conceptually only works
if Hibernate can compare the old and new state, i.e. if you use a single long if Hibernate can compare the old and new state, i.e. if you use a single long
<literal>Session</literal> and not session-per-request-with-detached-objects. <literal>Session</literal> and not session-per-request-with-detached-objects.
</para> </para>
@ -909,7 +909,7 @@ session.close();]]></programlisting>
comparison, Hibernate uses a single <literal>UPDATE</literal> statement (with an comparison, Hibernate uses a single <literal>UPDATE</literal> statement (with an
appropriate <literal>WHERE</literal> clause) per entity to execute the version check appropriate <literal>WHERE</literal> clause) per entity to execute the version check
and update the information. If you use transitive persistence to cascade reattachment and update the information. If you use transitive persistence to cascade reattachment
to associated entities, Hibernate might execute uneccessary updates. This is usually to associated entities, Hibernate might execute unnecessary updates. This is usually
not a problem, but <emphasis>on update</emphasis> triggers in the database might be not a problem, but <emphasis>on update</emphasis> triggers in the database might be
executed even when no changes have been made to detached instances. You can customize executed even when no changes have been made to detached instances. You can customize
this behavior by setting <literal>select-before-update="true"</literal> in the this behavior by setting <literal>select-before-update="true"</literal> in the
@ -925,7 +925,7 @@ session.close();]]></programlisting>
<title>Pessimistic Locking</title> <title>Pessimistic Locking</title>
<para> <para>
It is not intended that users spend much time worring about locking strategies. Its usually It is not intended that users spend much time worrying about locking strategies. It's usually
enough to specify an isolation level for the JDBC connections and then simply let the enough to specify an isolation level for the JDBC connections and then simply let the
database do all the work. However, advanced users may sometimes wish to obtain database do all the work. However, advanced users may sometimes wish to obtain
exclusive pessimistic locks, or re-obtain locks at the start of a new transaction. exclusive pessimistic locks, or re-obtain locks at the start of a new transaction.
@ -1042,7 +1042,7 @@ session.close();]]></programlisting>
<listitem> <listitem>
<para> <para>
<literal>ON_CLOSE</literal> - is essentially the legacy behavior described above. The <literal>ON_CLOSE</literal> - is essentially the legacy behavior described above. The
Hibernate session obatins a connection when it first needs to perform some JDBC access Hibernate session obtains a connection when it first needs to perform some JDBC access
and holds unto that connection until the session is closed. and holds unto that connection until the session is closed.
</para> </para>
</listitem> </listitem>

View File

@ -237,7 +237,7 @@ public class Event {
</hibernate-mapping>]]></programlisting> </hibernate-mapping>]]></programlisting>
<para> <para>
The <literal>id</literal> element is the declaration of the identifer property, The <literal>id</literal> element is the declaration of the identifier property,
<literal>name="id"</literal> declares the name of the Java property - <literal>name="id"</literal> declares the name of the Java property -
Hibernate will use the getter and setter methods to access the property. Hibernate will use the getter and setter methods to access the property.
The column attribute tells Hibernate which column of the The column attribute tells Hibernate which column of the
@ -776,7 +776,7 @@ else if (args[0].equals("list")) {
<listitem> <listitem>
<para> <para>
Now disable hbm2ddl by commenting out the property in your <literal>hibernate.cfg.xml</literal> Now disable hbm2ddl by commenting out the property in your <literal>hibernate.cfg.xml</literal>
file. Usually you only leave it turned on in continous unit testing, but another file. Usually you only leave it turned on in continuous unit testing, but another
run of hbm2ddl would <emphasis>drop</emphasis> everything you have stored - the run of hbm2ddl would <emphasis>drop</emphasis> everything you have stored - the
<literal>create</literal> configuration setting actually translates into "drop all <literal>create</literal> configuration setting actually translates into "drop all
tables from the schema, then re-create all tables, when the SessionFactory is build". tables from the schema, then re-create all tables, when the SessionFactory is build".
@ -1144,7 +1144,7 @@ public void setEmailAddresses(Set emailAddresses) {
}]]></programlisting> }]]></programlisting>
<para> <para>
This time we didnt' use a <emphasis>fetch</emphasis> query to initialize the collection. This time we didn't use a <emphasis>fetch</emphasis> query to initialize the collection.
Hence, the call to its getter method will trigger an additional select to initialize Hence, the call to its getter method will trigger an additional select to initialize
it, so we can add an element to it. Monitor the SQL log and try to optimize this with it, so we can add an element to it. Monitor the SQL log and try to optimize this with
an eager fetch. an eager fetch.
@ -1216,7 +1216,7 @@ public void setParticipants(Set participants) {
</para> </para>
<para> <para>
Many developers program defensive and create link management methods to Many developers program defensively and create link management methods to
correctly set both sides, e.g. in <literal>Person</literal>: correctly set both sides, e.g. in <literal>Person</literal>:
</para> </para>
@ -1346,7 +1346,7 @@ public class EventManagerServlet extends HttpServlet {
<para> <para>
Finally, the unit of work ends when processing and rendering is complete. If any Finally, the unit of work ends when processing and rendering is complete. If any
problem occured during processing or rendering, an exception will be thrown problem occurred during processing or rendering, an exception will be thrown
and the database transaction rolled back. This completes the and the database transaction rolled back. This completes the
<literal>session-per-request</literal> pattern. Instead of the transaction <literal>session-per-request</literal> pattern. Instead of the transaction
demarcation code in every servlet you could also write a servlet filter. demarcation code in every servlet you could also write a servlet filter.
@ -1456,7 +1456,7 @@ out.close();]]></programlisting>
That's it, the servlet is complete. A request to the servlet will be processed That's it, the servlet is complete. A request to the servlet will be processed
in a single <literal>Session</literal> and <literal>Transaction</literal>. As in a single <literal>Session</literal> and <literal>Transaction</literal>. As
earlier in the standalone application, Hibernate can automatically bind these earlier in the standalone application, Hibernate can automatically bind these
ojects to the current thread of execution. This gives you the freedom to layer objects to the current thread of execution. This gives you the freedom to layer
your code and access the <literal>SessionFactory</literal> in any way you like. your code and access the <literal>SessionFactory</literal> in any way you like.
Usually you'd use a more sophisticated design and move the data access code Usually you'd use a more sophisticated design and move the data access code
into data access objects (the DAO pattern). See the Hibernate Wiki for more into data access objects (the DAO pattern). See the Hibernate Wiki for more
@ -1510,7 +1510,7 @@ out.close();]]></programlisting>
Before you compile and deploy the web application, note that an additional library Before you compile and deploy the web application, note that an additional library
is required: <literal>jsdk.jar</literal>. This is the Java servlet development kit, is required: <literal>jsdk.jar</literal>. This is the Java servlet development kit,
if you don't have this library already, get it from the Sun website and copy it to if you don't have this library already, get it from the Sun website and copy it to
your library directory. However, it will be only used for compliation and excluded your library directory. However, it will be only used for compilation and excluded
from the WAR package. from the WAR package.
</para> </para>