lucene-dev mailing list archives

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

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

Uwe Schindler commented on SOLR-3358:
-------------------------------------

Hi,

I strongly agree here with Robert, one thing to add: Maven (sorry) has the notion of "runtime",
"test" and "compile" (and even "test-compile") classpaths, which may all be different. Log4J
is not the only problem that we have on that, since the upgrade to Jetty 8 we have a *serious*
flaw here, too: I just repeat that on every issue because it seems nobody takes care or maybe
nobody understands the problem: The Solr webapp / Solr core should be compatible with a lot
of servlet containers. All on-the-market stable servlet containers are build on servlet-api
2.4 or 2.5. For compiling Solr-webapp, this API is enough and we *must* test and compile *against*
and *only against* servlet-api-2.4 (like we did with Java 5 in LuSolr 3.x). If we then run
tests with Jetty 8, we must of course plug in the Jetty-provided servlet-api (which is 3.0),
but for compile we *must* use the *generic _original_* servlet-api-2.4 interfaces JAR file
from Sun Microsystems (not a Jetty or Tomcat fake).

For compiling Solr *Core*, we should only have the slf4j-api.jar file in classpath, no impls
or delegators! No log4j, no commons-logging. To compile those "extra addons loaded by reflection",
we can use a separate compilation unit only containing the appender/listerners for various
logging systems compiled solely against its own oficially provided JAR file (not e.g. log4j-over-sfl4j.jar,
whcih is a fake like mentioned above).

My proposal:

- We should separate the lib folder to handle compile time-only references and runtime/tests
execution. The runtime classpatch is also packaged into WAR file.
- As Robert suggests: More clear separation into modules, so Solr core does not need jetty/servlet
classes to compile or even run!
- Only use *original* interface JARs on the minimum required version (servlet 2.4), from the
official provider (servlet-api 2.4 from Sun Microsystems, log4j from Apache,...) while _compiling_
(like using Java 5 rt.jar in Lucene 3.x), to ensure compatibility with public APIs.
                
> 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