|
[
Permlink
| « Hide
]
Sami Siren added a comment - 21/Oct/06 03:25 AM
Havent checked how admin GUI is constructed but if there is a cleanAPIi it might be easier to use something like hessian http://www.caucho.com/hessian/
 instead of hacking the jsps to emit xml and writing a custom client. Once the admin components emit XML, The XSLT transformation code written for
I went to the original thread where I started discussion about exposing some admin functionality as XML, http://www.mail-archive.com/solr-user@lucene.apache.org/msg01012.html
and realized Yonik had pointed out that the 'stats'(.jsp) page already spits out XML and has the XSL that transforms it to HTML: http://www.mail-archive.com/solr-user@lucene.apache.org/msg01074.html
The same with 'registry.jsp' - it's really XML + XSL. Is there anything else that I could expose as XML? $ ls -1 src/webapp/resources/admin/*jsp Here is what I think could still be XMLized:
Everything else in src/webapp/resources/admin/ is either an image or a helper JSP. Thoughts? ping.jsp does not retrun any content. It checks the solr server by sending the query defined in SolrConfig.xml (pingQuery) and returns 200 if the query works without any exception. Otherwise it returns 500.
action.jsp is a secondary JSP that performs action from the main page (enable/disable) and the logging page (set log level). So I agree that there is probably no need to XMLized it. I took a stab at analysis page, and it turned out it lends itself to XMLization. I'm attaching two files:
1) analysis XML output 2) analysis-xml.jsp - the JSP that replaces the output portion of analysis.jsp (if this looks good, then I'll just change the FORM action in analysis.jsp to point to analysis-xml.jsp and somebody familiar with XSL could provide that piece) Please comment. These are my targets for XMLization, and I'm going to work on them next. ANALYSIS (this attachment) Ping was simple, I just made it return <solr><status="200"/></solr> if ping was OK (attached), and if there was an error, then:
<solr> Thoughts? N.B. Here is threaddump-xml.jsp and the example of its output.
Here is the XML version of logging.jsp, named logging-xml.jsp.
Its output is trivial: <solr> I imagine the XSL would take this XML, convert it to HTML, and append the HTML with links to action.jsp with different logging levels. 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"> ...or if verbose is off... <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) This may be slightly OT for this issue, but since the ticket discusses XSLT in the browser, and the Self Service wiki page, I though to put up for comments a quick and dirty XSLT-based schema browser I made. It transforms schema.xml into a single page tree view, so you can inspect fields and types, with some cross referencing between fieldtypes and fields, and field copyField source/dests. I have only tried it against Firefox 2 and IE7, but it should work in all browsers with an XSLT engine, or, failing that, it could be done server-side, and the resulting HTML sent to the browser.
Unzipping and opening schema.xml in a browser is enough to see it, but it will be missing some styles and images referenced in the admin webapp. To use it in a solr webapp against your own schema, you have to: a) place schema.xml and the gifs in the /admin/ directory c) modify get-file.jsp to set a content type of text/xml, and not to emit any whitespace I have only tried it with my prototype small-scale schemas, but, if it works for people with larger schemas, and fits in with the "Self Service" aims, I could take suggestions, clean up the xsl, and submit the a-b-c changes above as a patch. The XML is being written (in the few attachments I sampled) as out.println() style. This has several drawbacks: 1) what about XML escaping/encoding issues? 2) What about clients that want JSON, Ruby, or some other format from a response writer? I strongly feel that the admin capability should work just like the front-end search capability, using a response writer for its output, not out.println's, making this much more flexible in the future. Refactoring so there is no difference between the front and "admin" sides would really make Solr shine!
 Hoss, thanks for the comments.
0) I have yet to find out - I haven't started writing that yet. Erik: Hoss, regarding your point 7) about ping - makes sense. I think this is what Walter Underwood was talking about in a recent thread, too. So what should the ping response look like in case of success and in case of error?
Is this ok? <solr> Sorry, forgot to add that, in addition to the above 200/500/error stuff, I'd change the HTTP response to 500 in case of error, and stick to 200 in case of success.
Here are the new outputs for:
Analysis Thread dump Ping All other outputs remain the same as before. Does this look ok? And here are the 3 JSPs that created those outputs.
They now do XML character escaping. If this (and other attachments from a few weeks back) looks good, I'll move onto XSLT. Greg: schemaxsl stuff looks fancy, but it doesn't really belong to this issue. I suggest you take it out and put it into a new JIRA issue, where it will get more visibility and attention than it's getting here.
Updated ping-xml.jsp + ping.xsl
I took the simplest XML output to transform to XSL, as I've never touched XSL before. Please comment if anything there doesn't look right or could be done better. I removed that <status> element from ping XML output, and tested this in the JSP: out.println("<error>"); Unfortunately, this results ina generic 500 Error from Jetty, without this XML in the output. Does anyone know how to get around this? logging.xsl + slightly modified ping.xsl
analysis-xml.jsp - the converted analysis.jsp that output XML
analysis-xml-out.txt - the XML output by the new version analysis.xsl - XSLT to transform the XML back to HTML threaddump-xml.jsp - the converted threaddump.jsp that outputs XML
threaddump-xml-out.txt - sample XML output of the new version threaddump.xsl - XSLT to transform the XML back to HTML Here is the patch with modified JSPs + XSLs.
I know there are a few small things missing:
The above omissions can easily be re-added, but let's see the review of the existing changes first. Yeah, some of those little things are really helpful when debugging.
For instance, hostname can be important when going through a load-balancer to know exactly what host you are hitting. Yeah, I'll make sure to put those back, but that's the easy part, whereas this XSL was new for me, so I want to make sure everything else looks okay first.
The new version with hostname:port, cwd, solrHome, and the collection name restored.
I'll commit tomorrow, when I'm less zombied out. Committed. Please reopen if there are issues or additional fixes are needed.
If this isn't an easy/quick fix, perhaps we could roll back just analysis.jsp so we can continue with release 1.1?
I'll resolve this as Fixed, even though it should be resolved as "No longer relevant", since I believe Ryan has changed or will change all admin stuff to work with handlers/writers....or at least that's what I recall reading.
This bug was modified as part of a bulk update using the criteria...
The Fix Version for all 38 issues found was set to 1.1, email notification For a list of all the issues modified, search jira comments for this |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Resolved
Minor
Change Admin components to return XML like the rest of the system
