Some experience i had over the past few days:
 I am trying to use velocity(1.1) and FOP(CVS) in the same servlet
 I get a clash in versions of logkit used. I use the latest FOP sources from
 which  uses logkit1.0b4.  Using velocity 1.1, i could not figure out which
 version of logkit is being used. the dist contains a log.jar. Using the
 logkit1.0b4 jar, the avalon logging system in velocity cant find a
 method in FileOutputLogTarget. In the reverse, using only the velocity
 FOP complains about some other method!
 For a while, i debated writing my own custom class loaders :). I got the
 whole thing to work by writing my own (almost dummy) LogSystem (not a happy
 situation, certainly). I did not want to use Log4j in velocity (which is 
 possible to plug into velocity), since FOP in any case uses logkit.
 Mails to the velocity dev-list (thanks Geir!) revealed that the latest CVS 
 version (1.2dev) of velocity did not have this problem, and worked well
 the latest issue of logkit. Subsequently the velocity build process has
 updated to optionally  build a no dependencies jar, and also to use a
 numbered jar for logkit. 

 In view of the this, i strongly feel that for a component that is used
 multiple projects, few API changes and a long deprecation period is
 Its similar to the issue Sam Ruby raised about batik/FOP and cocoon,
 upgrades become difficult.   

> -----Original Message-----
> From: COFFMAN Steven [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2001 10:30 PM
> Subject: [VOTE] Framework mods re: Logger
> Hi. Avalon wants FOP and other Avalon projects to give input 
> on changes to
> the Logger interface. If you want to discuss it on the FOP list, I can
> forward them to Avalon
> [EMAIL PROTECTED] if you aren't subscribed.
> -Steve
> -----Original Message-----
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 18, 2001 11:04 AM
> Subject: [VOTE] Framework mods
> There has been some discussion over what the Logger interface 
> should or
> should not be for the next release.  I want input from the different
> projects
> that _use_ Avalon, or would like to use it to help us make the final
> decision.
> First, let it be known that Avalon will allways prefer LogKit as the
> standard
> Logger--although it can provide hooks for you to add your own logger
> implementations.  That is what the vote is for.  There are a 
> proposed Logger
> interface and Loggable interface.
> We have two choices to allow for pluggable Logger implementations:
> 1) Simply replace the Loggable and AbstractLoggable classes with the
> proposed
>    version.  This causes a backwards incompatibility, and is 
> not preffered.
> 2) Deprecate Loggable and create a new interface to avoid 
> incompatibilities.
>    This causes us to have to use a less than desirable 
> interface name for
>    the equivalent of Loggable.
> Please be advised that the changes would affect you in two 
> ways:  The origin
> of the Logger interface is now 
> org.apache.avalon.logger.Logger, and if we
> alter the interface name for Loggable, you would have to 
> implement that
> interface
> instead.  The actual client API for Logger and Abstract 
> Logger will not
> change
> your existing code.
> The most impact will be for people who actually use the 
> Loggable interface
> directly or place the logger in a local variable.  You should 
> be able to
> change
> the import statement for the Logger object and all will be 
> working again.
> It is generally agreed that pluggable loggers would be a good 
> thing for
> Avalon,
> and we should be able to provide support for Log4J and LogKit 
> relatively
> easily.
> Committers, please place your votes.
> Users, please give your comments.
> Vote for approach 1 or 2 above.  If you choose method 2, 
> please provide a
> suggested
> name for the new interface.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to