Change Notes item #480527, was opened at 2001-11-10 21:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=480527&group_id=22866
Category: None Group: v3.0 (Rabbit Hole) Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: New mbean dependency mech: mq changes Initial Comment: I've rewritten the mbean dependency support in jboss 3 to rely on direct mbean - mbean dependencies instead of the depends tag in *-service.xml files: this tag has been eliminated. There are two new elements inside mbean in *service.xml files: <mbean-ref name="(property name)">(object name)</mbean-ref> and <mbean-ref-list name="(property name)"> <mbean-ref-list-element>(object name)</mbean-ref-list-element> ...(repeated) </mbean-ref-list> It is expected that the mbean has an ObjectName - valued property (mbean-ref) or Collection valued property (mbean-ref-list): on configuration these properties are set to the supplied ObjectName. The mbean is started only when all the referred-to mbeans have been started, and is stopped whenever one of the referred-to mbeans is stopped. ConnectionFactoryLoaders have been modified to take advantage of this system. A RarDeployment mbean has been introduced to display the properties of the deployed rar and to be depended on. A ConnectionFactoryLoader has an mbean-ref to the rar it uses: therefore it will be started only when the rar has been successfully deployed., and stopped when the rar is undeployed. This replaces the artificial dependence on the RARDeployer and the mbean notifications from RARDeployer to ConnectionFactoryLoader. A possible future enhancement would be to allow "property-less" dependencies of the form <mbean-ref>(object name)</mbean-ref> This would be useful for example to make DefaultDS depend on hsqldb starting. There is no natural mbean reference here, but there is a functional dependency. Another effect of this change is that the init and start, and stop and destroy, lifecycle events are now executed together for each mbean. Therefore there is no reason to keep 4, start and stop will be sufficient. Some progress has been made to combine these methods. In the future, ServiceMBean should only support start and stop. As a result of condensation of lifecylce methods, modifications to jbossmq were necessary for proper initialization of queues and topics on restart. This required refactoring and rearranging the PersistenceManager startup sequence, the StateManager startup sequence, and the JMSQueue and JMSTopic startup sequence. Mbean dependencies were introduced in many places to make dependencies explicit. However, there is still use of static JMSServer.getInstance() methods from IL code: this makes running and testing several PersistenceManagers simultaneously impractical. The Logging PersistenceManager was removed as it appears to be obsolete. In the course of this work it appeared that the UIL code does not (before or after the changes) pass the test suite, and that the JDBC PersistenceManager does NOT implement recovery from failure within a transaction, and does not pass most of the test suite. It was possible to modify the test suite to test all IL's (except in-vm), however due to the static methods on JMSServer it is considerably more difficult to test all PersistenceManagers. The JDBC PersistenceManager was modified to work by default with Hypersonic (or other databases supporting java_object rather than blob). There is a flag to set to return it to using blobs. It also creates the tables it needs if they are not present. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=381174&aid=480527&group_id=22866 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
