You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Mike Travers (JIRA)" <ji...@apache.org> on 2007/12/19 19:39:43 UTC

[jira] Created: (SOLR-441) example app comes up with some bad links

example app comes up with some bad links
----------------------------------------

                 Key: SOLR-441
                 URL: https://issues.apache.org/jira/browse/SOLR-441
             Project: Solr
          Issue Type: Bug
         Environment: Mac OSX, java version "1.5.0_13", Firefox
            Reporter: Mike Travers
            Priority: Minor


The solr example comes up with bad links on the admin page.  They contain ?core=null, which results in an error when they are clicked.  Removing the "core=null" from the URLs makes it work OK.

This is mostly an annoyance, spoiling what would otherwise be a very slick out-of-the-box experience.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Mike Klaas <mi...@gmail.com>.
On 28-Dec-07, at 7:31 AM, Ryan McKinley wrote:

> Mike Klaas wrote:
>>
>> Looks great, thanks.  I haven't really followed the multicore  
>> discussion very closely (so ignore this if it doesn't compute),  
>> but might it make sense for the core-specific log object to  
>> automatically prepend the corename to the log message (cursorily,  
>> it looks like current it is necessary for each logging call to  
>> prepend the corename (.getLogId()) if the log message is to be  
>> core-specific)?
>
> Sounds like a good idea, but how would you do it?
>
> Right now it calls log.info( logId + "message..." ) everywhere.  Is  
> there a way to change the underlying log format for each core?   
> (log is currently a static Logger log = Logger.getLogger(...);

I'm not too familiar with jdk logging, but I think that it should be  
possible to assign each SolrCore its own Logger (using getLogger 
(<classname> +'.'+ <corename)), then modifying the config of the  
logger (this might be useful for other reasons too, such as making  
each core's logfile output to a different file).  The simplest  
configuration might be to assign a custom java.util.logging.Formatter  
which calls .setMessage() on the LogRecord to prepend the corename  
before passing to the SimpleFormatter superclass.

The world of java logging and associated configuration is a bit of a  
sordid beast, so I'm not sure if this is kosher with all the possible  
custom configurations and such.

-Mike

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Ryan McKinley <ry...@gmail.com>.
Mike Klaas wrote:
> On 27-Dec-07, at 5:26 PM, Ryan McKinley wrote:
> 
>>
>>> Seems like that would be the best solution.  Me (and, I think, many 
>>> others), would be unlikely to used the multiple core functionality of 
>>> Solr at all.  Avoiding lengthening the log messages in this case 
>>> would be nice.
>>
>> check rev 607151 -- this removes the "[name] " bit for things where 
>> the name is null
> 
> Looks great, thanks.  I haven't really followed the multicore discussion 
> very closely (so ignore this if it doesn't compute), but might it make 
> sense for the core-specific log object to automatically prepend the 
> corename to the log message (cursorily, it looks like current it is 
> necessary for each logging call to prepend the corename (.getLogId()) if 
> the log message is to be core-specific)?
> 

Sounds like a good idea, but how would you do it?

Right now it calls log.info( logId + "message..." ) everywhere.  Is 
there a way to change the underlying log format for each core?  (log is 
currently a static Logger log = Logger.getLogger(...);

ryan

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Mike Klaas <mi...@gmail.com>.
On 27-Dec-07, at 5:26 PM, Ryan McKinley wrote:

>
>> Seems like that would be the best solution.  Me (and, I think,  
>> many others), would be unlikely to used the multiple core  
>> functionality of Solr at all.  Avoiding lengthening the log  
>> messages in this case would be nice.
>
> check rev 607151 -- this removes the "[name] " bit for things where  
> the name is null

Looks great, thanks.  I haven't really followed the multicore  
discussion very closely (so ignore this if it doesn't compute), but  
might it make sense for the core-specific log object to automatically  
prepend the corename to the log message (cursorily, it looks like  
current it is necessary for each logging call to prepend the corename  
(.getLogId()) if the log message is to be core-specific)?

-Mike

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Ryan McKinley <ry...@gmail.com>.
> 
> Seems like that would be the best solution.  Me (and, I think, many 
> others), would be unlikely to used the multiple core functionality of 
> Solr at all.  Avoiding lengthening the log messages in this case would 
> be nice.
> 

check rev 607151 -- this removes the "[name] " bit for things where the 
name is null

ryan

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Mike Klaas <mi...@gmail.com>.
On 27-Dec-07, at 1:00 PM, Ryan McKinley wrote:

>
>> INFO: [null] /select
>
> I just committed something that changes the default behavior to  
> "[core]"

Thanks!

>> Perhaps we should omit the [<corename>] if it is null?
>
> an early patch had that, but it seems a bit silly to have every log  
> message check for a valid core name.  Right now it does:
>
>   log.warning("["+name+"] "+ msg);
>
> maybe their could be be a
>  logID = (name==null)?"": ("["+name+"] ");
>
> then we could have:
>
>   log.warning( logID + msg);
>

Seems like that would be the best solution.  Me (and, I think, many  
others), would be unlikely to used the multiple core functionality of  
Solr at all.  Avoiding lengthening the log messages in this case  
would be nice.

cheers,
-Mike

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Ryan McKinley <ry...@gmail.com>.
> INFO: [null] /select 

I just committed something that changes the default behavior to "[core]"

> 
> Perhaps we should omit the [<corename>] if it is null?
> 

an early patch had that, but it seems a bit silly to have every log 
message check for a valid core name.  Right now it does:

   log.warning("["+name+"] "+ msg);

maybe their could be be a
  logID = (name==null)?"": ("["+name+"] ");

then we could have:

   log.warning( logID + msg);


thoughts?
ryan

Re: [jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by Mike Klaas <mi...@gmail.com>.
Related issue:  on the example, the default core name is null, and  
creates odd-looking log messages:

NFO: [null] /update  0 202
Dec 27, 2007 11:13:12 AM org.apache.solr.core.SolrCore execute
INFO: [null] /select/ indent=on&start=0&q=solr&version=2.2&rows=10 0 65
Dec 27, 2007 11:13:23 AM org.apache.solr.core.SolrCore execute
INFO: [null] /select  
explainOther=&fl=*,score&indent=on&start=0&q=solr&hl.fl=&qt=standard&wt= 
standard&hl=on&version=2.2&rows=10 0 3
Dec 27, 2007 11:13:35 AM org.apache.solr.core.SolrCore execute
INFO: [null] /select  
explainOther=&fl=*,score&indent=on&start=0&q=solr&hl.fl= 
+&qt=standard&wt=standard&hl=on&version=2.2&rows=10 0 1

Perhaps we should omit the [<corename>] if it is null?

-Mike

On 21-Dec-07, at 2:40 PM, Ryan McKinley (JIRA) wrote:

>
>      [ https://issues.apache.org/jira/browse/SOLR-441? 
> page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Ryan McKinley resolved SOLR-441.
> --------------------------------
>
>        Resolution: Fixed
>     Fix Version/s: 1.3
>          Assignee: Ryan McKinley
>
>> example app comes up with some bad links
>> ----------------------------------------
>>
>>                 Key: SOLR-441
>>                 URL: https://issues.apache.org/jira/browse/SOLR-441
>>             Project: Solr
>>          Issue Type: Bug
>>         Environment: Mac OSX, java version "1.5.0_13", Firefox
>>            Reporter: Mike Travers
>>            Assignee: Ryan McKinley
>>            Priority: Minor
>>             Fix For: 1.3
>>
>>
>> The solr example comes up with bad links on the admin page.  They  
>> contain ?core=null, which results in an error when they are  
>> clicked.  Removing the "core=null" from the URLs makes it work OK.
>> This is mostly an annoyance, spoiling what would otherwise be a  
>> very slick out-of-the-box experience.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>


[jira] Resolved: (SOLR-441) example app comes up with some bad links

Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SOLR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan McKinley resolved SOLR-441.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 1.3
         Assignee: Ryan McKinley

> example app comes up with some bad links
> ----------------------------------------
>
>                 Key: SOLR-441
>                 URL: https://issues.apache.org/jira/browse/SOLR-441
>             Project: Solr
>          Issue Type: Bug
>         Environment: Mac OSX, java version "1.5.0_13", Firefox
>            Reporter: Mike Travers
>            Assignee: Ryan McKinley
>            Priority: Minor
>             Fix For: 1.3
>
>
> The solr example comes up with bad links on the admin page.  They contain ?core=null, which results in an error when they are clicked.  Removing the "core=null" from the URLs makes it work OK.
> This is mostly an annoyance, spoiling what would otherwise be a very slick out-of-the-box experience.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.