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. RalphOn May 9, 2017, at 8:24 AM, Gary Gregory <garydgreg...@gmail.com> wrote: On May 9, 2017 12:18 AM, "Remko Popma" <remko.po...@gmail.com <mailto:remko.po...@gmail.com>> wrote: Mark Reinhold's reasoning in his response (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
-- <o:p></o:p><o:p> </o:p> cid:image005.jpg@01D2AFC0.49538E40 *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* **
smime.p7s
Description: Assinatura criptográfica S/MIME