Aaron Mulder wrote:
> I don't know - this is asking an awful lot of a user. Now if I
> want to add two datasources, I have to also add an aggregate datasource,
> and also tell AutoDeployer and Configurator and who knows what else what
> to listen for it?
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.
> Plus I need to know to tell the data source to listen
> for the transaction manager, the classpath extensions, the logger, etc.?
> This may be "trivial" to do, but knowing exactly what to do and getting it
> all right will be a total PITA.
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.
> That's going to far. Why don't we just load everything in the
> order it's listed in the file?
Because we don't have the order. Once the MBeans have been created the
order is random, plus we don't have the MBean names from the conf file
(needed to invoke "start"!). This has been the basic problem from the
beginning, and the thing is that *if* the MBeanServer had preserved the
order it would be false safety, since loading more conf files at runtime
and unloading MBeans and whatnot would make the order in the file
completely unimportant.
> That would require no extra code or
> configurations, and it's an easy rule.
Simplistic, not simple, I'm afraid.
> It makes shutting down a service a
> little more heavy (shutdown everything after it too, or require the user
> to manually shut down dependent services), but I have to believe we'll add
> a lot more value in having a simple configuration process than in having a
> hugely flexible service shutdown process (when was the last time you
> wanted to shut down 1 ClassPathExtension and nothing else?).
I'm afraid you don't see how important such a relationship service would
be. For example, in the future one will be able to upgrade parts of the
server at runtime, and without knowing what other parts depend on it,
mayhem would reign. Sorry, we need this kind of flexibility, at least if
jBoss is to grow beyond "a nice little thingy".
> And it would
> make it a lot easier to handle services like auto-deployer and
> configurator that really want to be "last".
I *do* think we should have some simple way to define relationships, but
what you propose is not enough.
If the relationship service could read a textfile with something like:
Logger->Server
ConsoleLogging->Logger
FileLogging->Logger
Logging->ConsoleLogging,FileLogging
...
etc.
I hope syntax and semantics is fairly clear.
That would make it reasonably simple to set up new relationships.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
