Howdy, I definitely meant the -1 in an opinion way, there's no vote ;) And I don't mean it to discourage your, or any other, discussion topics.
You described your scenario and desired functionality. I think this functionality is possible to implement, so I was thinking ahead: what if we had this sort of functionality already in log4j?. And I think that would cause more confusion than it's worth, hence my original comment. I also agree with Ceki that this type of functionality would probably require modifications to log4j code. Alternatively, you could write a little utility class that initializes log4j after having looked at the possible configuration sources and composing what it found there. There are tools to represent configurations and their sources, and composite them somewhat intelligently. I've contributed some relevant code to the commons-configuration project (still in the sandbox, although I have a partial commons-proper promotion proposal in thr works) which you may find useful. For the person who said they have to specify a system property to initialize log4j: that's just not true ;) There are several others ways to do it, all outlined in the documentation. I agree that a system property is not always available, e.g. on someone else's server. There was also a suggestion to write more powerful configurators: while this is possible, I would also point out that log4j can configure itself from a URL. This should be sufficient for nearly every need, as the URL can indicates a JNDI resource, a file resource, a remote http/https resource, etc. I personally use all of the above URL schemes to configure log4j in various production systems. So in conclusion: I don't think I misunderstood your request ;) As I said above, the -1 is just an opinion. The XML inclusions Ceki suggested are one way forward from here. Another one would be to write a utility class that composites several log4j configuration files, use it in your organization, and eventually contribute it to the log4j sandbox for everyone else to try? Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Mark R. Diggory [mailto:[EMAIL PROTECTED] >Sent: Saturday, March 29, 2003 1:05 PM >To: Log4J Users List >Subject: Re: Inherited Logger Config? > >IMHO, You have completely misundertood the goals of this thread, review >the rest of the thread for Ceki's simple and creative solution to my >question. I never suggested that I was making a feature request for >developers to implement greater functionality in log4j, certainly >nothing people should feel they have to vote on. If I were, then I'd be >making a feature request, not asking question on a users list. > >What I was seeking, was interest and discussion on an alternate way to >structure my logging configuration for my particular project. Something >a *users* list should be trying to foster. This is just a *discussion* >about hierarchical logging configuration ideas. Don't be so quick to >snuff out discussing ideas on a user list by throwing *-1's* around. > >IMHO, Log4J should be interested in promoting discussion about the >configuration solutions that can be applied to the product, and >expecially on the users list where others can search, reference and find >them. I also think using voting on users questions like this is not very >polite. Voting is really more appropriate for developers lists where the >majority of the members actually have a stake (and probibly karma) in >the direction the project goes in and are discussing making changes to >the product. > >Again, just my humble opinion. >-Mark > >Ingo Adler wrote: >> Shapira, Yoav wrote: >> >>> Howdy, >>> IMHO that's too complicated to be worth it. There are too many >>> possibilities for confusion. The simpler we can make configuration, the >>> better. -1 on that. >>> >>> >>> >> I agree with you (-1). The question boils down to "Where do I put any >> configuration file (not just log4j) for my system that is used in >> different environments (development, testing, production or other >> dimensions like WebSphere vs. JBoss; Standalong vs. Web Application vs. >> EJB...)? I don't think it's log4j's task to take care of this (Maybe >> it's Jakarta's common/Configuration's task.) And I doubt that there is a >> solution that will fit the different needs. Therefore - the simpler the >> log4j configuration schema is, the simpler it can be integrated in a >> more advanced, specialized solution. The only thing log4j could provide >> are more specialized Configurators that read the configuration from >> JNDI, database or whatever. But even then ... >> >> Ingo >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
