They remove all appenders because things other than JDBC may have caused the loggers to be set up some way and doing BasicConfigurer.configure()/BasicConfigurer.resetConfiguration() ends up setting up a single console appender.
If you have a better way of disabling logging for the tests then that would be preferred. Also the one TestMemDriverWithLogging class explicitly wants to configure logging because it is changing the logging setup at driver creation time to verify that portion of functionality. Currently this is redirecting stdout to a ByteArrayOutputStream so as to not pollute the build output. I likely need to add a note to the documentation about example logging configuration being available. I'm away on vacation through Wednesday so don't expect any responses from me in the meantime I.e. don't let me hold you up if you want/need to make changes to get the release prepared. Rob On 9/8/13 2:20 AM, "Andy Seaborne" <[email protected]> wrote: >On 07/09/13 21:55, Rob Vesse wrote: >> Comments inline: >> >> >> On 9/7/13 12:50 PM, "Andy Seaborne" <[email protected]> wrote: >> >>> Hi Rob, >>> >>> I've got the full build (deploy) building by using java7. It's not >>>that >>> it is always broken with Java6. The test build is still Java 6 and >>>that >>> usually works; it might be load-on-build-server sensitive. It builds >>> fully on my local machine in either set up. (I have added connection >>> caching to Fuseki test as well.) >>> >>>> What are the build exceptions in JDBC / JenaStatement? >>> >>> There's log at: >>> >>> https://builds.apache.org/job/Jena_Development_Deploy/437/console >>> >>>from about 25% to 50% of the scroll bar. >>> >>> I have a version locally that is clean. I found that the tests reset >>> Log4j and then remove all the appenders which causes the warning about >>> >>> log4j:WARN No appenders could be found for logger >>> (org.apache.jena.riot.stream.JenaIOEnvironment). >>> etc >>> >>> but it also stops configuring the logging from src/test/resources as >>> this is ignored. That confused me for a while :-) >>> >>> I'd guess this was just debugging setup? Also, there is logging to a >>> file, I switched that off as well. >> >> This was kind of intentional, when I was debugging in isolation prior to >> having Jena as a parent I guess the src/test/resources was never >>applicable > >Shall I commit my changes? They switch logging off in the tests for the >things that are expected to log. The exceptions are printed log >messages so they don't them appear - it's not clear looking at the build >job console output that is the case and that they are not real unhandled >exceptions. > >(/me still unclear as to why it removes all the appenders) > >> >>> >>> jena-jdbc-log4j.properties, which is src/main so goes in the final jar >>> but as far as I can see, it's only used in TestMemDriverWithLogging. >> >> This was primarily intended as an example for users, it does also get >>used >> to test that the JDBC connection parameter for logging works correctly >>in >> that test class as noted. > >So leave it in src/main/resources? > >How would the user find it? > >> >>> >>> A question: >>> >>> The POM says aspectj plugin is for debugging purposes. >>> >>> (and how do you get it working with Eclipse? When I add a maven nature >>> I get errors and Eclipse refuses to compile the JDBC projects). >> >> There is an AspectJ Development Tools (AJDT) that you can install which >> provides AspectJ support within Eclipse. AspectJ is used to add method >> entry and exit trace logging which is very useful when trying the >>drivers >> with a new tool to see where (if anywhere) things break. > >Thanks for that. > > Andy > >> >> Rob >> >>> >>> Andy >>> >>> >> >
