-
1. Re: What are the differences between the JBoss 3.2.0 and 3.0
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
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
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
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
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
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
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
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?
