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