[jira] Commented: (SOLR-75) XSLT-based Schema Browser in admin view
[ http://issues.apache.org/jira/browse/SOLR-75?page=comments#action_12456316 ] Bertrand Delacretaz commented on SOLR-75: - The tango icons (http://tango.freedesktop.org) could be used I think. As mentioned at the bottom of http://tango.freedesktop.org/Tango_Desktop_Project, they are licensed under the Creative Commons Attribution Share-Alike license, which I think is acceptable for us to redistribute (although there is no black/white policy on this yet at the ASF, see [1] and [2]). [1] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200610.mbox/[EMAIL PROTECTED] [2] http://www.apache.org/legal/3party.html XSLT-based Schema Browser in admin view - Key: SOLR-75 URL: http://issues.apache.org/jira/browse/SOLR-75 Project: Solr Issue Type: New Feature Components: web gui Environment: any Reporter: Greg Ludington Priority: Minor Attachments: closed.gif, open.gif, solr75v1.diff The files in this upcoming patch create a simple schema browser for the admin tool. It serves schema.xml along with a stylesheet that in compliant browsers creates a page with a tree widget to show the fieldtypes and fields, as well as their uses and cross references. This is similar to the schemaxsl.zip originally attached to SOLR-58, but a few features have been added, and the look and feel has been changed to fit in better with the rest of the admin tool. Note that it does *not* work against the live IndexSchema -- it merely transforms schema.xml. There is probably not a significant difference now, but it is worth raising the issue in case there are future administration capabilities in mind (i.e. on http://wiki.apache.org/solr/MakeSolrMoreSelfService ) that might require a schema browser to be talking to the live values. -- 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
[jira] Commented: (SOLR-76) New look for the HTML admin pages
[ http://issues.apache.org/jira/browse/SOLR-76?page=comments#action_12456322 ] Bertrand Delacretaz commented on SOLR-76: - I agree that it'd be good to have a closer connection to the sun. Nicolas says the hard part is in avoiding the cheap holiday club look ;-) Maybe solar flares would help make a clear connection while staying subtle, I like the power that such images evoke: http://hesperia.gsfc.nasa.gov/sftheory/fulldisk.htm http://perso.orange.fr/universimmedia/soleil/lexique/protuberances.htm I told Nicolas to think about it, but if others have ideas, let's see them! New look for the HTML admin pages - Key: SOLR-76 URL: http://issues.apache.org/jira/browse/SOLR-76 Project: Solr Issue Type: Improvement Components: web gui Reporter: Bertrand Delacretaz Priority: Minor Attachments: solr-beige.jpg, solr-black.jpg, solr-green.jpg As discussed on the mailing list (http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200611.mbox/[EMAIL PROTECTED]), I'm going to attach the suggested designs here. -- 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
Re: [jira] Commented: (SOLR-76) New look for the HTML admin pages
: I agree that it'd be good to have a closer connection to the sun. : Nicolas says the hard part is in avoiding the cheap holiday club look well .. if we want to keep the vibe of the pages upbeat, and the color scheme bright, then we may have to get a little holiday clubish... http://www.illustrations.com/images/logos/sun_bit.jpg ..but there's still a lot of room to manuver before we get cheap... http://www1.odn.ne.jp/tt-house/bigmate/big-icon/b-sun.png -Hoss
Re: problematicly fetching manifest info from a war
A good example of putting some diagnostic help into a JSP page is Axis happy.jsp (now called HappyAxis.jsp): http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/ webapp/HappyAxis.jsp?view=markup As for Solr classes - no reason not to JAR them up. Go for it. Erik On Dec 6, 2006, at 9:26 PM, Chris Hostetter wrote: For what it's worth, i was trying to add a quick and diry little bit of code to _info.jsp so that we could display info about the current version of Solr being run by accessing the manifest file, ala... core.getClass().getPackage().getImplementationVersion(); ...and discovered it didn't work. I freaked out a bit, thinking I still hadn't managed to get the manifest working properly, but i'm pretty sure it's right, it's just that for whatever reason that doesn't seem to work with a WAR, if you do the same type of thing with a jar it works fine, we can even modify _info.jsp to get the lucene version info out of the lucene-core-nightly.jar's manifest file using... org.apache.lucene.LucenePackage.class.getPackage ().getImplementationVersion(); Do any WAR/J2EE experts out there know why a JSP in a webapp can get info out of a MANIFEST.MF from a jar in it's classpath, but not out of the webapps own MANIFEST.MF file? One thing we might want to consider, is puting the solt.jar in the solr.war's lib directory, instead of adding all of the classes directly ... it would deal with this problem, and it would make our war look a little cleaner when/if it is unpacked. -Hoss
Config Loading Improvement
Hello, I recently started integrating Solr as Cocoon Block into our application. While doing this I noticed that there is a problem with loading the Solr configuration in Config.getVal(). It throws an UnsupportedOperationException when Node.getTextContent() is called when I run it in our Cocoon development environment, which is based on Jetty Maven Plugin. I think this is due older parser version which does not implement getTextContent for the Node type. So far I created a patch that should work for actual and older implementations of the DOM API. While searching the JIRA, I did not find any issues that refers to this problem (while there is a comment in the code about it). So my question is: is anybody else working on this problem or is this not really a problem and I did something wrong? If this seems to be a good improvement, I can supply a patch to the JIRA. Regards, Alex -- Alexander Saar Mindquarry - achieving more together (http://www.mindquarry.com) E-Mail: [EMAIL PROTECTED] | Mindquarry GmbH Work: +49 331 97992 223 | August-Bebel-Str. 88 Mobile: +49 177 59 85 437 | 14482 Potsdam, Germany Weblog: http://alexsaar.blogspot.com/ OpenBC Profile: http://www.openbc.com/hp/Alexander_Saar/
Re: Config Loading Improvement
On 12/7/06, Alexander Saar [EMAIL PROTECTED] wrote: I recently started integrating Solr as Cocoon Block into our application. While doing this I noticed that there is a problem with loading the Solr configuration in Config.getVal(). It throws an UnsupportedOperationException when Node.getTextContent() is called when I run it in our Cocoon development environment, which is based on Jetty Maven Plugin. I've seen this problem with older Resin containers. Solr's web.xml has commented out directives for Resin to use the Sun implementation from Java5 instead. I think this is due older parser version which does not implement getTextContent for the Node type. So far I created a patch that should work for actual and older implementations of the DOM API. While searching the JIRA, I did not find any issues that refers to this problem (while there is a comment in the code about it). So my question is: is anybody else working on this problem or is this not really a problem and I did something wrong? If this seems to be a good improvement, I can supply a patch to the JIRA. Sure, increasing the compatibility seems reasonable. -Yonik
[jira] Created: (SOLR-78) [PATCH] Improved config loading
[PATCH] Improved config loading --- Key: SOLR-78 URL: http://issues.apache.org/jira/browse/SOLR-78 Project: Solr Issue Type: Improvement Reporter: Alexander Saar Priority: Minor Solr configuration throws an UnsupportedConfigurationException for Node.getTextContent() if it is started in server environments that uses older implementations of the DOM API. This can be improved by checking wich node type is actually handled an calling the appropriate methods. A patch that fixes this problem is attached. -- 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
[jira] Updated: (SOLR-78) [PATCH] Improved config loading
[ http://issues.apache.org/jira/browse/SOLR-78?page=all ] Alexander Saar updated SOLR-78: --- Attachment: fixed-config-loading-with-older-parser-versions.patch Patch that fixes the problem described by this issue. [PATCH] Improved config loading --- Key: SOLR-78 URL: http://issues.apache.org/jira/browse/SOLR-78 Project: Solr Issue Type: Improvement Reporter: Alexander Saar Priority: Minor Attachments: fixed-config-loading-with-older-parser-versions.patch Solr configuration throws an UnsupportedConfigurationException for Node.getTextContent() if it is started in server environments that uses older implementations of the DOM API. This can be improved by checking wich node type is actually handled an calling the appropriate methods. A patch that fixes this problem is attached. -- 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
Re: [jira] Commented: (SOLR-75) XSLT-based Schema Browser in admin view
yeah .. i wasn't sure if this version was identicle or not, it sounds like you added some stuff, but the key thing i was refering to was what when showing a field we should display both the direct attributes as well as any attributes it inherits from it's fieldtype Currently, there is usage table on the field page, that contains a link from the field to the fieldtype (the usage table on the fieldtype page links back to all implementing fields) -- does that satisfy the need, or is it important to display the fieldtype data embedded within the field screen? -Greg
[jira] Updated: (SOLR-58) Change Admin components to return XML like the rest of the system
[ http://issues.apache.org/jira/browse/SOLR-58?page=all ] Otis Gospodnetic updated SOLR-58: - Attachment: SOLR-58.patch Here is the patch with modified JSPs + XSLs. I know there are a few small things missing: - I lost the solr/schema part that goes in the parentheses in page headings. - I lost the cwd, hostname, and the little stuff that I think _info.jsp gathers. - maybe something else... The above omissions can easily be re-added, but let's see the review of the existing changes first. 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, analysis.xsl, logging-xml.jsp, logging.xsl, ping-xml-out.txt, ping-xml.jsp, ping.xsl, SOLR-58.patch, threaddump-xml-out.txt, threaddump-xml.jsp, threaddump.xsl 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
[jira] Commented: (SOLR-58) Change Admin components to return XML like the rest of the system
[ http://issues.apache.org/jira/browse/SOLR-58?page=comments#action_12456638 ] Otis Gospodnetic commented on SOLR-58: -- 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. 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, analysis.xsl, logging-xml.jsp, logging.xsl, ping-xml-out.txt, ping-xml.jsp, ping.xsl, SOLR-58.patch, threaddump-xml-out.txt, threaddump-xml.jsp, threaddump.xsl 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
test release artifacts
I've gone through the process of making release artifacts and put them here: http://people.apache.org/~yonik/solr/test_release/ This is *not* a release candidate... this is just for people to review to see what problems they can see now. A couple of additional changes would have been in a real release, including - a note of the version number in CHANGES.txt, and perhaps some release-notes type of stuff in there as well - a bump of version number in build.xml - tags, and all that jazz I think we should try to make a real release candidate by the end of next week. -Yonik
Re: test release artifacts
On 12/7/06, Yonik Seeley [EMAIL PROTECTED] wrote: I've gone through the process of making release artifacts and put them here: http://people.apache.org/~yonik/solr/test_release/ This is *not* a release candidate... this is just for people to review to see what problems they can see now. Is there anything in particular you would like reviewed? I don't know much about apache release policies or licenses so I'm not sure how to help out here. -MIke
Re: test release artifacts
On 12/7/06, Mike Klaas [EMAIL PROTECTED] wrote: On 12/7/06, Yonik Seeley [EMAIL PROTECTED] wrote: I've gone through the process of making release artifacts and put them here: http://people.apache.org/~yonik/solr/test_release/ This is *not* a release candidate... this is just for people to review to see what problems they can see now. Is there anything in particular you would like reviewed? I don't know much about apache release policies or licenses so I'm not sure how to help out here. Could you go through the process of trying to verify the signatures? That's something that might turn out different than if I did it myself (since it's my keys). -Yonik
Re: test release artifacts
On 12/8/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...Could you go through the process of trying to verify the signatures?... Signatures for both the .tgz and .zip files pass, after importing your key from pgp.mit.edu into my gpg keystore. I have added http://svn.apache.org/repos/asf/incubator/solr/trunk/KEYS.txt to make it easier for people to get our keys, it would be good to add yours there. -Bertrand Example: gpg --verify apache-solr-1.1.0-incubating.tgz.asc apache-solr-1.1.0-incubating.tgz gpg: Signature made Fri Dec 8 04:22:19 2006 CET using DSA key ID 0AFCEE7C gpg: Good signature from Yonik Seeley [EMAIL PROTECTED] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: E404 B4CF 10D8 F153 04F7 651C B83E A82A 0AFC EE7C
