Bug 35654 - binary incompatibility between 1.2.xx Filter and 1.3 Filter
Summary: binary incompatibility between 1.2.xx Filter and 1.3 Filter
Alias: None
Product: Log4j - Now in Jira
Classification: Unclassified
Component: Other (show other bugs)
Version: 1.2
Hardware: Other All
: P2 major
Target Milestone: ---
Assignee: log4j-dev
Depends on:
Reported: 2005-07-08 05:43 UTC by Jacob Kjome
Modified: 2005-07-12 21:11 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Kjome 2005-07-08 05:43:47 UTC
In Log4j-1.2.xx, the "next" variable in org.apache.log4j.spi.Filter is public. 
This was made private in Log4j-1.3 and added getter/setter for access instead. 
This is the right way to go, however for projects such as LogWeb which use the
Log4j API extensively, this creates an incompatibility between 1.2.xx and 1.3.

I propose one of two solutions...

1.  make "next" public again in 1.3 (yuck!)

2.  release a version of 1.2.xx with getter/setters just as the 1.3 has.  1.2.12
would be a great candidate!  "next" would be left public in 1.2.xx with a
deprecation warning to use the getter/setter methods.  LogWeb and other like
code can move to support 1.2.12+ and use the getter/setter methods to be
compatible with 1.3

Comment 1 Mark Womack 2005-07-08 21:57:07 UTC
1.2.12 candidate
Comment 2 Mark Womack 2005-07-13 01:55:38 UTC
Option 3: What if we just make the "next" member public again in 1.3 and mark 
it as deprecated in favor of the getter/setter?  Then we don't have to change 
1.2 and compatibility is maintained.
Comment 3 Jacob Kjome 2005-07-13 05:11:30 UTC
Yeah, that's probably the best way to go.  We shouldn't have been exposing
member variables in the first place, but we'll just have to live with the mistake.

Fixed in 1.3

Mark, I leave it to you to decide whether adding the getter/setter methods to
1.2.xx is still adviseable.  It would allow 1.2.12 users to use a non-deprecated
API that is compatible with 1.3's non-deprecated API.