Starting a new thread about recursive logging at runtime since that's not related to Java 9 modules.
On Wed, May 10, 2017 at 5:08 PM, Matt Sicker <[email protected]> wrote: > https://github.com/apache/logging-log4j2/blob/master/ > log4j-core/src/main/java/org/apache/logging/log4j/core/ > config/AppenderControl.java > > All appenders are supported generically. > > On 10 May 2017 at 09:59, Mikael Ståldal <[email protected]> wrote: > > > Do we have recursion prevention in any other appender than KafkaAppender? > > > > On Wed, May 10, 2017 at 4:55 PM, Matt Sicker <[email protected]> wrote: > > > > > We already have recursion prevention in appenders, so that's not an > > issue. > > > Runtime cycles are based on module imports apparently, not necessarily > on > > > the flow of data. > > > > > > On 10 May 2017 at 04:28, Mikael Ståldal <[email protected]> > > wrote: > > > > > > > Actually, it is a bit of a problem that the Kafka client library do > > > logging > > > > during our calls to it in KafkaAppender. But this is only a problem > at > > > > runtime. > > > > > > > > On Tue, May 9, 2017 at 6:36 PM, Ralph Goers < > > [email protected]> > > > > wrote: > > > > > > > > > As I understand it, what you are saying is possible but Log4j > doesn’t > > > > > currently need to load these dependencies dynamically. We > dynamically > > > > load > > > > > our plugins, but the plugins we are talking about are provided by > > > Log4j. > > > > > These plugins use a third party jar and these are hard-wired > > > > dependencies. > > > > > This all works fine today as Java doesn’t care about circularities. > > Of > > > > > course we do and handle that situation at runtime if an actual > > > > circularity > > > > > exists when performing the logging operations. But there is no > > problem > > > if > > > > > Log4j needs Kafka, and Kafka needs Log4j. > > > > > > > > > > Ralph > > > > > > > > > > > > > > > > > > > > > On May 9, 2017, at 9:07 AM, Pedro Lamarão < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > Hello all! > > > > > > I have been lurking on the list for a while, as a user of both > > log4j > > > > and > > > > > log4cxx. > > > > > > This Java 9 module situation greatly interests me. > > > > > > About the circularity problem, isn't it the case that loading > > modules > > > > at > > > > > runtime will solve the circularity problem? > > > > > > As far as I understand the new system, it is possible to build a > > new > > > > > Layer and load modules into it. > > > > > > Say the application depends on log4j. At runtime, log4j-core > > > discovers > > > > > the need to load log4j-foo. It creates a new Layer and loads > > log4j-foo > > > > and > > > > > foo into it. foo may depend on log4j, yes, but that is already > loaded > > > in > > > > > the parent Layer. > > > > > > Am I missing something? > > > > > > Regards, > > > > > > P. > > > > > > > > > > > > > > > > > > Em 09/05/2017 12:43, Ralph Goers escreveu: > > > > > >> While it may sound reasonable, it is not. Matt’s point about > > > > > LoggerFinder and our support of NoSQL appenders and the like is > proof > > > > that > > > > > there are valid reasons for circularities. We are just lucky that > > > Jackson > > > > > and Disruptor don’t seem to do logging or we would have > circularities > > > > there > > > > > too. > > > > > >> > > > > > >> BTW - I got a private answer to my question on this. It was > that I > > > > > should post my question to the jigsaw dev list but that I should > > expect > > > > > that Log4j - or at least pieces of it - can’t be modularized. > > > > > >> > > > > > >> Ralph > > > > > >> > > > > > >>> On May 9, 2017, at 8:24 AM, Gary Gregory < > [email protected] > > > > > > > > <mailto:[email protected]> wrote: > > > > > >>> > > > > > >>> On May 9, 2017 12:18 AM, "Remko Popma" <[email protected] > > > > <mailto: > > > > > [email protected]> <mailto:[email protected]> <mailto: > > > > > [email protected]>> wrote: > > > > > >>> > > > > > >>> > > > > > >>> Mark Reinhold's reasoning in his response ( > > > > > http://mail.openjdk.java.net/ <http://mail.openjdk.java.net/> > > > > > >>> pipermail/jpms-spec-experts/2017-May/000695.html) makes sense > to > > > me. > > > > > >>> > > > > > >>> > > > > > >>> Sounds reasonable indeed. Reading this latest sounds like JBoss > > > has a > > > > > lot > > > > > >>> of work to do in order to fit in Java 9 modules from its own > > module > > > > > system > > > > > >>> and they'd rather not do more work than less, which is > > > > understandable. > > > > > MR's > > > > > >>> view on a conservative first cut makes sense. It is so late in > > the > > > > > Java 9 > > > > > >>> timeframe that these change requests seem doomed anyway. > > > > > >>> > > > > > >>> Gary > > > > > > > > > > > > -- > > > > > > > > > > > > <image001.jpg> > > > > > > Pedro Lamarão > > > > > > PRODIST TECHNOLOGIES > > > > > > http://www.prodist.com.br <http://www.prodist.com.br/> > > > > > > "Securing Critical Systems" > > > > > > > > > > > > (11) 3672-3526 > > > > > > (21) 2292-9481 > > > > > > (21) 98887-5175 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > [image: MagineTV] > > > > > > > > *Mikael Ståldal* > > > > Senior software developer > > > > > > > > *Magine TV* > > > > [email protected] > > > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > > > > > > > Privileged and/or Confidential Information may be contained in this > > > > message. If you are not the addressee indicated in this message > > > > (or responsible for delivery of the message to such a person), you > may > > > not > > > > copy or deliver this message to anyone. In such case, > > > > you should destroy this message and kindly notify the sender by reply > > > > email. > > > > > > > > > > > > > > > > -- > > > Matt Sicker <[email protected]> > > > > > > > > > > > -- > > [image: MagineTV] > > > > *Mikael Ståldal* > > Senior software developer > > > > *Magine TV* > > [email protected] > > Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com > > > > Privileged and/or Confidential Information may be contained in this > > message. If you are not the addressee indicated in this message > > (or responsible for delivery of the message to such a person), you may > not > > copy or deliver this message to anyone. In such case, > > you should destroy this message and kindly notify the sender by reply > > email. > > > > > > -- > Matt Sicker <[email protected]> > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* [email protected] Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
