Re: Solr Logging
Thomas, I don't understand why you say that JDK Logging is only on JVM
level. You can have as many different log files as you have Solr instances.
All you need to do it to put a logging properties inside Solr's
web-inf/classes. For example:
# Global Default logging behavior
handlers= org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
.level=INFO
# File Handler specific behavior
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = myapp1.
org.apache.juli.FileHandler.formatter = java.util.logging.SimpleFormatter
This will make logging from the webapp goto a log starting with myapp1. You
can add these properties to each solr instance you run and you'll get a log
file for each instance.
Some people have talked about emails and notifications. IMHO, those features
don't really belong in a core logging library and are best handled through
tools like logcheck ( http://logcheck.org/ ).
Let's try to enumerate the use-cases that would require Solr to move to a
different logging framework and agree on how commonly those use-cases come
up.
I would like Solr to continue to respect and use the container/JVM's logging
configuration without having to make any manual changes.
On Wed, Apr 23, 2008 at 12:12 PM, Thomas Peuss [EMAIL PROTECTED] wrote:
Erik Hatcher wrote:
I'm also opposed (sorry Grant) to tossing in a 3rd party library for
logging when the built-in logging facility is sufficient, configurable, and
adaptable already.
I must say I never liked JDK logging because it feels like a step back
when you are used to log4j.
So from my perspective:
* Solr is a software you mostly run on servers. So log rotation and
sending emails on errors is a must. Nothing of that is provided by the JDK
logging implementation (or does not work correctly as someone else has
stated).
* JDK logging configuration is only on JVM level. When you use many Solr
instances in one JVM (we have one per customer) and want several different
log destinations that is not possible. I want logs per customer - that is
currently not possible.
I would like to see SL4J based logging in Solr. commons-logging is no
alternative. It is meant for libraries because commons-logging does not
attempt to initialize or terminate the underlying logging implementation
that is used at runtime; that is the responsibility of the application.
CU
Thomas
--
Regards,
Shalin Shekhar Mangar.
[jira] Updated: (SOLR-380) There's no way to convert search results into page-level hits of a structured document.
[ https://issues.apache.org/jira/browse/SOLR-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tricia Williams updated SOLR-380: - Attachment: (was: lucene-core-2.3-dev.jar) There's no way to convert search results into page-level hits of a structured document. - Key: SOLR-380 URL: https://issues.apache.org/jira/browse/SOLR-380 Project: Solr Issue Type: New Feature Components: search Reporter: Tricia Williams Priority: Minor Attachments: SOLR-380-XmlPayload.patch, SOLR-380-XmlPayload.patch Paged-Text FieldType for Solr A chance to dig into the guts of Solr. The problem: If we index a monograph in Solr, there's no way to convert search results into page-level hits. The solution: have a paged-text fieldtype which keeps track of page divisions as it indexes, and reports page-level hits in the search results. The input would contain page milestones: page id=234/. As Solr processed the tokens (using its standard tokenizers and filters), it would concurrently build a structural map of the item, indicating which term position marked the beginning of which page: page id=234 firstterm=14324/. This map would be stored in an unindexed field in some efficient format. At search time, Solr would retrieve term positions for all hits that are returned in the current request, and use the stored map to determine page ids for each term position. The results would imitate the results for highlighting, something like: lst name=pages nbsp;nbsp;lst name=doc1 nbsp;nbsp;nbsp;nbsp;int name=pageid234/int nbsp;nbsp;nbsp;nbsp;int name=pageid236/int nbsp;nbsp;/lst nbsp;nbsp;lst name=doc2 nbsp;nbsp;nbsp;nbsp;int name=pageid19/int nbsp;nbsp;/lst /lst lst name=hitpos nbsp;nbsp;lst name=doc1 nbsp;nbsp;nbsp;nbsp;lst name=234 nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;int name=pos14325/int nbsp;nbsp;nbsp;nbsp;/lst nbsp;nbsp;/lst nbsp;nbsp;... /lst -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-549) Enable configurable logging (jul or log4j)
Enable configurable logging (jul or log4j) -- Key: SOLR-549 URL: https://issues.apache.org/jira/browse/SOLR-549 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Henri Biestro java.util.logging does not allow to easily create a self-sufficient 'war' with respect to logging configuration. The java.util.logging.LogManager used by the application is always created by the container and is thus only configurable through the container; furthermore, if one already uses say log4j in a webapp that embeds Solr, it does not even seem possible to re-route jul logging into log4j just by configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-549) Enable configurable logging (jul or log4j)
[ https://issues.apache.org/jira/browse/SOLR-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591672#action_12591672 ] Ryan McKinley commented on SOLR-549: This solves the how do I use log4j in solr problem, but I think it sends solr down the wrong path. I really don't think we want to deal with configuring the logging internally. That is what the logging frameworks are supposed to do for us! Rather then taking this approach, I think we should just use SLF4J (http://www.slf4j.org/), it does what this patch does, but it is supported elsewhere and has more options ;) Enable configurable logging (jul or log4j) -- Key: SOLR-549 URL: https://issues.apache.org/jira/browse/SOLR-549 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Henri Biestro Attachments: solr-log4j.patch java.util.logging does not allow to easily create a self-sufficient 'war' with respect to logging configuration. The java.util.logging.LogManager used by the application is always created by the container and is thus only configurable through the container; furthermore, if one already uses say log4j in a webapp that embeds Solr, it does not even seem possible to re-route jul logging into log4j just by configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-380) There's no way to convert search results into page-level hits of a structured document.
[
https://issues.apache.org/jira/browse/SOLR-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591897#action_12591897
]
Erik Hatcher commented on SOLR-380:
---
{quote}Cool?{quote}
Very! Wow Tricia - thanks for documenting that so thoroughly. This
particular feature is sure to be of great interest to many.
There's no way to convert search results into page-level hits of a
structured document.
-
Key: SOLR-380
URL: https://issues.apache.org/jira/browse/SOLR-380
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Tricia Williams
Priority: Minor
Attachments: SOLR-380-XmlPayload.patch, SOLR-380-XmlPayload.patch,
xmlpayload-example.zip, xmlpayload-src.jar, xmlpayload.jar
Paged-Text FieldType for Solr
A chance to dig into the guts of Solr. The problem: If we index a monograph
in Solr, there's no way to convert search results into page-level hits. The
solution: have a paged-text fieldtype which keeps track of page divisions
as it indexes, and reports page-level hits in the search results.
The input would contain page milestones: page id=234/. As Solr processed
the tokens (using its standard tokenizers and filters), it would concurrently
build a structural map of the item, indicating which term position marked the
beginning of which page: page id=234 firstterm=14324/. This map would
be stored in an unindexed field in some efficient format.
At search time, Solr would retrieve term positions for all hits that are
returned in the current request, and use the stored map to determine page ids
for each term position. The results would imitate the results for
highlighting, something like:
lst name=pages
nbsp;nbsp;lst name=doc1
nbsp;nbsp;nbsp;nbsp;int name=pageid234/int
nbsp;nbsp;nbsp;nbsp;int name=pageid236/int
nbsp;nbsp;/lst
nbsp;nbsp;lst name=doc2
nbsp;nbsp;nbsp;nbsp;int name=pageid19/int
nbsp;nbsp;/lst
/lst
lst name=hitpos
nbsp;nbsp;lst name=doc1
nbsp;nbsp;nbsp;nbsp;lst name=234
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;int
name=pos14325/int
nbsp;nbsp;nbsp;nbsp;/lst
nbsp;nbsp;/lst
nbsp;nbsp;...
/lst
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
