lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-58) Change Admin components to return XML like the rest of the system
Date Thu, 09 Nov 2006 19:48:37 GMT
    [ http://issues.apache.org/jira/browse/SOLR-58?page=comments#action_12448568 ] 
            
Hoss Man commented on SOLR-58:
------------------------------

A few comments/questions in no particular order...

0) in general, i've found it's difficult to know how hard some XML will be to style, untill
you've tried styling it :(

1) the assumption is that these will include xsl-stylesheet headers list stats/registry do
right now and let teh browser apply them right?

2) Within the outermost <solr> tag, it would probably be good to have another wrapper
tag specific to each of the pages .. it might make reusing a single (or a small number of)
XSL file(s) for multiple pages easier.

3) I think for analysis.jsp you're going to want a <form> block containing info about
the options used and a <results> block containing what you've got right now ... otherwise
it's going to be hard for an XSLT to recreate the form with the current state filled in (as
i recall: there are ways of getting the URI of the current document in XSLT, and parsing out
it's query params, but they have issues ... and they don't work if someone attempts to save
the file locally to review later)

4) it would probably make more sense to group the <token>s as children of the <factorry>s
when verbose is turned on ... acctaully it would probably make sense to group them under the
<factory> even if verbose isn't on....

5) as long as we are outputing structured XML, we should render the factory.getArgs() as individual
key/val pairs instead of just a string, maybe something like...

<factory class="org.apache.solr.analysis.WordDelimiterFilterFactory">
   <args>
      <arg name="catenateWords">1</arg>
      <arg name="catenateNumbers">1</arg>
   </args>
  <tokens>
     <token type="word" pos="1" start="0" end="6">Search</token>
     <token type="word" pos="2" start="7" end="12">Stuff</token>
     <token type="word" pos="2" start="0" end="12">SearchStuff</token
  </tokens>
</factory>

...or if verbose is off...

<factory>
  <tokens>
     <token type="word" pos="1" start="0" end="6">Search</token>
     <token type="word" pos="2" start="7" end="12">Stuff</token>
     <token type="word" pos="2" start="0" end="12">SearchStuff</token
  </tokens>
</factory>

6) converting action.jsp to XML might actually make sense if you want to programatically hit
it to change the logging level and test that the operation succeeded (right now you'd have
to parse the HTML)

7) ping's utilitiy for monitoring systems like nagios and load balancers is that it's trivial
to check if the port is functioning just by checking the HTTP status code (where the definition
of functioning is defined by a query in the solrconfig) ... it *must* have a genuine HTTP
status code != 200 if there is a failure, returning an HTTP status code of 200 with a response
body that says <status="500">...</status> just makes everything more complicated.

...either it shouldn't be converted, or it should manually set the reponse status to 500 before
outputing the XML representation of the exception  (incidently: it will need to be XML escaped
too)



> Change Admin components to return XML like the rest of the system
> -----------------------------------------------------------------
>
>                 Key: SOLR-58
>                 URL: http://issues.apache.org/jira/browse/SOLR-58
>             Project: Solr
>          Issue Type: New Feature
>          Components: web gui
>            Reporter: Otis Gospodnetic
>         Assigned To: Otis Gospodnetic
>            Priority: Minor
>         Attachments: analysis-xml-out.txt, analysis-xml.jsp, logging-xml.jsp, ping-xml-out.txt,
ping-xml.jsp, threaddump-xml-out.txt, threaddump-xml.jsp
>
>
> I need to expose the admin functionality to an external application.  I think returning
admin data as XML may be a good and simple first step towards that.
> To do that I think I'll mostly need to modify JSPs (but I haven't had a good look at
Admin GUI yet).  From what I saw a few weeks ago when I briefly looked at this, no Java code
will need to be modified.  If you have concrete ideas about how this should be done, please
comment before I start next week (week of October 23rd 2006).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message