On Jan 3, 2006, at 1:05 AM, Jacob Kjome wrote:
I don't see this happening quite so much as with the
RepositorySelector interface, which did change between 1.2 and
1.3. The changes are somewhat important for 1.3's usage... at
least it used to be. I haven't tracked all the recent changes. I
hope the recent changes don't blow away stuff like self-logging and
improvements to repository selectors.
Jake
Looks like RepositorySelector poses a similar problem as
LoggerRepository. From my analysis of the code, it does appear that
the intention was to allow clients to specify their own
RepositorySelector and the following page gives an example of
implementing a log4j 1.2 RepositorySelector for a JBoss app (http://
www.jboss.org/wiki/Wiki.jsp?page=Logging).
http://jira.jboss.com/jira/browse/JBAS-1853 is a JBoss JIRA issue
suggests that at least that user attempted to implement a log4j 1.2
LoggerRepository.
My understanding is that if an app that implemented the log4j 1.2
version of LoggerRepository or RepositorySelector passes that object
into log4j 1.3 then any attempt to call one of the log4j 1.3
introduced methods would raise an unchecked NoSuchMethodException.
In the case of LoggerRepository, I put if(repo instanceof
LoggerRepositoryEx) guards around any calls to the new methods and
attempted to implement reasonable fallback behavior. I have not
looked at RepositorySelector and do not know how reasonable it would
be to implement acceptable fallback behavior if presented with a
1.2.x implementation of RepositorySelector.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
