CVS Update: Barracuda

[email protected] Sat, 26 Oct 2002 12:26:59 ()
Newsgroups gmane.comp.java.enhydra.barracuda.cvs
Message-ID <[email protected]>
CVSROOT:	/u/cvs
Module name:	Barracuda
Repository:	Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/
Changes by:	JacobK@frogger.	02/10/26 12:26:59

Modified files:
	Projects/EnhydraOrg/toolsTech/Barracuda/src/: build.xml 
	Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/: 
	                                                                                      Log4jApplicationWatch.java 
	                                                                                      Log4jInit.java 
Added files:
	Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/: 
	                                                                                      Log4jCRS.java 

Log message:
	Adding a new Log4j concept called a logger repository selector.  Log4j uses a default one, but we can make it use our own and then have more control over the LoggerRepository (Hierarchy) being used.  This allows us to put Log4j in a parent classloader and allow all applications to use that instance of Log4j without stomping on each others logger configuration.  For those who still want to use Log4j from within each webapp, that is still completely supported.  There isn't anything different that a user will have to do in configuring Log4j or using Loggers.  Everything will work as it always has transparently.  The one thing that needs to be remembered, however, is that log4j needs to live wherever you move the logger repository selector or, in our case, wherever you put plankton.jar.  So, if plankton.jar gets moved to a parent classloader such as Tomcat's shared/lib, you need to make double sure that you remove the log4j jar file from your webapp's WEB-INF/lib folder.  Other!
 
wise, you will get mysterious java.lang.IncompatibleClassChangeError messages at application startup and your logging won't work and neither will your application.  So, you are *always* safe if you put keep plankton in WEB-INF/lib, but if you move plankton to a parent classloader, Log4j must move to that parent classloader as well and be removed from WEB-INF/lib.
	
	I also made a modification to the build file.  I noticed that the barracuda-core.jar was not excluding the org.enhydra.barracuda.core.util package.  That was making it about 152k larger than it needed to be and, of course, this also duplicated the contents of plankton.jar.  Not sure when that happened, but it is fixed now.
	
	Jake

===================================================================
File: no file build.xml		Status: Unknown

   Working revision:	No entry for build.xml
   Repository revision:	No revision control file

===================================================================
File: no file Log4jApplicationWatch.java		Status: Needs Checkout

   Working revision:	1.2	Sat Oct 26 19:26:59 2002
   Repository revision:	1.2	/u/cvs/Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/Log4jApplicationWatch.java,v

   Existing Tags:
	No Tags Exist

===================================================================
File: no file Log4jInit.java		Status: Needs Checkout

   Working revision:	1.4	Sat Oct 26 19:26:59 2002
   Repository revision:	1.4	/u/cvs/Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/Log4jInit.java,v

   Existing Tags:
	Barracuda_1_1_1          	(revision: 1.3)
	Barracuda_1_1_0          	(revision: 1.3)

===================================================================
File: no file Log4jCRS.java		Status: Needs Checkout

   Working revision:	1.1	Sat Oct 26 19:26:59 2002
   Repository revision:	1.1	/u/cvs/Projects/EnhydraOrg/toolsTech/Barracuda/src/org/enhydra/barracuda/core/util/logging/Log4jCRS.java,v

   Existing Tags:
	No Tags Exist