Ah, I see. Each PrivateManager defines its own FQCN, so the 'duplication'
makes sense.
I have made some clean ups in the PrivateManager getContext() methods: they
now return a Core LoggerContext. That eliminated a bunch of type casts.
We now have 3 PrivateManager classes with methods like :
public static LoggerContext getContext() {
return (LoggerContext) getContext(FQCN, false);
}
Which I could further clean up as:
public static LoggerContext getContext() {
return LoggerContext.getContext(FQCN, false); // this
getContext method does not exist
}
Which might be silly since PrivateManager is a subclass
of org.apache.logging.log4j.LogManager, which provides getContext(String,
boolean);
In order to implement a clean up that uses:
LoggerContext.getContext(FQCN, false);
The protected method org.apache.logging.log4j.LogManager.getContext(String,
boolean) would have to be made public and _I am not sure that this is in
the best interest of the org.apache.logging.log4j.LogManager for what is
only an internal clean up_.
Thoughts?
Gary
On Sun, Aug 9, 2015 at 11:40 AM, Ralph Goers <[email protected]>
wrote:
> I don't think you can, but I am on the road and can't look now.
>
> Ralph
>
> Sent from my iPhone
>
> On Aug 9, 2015, at 9:10 AM, Gary Gregory <[email protected]> wrote:
>
> Patch committed to git master. Thank you for the review.
>
> Now I see code in log4j-1.2.-api that also type casts to the Core's
> LoggerContext from org.apache.log4j.Category.PrivateManager.
>
> In fact there are 3 versions/copies of PrivateManager in Category,
> LogManager, and Logger.
>
> Should we:
> (1) Have one package private implementaion
> (2) Avoid the type casts.
>
> ?
>
> On Sun, Aug 9, 2015 at 5:17 AM, Ralph Goers <[email protected]>
> wrote:
>
>> Nope. I am fine with this change. Thanks for asking!
>>
>> Ralph
>>
>> On Aug 9, 2015, at 2:46 AM, Gary Gregory <[email protected]> wrote:
>>
>> I have a patch that does not warrant a JIRA on pastebin at
>> http://pastebin.com/dckkjc0T
>>
>> It replaces calls like:
>>
>> final LoggerContext context = (LoggerContext)
>> LogManager.getContext(false);
>>
>> with new LoggerContext methods like:
>>
>> final LoggerContext context = LoggerContext.getContext(false);
>>
>> as I find the type casts we have all over the place distasteful.
>>
>> If it were just me, I'd apply it, but I am looking for feedback since
>> perhaps the type cast is an intentional marker that once it jumping from
>> the API into the Core.
>>
>> Gary
>>
>> --
>> E-Mail: [email protected] | [email protected]
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>
>
> --
> E-Mail: [email protected] | [email protected]
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
--
E-Mail: [email protected] | [email protected]
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
