[jboss-cvs] JBossAS SVN: r83446 - in projects/docs/enterprise: 4.2.6/readme/en-US and 2 other directories.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Mon Jan 26 22:22:59 EST 2009
Author: irooskov at redhat.com
Date: 2009-01-26 22:22:59 -0500 (Mon, 26 Jan 2009)
New Revision: 83446
Modified:
projects/docs/enterprise/4.2.6/Getting_Started/en-US/Start_Stop_Server.xml
projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
projects/docs/enterprise/4.3.4/Getting_Started/en-US/Start_Stop_Server.xml
projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
Log:
updated release notes and getting started guide for next CP releases
Modified: projects/docs/enterprise/4.2.6/Getting_Started/en-US/Start_Stop_Server.xml
===================================================================
--- projects/docs/enterprise/4.2.6/Getting_Started/en-US/Start_Stop_Server.xml 2009-01-26 22:55:33 UTC (rev 83445)
+++ projects/docs/enterprise/4.2.6/Getting_Started/en-US/Start_Stop_Server.xml 2009-01-27 03:22:59 UTC (rev 83446)
@@ -237,5 +237,28 @@
</para>
</note>
</section>
+ <section>
+ <title>Enabling Remote Connectivity to the JBoss Server</title>
+ <para>
+ Older versions of the JBoss Server always bound to the address 0.0.0.0 (for instance, all network interfaces). This resulted in many unprotected instances of JBoss on the Internet. This is no longer the case as JBoss now only binds to the local interface (typically 127.0.0.1) by default. To change this, the <code>-b</code> command line option can be used.
+ </para>
+ <para>
+ In order to execute this under Linux run:
+ </para>
+<programlisting>
+./run.sh -b <ip address>
+</programlisting>
+ <para>
+ In order to execute this under Windows run:
+ </para>
+<programlisting>
+run.bat -b <ip address>
+</programlisting>
+ <note>
+ <para>
+ Using <code>-b</code> as part of the JBoss Server's command line is equivalent to setting these individual properties: <varname>-Djboss.bind.address</varname> <varname>-Djava.rmi.server.hostname</varname> <varname>-Djgroups.bind_addr</varname> and <varname>-Dbind.address</varname>. Also note that passing <varname>-Djboss.bind.address</varname> to the Java process as part of the <varname>JAVA_OPTS</varname> variable in the run scripts will not work as it is a JBoss property not a JVM property.
+ </para>
+ </note>
+ </section>
</section>
Modified: projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml
===================================================================
--- projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml 2009-01-26 22:55:33 UTC (rev 83445)
+++ projects/docs/enterprise/4.2.6/readme/en-US/Release_Notes_CP06.xml 2009-01-27 03:22:59 UTC (rev 83446)
@@ -61,12 +61,12 @@
</listitem>
<listitem>
<para>
- Hibernate Annotations 3.2.1.GA.CP04
+ Hibernate Annotations 3.2.1.GA.CP03
</para>
</listitem>
<listitem>
<para>
- Hibernate Entity Manager 3.2.1.GA_CP05
+ Hibernate Entity Manager 3.2.1.GA_CP04
</para>
</listitem>
<listitem>
@@ -521,46 +521,54 @@
<title>JBoss Hibernate</title>
<para>
<itemizedlist>
+ <important>
+ <para>
+ Hibernate Core has been updated to an enhanced 3.2.4.sp1.cp07 version. The following issues represent the changes for this version.
+ </para>
+ </important>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existance of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
+ </para>
+ <para>
+ <filename>AbstractEntityPersister.java</filename> has been updated to execute a prepared statement on the result set and after calculating the <varname>propValue</varname> the result set is closed if it is not null; ensuring that no leak can occur.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1582">JBPAPP-1582</ulink>:
</para>
</listitem>
<!-- <listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1556">JBPAPP-1556</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1529">JBPAPP-1529</ulink>: The composite primary key of 765 bytes fails within the unit test for Sybase, as it exceeds the maximum index length of 600 bytes. In order to rectify this issue, a hard coded length of 32 bytes is now in place for the compasite primary key ID within the <filename>UserGroup.hbm.xml</filename> file.
</para>
</listitem> -->
- <listitem>
+ <!-- <listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1529">JBPAPP-1529</ulink>: The composite primary key of 765 bytes fails within the unit test for Sybase, as it exceeds the maximum index length of 600 bytes. In order to rectify this issue, a hard coded length of 32 bytes is now in place for the compasite primary key ID within the <filename>UserGroup.hbm.xml</filename> file.
- </para>
- </listitem>
- <listitem>
- <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1528">JBPAPP-1528</ulink>: When Sybase would convert Java byte into tinyint, failures would arise within tests because of the use of 8 bit values. To correct this the unit tests have been updated to use 7 bit values instead of 8. In order to instigate this correction, the <filename>InterfaceProxyTest.java</filename> and <filename>MixedTest.java</filename> files have been updated.
</para>
- </listitem>
- <listitem>
+ </listitem> -->
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1527">JBPAPP-1527</ulink>: Limitations of the Sybase ResultSet implementation would cause unit test failures because the data would not be read before closing the ResultSet. The <filename>AggressiveReleaseTest.java</filename>, <filename>CMTTest.java</filename> and <filename>StatsTest.java</filename> files have been updated so that the ResultSet is read correctly for Sybase so that no <exceptionname>NullPointerException</exceptionname> is thrown.
</para>
- </listitem>
+ </listitem> -->
<listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1524">JBPAPP-1524</ulink>: The Sybase functions <methodname>second()</methodname>, <methodname>minute()</methodname>, <methodname>hour()</methodname> and <methodname>extract()</methodname> caused a <exceptionname>GenericJDBCException</exceptionname> when used. Moving these functions from the <filename>SQLServerDialect.java</filename> file to the <filename>SybaseDialect.java</filename> file allows for these functions to work correctly.
</para>
</listitem>
- <listitem>
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1523">JBPAPP-1523</ulink>: The test supplied for the <methodname>str()</methodname> method is invalid for SQL Server and Sybase as optional parameters for controlling the number of characters for decimal plus decimal values is 0 and the test uses these values by default for SQL Server and Sybase, returning null values. The test has been updated for these dialects so that the values passed are appropriate and do not return null.
</para>
- </listitem>
- <listitem>
+ </listitem> -->
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1520">JBPAPP-1520</ulink>: The <methodname>FooBarTest.testCollectionsInSelect()</methodname> tests fails for Sybase because implicit support for conversion between <varname>VARCHAR</varname> to <varname>INT</varname>.The files <filename>NativeQueryTest.java</filename> and <filename>FooBar.test</filename> have been updated to correct this issue.
</para>
- </listitem>
+ </listitem> -->
<listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the opperation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both opperate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
@@ -611,6 +619,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1365">JBPAPP-1365</ulink>: A bug existed within Hibernate Core where the <methodname>addDuplicateAlias</methodname> method would include an entry into the hash map even when the <varname>classAlias</varname> variable was set to null; causing a <exceptionname>NullPointerException</exceptionname> when the <methodname>CrazyJPARRequirements()</methodname> method is called. To correct this issue the <filename>FromClause.java</filename> file has been modified to correct the <methodname>addDuplicateAlias</methodname> method by testing if the <varname>alias</varname> variable is null and if it is not null then the <methodname>fromElementByClassAlias.put</methodname> is now called, instead of this method being called even if <varname>alias</varname> contained a null value.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has expectly said that the version field should not be updated and does not update the field if this is the case.
</para>
</listitem>
@@ -670,6 +683,16 @@
<itemizedlist>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1636">JBPAPP-1636</ulink>: When an adapter handled the scheduling of work to be performed, the <classname>ExecutionContext</classname> class contains a value in seconds, from which the <methodname>getCompletionTimeout</methodname> method of <classname>org.jboss.resource.work.WorkWrapper</classname> obtains its information. An issue arises with <methodname>getCompletionTimeout</methodname> expecting the value to be in milliseconds, creating an error where the initially set timeout value may be 6 seconds but be passed to the thread pool as 6 milliseconds. The <filename>WorkWrapper.java</filename> file has been updated and correctly converts the timeout value from seconds to milliseconds.
+ </para>
+ <important>
+ <para>
+ This bug only affected third party adapters running within the JBoss Application Server.
+ </para>
+ </important>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1635">JBPAPP-1635</ulink>: The <classname>OracleExceptionSorter</classname> has been enhanced for this release with new error codes of 17002 (connection reset) and 17008 (connection closed) now able to be handled. These enhancements have been applied to the <filename>OracleExceptionSorter.java</filename> file.
</para>
</listitem>
Modified: projects/docs/enterprise/4.3.4/Getting_Started/en-US/Start_Stop_Server.xml
===================================================================
--- projects/docs/enterprise/4.3.4/Getting_Started/en-US/Start_Stop_Server.xml 2009-01-26 22:55:33 UTC (rev 83445)
+++ projects/docs/enterprise/4.3.4/Getting_Started/en-US/Start_Stop_Server.xml 2009-01-27 03:22:59 UTC (rev 83446)
@@ -240,28 +240,25 @@
</note>
</section>
<section>
- <title>Starting Remote Connectivity to the JBoss Server</title>
+ <title>Enabling Remote Connectivity to the JBoss Server</title>
<para>
- In older versions of the JBoss Server, JBoss always bound to the address 0.0.0.0; creating an unprotected instance of JBoss. This is no longer the case, however there may arise a need for an unprotected instance and in order to instruct this behavior, the <code>-b</code> option must be used.
+ Older versions of the JBoss Server always bound to the address 0.0.0.0 (for instance, all network interfaces). This resulted in many unprotected instances of JBoss on the Internet. This is no longer the case as JBoss now only binds to the local interface (typically 127.0.0.1) by default. To change this, the <code>-b</code> command line option can be used.
</para>
<para>
- This option configures the <varname>jboss.bind.address</varname> to the JBoss startup script and setting the address to 0.0.0.0 permits JBoss to listen for connections on all IP addresses of the machine.
- </para>
- <para>
In order to execute this under Linux run:
</para>
<programlisting>
-./run.sh -b 0.0.0.0
+./run.sh -b <ip address>
</programlisting>
<para>
In order to execute this under Windows run:
</para>
<programlisting>
-run.bat -b 0.0.0.0
+run.bat -b <ip address>
</programlisting>
<note>
<para>
- Passing <code>-Djboss.bind.address</code> to the Java process as part of the <varname>JAVA_OPTS</varname> variable in the run scripts will not work, as the <code>-b</code> option should be utilized. The equivalent of the <code>-b</code> option however is <code>-Djboss.bind.address -Djava.rmi.server.hostname -Djgroups.bind_addr -Dbind.address</code>.
+ Using <code>-b</code> as part of the JBoss Server's command line is equivalent to setting these individual properties: <varname>-Djboss.bind.address</varname> <varname>-Djava.rmi.server.hostname</varname> <varname>-Djgroups.bind_addr</varname> and <varname>-Dbind.address</varname>. Also note that passing <varname>-Djboss.bind.address</varname> to the Java process as part of the <varname>JAVA_OPTS</varname> variable in the run scripts will not work as it is a JBoss property not a JVM property.
</para>
</note>
</section>
Modified: projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml
===================================================================
--- projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml 2009-01-26 22:55:33 UTC (rev 83445)
+++ projects/docs/enterprise/4.3.4/readme/en-US/Release_Notes_CP04.xml 2009-01-27 03:22:59 UTC (rev 83446)
@@ -56,17 +56,17 @@
</listitem>
<listitem>
<para>
- Hibernate 3.2.4.SP1.CP07
+ Hibernate Core 3.2.4.SP1.CP07
</para>
</listitem>
<listitem>
<para>
- Hibernate Annotations 3.2.1.GA.CP04
+ Hibernate Annotations 3.2.1.GA.CP03
</para>
</listitem>
<listitem>
<para>
- Hibernate Entity Manager 3.2.1.GA_CP05
+ Hibernate Entity Manager 3.2.1.GA_CP04
</para>
</listitem>
<listitem>
@@ -618,46 +618,54 @@
<title>JBoss Hibernate</title>
<para>
<itemizedlist>
+ <important>
+ <para>
+ Hibernate Core has been updated to an enhanced 3.2.4.sp1.cp07 version. The following issues represent the changes for this version.
+ </para>
+ </important>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1628">JBPAPP-1628</ulink>: In an earlier fix to Hibernate the <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> method was changed to check for the existance of the prepared statement in the <classname>statementsToClose</classname> collection instead of closing it unconditionally. This has now caused a properties leak as the <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> used <methodname>org.hibernate.jdbc.AbstractBatcher#closeQueryStatement()</methodname> and the statement within <methodname>org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties()</methodname> is not added to the <classname>statementsToClose</classname> collection.
+ </para>
+ <para>
+ <filename>AbstractEntityPersister.java</filename> has been updated to execute a prepared statement on the result set and after calculating the <varname>propValue</varname> the result set is closed if it is not null; ensuring that no leak can occur.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1582">JBPAPP-1582</ulink>:
</para>
</listitem>
<!-- <listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1556">JBPAPP-1556</ulink>:
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1529">JBPAPP-1529</ulink>: The composite primary key of 765 bytes fails within the unit test for Sybase, as it exceeds the maximum index length of 600 bytes. In order to rectify this issue, a hard coded length of 32 bytes is now in place for the compasite primary key ID within the <filename>UserGroup.hbm.xml</filename> file.
</para>
</listitem> -->
- <listitem>
+ <!-- <listitem>
<para>
- <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1529">JBPAPP-1529</ulink>: The composite primary key of 765 bytes fails within the unit test for Sybase, as it exceeds the maximum index length of 600 bytes. In order to rectify this issue, a hard coded length of 32 bytes is now in place for the compasite primary key ID within the <filename>UserGroup.hbm.xml</filename> file.
- </para>
- </listitem>
- <listitem>
- <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1528">JBPAPP-1528</ulink>: When Sybase would convert Java byte into tinyint, failures would arise within tests because of the use of 8 bit values. To correct this the unit tests have been updated to use 7 bit values instead of 8. In order to instigate this correction, the <filename>InterfaceProxyTest.java</filename> and <filename>MixedTest.java</filename> files have been updated.
</para>
- </listitem>
- <listitem>
+ </listitem> -->
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1527">JBPAPP-1527</ulink>: Limitations of the Sybase ResultSet implementation would cause unit test failures because the data would not be read before closing the ResultSet. The <filename>AggressiveReleaseTest.java</filename>, <filename>CMTTest.java</filename> and <filename>StatsTest.java</filename> files have been updated so that the ResultSet is read correctly for Sybase so that no <exceptionname>NullPointerException</exceptionname> is thrown.
</para>
- </listitem>
+ </listitem> -->
<listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1524">JBPAPP-1524</ulink>: The Sybase functions <methodname>second()</methodname>, <methodname>minute()</methodname>, <methodname>hour()</methodname> and <methodname>extract()</methodname> caused a <exceptionname>GenericJDBCException</exceptionname> when used. Moving these functions from the <filename>SQLServerDialect.java</filename> file to the <filename>SybaseDialect.java</filename> file allows for these functions to work correctly.
</para>
</listitem>
- <listitem>
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1523">JBPAPP-1523</ulink>: The test supplied for the <methodname>str()</methodname> method is invalid for SQL Server and Sybase as optional parameters for controlling the number of characters for decimal plus decimal values is 0 and the test uses these values by default for SQL Server and Sybase, returning null values. The test has been updated for these dialects so that the values passed are appropriate and do not return null.
</para>
- </listitem>
- <listitem>
+ </listitem> -->
+ <!-- <listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1520">JBPAPP-1520</ulink>: The <methodname>FooBarTest.testCollectionsInSelect()</methodname> tests fails for Sybase because implicit support for conversion between <varname>VARCHAR</varname> to <varname>INT</varname>.The files <filename>NativeQueryTest.java</filename> and <filename>FooBar.test</filename> have been updated to correct this issue.
</para>
- </listitem>
+ </listitem> -->
<listitem>
<para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1519">JBPAPP-1519</ulink>: Sybase does not support the opperation <emphasis>on cascade delete</emphasis> while SQL Server does. To make sure that both opperate correctly the <filename>SQLServerDialect.java</filename> file has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns true and <filename>SybaseDialect.java</filename> has been updated to include a new <methodname>supportsCascadeDelete()</methodname> method which returns false.
@@ -708,6 +716,11 @@
</listitem>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1365">JBPAPP-1365</ulink>: A bug existed within Hibernate Core where the <methodname>addDuplicateAlias</methodname> method would include an entry into the hash map even when the <varname>classAlias</varname> variable was set to null; causing a <exceptionname>NullPointerException</exceptionname> when the <methodname>CrazyJPARRequirements()</methodname> method is called. To correct this issue the <filename>FromClause.java</filename> file has been modified to correct the <methodname>addDuplicateAlias</methodname> method by testing if the <varname>alias</varname> variable is null and if it is not null then the <methodname>fromElementByClassAlias.put</methodname> is now called, instead of this method being called even if <varname>alias</varname> contained a null value.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1259">JBPAPP-1259</ulink>: When using <methodname>dynamicUpdate</methodname> to generate SQL and the version field is specified by the user to not be updated, the <methodname>AbstractEntityPersiter.getPropertiesToUpdate</methodname> method would still update the field causing exceptions to appear in certain cases. Within this EAP update <filename>AbstractEntityPersister.java</filename> has been corrected to check if the user has expectly said that the version field should not be updated and does not update the field if this is the case.
</para>
</listitem>
@@ -767,6 +780,16 @@
<itemizedlist>
<listitem>
<para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1636">JBPAPP-1636</ulink>: When an adapter handled the scheduling of work to be performed, the <classname>ExecutionContext</classname> class contains a value in seconds, from which the <methodname>getCompletionTimeout</methodname> method of <classname>org.jboss.resource.work.WorkWrapper</classname> obtains its information. An issue arises with <methodname>getCompletionTimeout</methodname> expecting the value to be in milliseconds, creating an error where the initially set timeout value may be 6 seconds but be passed to the thread pool as 6 milliseconds. The <filename>WorkWrapper.java</filename> file has been updated and correctly converts the timeout value from seconds to milliseconds.
+ </para>
+ <important>
+ <para>
+ This bug only affected third party adapters running within the JBoss Application Server.
+ </para>
+ </important>
+ </listitem>
+ <listitem>
+ <para>
<ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1635">JBPAPP-1635</ulink>: The <classname>OracleExceptionSorter</classname> has been enhanced for this release with new error codes of 17002 (connection reset) and 17008 (connection closed) now able to be handled. These enhancements have been applied to the <filename>OracleExceptionSorter.java</filename> file.
</para>
</listitem>
More information about the jboss-cvs-commits
mailing list