Bug 8705 - SessionListener should extend EventListener
Summary: SessionListener should extend EventListener
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 4.0.3 Final
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2002-05-01 18:09 UTC by Rob Misek
Modified: 2010-12-02 15:50 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Rob Misek 2002-05-01 18:09:13 UTC
org.apache.catalina.SessionListener does not extend java.util.EventListener

To meet the Javabean event spec, it must. This should not break anything, since 
(a) it currently does not extend anything and (b) the EventListener interface 
does not contain any methods.
Comment 1 Craig McClanahan 2002-05-01 19:09:33 UTC
Just as a note, doing something like this *would* break binary compatibility for
code compiled against the old version of the interface :-(.  Could be worked
around by a recompile, but that is not always guaranteed to be possible.

Therefore, I don't think this should be considred an option for a 4.0.x release.
 It could perhaps be considered in a 4.1.x release.
Comment 2 Rob Misek 2002-05-01 19:44:27 UTC
I don't believe that it would break binary compatibility. Could you please 
provide an explanation as to how that would occur?
Comment 3 Craig McClanahan 2002-05-01 20:06:42 UTC
We ran into this case in one of the proposed changes to Servlet 2.3, which added
FilterConfig.  Conceptually, it made sense to abstract out the common features
of FilterConfig and the existing ServletConfig interfaces into a new Config
interface that both would inherit from.  Alas, when you do that, code compiled
against the "old" version cannot run against implementations compiled against
the "new" version -- and vice versa.  So, we had to back away from doing this.

The reason this happens is that the compiler remembers the whole inheritance
tree at compile time, and the JVM uses that at runtime as part of the matching
criteria to see if the class you are requesting is compatible with the way it is
being used.  Unfortunately, introducing an additional parentage to an interface
(even though it doesn't affect the available methods) can trigger this
incompatibility check.

Admittedly, there is probably not a lot of code in the world that would be
affected by this in the case of SessionListener -- but it is still a real issue.
Comment 4 Mark Thomas 2010-12-02 15:50:28 UTC
This took rather too long but is now implemented in Tomcat 7.0.x and will be included in 7.0.6 onwards.

It can't be back-ported for the reasons outlined above.