11 Replies Latest reply on May 13, 2003 9:55 AM by doc_brown

    What are the differences between the JBoss 3.2.0 and 3.0.x?

    whyau

      Q: Where can I find overview note or release note of new features, enhancements, and bugfixes?
      Thanks!

        • 1. Re: What are the differences between the JBoss 3.2.0 and 3.0
          sysuser1

          This is a really good question. I've searched through the site and can't find anything that answers it. Isn't there any release notes, release description, anything?

          Doug

          • 3. Re: What are the differences between the JBoss 3.2.0 and 3.0
            fbiaggi

            Hi,
            Just installed, 2 big differences:
            1. The ejb-jar.xml must contain a DOCTYPE
            2. The 3.0.6 DB-service.xml do not work, repalced by -ds.xml

            fyi...

            • 4. Re: What are the differences between the JBoss 3.2.0 and 3.0
              usiwill

              The release notes list differences between RC4 and the final release, but it would be nice to be able to see the additional features that 3.2 has to offer over 3.0.6 and 3.0.7

              -Will

              • 5. Re: What are the differences between the JBoss 3.2.0 and 3.0
                • 6. Re: What are the differences between the JBoss 3.2.0 and 3.0
                  • 7. Re: What are the differences between the JBoss 3.2.0 and 3.0
                    tobias

                    In the tracker on sf.net select "descending" for sorting or "v3.2" for group. That should give you a nice list with detailed information to each topic.

                    • 8. Re: What are the differences between the JBoss 3.2.0 and 3.0
                      jonmartin

                      That's "Changes between 3.2.0 and 3.2.0RC4", not between 3.0.X and 3.2.0 (unless the heading is misleading, ofcourse :-)

                      • 9. Re: What are the differences between the JBoss 3.2.0 and 3.0
                        doc_brown



                        Ok.. so this topic has the changes from 3.2.0RC4 to 3.2.0 (Final).

                        What are the changes and new additions if I am upgrading from 3.0.x to 3.2.0.

                        Is there a single document listing all the changes and additions?

                        • 10. Re: What are the differences between the JBoss 3.2.0 and 3.0
                          tobias

                          ARGH! Since using the given URL seems too hard for a lot of people I took all the change notes you get there and compiled one big text file. You owe me a beer now ! Here you go :
                          --------------------

                          ejb-jar.xml requires a Public ID

                          Any ejb-jar.xml file encountered now *requires* a valid DOCTYPE
                          Declaration and public Id as per the EJB 1.1 / 2.0 Specs. Acceptable
                          public Id's are:

                          - "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
                          1.1" for EJB 1.1

                          - "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
                          2.0" for EJB 2.0

                          if this breaks your deployments, fix your DOCTYPE declaration that
                          should be all that's necessary.

                          ----

                          XSL based deployment w/datasource example

                          I've written a simple xsl based deployment system and used it to
                          provide a much simpler datasource configuration method. An example of
                          how to specify a xsl subdeployer is in jboss-jca.sar. You specify the
                          acceptable extension and the stylesheet and the delegate deployer, and
                          the xsl deployer transforms incoming dds into a format acceptable to
                          the delegate deployer.

                          This is applied to datasource configuration to allow configurations
                          like this:


                          <local-tx-datasource>
                          <jndi-name>InformixDS</jndi-name>
                          <connection-url>jdbc:informix-sqli://
                          myhost.mydomain.com:1557/mydb:INFORMIXSERVER=
                          myserver</connection-url>
                          <driver-class>com.informix.jdbc.IfxDriver</driver-class>
                          <user-name>x</user-name>
                          y
                          </local-tx-datasource>

                          <xa-tx-datasource>
                          <jndi-name>InformixXADS</jndi-name>
                          <xa-datasource-class>com.informix.jdbcx.IfxXADataSource</
                          xa-datasource-class>
                          <xa-datasource-property name="IfxWAITTIME">10</xa->
                          <xa-datasource-property name="Description">Something
                          Descriptive</xa-datasource-property>
                          <xa-datasource-property name="IfxIFXHOST">
                          myhost.mydomain.com</xa-datasource-property>
                          <xa-datasource-property name="PortNumber">1557</xa->
                          <xa-datasource-property name="DatabaseName">mydb</xa->
                          <xa-datasource-property name="ServerName">myserver</xa->
                          <!-- not sure if these should be here-->
                          <user-name>x</user-name>
                          y
                          </xa-tx-datasource>



                          ----

                          farm service update

                          Farm service will now sync with cluster on startup. It has also been
                          rewritten as a URL Scanner so the configuration is different.

                          ----

                          Strict Verification of EJB .jar Files

                          The EJBDeployer has a new boolean flag called "StrictVerifier" which
                          can be set both in jboss-service.xml as well as via JMX.

                          Setting this to 'true' (currently the default) will cause all EJB
                          Deployments which do *not* pass the Verifier mechanism to throw a
                          DeploymentException (and thus they will not be deployed ... :).

                          If this causes too many problems we might change this to 'false' for
                          the 3.2 branch but methinks that this should be defaulted to 'true'
                          for 4.0 and later.

                          ----

                          JMX Serialization

                          Implemented JMX Serialization as specified in the 1.1 specification

                          The property jmx.serial.form is supported by JBossMX.

                          It has been tested with jmxri.jar versions 1.0 and 1.1

                          The jmxri 1.1 release has problems when
                          jmx.serial.form="1.0",
                          including crashing the VM when serializing DescriptorSupport on a java
                          1.3 VM

                          QueryExp is not serializable in a portable manner. The specification
                          does not define the classes or a serialization mechanism. This does
                          not affect queryMBeans on the ObjectName parameter.

                          ----

                          Applied Common Interfaces of JMS 1.1

                          I added the common interfaces of the JMS 1.1 specification to JBossMQ.

                          ----


                          Entity Lock Monitor added

                          look in jboss-service.xml and uncomment it. Allows you to find out num
                          lock contentions, time for lock contentions and other shit.

                          ----

                          <sync-on-commit-only>

                          Added this boolean flag to standardjboss.xml and jboss.xml

                          If set to true, ejbStore will only be called on transaction commit.

                          ----

                          interrupt threads on tx timeout

                          Threads involved with a timed out transaction are now interrupted.

                          ----

                          JDBC parameter getting/setting overhaul

                          The getting and setting of JDBC parameters in the CMP2 engine has been
                          given a bit of an overhaul.

                          This will have two user visible impacts:

                          1. CLOBS/BLOBS and large objects in general are now fully operational
                          with Oracle. The code used is quite generic and should work against
                          all databases that support LOBs. It has been tested against Oracle
                          9i, Postgres 7.2 and MySQL 3.23.53, (and hsqldb of course). Don't try
                          to use CLOB mappings with MySQL because:

                          a) it doesn't have a native CLOB datatype;

                          b) the jboss code uses ResultSet.getCharacterStream which is not
                          implemented in the current mysql JDBC driver.

                          Really large LOBs are probably better handled using BMP, because the
                          CMP code needs to load the whole thing into memory.

                          2. For some reason, previous versions of JBoss mapped java.lang
                          .Object to a JDBC type of JAVA_OBJECT, and then proceeded to serialize
                          the object into a binary column. Some JDBC drivers would accept this
                          behaviour, but many would not. JAVA_OBJECT is intended to be mapped
                          to custom types on the database, and used in conjunction with the
                          java.sql.SQLData/ SQLInput/SQLOutput interfaces, which are managed by
                          the JDBC driver. Therefore JAVA_OBJECT types are now passed straight
                          through to the JDBC driver via set/getObject. The standard mappings
                          for java.lang.Object that I was able to test (as in item 1) have been
                          changed to have a binary JDBC type to preserve the previous behaviour.

                          NOTE: Anyone who has used JAVA_OBJECT in their jbosscmp- jdbc.xml will
                          need to change it to VARBINARY, LONGVARBINARY or BLOB to get the
                          previous behaviour.

                          IMPORTANT: I have only changed the standard mappings for the db
                          platforms that I could test. If your database is not mentioned above I
                          would appreciate feedback on which binary jdbc types are appropriate.

                          ----

                          JBossMQ MessageCache changes Applies to 4.0 only for now.

                          The global locking on the MessageCache is gone. Locks are now on the
                          message and the LRUCache when required.

                          Softening is now done by the softening thread, except addMessage which
                          will soften one message when required to make room for the new
                          message.

                          Some fixes to the message cache processing under stress, mostly for
                          the joint CacheStore/PersistenceManager jdbc2.

                          Some fixes for jdbc2. Including changes to the SQL in
                          jbossmq-service.xml to correct the recovery process.

                          Added an update operation to the persistence managers so that the
                          redelivered flag is persisted across server reboots.

                          Removed the linear traversal of unacknowledgedMessages in BasicQueue,

                          Rollback the message cache entry when an addMessage transaction fails.

                          Fixed problems with rollingback when a transaction timeout interrupts
                          the thread for jdbc2.

                          Fixed the testsuite to clear undelivered messages and remove durable
                          subscriptions, making it easier to spot a message cache leak in
                          future.

                          ----

                          FK fields mapped to PK fields support

                          It's possible to map foreign key fields in one-to-many and one-to-one
                          relationships to primary key fields. All is needed to assign the same
                          names to the corresponding foreign and primary key fields.

                          Relationships are assigned between ejbCreate and ejbPostCreate. This
                          means that relationships are accessible in ejbPostCreate and not in
                          ejbCreate. Relationships are established and removed only with
                          creation and removal of entities. Modifications with abstract CMR
                          accessors are not allowed as they change primary key values.

                          If ONE side doesn't exist CMR on the MANY side will return null value.
                          If MANY side doesn't exist CMR on the ONE side will return empty
                          collection.

                          If cascade-delete is specified then removal of the ONE side will
                          remove the related MANY side. In this case, ONE side is removed first
                          breaking the relationship, i.e. CMR field on the MANY side in
                          ejbRemove will return null.

                          ----

                          Optimistic locking support

                          To setup optimistic locking, container configuration element
                          locking-policy should be set to

                          <locking-policy>org.jboss.ejb.plugins.lock.JDBCOptimisticLock</locking-policy>
                          and entity element in jbosscmp-jdbc.xml should have optimistic-locking
                          element.

                          Following are the possible configurations of optimistic- locking
                          element:

                          1. Fixed group of fields that will be used for optimistic
                          locking.

                          <optimistic-locking>
                          <group-name>optimisticLockingGroup</group->
                          </optimistic-locking>

                          where optimisticLockingGroup is one of the entity's load-
                          group-name's.

                          2. Modified strategy. The fields that were modified during transaction
                          will be used for optimistic locking.

                          <optimistic-locking>
                          <modified-strategy/>
                          </optimistic-locking>

                          3. Read strategy. The fields that were read during transaction will be
                          used for optimistic locking.

                          <optimistic-locking>
                          <read-strategy/>
                          </optimistic-locking>

                          4. Version (counter) column strategy. Additional version (counter)
                          field of type java.lang.Long will be added to entity which will be
                          used for optimistic locking. Each update of the entity will increase
                          the value of its version field by 1.

                          <optimistic-locking>
                          <version-column/>
                          <field-name>versionField</field-name>
                          <column-name>ol_version</column-name>
                          <jdbc-type>INTEGER</jdbc-type>
                          <sql-type>INTEGER(5)</sql-type>
                          </optimistic-locking>

                          5. Timestamp column strategy. Additional timestamp column field of
                          type java.util.Date will be added to entity which will be used for
                          optimistic locking. Each update of the entity will set the value of
                          its timestamp field to the current time.

                          <optimistic-locking>
                          <timestamp-column/>
                          <field-name>timestampField</field-name>
                          <column-name>ol_timestamp</column-name>
                          <jdbc-type>TIMESTAMP</jdbc-type>
                          <sql-type>DATETIME</sql-type>
                          </optimistic-locking>

                          6. Version column generated by KeyGenerator. Additional field will be
                          added to entity that will be used for optimistic locking. Each update
                          of the entity will update its version column with value generated by
                          KeyGenerator.

                          <optimistic-locking>
                          <key-generator-factory>UUIDKeyGeneratorFactory</key-generator-factory>
                          <field-type>java.lang.String</field-type>
                          <field-name>uuidField</field-name>
                          <column-name>ol_uuid</column-name>
                          <jdbc-type>VARCHAR</jdbc-type>
                          <sql-type>VARCHAR(32)</sql-type>
                          </optimistic-locking>

                          ----

                          HTTP URL scanning support

                          Support has been added for scanning HTTP locations using the WebDAV
                          protocol. This allows locations to be scanned when the server has been
                          netbooted from a web server in the same manner as local directories
                          are scanned. This allows JBoss to be booted from an unmodified
                          configuration located on a WebDAV capable server such as Tomcat 4.1.X,
                          Apache 2.0 with mod_dav or even Microsoft IIS. Alternatively, a trival
                          DAV server is supplied in docs/examples/netboot that allows JBoss to
                          be booted from any J2EE WebContainer such as JBossWeb.

                          DAV scanning is supported for the SARDeployer element and
                          for the URLDeploymentScanner element. The latter requires
                          locations to be specified in accordance with RFC2518 - basically URLs
                          will be scanned if they end with a '/' character and deployed if they
                          do not. See the standard conf/jboss-service.xml for examples.

                          With this change URLDeploymentScanner is now able to provide the
                          functionality of URLDirectoryScanner and HttpURLDeploymentScanner and
                          these mbeans should no longer be used.

                          A current limitation is that locations to be scanned via HTTP/DAV must
                          not contain unpacked archives (especially SAR or WAR archives). This
                          limitation may be removed in the future.

                          Also WAR archives should contain in their lib or classes directories
                          all classes needed to compile JSP pages. Strictly, the javac compiler
                          invoked during JSP compilation uses a classpath derived from
                          ClassLoaders referencing the local filesystem; as a result
                          dependencies on classes loaded over the network may result in "cannot
                          resolve symbol" errors during JSP compilation.

                          ----

                          JBossQL Limit/Offset support

                          Support has been added for restricting the amount of data fetched from
                          a JDBC database.

                          JBossQL now supports optional OFFSET and LIMIT parameters supplied at
                          the end of a query. An example would be

                          SELECT OBJECT(o) FROM Order o WHERE o.status = ?1 ORDER BY o.orderDate
                          OFFSET ?2 LIMIT ?3

                          This works by discarding rows until rows have been fetched
                          and then returning immedately once another rows have been
                          fetched. This simple mechanism is intended to preserve portability
                          across database vendors. Other approaches including scrollable cursors
                          or database-specific syntax may be considered later.

                          Currently the parameters passed to LIMIT and OFFSET must be int values
                          (or Integer for DynamicQL) as in the finder

                          Collection findAllOrders(String status, int offset, int limit) throws
                          FinderException;

                          ----

                          JBossMQ now disconects clients with stale connections.

                          Sometimes clients disconnect from the server but the server does not
                          notice (This is especialy the case with stateless protocols like
                          RMI). Added an interceptor to the DestinationManager that keeps track
                          of when the client last accessed the server. If the client is idle for
                          too long, the client gets disconnected.

                          ----

                          Container Managed Audit Fields

                          Initial support for Container Managed Audit Fields Initially in 3.2
                          for evaluation purposes.

                          Coding this in CMP2 is a pain and requires calculating the values on
                          every set, monitoring whether the set actually changed the value.

                          In jbosscmp-jdbc.xml add

                          <created-by/>
                          <created-time/>
                          <updated-by/>
                          <updated-time/>

                          to the relevent entity.

                          Four new fields are maintained by the CMP engine
                          audit_created_by, audit_created_time,
                          audit_updated_by, audit_updated_time

                          For created_by and updated_by the caller principal must be in the
                          entity context otherwise they are blank.

                          You can choose which of the fields you want to use e.g.


                          <updated-by/>
                          <updated-time/>


                          You can change the column names as follows

                          <updated-by><column-name>change_username></updated-by>

                          The field can also be a CMP field, by matching the field-name

                          <updated-by><field-name>changedBy</field-name><updated-by>

                          When the field is set programmatically this takes precedence over the
                          container managed values.

                          TODO
                          1) Decide and support relevent jdbc-type/sql-types.
                          2) Support date and time as separate fields for legacy data mappings
                          3) Add support for CMR tables.

                          ----

                          New entity commands

                          Abstracted primary key fetching JDBCMySQLCreateCommand into
                          JDBCAbstractVendorCreateCommand and created implementations for
                          hsqldb, sybase and informix.

                          Entity commands name are :
                          o mysql-get-generated-keys
                          o hsqldb-fetch-key
                          o sybase-fetch-key
                          o informix-serial

                          -----

                          BeanShell JBoss sub-deployer added

                          A BeanShell (BSH, www.beanshell.org) sub-deployer in has been added to
                          3.2+. It is in module varia and you can find its lib in
                          varia/output/lib/bsh-deployer.sar.

                          It allows you to hot-deploy *.bsh files in /deploy.

                          SIMPLE USAGE: client-only
                          =========================

                          In its simple usage, the script will act as a simple client-script
                          making invocations on other objects. Each script can follow the
                          org.jboss.system.Service interface i.e. the create, start, stop and
                          destroy calls. You can implement only a subset of those. Thus, a very
                          simply one-line script can be: Simple.bsh:

                          void start() { System.out.println ("I'm called!"); }

                          that's it.


                          ADVANCED USAGE: server script!
                          ==============================

                          But it is almost as easy to make your script a JBoss service fully
                          invocable/administrable through JMX! For this, your script can
                          implement any of the methods of the following interface:

                          public interface ScriptService
                          extends org.jboss.system.Service
                          {
                          public String objectName ();
                          public String[] dependsOn ();
                          public Class[] getInterfaces ();

                          public void setCtx (ServiceMBeanSupport wrapper);
                          }

                          You can implement the objectName method to choose your own MBean
                          ObjectName. You can implement the dependsOn method to return a set of
                          JMX MBean ObjectName (as string) on which you depends (for service
                          lifecyle). You can implement the getInterfaces method to return the
                          set of interfaces that you *say* your script do implement. Your
                          wrapper will analyse these interfaces and fully generate the
                          associated JMX MBeanInfo (the script wrapper is a Dynamic MBean).

                          Example, let's say you have this interface:

                          public interface MyIntf
                          {
                          public void doThat();

                          public String getRWString ();
                          public void setRWString (String val);

                          public String getROString ();
                          }

                          You could then provide this script:

                          String name = "bla";

                          String objectName () { return "jboss.scripts:service=myService"; }
                          Class[] getInterfaces () { return new Class[] {MyIntf.class}; }

                          void create () { System.out.println ("Create called on me"); }

                          void doThat () { System.out.println ("doThat called"); }

                          String getRWString() { return super.name; }
                          void setRWString(String bla) { super.name = bla; }

                          String getROString() { return "I am read-only!"; }


                          Then, not only can you invoke methods and get/set attributes on your
                          script using JMX, you can also browse your scripts using the
                          http://localhost:8080/jmx-console/ and see all available
                          methods/attributes (MBeanInfo is generated by the DynamicMBean script
                          wrapper)

                          Infos on BeanShell are available here: www.beanshell.org

                          ----

                          CMP Create performance and SQLExceptionProcessing Service

                          To address bug 723908, a new <entity-command> has been added which
                          does not perform a SELECT to detect duplicate primary keys but instead
                          examines any SQLException thrown.

                          Prior to 3.2.1, CMP attempted to detect a DuplicateKey condition by
                          performing a SELECT for a row with the supplied primary key and
                          throwing DuplicateKeyException if any row existed. This required an
                          SQL operation, impacting performance, and suffered from a potential
                          race condition as no lock was taken on the PK value.

                          In 3.2.1 a new entity-command has been added that does not perform
                          this check but instead examines any SQLException thrown by the INSERT
                          to determine if a DuplicateKeyException should be thrown.

                          This eliminates the addition SQL operation, closes the race window and
                          guarantees that a DuplicateKeyException will be thrown if a suitable
                          database constraint is in place. For most databases, this will result
                          in DuplicateKeyException if any unique constraint is violated, even
                          for secondary keys.

                          As different JDBC drivers may indicate constraint violations in
                          different ways, an SQLExceptionProcessor service has been added that
                          can be used to classify an SQLException raised by the driver. The
                          supplied implementation uses the ANSI SQL99 standard SQLState code of
                          "23000" to detect constraint violations.

                          To avoid migration issues, the default configuration has not been
                          modified and exception-based detection must specifically be
                          activated. The SQLExceptionProcessor service is deployed only in the
                          "all" configuration.

                          • 11. Re: What are the differences between the JBoss 3.2.0 and 3.0
                            doc_brown

                            Tobias, yes those notes are what's on the URL.

                            However, that's not all the release notes.

                            The release notes from just 3.2.0rc4 to 3.2.0 contain many things not listed.

                            Also, now that 3.2.1 is out (with another long list of changes from 3.2.0), were can I find the changes from 3.0.6 to 3.2.0?