[I've CC'd the mav-user list because I suspect the reply-to was an oversight and because I think others would find this thread helpful]
I am not suggesting that there are not many cases where it is advisable or even necessary to have log4j.jar (or xalan.jar) in the individual WAR files. However, I think as a general case this extra complexity is probably unnecessary. I myself only have two active webapps running, and they are perfectly happy with a container-wide instance of log4j. I'm quite happy adding a full explanation of these issues to the FAQ, including an explanation of how to configure log4j a per-application with a special servlet. But I think modifying the examples this way would complicate them unnecessarily. Of course, I'm open to being persuaded otherwise by a ruckus of voices on this list. BTW, even if a container hides its implementation jars, nothing prevents those jars from being made available separately by placing them in the container shared lib. You would simply have two copies of log4j.jar (or whatever). Since all containers, to my knowledge, have the concept of a "shared lib", I don't think there are any portability issues with this. Regarding xml-apis.jar and xalan.jar: Since these are both officially part of JDK1.4, my feeling is that in prior JDK versions these should really be added to the system classpath. Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Donnie Hale [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 06, 2002 6:11 PM > To: Jeff Schnitzer > Subject: RE: [Mav-user] 2.0 Installation Issues > > I may have slightly overstated the case regarding the restriction, but as > a > follower of the Tomcat lists, I've seen Craig's repeated quite direct > responses regarding usage of container-wide libraries. He's stated that, > apart from how to configure the web server connectors, it's the biggest > cause of problems with Tomcat. > > As far as what you *can* do versus what you *should* do, there are > multiple > problems with having a container-wide log4j.jar (as an example): > > - if a webapp in the container doesn't realize other webapps are using > log4j.jar, its log4j.properties file may not be configured correctly to > get > its log entries in a webapp-specific log file (assuming it's using a file > appender) > > - what if webapp "a" is using version 1.1.3 of log4j.jar but webapp "b" is > using the 2.0 beta (or whatever the latest dev revision is)? > > Lastly, log4j.jar and xalan.jar, as examples, could be among the "web > container's implementation classes". The recommendation against allowing > access to them means that, to be portable, a webapp should not rely on the > availability of these classes at the container level. > > Donnie > > > > -----Original Message----- > > From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 06, 2002 10:01 AM > > To: Donnie Hale > > Subject: RE: [Mav-user] 2.0 Installation Issues > > > > > > Interesting. Are you sure about that? I'm having trouble finding > > reference to this in the 2.3 spec; the closest I have found is SRV.9.7.2 > > which says: > > > > "The classloader that a container uses to load a servlet in a WAR must > > allow the developer to load any resources contained in library JARs > > within the WAR > > following normal J2SE semantics using getResource. It must not allow > > theWAR to override J2SE or Java servlet API classes. It is further > > recommended that the loader not allow servlets in the WAR access to the > > web container's implementation classes. It is recommended also that the > > application class loader be implemented so that classes and resources > > packaged within the WAR are loaded in preference to classes and > > resources residing in container-wide library JARs." > > > > The last sentence seems to strongly suggest that there are such things > > as container-wide library JARs. And a container implemented as it > > suggests would certainly not have problems configuring different log4j > > environments; any application which wanted behavior different from that > > supplied by the container can have its own copy of log4j.jar. > > > > The currently released version of Tomcat4 lets me have a container-wide > > log4j.jar and xalan.jar; I use it this way. > > > > Jeff > > > > > > > -----Original Message----- > > > From: Donnie Hale [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 06, 2002 4:18 PM > > > To: Jeff Schnitzer > > > Subject: RE: [Mav-user] 2.0 Installation Issues > > > > > > Re: point 1) > > > > > > With the servlet 2.3 spec, you really can't configure log4j at the > > > container > > > level. The requirement is for the system classloader to not allow 3rd > > > party > > > libraries to be available to web applications. Using Tomcat, Craig > > will > > > respond on the tomcat-user list with a "adding a library to the system > > > classpath is unsupported" message. One reason this is important is for > > > different web apps running in the same container which most likely > > want to > > > easily be configured for different log files, appenders, whatever. > > > > > > It's straightforward to use Ant to build the .war file properly > > depending > > > on > > > whether it's a debug or release build. We have two different > > > log4j.properties files that are placed in the .war file accordingly. > > > > > > This is essentially the same issue as xalan - containers which require > > it > > > in > > > their own implementation should no longer be allowing default access > > to it > > > at the web app level. Tomcat 4.x (and perhaps even 3.3+) enforce this. > > > > > > FWIW... > > > > > > Donnie > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff > > Schnitzer > > > > Sent: Wednesday, February 06, 2002 8:13 AM > > > > To: Dan Finkelstein; [EMAIL PROTECTED] > > > > Subject: RE: [Mav-user] 2.0 Installation Issues > > > > > > > > > > > > > From: Dan Finkelstein [mailto:[EMAIL PROTECTED]] > > > > > > > > > > Hi -- > > > > > > > > Hi! > > > > > > > > > I'm using 2.0 beta 1. When you're writing the doc for 2.0, the > > > > problems > > > > > I've been having might be useful to document. > > > > > > > > Thanks, this helps! > > > > > > > > > 1. On loading, I get errors that log4j isn't properly configured. > > I > > > > > added > > > > > a log4j initialization call in Dispatcher.init() and that seemed > > to do > > > > the > > > > > trick. (I grepped the sources but didn't see any explicit > > > > initialization > > > > > occurring. I also added simple properties file that log4j > > needed.) > > > > > > > > This is a FAQ in the yet-to-be-checked-in 2.0 manual. First a > > caveat: > > > > I'm not an expert in log4j, so I might be off base here. > > > > > > > > My general feeling is that log4j is really something that the > > container > > > > should be initializing, outside of the webapp. After all, you're > > > > typically going to want full logging when debugging, but minimal > > logging > > > > on the production box. Producing separate WARs for testing and > > > > deployment is not only a hassle, it's rather risky. > > > > > > > > My habit has been to provide default initialization to the JVM on > > > > startup using > > > > -Dlog4j.configuration=file:/path/to/maverick/tools/log4j.properties. > > > > > > > > > 2. When running friendship-velocity, it gave me errors that were > > > > only > > > > > resolved when I added in xalan.jar and xml-apis.jar. I had to > > > > download > > > > > xalan from jakarta since it wasn't in the distribution. The > > readme > > > > note > > > > > says to put them in the web server's lib directory. Could the > > > > friendship > > > > > war have been built with these files inside, which is more > > typical? > > > > > > > > I'll update the documentation regarding the xml-apis.jar... since > > jaxp > > > > is moving into the JDK itself, it doesn't seem like something that > > > > should be included in the WARs. Also, some containers put it on the > > > > classpath already, so this is really only a tomcat deployment issue. > > > > BTW, didn't a previous version of tomcat include jaxp? I don't > > remember > > > > having this problem before... oh well. > > > > > > > > I'm hesitant to include xalan.jar in the distribution. There are > > > > currently five sample applications in all of Maverick. The xalan > > jar > > > > itself is 800K, and it would be included in each of the WARs plus > > the > > > > maverick/lib directory. This would bloat the distributions by five > > megs > > > > or so. > > > > > > > > Also, not everyone uses xalan... theoretically, any jaxp-compliant > > > > processor will do, and some web containers (e.g. Orion) already > > include > > > > one. > > > > > > > > > 3. I'm interested in distributing different "skins" which would > > run > > > > > alongside the war file. Thus, I would like maverick.xml, the vm > > > > files, > > > > > html files, gif files, etc to live in a separate directory. I > > think > > > > > maverick is wired to expect them inside right now. What do you > > think > > > > of > > > > > this idea? > > > > > > > > It's definitely possible to have all the content (vm,html,images) in > > > > separate directories; paths are simply paths. At the moment, the > > > > maverick config file is hard-coded to WEB-INF/maverick.xml, although > > > > this could easily be made into a servlet init parameter. Is this > > what > > > > you have in mind? > > > > > > > > Also, would the shunting feature be of use to you for skinning? You > > > > could define each skin as a mode, and define views for all the > > modes. A > > > > custom Shunt could determine mode based on a session attribute. > > This > > > > would allow you to keep a single list of commands and controllers, > > and > > > > the Controllers wouldn't have to know anything about skins. > > > > > > > > If you want separate files just for the view lists, you could use > > > > entities to make the parser assemble the XML file for you. I > > figured > > > > out how this works (my sgml-fu grows stronger!) from reading the > > > > O'Reilly Docbook book. I'll put it in the FAQ. > > > > > > > > > I'll probably have more questions later.... Thanks for any help, > > > > > > > > No problem, and thanks for your input! > > > > > > > > Jeff Schnitzer > > > > [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > > > Mav-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > > > > > > _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
