On Feb 26, 2005, at 10:00 AM, Ceki G�lc� wrote:
Curt, today there is not a single appender which implements the Appender interface without extending the AppenderSkeleton class.
All we know for sure is the code in the Gump universe. The Appender interface is complex enough that it would drive almost all implementations to subclass AppenderSkeleton. But is isn't impossible and wasn't discouraged. If someone implemented a remote appender using RMI or Soap, they may have only exposed the Appender interface.
2) The changes only affect programmatic calls to appenders maintained outside the log4j project. If those appenders are invoked from log4j configuration files, then they will work just fine and without change with 1.2 as well as 1.3.
I haven't confirmed it, but from code review it appears that any existing custom appended that implemented activateOptions will not be properly initialized from configuration files, since ConfigurationBase calls activate, not activateOptions. For a custom appender that required activateOptions and wanted to work with both log4j 1.2 and 1.3, it appears that the would have to implement both activateOptions and activate and avoid calling one from the other to avoid loops but avoid doing activation twice for one call. Let me know if you want be to build a test case to check this.
You have a point there. However, things are not as bad as you depict nor as rosy as I asserted previously. Existing appenders would need to rename their activatOptions() method as activate(). I think that's an acceptable price to pay. When a software product changes for the better, it's extensions need to change as well. Client code won't see the difference as long as the appenders they use adapt to changes in 1.3. Adapting existing appenders involves minimal easy to perform changes. (It took about 10 minutes to perform on the dozen or so appenders shipping with log4j proper.)
However, you were making a deliberate decision that those appenders would only work with 1.3 (which is appropriate since they are part of the log4j package). However, users of custom appenders may not have the choice of what version of log4j they work under. Even if they are committed to migrate to 1.3, they may want to run under both 1.2 and 1.3 for a period of time to test the migration. At least for some class of appenders, it may be extremely complicated to write activate and activateOptions so they behave identically.
I agree that activateOptions is not the best name, but it is an established extension point and custom appender writers have probably gotten use to it. I would have no problem with adding a
public final void activate() {
activateOptions();
}to AppenderSkeleton so that Appender users could have a synonym for activateOptions.
3) Applications such as hivemind which configure their custom appenders programmatically need to add one line to their code in order to invoke the activateOptions() method. If they do that, they will be compatible with both 1.2 and 1.3.
For Appenders that are ready at construction, they would more likely do what you did for tests/.../VectorAppender and just call super.activate() in the constructor.
By adding both AppenderSkeleton() and AppenderSkeleton(boolean), we allow existing custom to continue to work consistent with 1.2 and allow internal implementations to take advantage of the check that activate/activateOptions has been called. If we wanted to encourage custom appenders to migrate away from the compatibility behavior, then we could mark the default AppenderSkeleton constructor as deprecated.
It's a matter of taste and priorities. IMHO going into all these contortions does not pay off. We can't behave as if we had a yearly development budget of 20 million USD with 50 developers on the project. We don't have that kind of resources. Subsequently, we have to keep things simple for the sake of current developers as well as future ones.
I think it was all of 10 non-comment lines (two AppenderSkeleton constructors and adding calls to super(false) in about 6 derived classes) that would eliminate a known problem area while still preserving the behavior that you desired with the built-in appenders. I would much rather write and maintain those lines instead of repeatedly explaining on the situation log4j-user.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
