On Tue, 22 Jun 2010, Rainer Gerhards wrote: > On Tue, 2010-06-22 at 14:11 +0200, Rainer Gerhards wrote: >> I have a bit of a problem with the dynamic nature of rsyslog. As you know, >> almost everything is loaded, so from the rsyslog core's PoV there is little >> known in advance. However, the core has some "base objects", like inputs and >> actions. There is common code for these and there are common properties. >> Actually, rsyslog employs objects in an OO-type of manner, where e.g. input >> is the super class of each of input modules, which "inherit" from it. >> >> The <input type="imtcp"> thing was designed with that class structure on my >> mind. So I had a clear indication that this is an input and so I know where >> to look up. >> >> If I now get <imtcp ...> I don't know immediately what I am dealing with. >> Granted, I probably just need to adopt the way I look at it. Probably I need >> to craft a facility where modules can register XML entity names and tell the >> core what type of entity it is. Maybe I need some time to adapting to that. >> >> Anyhow, and as you seem to be online right now, don't you think there is a >> problem with that method. Especially when thinking about rsyslog's dynamic >> nature? > > I think I just identified one myself. Let's assume that plugins can > register xml entities. But that means that the xml parser can only be > called after all plugins are loaded (because the plugins need to be > loaded first). So I think the actual plugin load process could NOT be > specified inside the main rsyslog.conf. Am I right here?
it depsnds on the parser that you use. if you use a parser that parses everything and gives you back a resulting data structure in one lump then you are right but there are also incremental parsers that have callbacks as they hit each tag, those callbacks can do anything, including loading modules, defining new allowed tags, etc. as XML files get bigger, people have moved to the incremental versions so that they don't have to handle the entire file at once before doing anything. > On the other hand, it may not be a bad solution to have two config > files, one for plugins to be loaded and one for the actual config. That > would probably substantially reduce the complexity of a config-reload > HUP (under the assumption that changes to plugins require a full > restart). that's a good point, although I'm not sure that it will work in all cases. changing modules requires a full restart but what about changing what port you are listening on? (especially if you are dropping privilates for security reasons) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
