User: starksm
Date: 01/06/25 08:44:07
Modified: . changelog_2_4_beta.jsp
Log:
Fix the unclosed pre tag
Revision Changes Path
1.2 +386 -381 newsite/changelog_2_4_beta.jsp
Index: changelog_2_4_beta.jsp
===================================================================
RCS file: /cvsroot/jboss/newsite/changelog_2_4_beta.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- changelog_2_4_beta.jsp 2001/06/25 05:14:14 1.1
+++ changelog_2_4_beta.jsp 2001/06/25 15:44:07 1.2
@@ -29,47 +29,50 @@
<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.
+ ConfigurationService & ServiceControl
+ The following changes have been made to the JBoss
+ ConfigurationService & ServiceControl mbeans:
+<ol>
+ <li> 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.
+ </li>
+<li>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.
+</li>
+<li> 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.
+ </li>
+ </ol>
</p>
@@ -140,70 +143,69 @@
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>
+<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>
+</pre>
<pre>
+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.
+ 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.
+ 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:
-
+ 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>
+ <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.
+ 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>
@@ -218,19 +220,19 @@
<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.
+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>
@@ -243,170 +245,168 @@
<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.
+ 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
+<p class="text">
+
+ 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:
+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>
+ <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:
+ 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"?>
+ <?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>
+ <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.
+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.
+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.
+
+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>
@@ -414,15 +414,15 @@
<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.
+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>
@@ -471,53 +471,52 @@
<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!
+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.
+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.
+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.
+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.
+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.
+Hopefully this won't cause too much grief.
</p>
@@ -533,59 +532,68 @@
<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.
+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
+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:
+ <ul>
+<li>Schedulable: schedulable Task which could be either
+ created on the fly or refer to another MBean.
+ </li>
+ <li>Initial Start Date: when the first scheduled call is
+ made.
+ </li>
+ <li>Schedule Period: the time between to scheduled calls
+ </li>
+ <li>Repetitions: number of scheduled calls (also
+ unlimited)
+ </li>
+<li>startSchedule(): start the schedule if not started
+ yet.
+ </li>
+ <li>stopSchedule(): stops the schedule if started
+ </li>
+ <li>restartSchedule(): stop and start the Schedule
+ </li>
+<li>isStart(): true if started
+</li>
+ <li>isUpdatePending(): true if attributes have changed
+ but schedule is not restarted
+ </li>
+ </ul>
</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
+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.
+JMS selectors didn't work correctly for JMSCorrelationID headers.
</p>
@@ -599,88 +607,85 @@
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>
+ <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."
+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.
+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.
+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.
+<p class="text">
+ 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.
+<p class="text">
+ 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.
+<p class="text">
+ 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.
+<p class="text">
+ 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
