Do we have recursion prevention in any other appender than KafkaAppender?

On Wed, May 10, 2017 at 4:55 PM, Matt Sicker <[email protected]> wrote:

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



-- 
[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.

Reply via email to