logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Deboy <scott.de...@gmail.com>
Subject Re: [ANN] Deleting receivers and components 'companions'
Date Tue, 18 Oct 2011 22:12:13 GMT
I would like to see much of what is in extras and component (at least
functionality-wise) be rolled in to log4j 2.  If it's in Chainsaw I really
doubt that will happen.  If it's in extras it may happen but I still doubt
it.

My preference would be to move component and extras and receivers in to
log4j 1.2.  If that isn't worth the effort, moving everything in to extras
would be the next best thing.

Scott

On Tue, Oct 18, 2011 at 12:55 PM, Christian Grobmeier
<grobmeier@gmail.com>wrote:

> So, what are we doing now?
>
> I don't want to stop in a deadlock again.
>
>
> On Wed, Oct 12, 2011 at 6:29 AM, Scott Deboy <scott.deboy@gmail.com>
> wrote:
> > Maybe everything optional should be pulled out of core - including
> > appenders.  I assume the reason they are in core is due to the fact that
> > people don't want to download a separate jar to get a
> > FileAppender..although, that justification doesn't seem to fit the
> guidance
> > provided by ObjectMentor :)
>
> I am with you Scott. I have send around a link before a while in which
> somebody said the log4j packaging model sucks. He would applaud you
> now.
>
> But do we really want to put so much effort in log4j 1.2 and
> modularize it when there is log4j2 on the road? Feels wrong to me.
>
> On the other hand, what Curt said is pretty heavy too. I looked into
> the tests and it is really not nice a nice place to dwell and code.
> Not sure if we want to put much effort int it too. I don't feel the
> urgent need.
>
> Then there is chainsaw. It feels very wrong to put the stuff there
> too. If it would be easy, ok. Scott, you need to say yes/no.
>
> And there is a last option. Finally make up a single component of all
> the classes and release it as "extras" package. Stuff we don't
> won't/need we leave out. I have already made some stuff for the
> website, so it is not impossible. I forgot why we left out this
> option. Should we go back to this one? We then just need to decide
> a) how the component is finally named
> b) which repositories go into this component
>
> Even when I have not exactly much time, I will help with this release.
>
> So, other options/ideas?
>
>
>
>
>
> > Scott
> >
> > On Tue, Oct 11, 2011 at 9:13 PM, Curt Arnold <carnold@apache.org> wrote:
> >>
> >> On Oct 10, 2011, at 3:23 AM, Christian Grobmeier wrote:
> >> >> Moving component and receivers to core would be more work given the
> >> >> peculiarities of the tests. It took a couple of hours just to move
> the
> >> >> Rewrite appenders and their tests.
> >> >
> >> >
> >> > Because why exactly? I thought it could be done with svn cp?
> >> >
> >>
> >> The files can be moved there, but the test environment is different and
> >> the tests will need to be modified to fit.
> >>
> >> extras and Chainsaw both use the Maven surefire plugin and expect
> >> configuration files and reference files to be in src/test/resources and
> >> available on the classpath, log4j's typically loads them from
> tests/input
> >> and tests/witnesses from the file system. Output files are written to
> >> tests/output in log4j.
> >>
> >> The OSGi manifest would also need to be tweaked for the new classes.
> >>
> >> Not hugely difficult, but more time consuming that moving the source and
> >> tests to extras or Chainsaw.
> >>
> >> > Actually I have no preference. I just think we need a pragmatic
> >> > approach. We do not the man power to release packages like
> >> > extras/receivers/whatever and therefore we need to move that stuff to
> >> > a proper location. From what I understood log4j is the better location
> >> > b/c the classes are expected there.
> >>
> >> Chainsaw is nearly the exclusive user of receivers and receivers is
> likely
> >> the exclusive user of components.  They are used together, will be
> debugged
> >> together and should be released together and the easiest way to do that
> it
> >> to have them in the Chainsaw tree.
> >>
> >>
> http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
> >> starting at page 17 has some principles for package architecture. I
> think
> >> all of those principles would favor putting the classes in Chainsaw.
> >>
> >>
> >> >
> >> > Can you explain a bit more in detail why it is more complicated to mv
> >> > classes to log4j-core than to chainsaw? I don't see the difference
> >> >
> >>
> >> See above.
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
>
>
>
> --
> http://www.grobmeier.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>

Mime
View raw message