You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Remko Popma (JIRA)" <ji...@apache.org> on 2018/01/29 17:14:00 UTC

[jira] [Commented] (LOG4J2-2234) Clarify which classes in core are internal vs exported

    [ https://issues.apache.org/jira/browse/LOG4J2-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16343642#comment-16343642 ] 

Remko Popma commented on LOG4J2-2234:
-------------------------------------

The following packages look private/internal to me:
 * core.config.builder.impl
 * core.config.json
 * core.config.plugins.convert
 * core.config.plugins.processor
 * core.config.plugins.util
 * core.config.plugins.validation.validators
 * core.config.plugins.visitors
 * core.config.status
 * core.config.xml
 * core.config.yaml
 * core.impl (partially)
 * core.jackson
 * core.jmx (except the interfaces)
 * core.osgi (?)
 * core.script
 * core.tools
 * core.tools.picocli
 * core.util

Should these packages be renamed to reflect that they are internal packages and may change (we don't commit to preserving binary compatibility for these packages)?

> Clarify which classes in core are internal vs exported
> ------------------------------------------------------
>
>                 Key: LOG4J2-2234
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2234
>             Project: Log4j 2
>          Issue Type: Epic
>          Components: Core
>            Reporter: Remko Popma
>            Priority: Major
>
> While the Log4j 2 community is committed to preserving binary compatibility for the Log4j API jar, the Log4j Core jar was intended as "private" and subject to change. It turned out that in order to extend Log4j with custom plugins, users often found it necessary or very convenient to depend on classes in the Log4j Core jar. The need to preserve binary compatibility for the Log4j Core jar made it difficult for the Log4j Core module to evolve.
> This epic intends to create clarity as to which packages can be safely depended on.  Existing classes in Log4j Core that should be considered private and cannot be depended on need to be moved to new packages with "internal" in the name. Such packages will not be exported when Log4j Core becomes a full-fledged Java 9 module.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)