[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
