Hello David,

> > oh yes! This problem really involves all management parts i.e. how we
> > want
> > to be able to store the config, modify the config, have config
> > repositories,
> > etc. Furthermore, we need to take in account in this new design the
> > really-missing-"restart"-feature which is not equivalent to the
> > stop-start
> > semantic.
>
> Why not?

because otherwise, when you are in the stop state, you don't know if it is a
definitive stop (in which case you shouln't block the valve for example) or
a temporary stop (in which case you may want to give a way to a
service/application to provide some temporary state that the service
controller can give it back once the service is restarted for example)


> > We must really implement the restart trick for 4.0 as it is one of the
> > only
> > way to cleanly implement the "valve" trick (block the valve for new
> > invocations as we cycle the app/service).
>
> I was planning to move the dependency logic from ServiceController to
> ServiceContext and make ServiceContext an mbean interceptor.  It would
> also block calls when state was not started.   If you change a set of
> attributes, it would consult the metadata to see what lifecycle state
> it must downgrade to, go to it, and go back to "started".  Do you see
> something wrong with this plan?

Well, then you cannot update the list of the JMX interceptors as you cycle
your service, right? Otherwise, how do you cycle the "ServiceContext"
interceptor? At one point, independently of where do you manage that, I am
pretty sure that you need a part of the system that thinks "I do think in a
specific way because it is a restart and not a definitive stop". You don't
think so?

Cheers,



sachay



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to