Hudson build is back to normal: Solr-Nightly #267
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/267/changes
[jira] Commented: (SOLR-414) Coherent plugin initialization strategy
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544834
]
Henri Biestro commented on SOLR-414:
Looks good to me; got a solr-350 + 409 patch (414 pre-integrated) ready to
upload as soon as this gets committed.
Coherent plugin initialization strategy
---
Key: SOLR-414
URL: https://issues.apache.org/jira/browse/SOLR-414
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Fix For: 1.3
Attachments: SOLR-414-Initialization.patch,
SOLR-414-Initialization.patch, SOLR-414-Initialization.patch,
SOLR-414-Initialization.patch, SOLR-414-Initialization.patch
We currently load many plugins with a Map or NamedList -- since SOLR-215, the
current core is not available through SolrCore.getSolrCore() and may need to
be used for initialization.
Ideally, we could change the init() methods from:
{panel}void init( final MapString,String args );{panel}
to
{panel}void init( final SolrCore core, final MapString,String args );{panel}
Without breaking existing APIs, this change is difficult (some ugly options
exist). This patch offers a solution to keep existing 1.2 APIs, and allow
access to the SolrConfig and SolrCore though ThreadLocal. This should be
removed in a future release.
{panel}
DeprecatedPluginUtils.getCurrentCore();
DeprecatedPluginUtils.getCurrentConfig();
{panel}
This patch removes the SolrConfig.Initalizable that was introduced in
SOLR-215.
For background, see:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html
See also: SOLR-260, SOLR-215, SOLR-399
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Initializing - break init() API compatibility?
You both convinced me this is the right functional approach -and that no (mostly) technical trick alone would meet those (the last one was not working btw, some class loading security errors, ugh...). Note for self: Clear constraints are better than a 'free for all' feature that will ultimately generate more problems than potential solutions. Thanks for helping me become a better member of the team. -- View this message in context: http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13898931 Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544856 ] Jörg Kiegeland commented on SOLR-139: - A useful feature would be update based on query, so that documents matching the query condition will all be modified in the same way on the given update fields. This feature would correspond to SQL's UPDATE command, so that Solr would now cover all the basic commands SQL provides. (While this is a theoretic motivation, I just missed this feature for my Solr projects..) Support updateable/modifiable documents --- Key: SOLR-139 URL: https://issues.apache.org/jira/browse/SOLR-139 Project: Solr Issue Type: New Feature Components: update Reporter: Ryan McKinley Assignee: Ryan McKinley Fix For: 1.3 Attachments: Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, SOLR-269+139-ModifiableDocumentUpdateProcessor.patch It would be nice to be able to update some fields on a document without having to insert the entire document. Given the way lucene is structured, (for now) one can only modify stored fields. While we are at it, we can support incrementing an existing value - I think this only makes sense for numbers. for background, see: http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-419) SolrDispatchFilter throws NullPointerException in some cases
SolrDispatchFilter throws NullPointerException in some cases
Key: SOLR-419
URL: https://issues.apache.org/jira/browse/SOLR-419
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.2, 1.3
Environment: Tomcat 6.0/servlet
Reporter: Oz Solomon
Priority: Minor
In the class SolrDispatchFilter, the destroy method is as follows:
public void destroy() {
core.close();
}
The problem is when the servlet doesn't initialize properly (for example, if
there is a problem in schema.xml) then core isn't initialized, and this will
throw a NullPointerException. A better implementation would be:
public void destroy() {
if (core != null) core.close();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
