1.3 Tasks (and beyond)

[Mark Womack <mw...@apache.org>]

As Curt has mentioned, we got together for a little while to talk about 1.3 
stuff.  I have included the list of tasks we came up between ourselves.  I'm 
sure it is not complete, but gives an idea of some scope.  Please feel free 
to comment and add more as you see it.

The one thing that really struck me at ApacheCon, and has been reflected 
here and on the users list, is that big changes in the API and binary 
compatibility is going to really mess people up.  If there are big changes, 
it is going to really affect the adoption of log4j 1.3, and I think we need 
to seriously ask ourselves if we want the current level of change that is 
reflected in the current source.  I'm all for moving forward and adding 
features, but I think we need to do it in a context of maintaining a high 
level compatibility.

Curt has done work to generate a binary compatibility report, and Paul was 
able to set up a jDiff report task.  I think that between the 2 of them we 
should review and start the work of reverting back to the 1.2 api as much as 
possible, having fewer breaking changes.  Adding new features like Plugins, 
JoranConfigurator, Receivers, Watchdogs is still doable.  And get the needed 
feedback from the community going forward.

For the big breaking changes, I think we should look to log4j 2.0.  We can 
really look to that version to do some fundamental work from the ground up, 
fix the things that really bother us, target features in the current JDK's 
(1.4, 5.0), etc.  In that version, we should expect to break things.  We can 
really look at things fresh and do new things.  I don't know how much the 
core workings will really change, but the stuff built around them could 
change.  Anyway, it is just thinking at this point.

Breaking lots of things in 1.3 and then breaking them all over again in 2.0 
is asking too much of the user base, IMO.

But I'm not a project manager/leader here.  What do you guys think?

Here is the list of stuff I had from ApacheCon (below).  Please feel free to 
comment/add.  It needs to be translated to a set up 1.3 bugs at some point, 
but we can discuss in email for now.

-Mark


log4j 1.3 tasks (this is just what Curt and I came up with between us)

- locking/threading issue
  - prerender the message before the lock?
- restore binary compatibility, restore as much source compatibility as 
needed
  (this is a really big area which needs an email on its own, but a few 
items...)
  - switch the Priority/Level change
  - binary compatibility of LoggingEvent between 1.2 and 1.3 (drop sequence 
number?)
 - 1.3 should pass 1.2 unit tests?
 - restore DOMConfigurator and a bunch of other classes that have been 
removed.
 ...and much more...
- JoranConfigurator/DOMConfigurator review
  - silent failures right now, add methods to get configuration exceptions
  - support namespaces
  - support different rule sets to be defined (basically reuse 
JoranConfigurator for different formats?)
- finalize slf4j support: direct or adapter?
- Review internal message logging mechanism, too verbose right now
- Plugin/PluginRegistery review and implementation
- Watchdog review and implementation
- Documentation - update, get community involved
- build changes
  - log4j-all jar
  - separate binary and source distributions
  - put external dependencies into build tasks, or Maven2
  - gbuild (build system for Geronimo) support for official builds and 
testing


log4j 2.0 thoughts (these are just thoughts now, don't freak out)
Will break extensions source wise and break binary compatibility.

- fundamental redesign
 - reorganize the classes/packages (interfaces vs implementations, group 
under packages), get rid of deprecated classes
 - configuration vs runtime (immutable) objects
 - finer grained locking for synchronization
 - Serialized version of LoggingEvent supportable across log4j 2.X versions 
and other logging services projects
 - new package name (log4j2?)
 - Implement to target more recent JDK (at least 1.4.X, use 1.5 annotations, 
etc?)
 - Cleaner design of what is a core, public interface and implementations
 - Use modern best practice designs from the core on up
 - Focus on core classes with "required" entities
 - Design entities for better encapsulation of members and methods
 - Precisely define lifecycle events and callbacks
 - Precisely define extension points 



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: 1.3 Tasks (and beyond)

[Mark Womack <mw...@apache.org>]

Yes.  log4j 2.0 would need to be in a new package.  But hopefully the
client upgrade might be as simple as changing the package imports. 
Now extensions or more complicated configuration would probably need
to be rewritten.

-Mark

On 12/20/05, Jess Holle <je...@ptc.com> wrote:
> Mark Womack wrote:
> > - new package name (log4j2?)
>
> I believe that's a must -- else you pose serious issues to both those
> attempting to use log4j 1.x and those attempting to use log4j 2.x --
> they'll be stepping on each other in practice otherwise.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: 1.3 Tasks (and beyond)

[Jess Holle <je...@ptc.com>]

Mark Womack wrote:

> log4j 2.0 thoughts (these are just thoughts now, don't freak out)
> Will break extensions source wise and break binary compatibility.
>
> - fundamental redesign
> - reorganize the classes/packages (interfaces vs implementations, 
> group under packages), get rid of deprecated classes

This may make sense for 2.0, but if the change is to be that dramatic, 
the whole set of classes should be moved to another package, e.g. 
org.apache.log4j2.

That way libraries which use log4j 1.x can co-exist with those using 
2.x.  Sure those using 2.x will have to global replace as well as 
recompile, but an Ant script could be provided to automate that.

> - configuration vs runtime (immutable) objects
> - finer grained locking for synchronization
> - Serialized version of LoggingEvent supportable across log4j 2.X 
> versions and other logging services projects
> - new package name (log4j2?)

I believe that's a must -- else you pose serious issues to both those 
attempting to use log4j 1.x and those attempting to use log4j 2.x -- 
they'll be stepping on each other in practice otherwise.

--
Jess Holle

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: 1.3 Tasks (and beyond)

[Endre Stølsvik <En...@Stolsvik.com>]

On Mon, 19 Dec 2005, Mark Womack wrote:

|  - prerender the message before the lock?

I'd say that this is a rather obvious performance improvement, and will 
IIUC also alleviate the deadlock-situations, since any objects that might 
cause deadlock by being locked as a side effect of rendering would be 
locked without any other locks held, preserving the linear lock-order.

Also, I think I saw that NDC uses HashTable keyed on Thread for its 
operation, which I find super-bad if I understand the usage correctly. 
What about ThreadLocal, in which case the NDC.remove() invocation on 
thread exit wouldn't be needed either?! ThreadLocal is "since 1.2", and 
since 1.4 and recent it is much faster than contended synchs around a Map.
  .. or at least use ConcurrentMap? But ThreadLocal is rather obvious 
here, I believe? Am I missing something? I could do such a patch..

Regards,
Endre.

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org