You know I am a fool for anything that says "let's draw from Unix' ease of
administration"
the rc.d equivalents offer some power, and the dependencies need to be
added.
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Oleg Nitz
> Sent: Monday, September 04, 2000 3:15 AM
> To: jBoss Developer
> Subject: Re[2]: [jBoss-Dev] More JMX
>
>
> 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
>
>
>
>
