[infinispan-dev] build failures on jenkins

Sanne Grinovero sanne at infinispan.org
Wed Aug 3 04:50:22 EDT 2011


2011/8/3 Galder Zamarreño <galder at redhat.com>:
>
> On Aug 2, 2011, at 6:33 PM, Sanne Grinovero wrote:
>
>> 2011/8/2 Galder Zamarreño <galder at redhat.com>:
>>> Here's the JIRA: https://issues.jboss.org/browse/ISPN-1298
>>
>> Fine for me, but I don't understand why you had me remove the
>> log4j.xml file from the test resources in the module, aren't we
>> achieving the same effect?
>
> The problem of a file called 'log4j.xml' is that log4j automatically tries to find it and will use it everytime the testsuite is run.
>
> I see logging as being something selective, something you sometimes enable but most of the time is disabled. So, what I wanted to avoid having files called 'log4j.xml' all over the place. Imagine the sort of problems that appear if you relied on a module that already defines a log4j.xml  (i.e. infinispan core tests - not that) and you had another 'log4j.xml' in the classpath, which one would be resolved automatically? Which one will log4j choose? You have no idea and based on past experience, it's a royal PITA figuring out why your log4j.xml changes are not having an effect.
>
> It's because of problems like this that I'd prefer names like 'log4j-lucene.xml' or something like that, and you selectively enable when you need it via a profile...etc.

Right, makes sense. I thought this was an Eclipse users only problem,
since we usually don't include the test resources in the classpath of
other modules, but Eclipse would add them when opening multiple
modules, and all builds would include an eventual file from
Infinispan's testing suite.
I agree it's worth trying what you proposed on this JIRA, if it
doesn't work I can live with the multiple resources since Eclipse at
least seems to order them properly so I always get the right one
loaded.

Cheers,
Sanne



More information about the infinispan-dev mailing list