lucene-dev mailing list archives

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

    [ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256815#comment-13256815
] 

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
complicated.

The issue stumbles upon an existing problem actually: the solr dependencies and compilation
classpaths
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
or 
  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
know 
  what packaging magic makes the solrj-lib in the binary distribution. But whatever it is
probably 
  error-prone (SOLR-3374)
* the webapp/ is confusing to me: if solr core doesn't actually depend on jetty and can even
work
  embedded, then why does it have classes that include/extend jetty/servlet classes? Shouldn't
all
  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'
should
  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
jars
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: https://issues.apache.org/jira/browse/SOLR-3358
>             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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message