lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
Date Wed, 18 Apr 2012 18:50:40 GMT


Robert Muir commented on SOLR-3358:

I'm gonna dodge your question about 'do we support logging framework X' because i don't really
care about logging, i just piped up because i care about the build or release packaging being

The issue stumbles upon an existing problem actually: the solr dependencies and compilation
are already quite confusing:

* solr tests suck in huge classpaths from solr/lib and example/lib and other places: not really
  testing the 'desired classpath'. For example, nobody wants solrj to depend on lucene-core
  lucene-spellchecker, but i can easily add new SpellChecker() to solrj java files and all
tests pass.
* the lack of separation (e.g core/lib and solrj/lib), makes packaging a mystery: i dont even
  what packaging magic makes the solrj-lib in the binary distribution. But whatever it is
  error-prone (SOLR-3374)
* the webapp/ is confusing to me: if solr core doesn't actually depend on jetty and can even
  embedded, then why does it have classes that include/extend jetty/servlet classes? Shouldn't
  this stuff be in webapp/ to cleanly separate it out?
* the example/ in my opinion should also be treated as another 'module' and the 'example tests'
  sit underneath it. I think its confusing how other tests reach around to the example.

I think these are generally unrelated to your patch: but trying to do what you want with logging
just puts it over the edge in complexity.

If things like alternative logging frameworks and servlet containers are actually intended
to be supported,
then shouldn't we:
# fix all these classpaths to be per-module, enforcing that our dependencies are what we think
they are,
  and that we package up what we think we are packaging up.
# add things like alternative ivy configurations to allow us to test these different implementations

 (e.g. log4j, tomcat, etc) at least in hudson via -D switches, otherwise how do we know they
actually work 
  without manual testing?

> Capture Logging Events from JUL and Log4j
> -----------------------------------------
>                 Key: SOLR-3358
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Ryan McKinley
>            Assignee: Ryan McKinley
>         Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch
> The UI should be able to show the last few log messages.  To support this, we will need
to register an Appender (log4j) or Handler
> (JUL) and keep a buffer of recent log events.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message