User: vlada
Date: 01/06/24 22:14:14
Added: . changelog_2_4_beta.jsp
Log:
change log for 2.4 beta
Revision Changes Path
1.1 newsite/changelog_2_4_beta.jsp
Index: changelog_2_4_beta.jsp
===================================================================
<jsp:include page="head.jsp" flush="true" />
<jsp:include page="slogan.jsp" flush="true" >
<jsp:param name="SLOGAN" value="RELEASE NOTES AND CHANGE LOG"/>
</jsp:include>
<!-- CONTENT -->
<p class="head">JBOSS 2.4 BETA RELEASE</p>
<p class="head">415088 Display LinkRef targets in JNDIView </p>
<p class="text">
Added support for displaying the node that LinkRef
JNDI nodes point to. This allows one to see what
elements like ejb-refs, resource-refs, etc. in the
ENC point to.
</p>
<p class="head">415379 Patch #415337: Informix jaws.xml</p>
<p class="text">
See
http://sourceforge.net/tracker/index.php?func=detail&aid=415337&group_id=22866&atid=376687
</p>
<p class="head">415982 ConfigurationService & ServiceControl</p>
<p class="text">
ConfigurationService & ServiceControl
The following changes have been made to the JBoss
ConfigurationService & ServiceControl mbeans:
1. The org.jboss.util.ServiceControl mbean service no
longer listens for
mbean registration events as the means for selecting
mbeans which will
receive the init/start/stop/destroy lifecycle method
invocations. Mbeans
wishing this service must register the
org.jboss.util.Service interface though
which they wish to be notified using the
ServiceControl.register(Service)
method.
2. The org.jboss.configuration.ConfigurationService
mbean now registers all
mbeans loaded from the jboss.jcml configuration file
with the ServiceControl mbean.
There is no requirement that an mbean implements the
org.jboss.util.Service interface.
The Service interface used to register the jboss.jcml
mbean with the
ServiceControl mbean is obtained either from the
implementation of the new
org.jboss.util.ServiceFactory interface specificed
via
the new serviceFactory
jboss.jcml mbean tag attribute, or by a dynamic proxy
that determines
which if any of the init/start/stop/destroy methods
the mbean implements using
introspection of the mbean operations. The latter is
used in the absence of
a non-empty serviceFactory attribute.
3. Another behavior change made to the
ConfigurationService is that it no longer reads
the jboss-auto.jcml config file. This is now a write
only file that does reflect
configuration changes made at runtime, but it is no
longer read on startup.
</p>
<p class="head">416083 Patch #415652: Jaws Mapping for SQL2000 </p>
<p class="text">
See
http://sourceforge.net/tracker/?func=detail&atid=376687&aid=415652&group_id=22866
</p>
<p class="head">416227 Resource adapters can be auto-deployed</p>
<p class="text">
Resource adapters can be auto-deployed
It is possible to configure the AutoDeployer service
to
use the RARDeployer service from the JBossCX module
to
deploy resource adapters.
An example of this is included in jboss.jcml. This
example sets up the directory deploy/lib to be
watched
for resource adapters. The bundled Minerva JDBC
resource adapters are installed in this directory and
are thus available at server startup.
</p>
<p class="head">416846 OpenJMS support migrated to contrib</p>
<p class="text">
Support for OpenJMS as a JMS provider inside of JBoss
has moved to an external contrib module:
contrib/openjms
The support classes have been repackaged into a
single
package in the contrib module, so users will need to
update there configurations with the new package
names:
org.jboss.jms.openjms.OpenJMSProvider
org.jboss.jms.openjms.OpenJMSServerSessionPoolFactory
</p>
<p class="head">416922 Don't use CLASSPATH in run.bat/run.sh</p>
<p class="text">
Don't use CLASSPATH in run.bat/run.sh
Removed the use of the system CLASSPATH variable as
this results in too many conflicts in general.
Changed
CLASSPATH to JBOSS_CLASSPATH to make it clear that
the
CLASSPATH variable is not used. If you are relying on
the system CLASSPATH to include required jars you
either need to edit run.bat/run.sh to include
CLASSPATH or setup a JBOSS_CLASSPATH variable with
the
required jars.
</p>
<p class="head">416928 Removed res-jndi-name java:/ prefix need</p>
<p class="text">
Fixed bug #414854.
The requirement that the res-jndi-name be prefixed
with java: has been removed from the
ApplicationMetaData class.
This change requires that a jboss.xml descriptor
like:
<pre>
<jboss>
<enterprise-beans>
<session>
<ejb-name>ENCBean</ejb-name>
<resource-ref>
<resource-name>DefaultDS</resource-name>
<res-ref-name>jdbc/DefaultDS</res-ref-name>
</resource-ref>
</session>
</enterprise-beans>
<resource-managers>
<resource-manager res-class="">
<res-name>DefaultDS</res-name>
<res-jndi-name>DefaultDS</res-jndi-name>
</resource-manager>
</resource-managers>
</jboss>
would now require a resource-managers element like:
<resource-managers>
<resource-manager res-class="">
<res-name>DefaultDS</res-name>
<res-jndi-name>java:/DefaultDS</res-jndi-name>
</resource-manager>
</resource-managers>
<pre>
where the res-jndi-name element value now must
explicitly include the java:/ value that was assumed.
</p>
<p class="head">417532 Config service and MBean constructors</p>
<p class="text">
Config service and MBean constructors
The configuration service has been augmented to allow
the specification of the constructor to use when
creating a new instance of the MBean.
To specify which constructor to use, a
<constructor>
element with nested <arg> elements is placed
inside of
a <mbean> element (in the jboss.jcml file).
The <arg> elements attempt to follow the syntax
used
for <mlet> elements (in the jboss.conf file).
Only one <constructor> element is allowed per
<mbean>.
If more than one is found, then an exception will be
thrown.
Example:
<pre>
<mbean code="MyMBean" name="name=myMBean">
<constructor>
<arg type="java.lang.String" value="hello"/>
<arg type="java.lang.String" value="there"/>
</constructor>
</mbean>
</pre>
This will cause the MyMBean(String,
String)constructor
to be used when creating the bean instance.
</p>
<p class="head">417769 Stateful session bean timeout</p>
<p class="text">
Added a configurable timeout for stateful session
beans in (standard)jboss.xml. When their life exceed
the timeout, a periodic task removes them from the
cache (if present) and from the storage where they
have been passivated (if present).
</p>
<p class="head">417793 PATCH: Using log names for log4j categories.</p>
<p class="text">
The current Log4jService mbean, while it does allow
logging to take place through log4j, does not appear
to
allow use of one of its big features-- categories
that
can be turned on and off independently. This patch
partially fixes this by using the log name as a
category name. This is not the full power of the
hierarchy of categories supported by log4j, but it is
way better than nothing.
This patch consists of a few lines of code to use the
log name as the category, rather than always using
the
root category, and a (commented out) example line in
log4j.properties showing a simple use of this
feature.
</p>
<p class="head">418054 JBossAdmin: Monitoring client</p>
<p class="text">
Monitor client added from the admin module to JBoss
distro.
Provides basic monitoring of invocation times and
cache usage.
</p>
<p class="head">418685 Made log4j the default logging framework</p>
<p class="text">
Made log4j the default logging framework
The org.apache.log4j framework is now the default
logging framework. The jboss.conf come configured
with
the Log4jService mbean setup to initialize the log4j
framework using the logj4.properties file found in
the
JBoss config directory. The Log4jService continues to
bridge messages logged via the legacy
The org.jboss.logging.Log and Logger classes have
been
decprecated. Existing JBoss services derived from the
org.jboss.util.ServiceMBeanSupport class that use the
log instance var are really logging through a log4j
Category. A log4j Category object instance var has
been added to the ServiceMBeanSupport to allow
services easy access to the log4j Category object.
This Category instance is derived from the service
getName() method value.
</p>
<p class="head">418934 ConfigurationService & attr auto-trim</p>
<p class="text">
ConfigurationService will now auto-trim attribute
values by default. To disable this behavior, modify
the <mlet> configuration in jboss.conf:
<pre>
<MLET CODE =
"org.jboss.configuration.ConfigurationService"
ARCHIVE="jboss.jar,../xml.jar"
CODEBASE="../../lib/ext/">
<ARG TYPE="boolean" VALUE="false">
</MLET>
</pre>
</p>
<p class="head">419301 JMS Connector resource adapter</p>
<p class="text">
A JMS Connector resource adapter has been added to
the
JBoss
main trunk, under the package org.jboss.jms.ra.
A new JMSProviderAdapter has also been added to
support
JMS ra with local transactions: JBossLocalTXProvider.
The adapter is installed into dist/deploy/lib and an
entry for a TX version have been added to jboss.jcml.
I
have left configuration for a LocalTransaction out of
the default configuration, which will insted be
documented in the JBoss docu.
It is (probably) possible to get the ra to work also
in
JBoss 2.2.1, but it will not be added to that trunc
in
the CVS.
The connector makes it possible to use JMS in beans
as
is specifyed in J2EE 1.3, namely as a truly
transacted
resource.
It also makes it possible to deploy the Publisher
example for the SUN JMS tutorial, with a jboss.xml
file
like this:
<pre>
<?xml version="1.0" encoding="Cp1252"?>
<jboss>
<secure>false</secure>
<resource-managers>
<resource-manager>
<res-name>topicfactoryref</res-name>
<res-jndi-name>java:/JmsXA</res-jndi-name>
</resource-manager>
<resource-manager>
<res-name>topicref</res-name>
<res-jndi-name>topic/testTopic</res-jndi-name>
</resource-manager>
</resource-managers>
<enterprise-beans>
<session>
<ejb-name>Publisher</ejb-name>
<jndi-name>publisher</jndi-name>
<configuration-name>Standard Stateless
SessionBean</configuration-name>
<resource-ref>
<res-ref-name>jms/MyTopicConnectionFactory</res-ref-name>
<resource-name>topicfactoryref</resource-name>
</resource-ref>
<resource-ref>
<res-ref-name>jms/TopicName</res-ref-name>
<resource-name>topicref</resource-name>
</resource-ref>
</session>
</enterprise-beans>
</jboss>
</pre>
</p>
<p class="head">419927 Client UserTransaction support</p>
<p class="text">
Added UserTransaction support for stand-alone clients.
This implementation is suitable for thin clients, as
it
offloads all transaction handling to the server,
using
RMI communication.
It is completely independent of the underlying JTA
implementation used.
This is a very special use of transaction context
propagation: Nothing in the client will run under
transactions started by the client UserTransaction,
but
everything at the server will.
</p>
<p class="head">420628 Handles "remember" their container.</p>
<p class="text">
The JRMP proxy and handle implementation has been
updated to "remember" which container they came from.
This allows clients to pass handles to VMs that do
not
have an explicit configuration for the initial
context
factory and provider url (as well as other
environment
properties) from which the bean originated.
This should provide a better migration path from
other
EJB containers which provide this behavior.
The issuing container reads the environment
properties
which are required to construct a new InitialContext
object from a properties files specified by the
system
property:
org.jboss.ejb.plugins.jrmp.interfaces.InitialContextHandle.environment
The value of this property is currently assumed to be
a
URL or omitted to disable the feature.
The default value for this property is currently
being
set to:
file:../conf/default/handle-jndi.properties
Which contains properties suitable for connecting to
the default JNDI server configured to start with
JBoss.
If the port number which the Naming service is
changed
from the default, then this file should be updated to
reflect the new value.
If this property is omitted, then the old behavior
will
be used, which simply constructed a new
InitialContext
with no environment properties. This will assume that
they are suitable system properties set to setup the
context.
</p>
<p class="head">422062 Allow setting of rmiPort in jnp.props</p>
<p class="text">
The rmi port of the jnp naming provider can now be
set via the jnp.properties file rmiPort property.
Note that this could be set, and is overriden by
the NamingService rmiPort attribute in the jboss.jcml
file. The jnp.properties file provides the default
values for the port and rmiPort settings. Both the
port and rmiPort are override by setting the
corresponding attributes of the NamingService in
the jboss.jcml file.
</p>
<p class="head">422219 Xid class override now in jboss.jcml</p>
<p class="text">
The system property jboss.xa.xidclass is now no longer
used. Instead, use the XidClassName attribute of the
TransactionManagerService MBean in jboss.jcml.
</p>
<p class="head">423668 JBossMQ Fix: pass txId to log remove()</p>
<p class="text">
The txId (transaction id) was not passed to the remove
method of the log class. Therefore when logs were
read during startup, all messages were removed even
if
they were part of a rolled-back transaction.
</p>
<p class="head">423669 JBossMQ: fix for multiple subscribers</p>
<p class="text">
The destinationSubscriptions map was cloned and the
new subscription was added to the old map rather than
the cloned one.
</p>
<p class="head">423671 JBossMQ: pass selector to receiveMessage</p>
<p class="text">
This fixes a bug where selectors didn't work on
receiveNoWait method calls.
</p>
<p class="head">423673 JBossMQ fix setDeliveryMode & others.</p>
<p class="text">
Remove extraneous code that wrongly set delivery mode
to non-persistent when persistent mode was explictly
set.
</p>
<p class="head">423674 JBossMQ Synchronize lastMessageID update</p>
<p class="text">
Synchronize update of the lastMessageId.
When new messages are created from multiple threads
with the same connection the possiblity exists that
they can have the same jmsMessageID!
</p>
<p class="head">423678 JBossMQ Transaction synchronization</p>
<p class="text">
Synchronize transactions map and startTx method.
Multiple transactions could be assigned the same ID,
and the transaction map could be modified my multiple
threads simultaneosly.
</p>
<p class="head">424178 JBossMQ abstract out persistence layer.</p>
<p class="text">
Abstract out the old persistence layer so user's can
create their own persistence packages.
Add a new persistence package for file-based
persistence. i.e. each message is persisted in a
single file. Along with a log of uncommited
transactions for system restart rollback.
</p>
<p class="head">424377 Minerva forked; now JBossPool</p>
<p class="text">
It has been decided that we need to move the
maintenance of the pooling functionality provided by
Minerva back into the JBoss CVS repository.
So, now we have JBossPool, which is the latest
version
of Minerva that I had, with the package names changed
a
bit.
Your jboss.jcmls will need to be updated to refer to
org.jboss.pool classes instead of
org.opentools.minerva
classes.
Hopefully this won't cause too much grief.
</p>
<p class="head">425017 JBossMQ: Exceptions & Syncronization</p>
<p class="text">
Throw the correct JMS1.0.2 exceptions in the
appropriate places and fixed a few synchronization
issues.
</p>
<p class="head">426034 EJB/WAR deployment ordering changed</p>
<p class="text">
The deployment order of ejb jars and wars has been
changed so that wars are deployed before ejbs. This
allows servlets that are loaded on startup to access
ejbs from within their init method. Likewise, wars
are
now undeployed before ejbs so that servlets can
access
ejbs from within their destroy method. See bug item
#421956 for additional details.
</p>
<p class="head">431864 Scheduler Service</p>
<p class="text">
Creation of a Scheduler Service allowing the client to
specify a schedule with then calls the client's
schedulable Task class.
The scheduler service should work from "jboss.jcml",
any JMX Adaptors or by using the MBeanServer or a
Connector to create the instance.
Attributes and Operations:
- Schedulable: schedulable Task which could be either
created on the fly or refer to another MBean.
- Initial Start Date: when the first scheduled call
is
made.
- Schedule Period: the time between to scheduled
calls
- Repetitions: number of scheduled calls (also
unlimited)
- startSchedule(): start the schedule if not started
yet.
- stopSchedule(): stops the schedule if started
- restartSchedule(): stop and start the Schedule
- isStart(): true if started
- isUpdatePending(): true if attributes have changed
but schedule is not restarted
</p>
<p class="head">432903 CMP finder optimization</p>
<p class="text">
Finders returning collections of entities are now
optimizable in JAWS. This feature is activated by an
optional <read-ahead> tag in the finder's
configuration
in jaws.xml.
Ref: Feature Request 421688
</p>
<p class="head">433104 Bugfix #433081:Selector on CorrelationID</p>
<p class="text">
JMS selectors didn't work correctly for
JMSCorrelationID headers.
</p>
<p class="head">433273 Support for validation of ejb dtds added</p>
<p class="text">
Support for the validation of ejb-jar.dtd, and
jboss.dtd conforming deployment descriptors has
been added to the XmlFileReader. It is disabled by
default. To enable the printing of dtd errors set
the ValidateDTDs attribute of the ContainerFactory
service mbean to true in the jboss.jcml file:
<pre>
<mbean code="org.jboss.ejb.ContainerFactory"
name=":service=ContainerFactory">
<attribute
name="VerifyDeployments">true</attribute>
<attribute
name="ValidateDTDs">true</attribute>
<attribute
name="MetricsEnabled">false</attribute>
<attribute
name="VerifierVerbose">true</attribute>
<attribute
name="BeanCacheJMSMonitoringEnabled">false</attribute>
</mbean>
</pre>
</p>
<p class="head">433314 fixed bug 433115. storeEntities on find</p>
<p class="text">
When an finder method is called, JBoss will call
ejbStore(storeEntity) on all entities of the finder's
type that are in the same transaction as the finder.
*NOTE* Unnessary DB updates will result if your beans
do not implement isModified, or you have JAWS tuned-
updates turned off.
Further info:
The EJB spec 2.0 reads.... 9.6.4
"Before invoking the ejbFind<METHOD>(...)
method, the
container must first synchronize the state of any
entity bean instances that are participating in the
same transaction context as is used to execute the
ejbFind< METHOD>(...) by invoking the
ejbStore() method
on those entity bean instances."
</p>
<p class="head"> 435348 fix bug when PK field != column name</p>
<p class="text">
fix bug when PK field != column name
Fixed a bug where the PK constraint was generated
incorrectly when a PK field was mapped to a column of
a
different name.
</p>
<p class="head"> 435361 Security Changes</p>
<p class="text">
Added support for the EJB2.0 ejb-jar/assembly-
descriptor/method-permission/unchecked
element that allows a method to be declared as
accessible by all.
Added support for the EJB2.0 ejb-jar/assembly-
descriptor/exclude-list
element that allows a method to be declared as
accessible to no one.
Added an unauthenticated-principal element to allow
for the specification of
the principal that should be returned by the
EJBContext.getCallerPrincipal() method.
This principal has no assigned roles.
Added support for a jboss/container-
configurations/container-configuration/security-domain
element that allows for the security manager name.
This should be used in place of
the role-mapping-manager and authentication-module
elements. You can no longer supply
independent role mapping and authentication
functions.
The custom security proxy interceptor has been broken
out into a SecurityProxyInterceptor
that is only added to a container if the
configuration
has requested a custom security
proxy. The interceptor is inserted before the
container interceptor so that the
EJBContext and bean instance are available to the
custom security proxy.
</p>
<jsp:include page="navigation.jsp" flush="true" />
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
