logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <grobme...@gmail.com>
Subject Re: [ANN] Deleting receivers and components 'companions'
Date Tue, 18 Oct 2011 19:55:39 GMT
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

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


To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message