Re: logging-log4j2 git commit: [LOG4J2-2179] The MongoDB Appender should use keys and values from a Log4j MapMessage. Fix compile. Doc it!

7 commits for the same Jira? Ralph > On Jan 11, 2018, at 10:48 AM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master e78d205cc -> 672832929 > > > [LOG4J2-2179] > The MongoDB Appender should use keys and values from a Log4j MapMessage. > Fix comp

Re: logging-log4j2 git commit: [LOG4J2-2181] The JDBC Appender should use keys and values from a Log4j MapMessage. Implementation and documentation.

Again 6 commits for the same Jira? Ralph > On Jan 11, 2018, at 5:52 PM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branches: > refs/heads/master f530d4c8c -> 187e236ff > > > [LOG4J2-2181] The JDBC Appender should use keys and values from a Log4j > MapMessage. Implemen

Re: logging-log4j2 git commit: [LOG4J2-2185] Add a simple JDBC DriverManager-based ConnectionSource that uses JDBC's DriverManager#getConnection(String, String, String). Use @PluginBuilderFactory.

Why are there 5 commits in a row for the same Jira issue? Is there are reason you don’t test it all before committing? If you need to commit piecemeal then please squash the commits. Ralph > On Jan 12, 2018, at 10:15 PM, ggreg...@apache.org wrote: > > Repository: logging-log4j2 > Updated Branc

Re: [log4j] Move JDBC appender to own module?

My main complaint with core is the amount of time it takes to run unit tests. I don’t think the JDBC tests are a big contributor to that. Ralph > On Jan 13, 2018, at 6:34 PM, Gary Gregory wrote: > > On Jan 13, 2018 16:11, "Remko Popma" wrote: > > JDCB doesn’t require an external dependency s

Re: [log4j] Move JDBC appender to own module?

On Jan 13, 2018 16:11, "Remko Popma" wrote: JDCB doesn’t require an external dependency so why split it off into a separate module? So that core is thinner. Maybe that is not a big deal. Some folks complain more about the size of the API module. Gary This page is outdated now: https://loggin

Re: [log4j] Move JDBC appender to own module?

JDCB doesn’t require an external dependency so why split it off into a separate module? This page is outdated now: https://logging.apache.org/log4j/2.x/runtime-dependencies.html (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 14, 2018, at 3:43, Gary Gregory wr

Re: [log4j] Move JDBC appender to own module?

I created: LOG4J2-2188 Split off JPA support into a new module log4j-jpa LOG4J2-2187 Split off JDBC support into a new module log4j-jdbc

Re: [log4j] Move JDBC appender to own module?

On Jan 13, 2018 09:54, "Mikael Ståldal" wrote: As usual, I think we should avoid optional dependencies. That means more modules. Maybe we can start small here with a log4j-jpa module. Gary On 2018-01-13 10:16, Remko Popma wrote: > I meant to keep the jdbc and the generic db package toget

Re: [log4net] release 2.0.9

2018-01-13 16:40 GMT+01:00 Stefan Bodewig : > On 2018-01-12, Dominik Psenner wrote: > > > I'm working on LOG4NET-566, hoping that we can get a release build > > from our CI. > > CI won't be able to create the oldkey binaries unless we are willing to > make the old key public (which defeats the rea

Re: [log4j] Move JDBC appender to own module?

As usual, I think we should avoid optional dependencies. On 2018-01-13 10:16, Remko Popma wrote: I meant to keep the jdbc and the generic db package together. log4j-db: generic db + jdbc log4j-jpa: requires javax.persistance We can also keep all of these in a single module `log4j-db` with an

Re: [log4net] release 2.0.9

On 2018-01-12, Dominik Psenner wrote: > I'm working on LOG4NET-566, hoping that we can get a release build > from our CI. CI won't be able to create the oldkey binaries unless we are willing to make the old key public (which defeats the reason why the new key was introduced in the first place. >

Re: [log4j] Move JDBC appender to own module?

I meant to keep the jdbc and the generic db package together. log4j-db: generic db + jdbc log4j-jpa: requires javax.persistance We can also keep all of these in a single module `log4j-db` with an optional dependency on javax.persistance. More modules gives more flexibility but also more complex