> This won't do any good. If all required beans are present, the order will > be > > create > configure > call before start > start > call after start > > with no opportunity for anything else to happen. Might as well put > everything in start.
I don't understand. The problem we have here is that we have to call a method on the ClusterPartition MBean after all other MBeans are started. As far as I understand the ClusterPartition's JChannel must be initialized before the other "clustering" services can be started. Therefore to wait with this will do no good. What we need is: - create all MBeans - "initialize ClusterPartition before all other clustering services - start other clustering services - connect within the ClusterPartition to fire it up As long as all the clustering services are deployed as a unit it would work fine. Whenever a clustering services is deployed outsite we are f*cked and then we must be able to add new services at runtime. THAT is the catch in JavaGroups -> Clustering. > Unfortunately Hirams suggestion of "after server is started" doesn't make > sense- you never know when the server is completely started, someone is > always about to add one more mbean. Let us say after UNIT DEPLOYMENT and we are there. > The only way the cluster stuff ever worked was there was a more or less > hidden concept of a deployment unit, with a more or less explicit order, > which could be used to hide dependencies. This only works if the explicit > dependencies are between mbeans needed for a deployment unit (the depends > tag from David Maplesden) or between deployment units themselves (my > original recursive sar deployment scheme). For everything I've tried so > far, the mbean-ref method is simpler, clearer, and reduces the need for > fake and implicit dependencies than either of the other two methods, or the > "ordering in deployment unit" method. For instance, in the > ConnectionFactoryLoader, there was a really fake dependency on the > RARDeployer, the only use of which was to help the RARDeployer notify the > ConnectionFactoryLoaders when it deployed a rar. By making the > RARDeployment mbean, and having the ConnectionFactoryLoader refer to it, > the extraneous reference is no longer needed, and the actual dependence is > clearly exposed. The best way is to resolve the dependencies to make it dynamic like the other services but these seems to be a problem with JavaGroups and you know how long it can take to fix such a bug. > I think there must be a hidden ordering dependency in the cluster file. > The Cluster has to apperar before any of the services it manages, right?, > so it can be called from the init. > > Why not make this dependency explicit? I don't think it is a "single" depencies. First the JChannel must be initialized, then all the clustering services must be started and finally ClusterPartition must connect. See ya - Andy _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
