having some sort of configuration like

<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>[%date{HH:mm:ss.SSS}][%5level][%logger{40}][%msg]%n%rootException</pattern>
    </encoder>
  </appender>

<logger name="org.perrycorp" level="INFO">
    <appender-ref ref="STDOUT" />
    <appender-ref ref="DOES_NOT_EXIST" />
  </logger>
</configuration>

does not apply any appenders to org.perrycorp logger. Behaviour on 1.2.X was to apply known appenders, ignoring not existing appenders. We have more complex use cases where we define some appenders based on some properties being passed, applying one or another:

    <logger name="org.perrycorp" level="INFO">
      <if condition='!isNull( "logback.logstash.destinations" )'><then>
        <appender-ref ref="LOGSTASH_APPENDER" />
      </then></if>

      <if condition='isNull( "logback.logstash.destinations" )'><then>
        <appender-ref ref="STDOUT" />
      </then></if>
    </logger>

in these kind of cases one of the two appenders isn't going to be declared which, with Logback 1.3.0, causes the configuration to not attach any appender to org.perrycorp logger. Same thing occurs on custom appenders like the one noted on LOGBACK-551.

Workaround for the last case is to provide dummy appenders and overwrite instead of define the appenders inside the corresponding <if> elements (doable but not funny for us, so we'd appreciate if the old behaviour could be brought back)