[logback-dev] Looking at MongoDBAppender

[Christian Trutz]

Hi ceki,

thank you very much for your remarks :-)

Remark 1): yes i agree with you, that integration tests are also very
usefull and only
with integration tests you know, that the software do what you want.
I thought that maybe Maven profiles could be very useful to separate
execution of
integration tests. Only with profile (say "integration-tests") the
integration tests will
be executed. Have we any Hudson/Jenkins instance for logback-extensions?

Remark 2): I am using TestNG only because it was included, not because I
think it
is necesary. I will change the logback-ext-mongodb unit tests to JUnit
tests.

Remark 3):
>If I understand correctly, Jmockit relies on a java-agent to execute?
Yes, with jdk1.5 it relies on java-agent, with jdk1.6. it runs also without
java-agent.
We have jdk1.6. so we do not need any java-agent configurations, the tests
run OTB.

Remark 4): Ohh ok, I will separate logback-ext-mongodb into classic and
access ...
>Notwithstanding the above remarks, I am looking forward to testing
logback-mongodb-* once I install MongoDB on my local machine.
OK please look also to
https://github.com/qos-ch/logback-extensions/wiki/MongoDB
it contains a little tutorial for logback-access with Tomcat and MongoDB.

Regards
Christian


2012/6/18 ceki <ceki at qos.ch>

> Hi Christian,
>
> I've mostly looked at the tests (not MongoDBAppender
> itself). Here are some preliminary remarks:
>
> 1) Mocks in tests are very useful for certain tests. However, I don't
> think mock tests let us verify that MongoDBAppender actually works
> with MongoDB.
>
> We faced a similar problem with DBAppender which supports several
> databases such as oracle, mysqldb, postgresql, h2, etc. During the
> build, there are tests which actually run against these databases but
> only on "conforming" hosts, i.e. hosts that are known to run a
> database of certain type. Here is an except from
> DBAppenderIntegrationTest [1] which you might find useful.
>
> public class DBAppenderIntegrationTest {
>
>  static String LOCAL_HOST_NAME; // set in setUpBeforeClass()
>  static String[] MYSQL_CONFORMING_HOST_LIST = new String[] { "xharo" };
>
>  @Test
>  public void mysql() throws Exception {
>    if (!**isConformingHostAndJDK16OrHigh**er(MYSQL_CONFORMING_HOST_LIST)**)
> {
>      return;
>    }
>    doTest("src/test/input/**integration/db/mysql-with-**driver.xml");
>  }
>
>  static boolean isConformingHostAndJDK16OrHigh**er(
>                               String[] conformingHostList) {
>    if (!Env.isJDK6OrHigher()) {
>      return false;
>    }
>    for (String conformingHost : conformingHostList) {
>      if (conformingHost.**equalsIgnoreCase(LOCAL_HOST_**NAME)) {
>        return true;
>      }
>    }
>    return false;
>  }
>
> }
>
> The idea could perhaps be applied to MongoDB as well. We'd run
> integration tests on machines known to deploy MongoDB and skip the
> tests on most other machines.
>
> Remark 2)
>
> MongoDBAppender tests use TestNG. While TestNG offers some
> functionality beyond Junit, in my past experience, I often had to
> revert to Junit because it is better supported than TestNG by various
> tools, in particular IDEs. From what I could see, you care not using
> any TestNG specific features, so moving to Junit should be easy. If
> you really prefer TestNG, you are welcome to put the issue to a vote
> and we'll all use the tool with the most votes. However, it seems
> awkward to use TestNG in some parts of the project and JUnit in
> others. Relying on a must-have TestNG-only feature is a different
> matter which may justify TestNG in a particular test case.
>
> Remark 3)
>
> If I understand correctly, Jmockit relies on a java-agent to execute?
> Is there a way to run Jmockit without a javaagent?
>
> Remark 4)
>
> No logback-ext module should depend on logback-access and
> logback-classic at the same time. Otherwise, when such a module is
> used, it will pull in both logback-access and logback-classic into the
> client's project. This may have unintended consequences. In the most
> common deployment scenario, logback-access is deployed on the server's
> lib/ folder whereas logback-classic is deployed in a web-app. We don't
> want to break that common deployment scenario.
>
> Given the above, I would suggest to break mongodb into two modules,
> one for logback-access and one for logback-classic.
>
> Notwithstanding the above remarks, I am looking forward to testing
> logback-mongodb-* once I install MongoDB on my local machine.
>
> [1] http://tinyurl.com/d2anyzb
>
> --
> Ceki
> http://twitter.com/#!/ceki
> ______________________________**_________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://mailman.qos.ch/mailman/**listinfo/logback-dev<http://mailman.qos.ch/mailman/listinfo/logback-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-dev/attachments/20120618/870d7438/attachment-0001.html>