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 19:32:39 GMT


Robert Muir commented on SOLR-3358:

Well for one the current structure is really unrelated to maven. When Steve Rowe and I
first started working on the build, there were other things to fix (core tests depended on
contribs, etc).

So i think its improving, I'm not trying to complain: if we could have fixed this stuff
safely when transitioning to ivy, we would have. I feel like Chris Male and I spent an entire
night trying to figure out the best approach: populating the huge lib/ folder just like before
simple kept the issue scope contained.

Just a few notes about this:
# we don't really need to be downloading jars and putting them in lib/ at all (LUCENE-3943).
  what we have now is a 'transition mechanism' that works like the old build, but we should
  really fix this: then people wont have issues with things like having stale jars or anything
  else: and we avoid copying around or whatever. Still lets put this aside, we can still improve
  things right now (see below)
# i agree with your suggestions, though i think we actually have jetty-test classes in test-framework?
  so i think it should be solrj/lib, core/lib, test-framework/lib, etc (don't try to tackle
the lib-test
  initially, i think we should attack 'separation' first).
# after accomplishing #2 above, we can then start to think about alternative configurations,
  and whether or not we even want to try to do that before fixing #1. Fixing #1 would make
this task
  much simpler and cleaner. i don't think we should have a separate lib/ with jetty7 and example
with jetty8,
  because i think we would ultimately want the flexibility to be able to run both core and
example tests with
  any of (jetty6, jetty7, jetty8, tomcat-xx, ...), and this could be specified with a -D or
  Perhaps the defaults are set to something like you suggest, but hudson could test other

> 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