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 <ralph.go...@dslextreme.com> 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 <pedro.lama...@prodist.com.br> > 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 <garydgreg...@gmail.com> > <mailto:garydgreg...@gmail.com> wrote: > >>> > >>> On May 9, 2017 12:18 AM, "Remko Popma" <remko.po...@gmail.com <mailto: > remko.po...@gmail.com> <mailto:remko.po...@gmail.com> <mailto: > remko.po...@gmail.com>> 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* mikael.stal...@magine.com 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.
