[
https://issues.apache.org/jira/browse/LOG4J2-1418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219921#comment-17219921
]
Marcono1234 commented on LOG4J2-1418:
-------------------------------------
Could there please be a warning text (bold) that users can *only* expect a
{{MessageFactory2}}? E.g.:
{code}
* Gets the message factory used to convert message Objects and
Strings/CharSequences into actual log Messages.
*
* <p>Since version 2.6, Log4j internally uses message factories that implement
the {@link MessageFactory2} interface.
* To ease working with {@code MessageFactory2} but at the same time keeping
binary compability the return type of this
* method was changed in version 2.6.2 from {@code MessageFactory} to {@code <MF
extends MessageFactory> MF}.
* The returned factory will always implement {@code MessageFactory2}. Due to
the unbound type variable as return type
* the compiler cannot enforce type-safety. Therefore the caller <b>must not
make any other assumptions about the
* return type</b> unless the caller specified the message factory themselves.
*
* @return the message factory, as an instance of {@link MessageFactory2}
{code}
This method exposes non-type-safe functionality to the user which does not
cause any issues during compile time, but fails during runtime.
For example the user can write:
{code}
MyFactoryWhichIsDefinitelyNotUsedByLog4j factory = logger.getMessageFactory();
{code}
Due to the return type being unbound, that compiles fine.
Also what is the general policy regarding backporting / porting features to the
{{master}} branch? I have seen changes (such as asciidoc manuals) being only on
{{master}} while other changes (like the javadoc comment proposed by [~rpopma])
only existing for the {{release-2.x}} branch.
> Provide MessageFactory2 to custom Logger implementations
> --------------------------------------------------------
>
> Key: LOG4J2-1418
> URL: https://issues.apache.org/jira/browse/LOG4J2-1418
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.6, 2.6.1
> Reporter: Mikael Ståldal
> Assignee: Mikael Ståldal
> Priority: Major
> Fix For: 2.6.2
>
>
> It would be useful for a custom Logger implementation to be able to get hold
> of a {{MessageFactory2}} (and not just a {{MessageFactory}}), in order to
> efficiently process {{CharSequence}} etc.
> {{Logger.getMessageFactory()}} return {{MessageFactory}}, even though the
> sole implementation in {{AbstractLogger}} do have a {{MessageFactory2}}
> available.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
