Re: generation of SOLR XML
hai, Yes the Xml formats is understood but there is an to generate these xmls from a data source. These XML feild tags doesnot contain the smae start tags and end tags. like field name=catsoftware/field and standerd xml writers have xml generated as the same start and end tags. in SOLR xml start tag = field name=cat end tag = /field can you adivise anything on this please. regards, aditya On 3/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...can any one guide me on this XML generation, which SOLR will accepts for indexing... I'm not sure if I understand your question...the XML documents that Solr accepts for indexing are similar to those found in http://svn.apache.org/viewvc/lucene/solr/trunk/example/exampledocs/ , and must use the field names defined in your schema.xml. -Bertrand
Re: generation of SOLR XML
I understand, i will post it to that group thank you very much aditya On 3/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...Yes the Xml formats is understood but there is an to generate these xmls from a data source. These XML feild tags doesnot contain the smae start tags and end tags. like field name=catsoftware/field and standerd xml writers have xml generated as the same start and end tags IIUC you have something that generates XML like somefieldsomedata/somefield And to index it with Solr you'll need something like field name=somefieldsomedata/field If this is what you mean, it's a basic XML generation problem, not a Solr problem. You'll have to work with your something to either configure it to generate a format that Solr can accept, or insert some transformation in between, using XSLT or a similar tool. -Bertrand P.S. such questions really belong to the solr-user list, not solr-dev
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[
https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478810
]
Frederic Hennequin commented on SOLR-20:
Hello, we have been testing the solr-client and think we have found a small bug
:
the xml parsers on the query-side is not setup to use UTF-8 encoding
this resulted in weird characters being returned by the solr-client...
for example : é came out like © ... not really what we would like...
we fixed it by setting the input stream for the xmlparser to UTF8 which gave
us this code in ResultsParser.java :
[code]
public QueryResults process( InputStream reader ) throws SolrClientException,
SolrServerException, XmlPullParserException, IOException
{
QueryResults res = new QueryResults();
try {
XmlPullParser xpp = null;
try {
xpp = factory.newPullParser();
xpp.setInput(reader,UTF-8);
xpp.nextTag();
}
.
[/code]
notice we changed the argument for this method to InputStream instead of the
reader so we could add UTF-8 to the stream.
by doing this we had to change the reader in SolrClientImpl.java to an
inputstream :
[code]
InputStream inputStream = urlc.getInputStream();
try {
QueryResults res = parser.process( inputStream
);
res.setSolrURL( qurl );
res.setQuery( query );
return res;
}
[/code]
in our opinion this was a major bug (since all solr-xml is encoded in utf-8)
and we guess somebody just forgot to put it in...
yay, now we can all start using freaky characters without the client actually
freaking out :) enjoy
A simple Java client for updating and searching
---
Key: SOLR-20
URL: https://issues.apache.org/jira/browse/SOLR-20
Project: Solr
Issue Type: New Feature
Components: clients - java
Environment: all
Reporter: Darren Erik Vengroff
Priority: Minor
Attachments: DocumentManagerClient.java, DocumentManagerClient.java,
solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar,
solr-client.zip, solr-client.zip, solr-client.zip, SolrClientException.java,
SolrServerException.java
I wrote a simple little client class that can connect to a Solr server and
issue add, delete, commit and optimize commands using Java methods. I'm
posting here for review and comments as suggested by Yonik.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: /update performance testing
the old SolrTest app had some code in it for spinning up multiple threads to hammer Solr with a random entry from dictionary of searches/updates... http://svn.apache.org/viewvc/incubator/solr/trunk/src/apps/SolrTest/?pathrev=480682 ...if Yonik doesn't even remember it, then it might just be better to start from scratch (it was his baby back before i convinced him JUnit was useful) : Date: Tue, 6 Mar 2007 20:44:10 -0500 : From: Yonik Seeley [EMAIL PROTECTED] : Reply-To: solr-dev@lucene.apache.org : To: solr-dev@lucene.apache.org : Subject: Re: /update performance testing : : Nothing that I know of, but I've been considering writing a python : script to hammer Solr with multiple threads to check for concurrency : issues. Something to check for performance would be nice as well. : : -Yonik : : On 3/6/07, Ryan McKinley [EMAIL PROTECTED] wrote: : does anyone have performance testing scripts for /update? : : The three key things i'd like to test are: : : * SOLR-139, i'd like to make sure using the IndexDocumentCommand : (without modifying the existing document) is equivalent to what we : have. : : * /update as servlet vs /update/xml as filter -- *should* be the same : : * most importantly, SOLR-133 - i've been using StAX in a bunch of : custom handlers - its much easier then XPP and purports to be equally : fast. we should make sure. : : Any pointers would be great. : : It would be nice to have a performance test in /trunk that adds a ton : of files and spits back timing info. : : thanks : ryan : : -Hoss
[jira] Commented: (SOLR-188) bin scripts do not support non-default webapp names
[
https://issues.apache.org/jira/browse/SOLR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478827
]
Hoss Man commented on SOLR-188:
---
FWIW: I haven't looked at this patch in depth and my bash fu is weak, but i
definitely like the idea of this new -U param since the work with plugable
update handlers makes it possible to completely redefinte the path for sending
xml updates messages.
bin scripts do not support non-default webapp names
---
Key: SOLR-188
URL: https://issues.apache.org/jira/browse/SOLR-188
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.1.0, 1.2
Environment: Unix/Linux operating systems
Reporter: Jeff Rodenburg
Fix For: 1.1.0, 1.2
Attachments: scripts_url.patch
If the solr web application has been configured in a non-default location,
i.e. http://localhost:8080/solrapp2/, the operation scripts under
http://localhost:8080/solrapp2/bin/ will fail. The current logic assumes the
location to be {hostname}:{port}/solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-81) Add Query Spellchecker functionality
[ https://issues.apache.org/jira/browse/SOLR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478893 ] Hoss Man commented on SOLR-81: -- looking over both Otis's patches and Adam's patches for hte first time i find myself really confused. As previously discussed in email, there are two completley different appraoches that could be taken to achieve spell correction using Solr: 1) Use something like the Lucene SpellChecker contrib to make suggestions basedon the data in the main solr index (defined by the solr schema) ... adding hooks to Solr to keep the SpellChecker system aware of changes to the main index, and hooks to allow requesthandlers to return suggestions with each query 2) use the main solr index (defined by the schema) to store the dictionary of words, turning the entire solr instance into one giant SpellChecker. In this case there would be a recomended schema.xml for users who want to setup a SpellChecker Solr instance and possible a custom RequestHandler htat assumes you are using this schema. These two patches both seem to be dealing with case#1, but they have hints of approach#2 ... for example i don't entirely understand why they include the NGram tokenfilter factories, since they don't seem to need the fields of the solr index to be tokenized in any special way (since the lucene SpellChecker controls the format of it's dictionary). It's also not clear do me what the purpose of the SpellCheckerRequestHandler is ... if the main index is storing real user records, then wouldn't a helper method that existing request handlers (like dismax and standard) can optionally call to get the SpellChecker data be more useful? Add Query Spellchecker functionality Key: SOLR-81 URL: https://issues.apache.org/jira/browse/SOLR-81 Project: Solr Issue Type: New Feature Components: search Reporter: Otis Gospodnetic Priority: Minor Attachments: SOLR-81-edgengram-ngram.patch, SOLR-81-ngram-schema.patch, SOLR-81-ngram.patch, SOLR-81-ngram.patch, SOLR-81-ngram.patch, SOLR-81-ngram.patch, SOLR-81-spellchecker.patch, SOLR-81-spellchecker.patch Use the simple approach of n-gramming outside of Solr and indexing n-gram documents. For example: doc field name=wordlettuce/field field name=start3let/field field name=gram3let ett ttu tuc uce/field field name=end3uce/field field name=start4lett/field field name=gram4lett ettu ttuc tuce/field field name=end4tuce/field /doc See: http://www.mail-archive.com/solr-user@lucene.apache.org/msg01254.html Java clients: SOLR-20 (add delete commit optimize), SOLR-30 (search) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478895
]
J.J. Larrea commented on SOLR-183:
--
Er, sorry to be contrary, but to me it seems a bit excessive to go through so
many hoops to support the getXXX(param, default) methods, which contradicts
the very nature of the class, which is to require parameters.
If one wanted to stick with Hoss' preference for a decorator, and kept the
getXXX(param, default) method signatures defined in SolrParams, one could argue
that it would make sense to make those methods simply return SolrExceptions, on
the assumption that requires.getInt(param, 0) must be a programmer error. That
is of course automatically achieved if only get and getParams are overridden,
as was proposed earlier. It's not so terrible to maintain parallel params and
requires references to the same underlying param list.
But if one is going to bother adding real implementations for every method
signature in SolrParams, then why not simply dispense with the decorator and
add getRequiredXXX(param) methods with default implementations directly to
SolrParams, e.g.
getRequiredParam(String param)
getRequiredParams(String param)
getRequiredBool(String param)
getRequiredFieldBool(String field, String param)
... etc.
That seems simpler, straightforward, and unambiguous.
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478930
]
J.J. Larrea commented on SOLR-183:
--
Modest proposal: If one is going to come up with a programmer-facing mechanism
for required parameters (using any of the abovementioned schemes), why not also
make it configuration-facing as well. That is, in solrparams.xml:
requestHandler name=blah class=solr.DisMaxRequestHandler
lst name=defaults
str name=version2.1/str
int name=rows0/int
...
/lst
lst name=requires
str name=qA query must be specified using the q parameter/str
str name=versionThis handler depends on version being explicitly
set/str
/lst
...
/requestHandler
RequestHandlerBase would add to the definition and initialization of defaults,
extends, and invariants, a fourth SolrParams called requires. Then when the
init is building the (invariants -- ((request -- defaults) + appends))) chain
with DefaultSolrParams and AppendedSolrParams (delegated to method
SolrPluginUtils.setDefaults), it could interpose a new class RequiredSolrParams
which acts like DefaultSolrParams except it accepts the 'requires' SolrParams
defined in the handler config, which in my proposal defines a param
name/message pair. If a param not found in the target SolrParams is defined in
'requires', the exception is thrown. Otherwise the RequiredSolrParams behaves
similarly to DefaultSolrParams (which it extends) by delegating the request up
the chain, or if no chain is defined returning null.
Depending on what the programmer wants, the RequiredSolrParams could be chained
with just the request params:
(invariants - ((requires - request) - defaults) + appends)
or could be chained with the entire chain as it exists:
requires -- (invariants -- ((request -- defaults) + appends)))
I've attached an illustrative implementation. I must apologize, while it
compiles I have not yet tested it, I am under deadline and have spent too much
time on this today already; I'll try to do so over the weekend, along with the
RequestHandlerBase/SolrPluginUtils implementation. It accepts a requires
SolrParams as described above, with the values interpreted as a Formatter
string. It also has an always required mode with a method signature which
accepts a fixed message format string. It also has a convenience method
(temporarily commented out because of method signature clash) which shows how
you can provide custom messages for some parameters but have a stock default
message for others.
I believe this object should be compatible with what Ryan posted, e.g. you
could add implementations for getXXX(param, default) which override the throw
the exception behavior it now has.
Anyway, I am open to feedback. Useful? Excessive? Broken? Stupid?
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.J. Larrea updated SOLR-183:
-
Attachment: RequiredSolrParams.java
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: RequiredSolrParams.java, SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478934
]
Ryan McKinley commented on SOLR-183:
It seems bad to have the requited params be user configurable. The real use
case is that the RequestHandler developer wants to ask for a parameter and know
that the error checking is taken care of.
If the required params are configured externally, you run the risk of them
getting out of sync with the handler code - not to mention that it really isn't
something that should be configured. If misconfigured you get a null pointer
exception rather then 400... defeating the purpose altogether.
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: RequiredSolrParams.java, SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478980
]
J.J. Larrea commented on SOLR-183:
--
By the way, I think your logic to catch type conversion errors and return 400
with a specific error rather than let the request dispatcher return a generic
500, is very useful, but should be implemented directly in SolrParams and then
get inherited by RequiredSolrParams, ServletSolrParams, etc.
The concern of supplied or not is different from the concern of well-formed
or not, and params.getInt( param-returning-notint ) is an error, and should
ALWAYS return a specific and informative exception (code and message) as you
have done, regardless of the underlying SolrParams implementation. Ditto for
params.getInt( param-returning-notint, 999 ).
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: RequiredSolrParams.java, SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
logging - slf4j?
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message formats.
This means you don't have to wrap stuff in if( level = DEBUG ). By
default, the stuff you print out (even toString() ) isn't executed
unless that logging level is set.
logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
Other projects using slf4j include apache wicket and jetty6.
Thoughts?
ryan
[jira] Commented: (SOLR-183) add getRequiredParameter() to SolrParams
[
https://issues.apache.org/jira/browse/SOLR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479175
]
J.J. Larrea commented on SOLR-183:
--
I was unfortunately not very clear, and confounded 2 things, an enhanced
programmer-facing API, based on yours, for request-handler developers, and
secondly an API supported by RequestHandlerBase for request handler
configurators.
From the programmer perspective, my contribution is simply to allow
specification of either a global error format, and/or a parameter-specific
definition of which parameters are required and how missing required
parameters should be reported. It has no negative impact on the use case you
desire, and the modified code should pass all the exists/doesn't exist tests
in your RequiredSolrParamTest.java; if you slapped in your method signatures
that return 400 SolrExceptions on bad type conversion, either into my
RequiredSolrParams or SolrParams as I suggested above, it should pass all the
tests, and if not, I will make it so.
For example,
MapString,String rmap = new HashMapString, String();
rmap.put( q , A query must be specified using the q parameter );
rmap.put( version , This handler depends on version being explicitly
set );
SolrParams required = new RequiredSolrParams( params, new MapSolrParams(
rmap ) );
This is similar to the suggestion in Hoss' first comment on this issue.
The other use-case is for the RequestHandler configurator. There are a lot
more of those than RequestHandler programmers. My model is that they are
defining request handling service APIs by defining requestHandlers in
solrconfig. Those APIs can be used by other web programmers in the
organization, who will make mistakes in calling the API, as we all do.
RequestHandlerBase gives RequestHandler configurators three options for
controlling the API, the invariants defaults and appends. I am simply
proposing a 4th option to define which parameters are required, and the error
message that should be returned in the case it is missing. It's not a
comprehensive parameter validation mechanism, but such would be beyond the
scope of SOLR. However as someone who is actively creating RequestHandler APIs
for other programmers in my organization, using custom code when necessary but
avoiding it whenever possible, I think it might be useful.
And in no way does this second use-case by itself allow RH configurators to
override the first use-case requirements set up by RH programmers, unless the
RH programmers make explicit provision to do so. For example, by chaining a
DefaultSolrParams with params derived from a requestHandler requires list in
front of a default MapSolrParams like the above, the RH programmer allows the
RH configurator to add new requirements, and externally change the error
strings for programmer-supplied requirements, but not to remove
programmer-supplied requirements.
Anyway, hopefully I've better communicated the idea this time.
add getRequiredParameter() to SolrParams
Key: SOLR-183
URL: https://issues.apache.org/jira/browse/SOLR-183
Project: Solr
Issue Type: Wish
Reporter: Ryan McKinley
Priority: Trivial
Attachments: RequiredSolrParams.java, SOLR-183-required-param.patch,
SOLR-183-required-param.patch
I find myself including this with every patch, so i'll just separate it out.
This simply adds a utilty function to SolrParams that throws a 400 if the
parameter is missing:
/** returns the value of the param, or throws a 400 exception if missing */
public String getRequiredParameter(String param) throws SolrException {
String val = get(param);
if( val == null ) {
throw new SolrException( 400, Missing parameter: +param );
}
return val;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: logging - slf4j?
On 3/7/07, Ryan McKinley [EMAIL PROTECTED] wrote:
Is there any interest in using slf4j (http://www.slf4j.org/) rather
then forcing folks to use JDK logging?
The nice thing about slf4j is that user can easily switch the logger
implementation. The other nice thing is its use of message formats.
This means you don't have to wrap stuff in if( level = DEBUG ). By
default, the stuff you print out (even toString() ) isn't executed
unless that logging level is set.
logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
Well, it isn't quite that simple: entry.somethingThatTakesSomeTime()
will be executed in the example you provide. From what I've gleaned
by glancing at the site, it appears to be necessary to hide the calls
in the toString method of some object to delay the execution. Too bad
this isn't python or lisp ;).
I'm not particularly enmeshed in the enterprise java philosophy, but
ISTM that this type of choice matters more for frameworks and
containers than stand-alone products like Solr. I'm also loathe to
introduce dependencies unless there is a clear need.
OTOH, I'm certainly not against it if people have used it and found a
clear benefit that they believe will carry over to Solr.
-Mike
Re: logging - slf4j?
Well, it isn't quite that simple: entry.somethingThatTakesSomeTime()
will be executed in the example you provide. From what I've gleaned
by glancing at the site, it appears to be necessary to hide the calls
in the toString method of some object to delay the execution. Too bad
this isn't python or lisp ;).
sorry, bad example - it is only the toString() bit that is better. from:
http://www.slf4j.org/faq.html#logging_performance
The following two lines will yield the exact same output. However,
the second form will outperform the first form by a factor of at least
30, in case of a disabled logging statement.
logger.debug(The new entry is +entry+.);
logger.debug(The new entry is {}., entry);
I'm not particularly enmeshed in the enterprise java philosophy, but
ISTM that this type of choice matters more for frameworks and
containers than stand-alone products like Solr.
But i am using solr as a framework - not a stand alone product! The
RequestHandler / ResponseWriter framework is a great framework on its
own.
Solr is not just the .war, it is also the .jar :)
OTOH, I'm certainly not against it if people have used it and found a
clear benefit that they believe will carry over to Solr.
For me, the immediate benefit is that i could have one logging setup
rather then two. I'm integrating solr with an existing log4j based
system. I have some existing logging code I'd love to use with solr
rather then re-write a JDK logging version (SOLR-178 and other stuff)
Re: logging - slf4j?
: Is there any interest in using slf4j (http://www.slf4j.org/) rather
: then forcing folks to use JDK logging?
i'd really rather now .. JDK logging is universal (at least in all JDK
versions Solr supports) and while i have no problem adding dependencies
to SOlr if they allow for really great features, adding a dependency just
for differnet logging doesn't make sense to me.
: The nice thing about slf4j is that user can easily switch the logger
I've seen this argument against JDK logging before .. but frankly i've
never understood it -- JDK Logging is one of the few places where the JDK
really goes above and beyond to give the user hooks for controlling things
-- not just with configuration, but even with the underlying
implementation (via the java.util.logging.manager system property) if
someone doesn't like the implementation that comes with their JVM, they
can happily load in a differnet one at runtime.
: implementation. The other nice thing is its use of message formats.
: This means you don't have to wrap stuff in if( level = DEBUG ). By
: default, the stuff you print out (even toString() ) isn't executed
: unless that logging level is set.
:
: logger.debug(value: {}., entry.somethingThatTakesSomeTime() );
knowing that you really ment...
logger.debug(value: {}., entry );
...(refering to the delayed toString()ing only if the debug level
neccessitates it) this doesn't seem like a very compelling reason, since
JDK logging already supports that (via java.text.MessageFormat)
logger.log(Level.DEBUG, value: {0}., entry );
...granted, JDK logging doesn't provide the handy method alias in the case
where you want a paramterized message, but in cases where you are
concerned about the performance of toStringing an object, it's not asking
so much to use log(Level.DEBUG, ...) instead of debug(...)
-Hoss
Re: logging - slf4j?
On 3/7/07, Chris Hostetter [EMAIL PROTECTED] wrote: : Is there any interest in using slf4j (http://www.slf4j.org/) rather : then forcing folks to use JDK logging? i'd really rather now .. JDK logging is universal (at least in all JDK versions Solr supports) and while i have no problem adding dependencies to SOlr if they allow for really great features, adding a dependency just for differnet logging doesn't make sense to me. ok - i was just asking to see how you all feel about it. If I'm the only one who would like it, its obviously not worth changing. where you want a paramterized message, but in cases where you are concerned about the performance of toStringing an object, it's not asking so much to use log(Level.DEBUG, ...) instead of debug(...) damn! I was hoping an esoteric performance argument (that i don't particularly care about) would woo you!
