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

**

Attachment: smime.p7s
Description: Assinatura criptográfica S/MIME

Reply via email to