[jira] Commented: (SOLR-76) New look for the HTML admin pages
[ http://issues.apache.org/jira/browse/SOLR-76?page=comments#action_12454851 ] Bertrand Delacretaz commented on SOLR-76: - Got Nicolas' email wrong: nicolas (put at here) sarraux-dessous.ch 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: Solr, new index format (segments_N)
Chris Hostetter wrote: : Yes, i've tried that. Building and running Solr with the supplied jar : works ok, the problem raises when i copy the latest lucene jar. It has : to be with the created lucene .jar, but i don't know why... looking back at your stack trace, my gut instinct is that there is something wrong with your java setup, such that the native code libraries used to impliment the system classes (specificly the regex functionality) aren't linked properly (or some other crazy DLL/so mumbojumbo) and you only get the problem with the lockless commits version because thats when it started using pattern matching on file names. ...except that as far as i can tell the old version would used pattern matching too, just not as much. .. hmm, acctually, i take that bcak: the code to call String.matches to determine what files are part of the index was there, but i don't acctual see it getting used -- at least not in the code from your stack trace (opening an index) thinking about it a bit: before lockless commits there really was only one purpose for the IndexFileNameFilter, removing all index files from a directory when asked to create a new index ... code that Solr never would have executed (i don't believe) ... so maybe that is the problem? Manuel: forget about Solr for a minute, when you compile the Lucnee trunk, can you run the (Lucene) tests successfully ? more importantly: does the commandline Lucene demo work for you? can you run... java org.apache.lucene.demo.IndexFiles [somepath] ...if i'm write, that will fail if you run it more then once in the same directory (so that an index directory with stuff in it has already been created when you run it a a second time) ... it should even fail with the lucene 2.0 release. (hell: if i'm right, a 1 line hello world class you write that just calls System.out.println(string.matches(\\d)) would fail the same way) -Hoss Hi Chris, Now i have solr working with lockless index, but i had to download the binaries from the lucene website so now it works ok, but still don't know why the jar file generated in the compilation of the lucene svn sources doesn't work with solr, so the main part of the problem is solved, i will go on investigating why the compiled jar doesn't work, bu i think it's no a java problem, in that case it won't work even with the lucene binaries. Thank you for your time. Regards. Manu
Re: release requirements status
On 12/1/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 11/30/06, Yonik Seeley [EMAIL PROTECTED] wrote: ...I'm not sure if we need to note anything about Jetty in LICENSE or NOTICE or not... it already uses the ASL 2.0 license, but does seem to contain other licenses within it How about creating a legal directory with copies of Jetty's (and other) license files? I see there are some in example/etc, maybe a top-level legal would be clearer? AFAIK, best practice is currently a single NOTICE and LICENSE file at the top with everything in it (or at a minimum pointers from the LICENSE file to all other licenses). Part of the problem is one can't look at other ASF project releases for much guidance since many would not pass the current scrutiny of the incubator. -Yonik
Re: release requirements status
On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: ...I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff... Hmmm..you're right (it's Friday here, it's been a long week ;-) -Bertrand
Re: release requirements status
Ahh, here's the pointer: http://www.apache.org/dev/release.html ''' If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files? No - all license information should be contained in the LICENSE file. When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. ''' -Yonik On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff. LICENSE needs to apply to everything in the distribution. Solr's current LICENSE has ASL 2.0, followed by the license for the XML parser we use, as directed by legal-discuss. -Yonik
Re: release requirements status
Wow, cool. Yoav On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: Ahh, here's the pointer: http://www.apache.org/dev/release.html ''' If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files? No - all license information should be contained in the LICENSE file. When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. ''' -Yonik On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff. LICENSE needs to apply to everything in the distribution. Solr's current LICENSE has ASL 2.0, followed by the license for the XML parser we use, as directed by legal-discuss. -Yonik
Re: release requirements status
Ooops, sent a bit too early -- meant wow, I was really wrong about this, good to know and cool, thanks for pointing it out ;) Yoav On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: Wow, cool. Yoav On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: Ahh, here's the pointer: http://www.apache.org/dev/release.html ''' If A Distribution Contains Code Under Several Licenses, Should It Contain Several License Files? No - all license information should be contained in the LICENSE file. When a distribution contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. ''' -Yonik On 12/1/06, Yonik Seeley [EMAIL PROTECTED] wrote: On 12/1/06, Yoav Shapira [EMAIL PROTECTED] wrote: I thought this was exactly what the NOTICE file is for? Mention all the code from other projects we use, including ASL code. LICENSE is just for our own (Solr) stuff. LICENSE needs to apply to everything in the distribution. Solr's current LICENSE has ASL 2.0, followed by the license for the XML parser we use, as directed by legal-discuss. -Yonik
Re: Solr, new index format (segments_N)
: Now i have solr working with lockless index, but i had to download the : binaries from the lucene website so now it works ok, but still don't : know why the jar file generated in the compilation of the lucene svn : sources doesn't work with solr, so the main part of the problem is : solved, i will go on investigating why the compiled jar doesn't work, bu : i think it's no a java problem, in that case it won't work even with the : lucene binaries. if the lucene jars built by someone else work, but the jars you compile for yourself don't then that suggests to me that there is an incompatibility between the java compiler you are using to compile the code, and the JVM you are using hte run the code ... is there any possibility you have a 1.6 javac lying arround that might be getting used by ant? -Hoss
Re: New look for the HTML admin pages?
Bertrand, please keep SOLR-58 in mind. I'm nearly finished with it. If you decide to make changes to the structure of admin pages, please do it within SOLR-58, so we avoid collision. There is some XSLT there already. Otis - Original Message From: Bertrand Delacretaz [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Wednesday, November 29, 2006 4:44:17 AM Subject: Re: New look for the HTML admin pages? On 11/29/06, Zaheed Haque [EMAIL PROTECTED] wrote: ...What about the front end i.e. example XSLT?... Not sure what you mean, currently the admin pages are currently generated by JSP pages IIUC. If we move to XSLT later on, using the CSS that would be created during this redesign wouldn't be a problem. -Bertrand
[jira] Commented: (SOLR-74) Cross-site scripting vulnerabilities
[ http://issues.apache.org/jira/browse/SOLR-74?page=comments#action_12455075 ] Otis Gospodnetic commented on SOLR-74: -- analysis.jsp is getting changed in SOLR-58, so the last 3 CSS issues will be taken care of there. Cross-site scripting vulnerabilities Key: SOLR-74 URL: http://issues.apache.org/jira/browse/SOLR-74 Project: Solr Issue Type: Bug Components: web gui Reporter: Erik Hatcher There are a number of cross-site scripting vulnerabilities in the Solr admin JSP pages, wherever data is being re-displayed as typed by the user. For example, in analysis.jsp: textarea class=std rows=1 cols=70 name=qval%= qval %/textarea These need to be modified to HTML escape the values rather than directly outputting the exact values. The other affected JSP pages: action.jsp and get-file.jsp -- 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
