Hi!
Oleg Nitz wrote:
> R�> Oleg Nitz wrote:
> >> 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.
>
> R�> I think the more flexible relationship system can be made to imitate
> R�> this quite easily. Just add dummy MBeans called "Level1-5" and add
> R�> dependencies to these. If we implement this system with the relationship
> R�> system I have no problem with it, since it would be easily replacable if
> R�> one needed more oomph in the relations.
> Sure, the best solution should be both easy to use and flexible, and I
> was thinking about the synthesis of the relationship approach and the
> level approach, too.
> Firstly, the level approach would place new DataSource or new
> TransactionManager to the correct place in the startup sequence
> automatically, you won't need to edit the dependent list manually in
> order to to make it dependent on one of the dummy MBeans.
> Secondly, it guarantees that due to a mistake you will never try to
> start AutoDeployer before a TransactionManager started.
> I mean that it states some general rules.
> Thus, I think that the synthetic approach could be as the following.
> The levels should be the primarily rule for building the startup
> sequence, the relationship list should be the secondary.
> We need a way to determine the level for each MBean, e.g. in some
> configuration file may be listed on proper levels all base MBean
> interfaces/classes like org.jboss.util.ServiceMBean, and the level for
> the MBean is defined by the closest match; if the MBean doesn't
> implement/extend any of interfaces/classes in the list, it should be
> attached to the highest level.
> The relations should define the start/stop sequence inside the level,
> and also define failure and upgrade processing.
Actually, there *is* a trivial way to do this today. The /bin/run.jar
actually takes arguments, but the default is jboss.conf :-) So, change
run.bat to include the following execution arguments "jboss1.conf",
"jboss2.conf", etc. This will make them be read and loaded in order. If
we change the bootstrap (org.jboss.Main) to call "start" between each
load of conf file, then it will work in a crude way. When we get a
proper relationship system we can easily replace this with the
equivalent in the relationship engine.
> Also I see more homogeneous solution (I guess you'd like it more):
> to allow to put the generic rules to the relationship list. Then the
> list of relationships for the given MBean is a union of all
> relationships for all superclasses/superinterfaces.
That could be possible, yes.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
