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

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

    whyau Newbie

      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
          sys user Master

          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
            Franco Apprentice

            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
              Will McCracken Newbie

              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

              • 7. Re: What are the differences between the JBoss 3.2.0 and 3.0
                Tobias Frech Apprentice

                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
                  Jon Martin Solaas Newbie

                  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
                    Jim Newbie



                    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 Frech Apprentice

                      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
                        Jim Newbie

                        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?