So similar to the OSGi bundle loading strategy, for Java 9, we'll need a layer loading strategy?
On 9 May 2017 at 11:36, 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 > > > > > > > > -- Matt Sicker <[email protected]>
