Robert, putting aside the attitude discussion for a while and go back to the facts on the table;
You would like to use Log4J in the production environment. GOOD! You want to re-write Cocoon to explicitly do the Log4J "lookup" of the Logger through the Logger static method. NOT SO GOOD, in my humble opinion. I have been convinced about the advantage of Inversion of Control that Avalon is strongly promoting. Provide the logger to the component is much more flexible, and some say more secure (of which I can't tell.) The Avalon approach, allows that a very slim Logger layer can be mapped on top of basically any logger backend, and the Avalon community provides a few, although I am not sure if it is fully supported in the older ECM (agree ancient Avalon container), but I think it is. So, I am sure Carsten & Co, can provide some easier way to configure this, than present day, and perhaps it should be the default configuration to use Log4J as the backend. The performance hit, using the extra layer, would be far less than it takes Log4J to do something about the message, and if the Cocoon code properly use, logger.isXXXEnabled(), the main culprit of logging (debug statements being constructed) performance degrade is eliminated. Isn't this what you are REALLY asking for? Instead of; "Let's throw all that out, and re-implement against a package, that we can't easily change in the future". Trying to be constructive. Niclas Robert Simmons said: > <quote>I wasnt insulting anyone and i appologize if it sounded > like that. </quote> > > I noticed you failed to copy that block into your acerbic reply. I > appologized once, I wont do it again. > > -- Robert > > > "Gianugo Rabellino" <[EMAIL PROTECTED]> schrieb im Newsbeitrag > news:[EMAIL PROTECTED] >> Robert Simmons wrote: >> >> > I wasnt accusing anyone of being childish. I wish you wouldnt >> put words > in >> > my mouth. I merely meant that the demands of a business >> environment are quite different then the demands of >> non-business environments. >> >> Please rest assured that many (probably most) of us know what >> the demands of business environments are. >> >> > Many open >> > source projects have yet to bridge this gulf and only a few >> have done it sucessfully (apache web server, ant, log4j, >> tomcat, jboss). For example, > the >> > decision to NOT distribute a binary build of cocoon is a good >> example of going in the opposite direction of business. Many >> business consultants > are >> > not interested in building source, but rather using the >> product as is. >> >> Oh, gosh... will not distributing a binary build be enough for >> us not to "cross the bridge"? Let's have a party on this side of >> the river with Linus then. Oh, and please tell me where you are >> going to find Gnome or KDE binary distributions (RPM, DEB and >> other linux distro packages don't count). And tell the FreeBSD >> guys that their port system is doomed. >> >> Anyway, here is your binary distribution: >> >> $ cat > setup.sh >> ./build.sh war > install.log 2>&1 >> if [ $? == 0 ] >> then >> echo "Installation successful, Cocoon war installed in >> `pwd`/build/cocoon.war" >> else >> echo "Installation failed, plese check install.log for >> details" >> fi >> ^D >> >> Rant apart, you might have a point in blaming Cocoon of not >> being "business friendly", and I'm starting to consider that >> there might be room for someone to come up and be Cocoon's >> RedHat, providing >> "production" builds and "certified" WARs, thus relieving the >> Cocoon community in these issues. Any Orixians listening? ;-)) >> >> Ciao, >> >> -- >> Gianugo Rabellino >> Pro-netics s.r.l. - http://www.pro-netics.com >> Orixo, the XML business alliance - http://www.orixo.com >> (Now blogging at: http://blogs.cocoondev.org/gianugo/)
