Hi!
"Schaefer, Andreas" wrote:
> Yeah, but I do not think to make stuff simplier by
> making them dependable is the right step.
>
> Why should the list of services also contain the order
> in which the services are started?
Because it is easier to understand now. The old way was perhaps more
feature-complete, but also more complex so more difficult to understand.
Have you looked at the new configuration files? Do you think it is hard
to understand?
> And in addition the problem is only solved during startup
> therefore we screwed up the possibilty to define a dynamic,
> dependecy aware startup and shutdown behaviour during
> runtime (or to you want the user to define this in the
> jboss.jcml and ALSO in the jboss.dependencies?).
No, I want to deprecate jboss.dependencies, and add dependency settings
in jboss.jcml. All in one place, but not necessarily used by one MBean
(some by ServiceControl and some by DependencyManager).
> BTW I do not think that just to say the DependencyManager
> (DM) does not implement all the posabilties is a reason to
> abandom it.
1) The DM was only useful during startup. Since this need was taken care
of in a simpler way with the new conf scheme, why use it?
2) The main reason to have a DM at all, as opposed to just using the
server conf. file order, was to allow runtime checking of dependencies.
The current DM doesn't use this, and it wasn't an MBean so it wasn't
even usable at runtime even if it had work.
> Rickard told me once that you should try
> to understand and use code written by someone else instead
> of create you own.
Yes, if the code works. And I *did* read through the DependencyManager
very carefully before doing this, but considering the above the decision
was not so strange I think.
> I think this was a quick and dirty solution instead of
> a well designed one
This was not a q&d solution, but the result of listening to all
complaints with the current scheme. I believe it covers all what used to
be, and took care of all the problems that was present with the old
scheme. Even you have provided quite a lot of input for the new scheme
(named attributes for example). All that was handled before is taken
care of now.
That said, there are still things to be done, runtime dependencies being
the main one. So, the dependency manager *functionality* will reappear
somehow in an MBean, but this time it will actually work at runtime too
which is the main reason to have one in the first place.
> (maybe also for Rickard it would be
> good to discuss such changes beforehand instead of just
> make it happen).
I agree, I should have discussed it more. I did post info about it
though, and no complaints were voiced, so I continued.
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
