Let me come out with a simple proposition, that may be simplistic or
even stupid.
In brief, I propose to use Unix/Linux startup pattern.
Let's assign to each of MBean classes some level, e.g.:
Level 1: ClassPathExtension
Level 2: Logging
Level 3: JDBC, Webserver, NamingService
Level 4: DataSource, TransactionManagerService, SecurityManager
Level 5: AutoDeployer, Configurator, ContainerFactory
jBoss should hold its current level.
Startup is a task "init 5", shutdown is a task "init 0"
Inside one level MBeans start either in arbitrary order, or in order
of appearance of jboss.conf.
If you want to change the TransactionManager, you execute commands
init 4
init 5
by means of some admin.jar or init.jar
Of course, this approach is less flexible and accurate than the list
of relations, yet it is easier and gives the possibility to upgrade
parts of the server at runtime, at least without full restart.
Best regards,
Oleg
Aaron Mulder wrote:
AM> On Sun, 3 Sep 2000, Rickard [iso-8859-1] �berg wrote:
>> Not necessarily. We could do this for one datasource as well to make it
>> easier to use. But the sad truth is that, yes, these relationships would
>> have to be maintained somehow. Flexible doesn't always mean simple.
>> ...
>> Yes, which is why this is something that we would do once and for all.
>> The server will be pre-loaded with all the right relationships for the
>> default modules. If you want to add stuff, you're on your own. Of
>> course.
AM> Well, I submit that nearly every user is going to set up one or
AM> more data sources. So there is no "once and for all" for the list of
AM> MBeans, and we don't want to put every user "on their own". Not very
AM> friendly.
AM> Perhaps this could be avoided if we list each configured MBean
AM> type (not instance) in our relationships file, and allow for the case that
AM> an MBean is present on the relationships file but not the real
AM> configuration file. So for example, AutoDeployer could list
AM> DataSourceImpl, JDBCDataSourceLoader, and XADataSourceLoader as
AM> prerequisites. If any of those were present, they would be loaded before
AM> AutoDeployer, but if one or more of them were not present, they would
AM> simply be ignored and the AutoDeployer would be loaded anyway. In any
AM> case, all beans of the same type would be treated together for
AM> relationship purposes, so you couldn't distinguish between DataSourceImpl
AM> A and DataSourceImpl B.
AM> As for the service reloading, I'm not sure how you plan to do
AM> this. Let's say I unload a ClassPathExtension ("CPE"), upon which every
AM> service depends (since we want the CPEs to be loaded *first*). Now all
AM> services are unloaded. I change the directory/JAR for the
AM> ClassPathExtension, and then reload it. Now what gets reloaded? At least
AM> one of you seemed to consider it simplistic to assume that the contents of
AM> the conf file were accurate once the server is running (who knows what was
AM> started or stopped in the mean time?). So what do you reload? Or do you
AM> have to reload everything manually? You don't want to just reload from
AM> the file anyway, since it clearly had a bad CPE entry, and if you reread
AM> the file (loaded everything again) and then unloaded the bad CPE entry
AM> again it would re-unload all the services. Aargh!
AM> Aaron
