Hi! On Fri, Aug 14, 2009 at 07:57, Niklas Gustavsson<nik...@protocol7.com> wrote: > 2009/8/13 Michael Jakl <jakl.mich...@gmail.com>: >> On Thu, Aug 13, 2009 at 20:06, Niklas Gustavsson<nik...@protocol7.com> wrote: > Well, the whole purpose of Spring is to enable being able to configure > things like this, so I don't think there is a problem at all. Reading > a separate configuration file from within the module seems to defeat > the purpose of using Spring. So, I would say that we should allow for > modules to be configured using constructor parameters or setters > methods (as appropriate).
Thanks for the clarification. Spring is still a little mystery to me. In that case I'll introduce the appropriate constructor. > In some cases, like the MUC module, it is required to run on a > subdomain (as per the spec). In that case, I would recommend that the > module takes the subdomain as a constructor parameter and then adds a > SubdomainHandlerDictionary has the only HandlerDictionary. If a module > supports both ways (a spec which contains namespace extensions > elements in all stanzas) the subdomain constructor parameter can be > made optional. Should the user have set it, the module would register > a SubdomainHandlerDictionary. If not set, it instead registers a > NamespaceHandlerDictionary. If the module is intended to extend the > server on the main domain, it would only register > NamespaceHandlerDictionary. > > Makes sense? To enable these scenarios was the background to why the > sub domain patch was designed as it was. Yes, all doubts cleared. Thanks, Michael
