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]>
