date:20110601

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041995#comment-13041995
]

Jason Rutherglen commented on SOLR-2193:

I'm curious if someone who doesn't work at Lucid can be involved in Solr design
discussions. In any case, please autocratically continue.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

The update handler needs an overhaul.
A few goals I think we might want to look at:
1. Cleanup - drop DirectUpdateHandler(2) line - move to something like
UpdateHandler, DefaultUpdateHandler
2. Expose the SolrIndexWriter in the api or add the proper abstractions to
get done what we now do with special casing:
if (directupdatehandler2)
success
else
failish
3. Stop closing the IndexWriter and start using commit (still lazy IW init
though).
4. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level.
5. Keep NRT support in mind.
6. Keep microsharding in mind (maintain logical index as multiple physical
indexes)
7. Address the current issues we face because multiple original/'reloaded'
cores can have a different IndexWriter on the same index.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041997#comment-13041997
]

Robert Muir commented on SOLR-2193:
---

I committed this patch (with some additional ref counting checks in
SolrTestCaseJ4) to https://svn.apache.org/repos/asf/lucene/dev/branches/solr2193

Jason (or anyone else!): if you want to be involved, please contribute
constructively in the form of useful ideas and patches against this branch.

In the meantime, I will be trying to improve the tests for what exists now, as
its the best way (not manual reviews) to increase my confidence.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042004#comment-13042004
]

Jason Rutherglen commented on SOLR-2193:

This article is an indicator of the types of benchmarks to perform:
http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042009#comment-13042009
]

Robert Muir commented on SOLR-2193:
---

Jason, this issue isn't intended to solve NRT.
You might want to create a followup issue for improved NRT support.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042011#comment-13042011
]

Jason Rutherglen commented on SOLR-2193:

bq. Jason, this issue isn't intended to solve NRT

What is this line doing?

{code}
newReader = currentReader.reopen(indexWriterProvider.getIndexWriter(), true);
{code}

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042013#comment-13042013
]

Jason Rutherglen commented on SOLR-2193:

Also:

https://issues.apache.org/jira/browse/SOLR-2193?focusedCommentId=13016875page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13016875

And this comment:

{quote}
Can you elaborate on why you don't think it's implementing NRT? I've tested
basic indexing/searching using wikipedia documents at about 50-100 documents a
second, opening a new reader every second. That felt pretty near-real-time to
me, but the phrase is subjective.
{quote}

from:
https://issues.apache.org/jira/browse/SOLR-2193?focusedCommentId=13041268page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13041268

Robert, your statement's confusing.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042015#comment-13042015
]

Robert Muir commented on SOLR-2193:
---

Its not confusing at all... its a step towards NRT, thats all.

the main improvement to me, is to not close the indexwriter
this patch doesn't need to fully make solr realtime.

you can keep whining that it isn't, but this doesn't accomplish anything.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Muir updated SOLR-2279:
--

Attachment: SOLR-2279.patch

updated patch: I really want to be able to track file handles in Solr's tests,
so I added a hack to avoid the issue of Directory.close() never being called.

A couple tests fail using MockDirectoryWrapperFactory, still trying to track
down why this is.

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Fix For: 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch

Currently, all Lucene tests open directories with newDirectory() [and
soon-to-be added newFSDirectory() which always ensures the directory returned
is an FSDir subclass, see LUCENE-2804 for this]. Additionally the directory
is wrapped with MockDirectoryWrapper.
This has a number of advantages:
* By default the directory implementation is random, but you can easily
specify a specific impl e.g. -Dtests.directory=MMapDirectory. When proposing
a change to one of our directory implementations, we can run all tests with
it this way... it would be good for Solr tests to respect this too.
* The test framework (LuceneTestCase before/afterclass) ensures that these
directories are properly closed, if not, it causes the test to fail with a
stacktrace of where you
first opened the directory.
* MockDirectoryWrapper.close() then ensures that there are no resource leaks
by default, when you open a file they save the stacktrace of where you opened
it from. If you try to close the directory without say, closing an
IndexReader, it fails with the stacktrace of where you opened the reader
from. This is helpful for tracking down resource leaks. Currently Solr warns
if it cannot delete its test temporary directory, but this is better since
you know exactly where the resource leak came from. This can be disabled with
an optional setter which we should probably expose for some tests that have
known leaks like SpellCheck.
* MockDirectoryWrapper enforce consistent test behavior on any operating
system, as it won't be dependent on the return value of FSDirectory.open
* MockDirectoryWrapper has a number of other checks and features, such as
simulating a crash, simulating disk full, emulating windows (where you can't
delete open files), etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3166) src/site should not be built under /docs

2011-06-01 Thread Shai Erera (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042018#comment-13042018
]

Shai Erera commented on LUCENE-3166:

bq. Does anyone have any opinions on this proposal?

Don't know if it counts (since I opened it), but +1 to follow this proposal !

src/site should not be built under /docs

Key: LUCENE-3166
URL: https://issues.apache.org/jira/browse/LUCENE-3166
Project: Lucene - Java
Issue Type: Improvement
Components: general/javadocs, general/website
Reporter: Shai Erera
Priority: Blocker
Fix For: 3.3, 4.0

I noticed that the source package contains a docs subdir with all the
site's docs. Also, the root has index.html which nicely points to all those
documents. However, it also points to the Javadocs which are absent. If you
ant javadocs, they are built under build/docs/api, which makes the links in
index.html still invalid.
Iterating on it shortly, Robert and I think that the following should be done:
# have src/site docs built under src/site/build. Today they already are, but
later cp -r under /docs, so we should remove the copy instruction.
# have ant docs or ant generate-docs which generates javadocs + copy
src/site/build under build/docs. Then all links will still work.
# remove docs from svn and keep them under src/site/build.
Marking it a blocker for 3.3 so we revisit before then.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2565) Prevent IW#close and cut over to IW#commit

2011-06-01 Thread Simon Willnauer (JIRA)

Prevent IW#close and cut over to IW#commit
--

 Key: SOLR-2565
 URL: https://issues.apache.org/jira/browse/SOLR-2565
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 4.0
Reporter: Simon Willnauer
 Fix For: 4.0


Spinnoff from SOLR-2193. We already have a branch to work on this issue here 
https://svn.apache.org/repos/asf/lucene/dev/branches/solr2193 

The main goal here is to prevent solr from closing the IW and use IW#commit 
instead. AFAIK the main issues here are:

The update handler needs an overhaul.

A few goals I think we might want to look at:

1. Expose the SolrIndexWriter in the api or add the proper abstractions to get 
done what we now do with special casing:
2. Stop closing the IndexWriter and start using commit (still lazy IW init 
though).
3. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level.
4. Address the current issues we face because multiple original/'reloaded' 
cores can have a different IndexWriter on the same index.

Eventually this is a preparation for NRT support in Solr which I will create a 
followup issue for.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2566) Add NRT support to SOLR

2011-06-01 Thread Simon Willnauer (JIRA)

Add NRT support to SOLR
---

 Key: SOLR-2566
 URL: https://issues.apache.org/jira/browse/SOLR-2566
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 4.0
Reporter: Simon Willnauer
 Fix For: 4.0


Followup from SOLR-2193 - Solr is waiting for NRT support for a long time now. 
Mark has started a great issues on re-arch the updatehandler and its followup 
SOLR-2565. This issue aims to provide NRT support to solr once SOLR-2565 is 
resolved. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

2011-06-01 Thread Simon Willnauer (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042026#comment-13042026
]

Simon Willnauer commented on SOLR-2193:
---

I intend to close this issue and go on in SOLR-2565 / SOLR-2566 I hope these
issues provide a more clear focus on what the issues trying to address. If
nobody objects I am going to close this today.

simon

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042032#comment-13042032
]

Robert Muir commented on SOLR-2193:
---

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Muir updated SOLR-2279:
--

Attachment: SOLR-2279.patch

attached is a committable patch, changes from previous:
* added to uima contrib too
* disabled for the two problematic tests.

I think its ok for now that we disable this factory for two tests like such in
setUp():
{noformat}
// TODO: fix this test to use MockDirectoryFactory
System.clearProperty(solr.directoryFactory);
{noformat}

Hopefully we can fix these tests in the future, but for now this is a good
improvement in test coverage. I'll test on windows now, and commit this as a
first step if everything is ok. I'll keep the issue open because I think we
want to fix those 2 tests.

Also, I was surprised to find no problems with the spellchecker, but the reason
for this is that it doesnt use the DirectoryFactory in solr, instead just
FSDirectory.open! (I wonder if this should be improved separately?)

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-3146) IndexReader.setNorms is no op if one of the field instances omits norms

2011-06-01 Thread Shai Erera (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shai Erera resolved LUCENE-3146.


   Resolution: Fixed
Fix Version/s: 3.3
 Assignee: Shai Erera

Committed revision 1130039 (trunk).
Committed revision 1130041 (3x).

Thanks Mike !

 IndexReader.setNorms is no op if one of the field instances omits norms
 ---

 Key: LUCENE-3146
 URL: https://issues.apache.org/jira/browse/LUCENE-3146
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/search
Reporter: Shai Erera
Assignee: Shai Erera
 Fix For: 3.3, 4.0

 Attachments: LUCENE-3146.patch, LUCENE-3146.patch


 If I add two documents to an index w/ same field, and one of them omit norms, 
 then IndexReader.setNorms is no-op. I'll attach a patch w/ test case

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Muir updated SOLR-2279:
--

Fix Version/s: 3.3

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 3.3, 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042041#comment-13042041
]

Robert Muir commented on SOLR-2279:
---

I committed the initial patch in 1130042, and backported to branch3x in 1130044.

So the remaining tests to figure out are the ones with the TODO:
* MergeIndexesEmbeddedTest (trunk, branch_3x)
* MultiCoreExampleJettyTest (trunk, branch_3x)
* MultiCoreEmbeddedTest -- strangely enough, this one only on branch_3x

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 3.3, 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML

[
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042046#comment-13042046
]

Upayavira commented on SOLR-2459:
-

So, slf4j is a facade, and it looks like Solr uses JDK logging behind that. I'm
assuming this is correct.

It seems that the best way to do this is to replace the LogLevelSelection
servlet with a Handler.

Coding a handler to display current settings is easy, and I've already done it.
However, to code the update side, requires a decision on suitable request
parameters.

The biggest question is whether to allow multiple settings to be changed in one
request. The current LogLevelSelection servlet allows you to change them all in
one single hit. However, allowing this in a new Handler would, in my opinion,
give rise to an ugly API. Therefore, I suggest that:

http://localhost:8983/solr/admin/logging - would display current settings
http://localhost:8983/solr/admin/logging?category=corelevel=FINE - would
change a single value

This latter would probably output the same as the previous, but perhaps with an
'updated' attribute set to true on that category.

Given the ajax nature of the new UI, I suspect this would be enough for it to
work with.

Thoughts?

LogLevelSelection Servlet outputs plain HTML

Key: SOLR-2459
URL: https://issues.apache.org/jira/browse/SOLR-2459
Project: Solr
Issue Type: Wish
Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

The current available Output of the LogLevelSelection Servlet is plain HTML,
which made it unpossible, to integrate the Logging-Information in the new
Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would
be really nice!
Just as an Idea for a future structure, the new admin-ui is [actually based
on that
json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
:)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2565) Prevent IW#close and cut over to IW#commit

[
https://issues.apache.org/jira/browse/SOLR-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042048#comment-13042048
]

Robert Muir commented on SOLR-2565:
---

I merged the initial commit from SOLR-2279 (which enables MockDirectoryWrapper
for solr tests/tracking file handles)... no issues found from the branch.

I'm gonna look now at some other general ways we can beef up the test coverage
in Solr, especially by reusing what we have done in Lucene.

Prevent IW#close and cut over to IW#commit
--

Key: SOLR-2565
URL: https://issues.apache.org/jira/browse/SOLR-2565
Project: Solr
Issue Type: Improvement
Components: update
Affects Versions: 4.0
Reporter: Simon Willnauer
Fix For: 4.0

Spinnoff from SOLR-2193. We already have a branch to work on this issue here
https://svn.apache.org/repos/asf/lucene/dev/branches/solr2193
The main goal here is to prevent solr from closing the IW and use IW#commit
instead. AFAIK the main issues here are:
The update handler needs an overhaul.
A few goals I think we might want to look at:
1. Expose the SolrIndexWriter in the api or add the proper abstractions to
get done what we now do with special casing:
2. Stop closing the IndexWriter and start using commit (still lazy IW init
though).
3. Drop iwAccess, iwCommit locks and sync mostly at the Lucene level.
4. Address the current issues we face because multiple original/'reloaded'
cores can have a different IndexWriter on the same index.
Eventually this is a preparation for NRT support in Solr which I will create
a followup issue for.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042052#comment-13042052
]

Robert Muir commented on SOLR-2279:
---

Ok, so now i can explain why MultiCoreEmbeddedTest only failed on trunk,
its because we System.clearProperty()'ed in a previous test to disable MDW,
which disabled it for all subsequent tests in the JVM.

I'm fixing this now so its reset in beforeClass().

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 3.3, 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML

[
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042056#comment-13042056
]

Stefan Matheis (steffkes) commented on SOLR-2459:
-

Upayavira,

thanks for having a look into this!

bq. Thoughts?
Yes, just a simple one -- GET for requesting Data and POST for changing them,
please :)

bq. The biggest question is whether to allow multiple settings to be changed in
one request. The current LogLevelSelection servlet allows you to change them
all in one single hit. However, allowing this in a new Handler would, in my
opinion, give rise to an ugly API.
Don't know much about the handling of arrays in java .. in php it's pretty
easy? For the Interface it would be okay to generate such an structure for an
HTTP-Request:
{code}logging[org.apache.solr.core.JmxMonitoredMap]=INFOlogging[org.apache.solr.update.UpdateHandler]=FINEST{code}
Given that Information you could loop over it, and set every Logger at the
specified Level. Of course we need to define how we could reset/delete a
Loggers-Setting ..

Stefan

LogLevelSelection Servlet outputs plain HTML

Key: SOLR-2459
URL: https://issues.apache.org/jira/browse/SOLR-2459
Project: Solr
Issue Type: Wish
Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042057#comment-13042057
]

Robert Muir commented on SOLR-2279:
---

Now that all 3 tests fail consistently with MockDirectoryWrapper, I suspect its
something in these base multicore test classes...

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 3.3, 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042078#comment-13042078
 ] 

Upayavira commented on SOLR-2459:
-

Well, Solr doesn't distinguish between GET and POST in its handlers as far as I 
can see, so either would work.

If by POST you mean that you would post some XML or JSON to it, and it would 
use that, that could be done (don't know how hard it is to accept JSON, but 
could look into it).

Upayavira


 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2567) Solr should default to TieredMergePolicy

Solr should default to TieredMergePolicy


 Key: SOLR-2567
 URL: https://issues.apache.org/jira/browse/SOLR-2567
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Robert Muir
 Fix For: 3.3, 4.0


even if we set a luceneMatchVersion to = 3.2 (SOLR-2557),
Solr still defaults to LogByte

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2567) Solr should default to TieredMergePolicy


 [ 
https://issues.apache.org/jira/browse/SOLR-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated SOLR-2567:
--

Attachment: SOLR-2567.patch

 Solr should default to TieredMergePolicy
 

 Key: SOLR-2567
 URL: https://issues.apache.org/jira/browse/SOLR-2567
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Robert Muir
 Fix For: 3.3, 4.0

 Attachments: SOLR-2567.patch


 even if we set a luceneMatchVersion to = 3.2 (SOLR-2557),
 Solr still defaults to LogByte

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2567) Solr should default to TieredMergePolicy


[ 
https://issues.apache.org/jira/browse/SOLR-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042080#comment-13042080
 ] 

Robert Muir commented on SOLR-2567:
---

the patch currently adjusts the default based on luceneMatchVersion, but this 
is confusing if we release 3.2 that disagrees with lucene's actual 3.2 
defaults.

we could check onOrAfter 3.3 at least to be safe so we don't surprise anyone 
when 3.3 comes out

 Solr should default to TieredMergePolicy
 

 Key: SOLR-2567
 URL: https://issues.apache.org/jira/browse/SOLR-2567
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Robert Muir
 Fix For: 3.3, 4.0

 Attachments: SOLR-2567.patch


 even if we set a luceneMatchVersion to = 3.2 (SOLR-2557),
 Solr still defaults to LogByte

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2279) Add a MockDirectoryFactory (or similar) for Solr tests

2011-06-01 Thread Shai Erera (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042103#comment-13042103
]

Shai Erera commented on SOLR-2279:
--

I debug-traced MultiCoreEmbeddedTest and this is what I found: the test opens
two indexes, one under a temp directory, and one under
trunk/solr/example/multicore/core0/data/index. The one under temp is populated
alright (and exists), while the one under solr/example (to clarify -- this
directory is expected to be found on the checkout, so it seems) is empty, and
hence the test fails on IndexNotFoundException.

I don't understand the test, so I cannot fix it. Just put it here in case
someone else knows this code. I don't understand why this test passes w/
RAMDirectoryFactory.

Also, under solr/example/multicore/core0/conf, solrconfig.xml lists dirFactory
to be StandardDirFactory. I don't know what are the implications of this on the
test, but pointing it out as well.

Hope this info helps someone debug and fix the test :).

Add a MockDirectoryFactory (or similar) for Solr tests
--

Key: SOLR-2279
URL: https://issues.apache.org/jira/browse/SOLR-2279
Project: Solr
Issue Type: Test
Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 3.3, 4.0

Attachments: SOLR-2279.patch, SOLR-2279.patch, SOLR-2279.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-1344) Make the Lucene jar an OSGi bundle


 [ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Stancapiano updated LUCENE-1344:
-

Attachment: lucene_trunk.patch

Ok I created a patch according the pom configuration seen before. It 
creates osgi bundles for lucene-core and the other modules. I tested them 
inside felix and they are installed correctly. There are not mainteinance 
problems because the packages are generated dinamically by the 
maven-bundle-plugin configured in this patch

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-r679133.patch, 
 LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, 
 LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML

[
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042124#comment-13042124
]

Stefan Matheis (steffkes) commented on SOLR-2459:
-

bq. Well, Solr doesn't distinguish between GET and POST in its handlers as far
as I can see, so either would work.
Ah okay .. good to know!

bq. If by POST you mean that you would post some XML or JSON to it, and it
would use that, that could be done (don't know how hard it is to accept JSON,
but could look into it).
No, not really - just POSTing the Params and don't append them to the url;
because some older browser has low restrictions to the length of an url -- and
while using POST the size/amount of data does not matter. i think there is no
need to support xml/json here, the data is plain key/value .. it's enough :

LogLevelSelection Servlet outputs plain HTML

Key: SOLR-2459
URL: https://issues.apache.org/jira/browse/SOLR-2459
Project: Solr
Issue Type: Wish
Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042129#comment-13042129
 ] 

Upayavira commented on SOLR-2459:
-

As far as a Handler is concerned, it is just a list of key/value pairs, 
regardless of whether POSTed or in the URL of a GET. (at least, that is my 
current understanding).

Perhaps it could be:

logging.category=org.apache.org.solr.core.JmxMonitoredMap
logging.level=INFO

Or, as an alternative:

logging.category.org.apache.solr.core.JmxMonitoredMap=INFO
logging.category.org.apache.solr.update.UpdateHandler=FINEST

Either would be acceptable.


 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042135#comment-13042135
 ] 

Ryan McKinley commented on SOLR-2459:
-

I like:
bq. logging.category=org.apache.org.solr.core.JmxMonitoredMap
bq. logging.level=INFO

As for actually updating the logging value  what is the plan for supporting 
various logging providers like Log4j?  The handler gets initialized with the 
logging framework and it takes care of translating the levels (FINEST == TRACE 
etc)?

 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2568) Solr NRT (real time search) does not work

2011-06-01 Thread Nagendra Nagarajayya (JIRA)

Solr NRT (real time search) does not work
-

 Key: SOLR-2568
 URL: https://issues.apache.org/jira/browse/SOLR-2568
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 3.1, 1.4.1
 Environment: linux, solaris
Reporter: Nagendra Nagarajayya
 Fix For: 3.1, 1.4.1


Real Time search does not work with Solr 1.4.1 or 3.1. Archives point to no 
solutions and it appears that the problem will not be addressed. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042138#comment-13042138
 ] 

Ryan McKinley commented on LUCENE-1344:
---

Thanks Luca!

When you upload a patch, can you click the Grant license to ASF for inclusion 
in ASF works button?  It seems a little silly for this small patch, but that 
is ASF policy.

thanks

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-r679133.patch, 
 LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, 
 LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2568) Solr NRT (real time search) does not work

2011-06-01 Thread Nagendra Nagarajayya (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042139#comment-13042139
 ] 

Nagendra Nagarajayya commented on SOLR-2568:


Here is a solution that provides real time search in version 1.4.1:
http://solr-ra.tgels.com/wiki/en/Near_Real_Time_Search
http://solr-ra.tgels.com/papers/NRT_Solr_RankingAlgorithm.pdf


 Solr NRT (real time search) does not work
 -

 Key: SOLR-2568
 URL: https://issues.apache.org/jira/browse/SOLR-2568
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4.1, 3.1
 Environment: linux, solaris
Reporter: Nagendra Nagarajayya
  Labels: nrt,, real, search, time
 Fix For: 1.4.1, 3.1


 Real Time search does not work with Solr 1.4.1 or 3.1. Archives point to no 
 solutions and it appears that the problem will not be addressed. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (LUCENE-1344) Make the Lucene jar an OSGi bundle


 [ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley reassigned LUCENE-1344:
-

Assignee: Ryan McKinley

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-r679133.patch, 
 LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, 
 LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2568) Solr NRT (real time search) does not work

2011-06-01 Thread Nagendra Nagarajayya (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nagendra Nagarajayya updated SOLR-2568:
---

Attachment: NRT_Solr_RankingAlgorithm.pdf

Attached paper describes how NRT (Near Real Time Search) can be implemented in 
Solr
using the RankingAlgorithm. The technical details of the NRT implementation are
discussed.

 Solr NRT (real time search) does not work
 -

 Key: SOLR-2568
 URL: https://issues.apache.org/jira/browse/SOLR-2568
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4.1, 3.1
 Environment: linux, solaris
Reporter: Nagendra Nagarajayya
  Labels: nrt,, real, search, time
 Fix For: 1.4.1, 3.1

 Attachments: NRT_Solr_RankingAlgorithm.pdf


 Real Time search does not work with Solr 1.4.1 or 3.1. Archives point to no 
 solutions and it appears that the problem will not be addressed. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042146#comment-13042146
]

Ryan McKinley commented on SOLR-2193:
-

this is a great step forward. better NRT support can come in later patches.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042160#comment-13042160
 ] 

Upayavira commented on SOLR-2459:
-

Ryan,

I'd implement both approaches - the latter might allow Stefan more flexibility 
in building a UI on top of it. (in fact, I have both coded, now looking at test 
cases).

At present, this is intentionally a rewrite of the LogLevelSelection servlet, 
which only works with JDK logging. I'm just plagiarising the logging code from 
there.

If we want to be more clever, and work with other frameworks, I'm up for it, 
but it is extending the scope somewhat!


 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-1344) Make the Lucene jar an OSGi bundle


 [ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley updated LUCENE-1344:
--

Attachment: LUCENE-1344-maven.patch

This is the same patch, but moved to the lucene parent pom -- this way it 
applies to all artifacts rather then just the lucene core.jar

The output manifest now looks like:
{code}
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven Bundle Plugin
Built-By: ryan
Build-Jdk: 1.6.0_13
Implementation-Vendor-Id: org.apache.lucene
Extension-Name: org.apache.lucene
Implementation-Title: org.apache.lucene
Implementation-Vendor: The Apache Software Foundation
Implementation-Version: 4.0-SNAPSHOT 1130132 - ryan - 2011-06-01 09:12
 :35
Specification-Title: Lucene Core
Specification-Vendor: The Apache Software Foundation
Specification-Version: 4.0.0.2011.06.01.09.12.35
X-Compile-Source-JDK: 1.5
X-Compile-Target-JDK: 1.5
Export-Package: org.apache.lucene.analysis;uses:=org.apache.lucene.ut
 il,org.apache.lucene.store,org.apache.lucene.document,org.apache.luce
 ne.analysis.tokenattributes,org.apache.lucene.index,org.apache.lucen
 e.analysis.tokenattributes;uses:=org.apache.lucene.util,org.apache.l
 ucene.index,org.apache.lucene.document;uses:=org.apache.lucene.util
 ,org.apache.lucene.analysis,org.apache.lucene.index;uses:=org.apach
 e.lucene.search,org.apache.lucene.util,org.apache.lucene.store,org.ap
 ache.lucene.document,org.apache.lucene.index.codecs,org.apache.lucene
 .analysis.tokenattributes,org.apache.lucene.analysis,org.apache.luce
 ne.index.codecs;uses:=org.apache.lucene.index,org.apache.lucene.util
 ,org.apache.lucene.store,org.apache.lucene.index.codecs.standard,org.
 apache.lucene.index.codecs.pulsing,org.apache.lucene.index.codecs.sim
 pletext,org.apache.lucene.index.codecs.preflex,org.apache.lucene.util
 .packed,org.apache.lucene.util.fst,org.apache.lucene.index.codecs.in
 tblock;uses:=org.apache.lucene.store,org.apache.lucene.index.codecs.
 sep,org.apache.lucene.util,org.apache.lucene.index.codecs.preflex;us
 es:=org.apache.lucene.store,org.apache.lucene.index.codecs,org.apach
 e.lucene.index,org.apache.lucene.util,org.apache.lucene.index.codecs.
 standard,org.apache.lucene.index.codecs.pulsing;uses:=org.apache.lu
 cene.index.codecs.standard,org.apache.lucene.util,org.apache.lucene.s
 tore,org.apache.lucene.index.codecs,org.apache.lucene.index,org.apac
 he.lucene.index.codecs.sep;uses:=org.apache.lucene.store,org.apache.
 lucene.util,org.apache.lucene.index,org.apache.lucene.index.codecs,o
 rg.apache.lucene.index.codecs.simpletext;uses:=org.apache.lucene.sto
 re,org.apache.lucene.index.codecs,org.apache.lucene.index,org.apache.
 lucene.util,org.apache.lucene.util.fst,org.apache.lucene.index.codec
 s.standard;uses:=org.apache.lucene.store,org.apache.lucene.index.cod
 ecs,org.apache.lucene.index,org.apache.lucene.util,org.apache.lucene
 ,org.apache.lucene.messages,org.apache.lucene.queryParser;uses:=org.
 apache.lucene.util,org.apache.lucene.search,org.apache.lucene.analysi
 s,org.apache.lucene.analysis.tokenattributes,org.apache.lucene.docume
 nt,org.apache.lucene.index,org.apache.lucene.search;uses:=org.apach
 e.lucene.util,org.apache.lucene.util.automaton,org.apache.lucene.inde
 x,org.apache.lucene.util.packed,org.apache.lucene.search.cache,org.ap
 ache.lucene.store,org.apache.lucene.document,org.apache.lucene.analys
 is.tokenattributes,org.apache.lucene.analysis,org.apache.lucene.searc
 h.spans,org.apache.lucene.search.cache;uses:=org.apache.lucene.util
 ,org.apache.lucene.search,org.apache.lucene.index,org.apache.lucene.u
 til.packed,org.apache.lucene.search.function;uses:=org.apache.lucen
 e.search,org.apache.lucene.index,org.apache.lucene.util,org.apache.l
 ucene.search.payloads;uses:=org.apache.lucene.search,org.apache.luce
 ne.search.spans,org.apache.lucene.index,org.apache.lucene.util,org.a
 pache.lucene.search.spans;uses:=org.apache.lucene.util,org.apache.lu
 cene.search,org.apache.lucene.index,org.apache.lucene.store;uses:=o
 rg.apache.lucene.util,org.apache.lucene.util;uses:=org.apache.lucen
 e.store,org.apache.lucene.index,org.apache.lucene,org.apache.lucene.s
 earch,org.apache.lucene.util.automaton;uses:=org.apache.lucene.util
 ,org.apache.lucene.util.fst;uses:=org.apache.lucene.util,org.apache
 .lucene.store,org.apache.lucene.util.packed;uses:=org.apache.lucene
 .util,org.apache.lucene.store
Tool: Bnd-1.15.0
Bundle-Name: Lucene Core
Bundle-Vendor: The Apache Software Foundation
Bundle-Version: 4.0.0.SNAPSHOT
Bnd-LastModified: 1306934011182
Bundle-ManifestVersion: 2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-Description: Apache Lucene Java Core
Bundle-SymbolicName: org.apache.lucene.core
Bundle-DocURL: http://www.apache.org/
{code}


 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL:

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042169#comment-13042169
 ] 

Ryan McKinley commented on LUCENE-1344:
---

committed to trunk in r1130150

Can someone verify that this makes useful OSGi artifacts before I resolve the 
issue?

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042172#comment-13042172
 ] 

Ryan McKinley commented on SOLR-2459:
-

great -- my comment about supporting log4j is just to keep it in mind.  
Sometimes its easier to think about the abstraction earlier, but we can 
obviously tackle that in a follow on issue.

 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Lucene/Solr release 3.2 (take 2)

2011-06-01 Thread Yonik Seeley

On Mon, May 30, 2011 at 11:54 PM, Robert Muir rcm...@gmail.com wrote:
 Please vote to release the artifacts at http://s.apache.org/lusolr32rc2 as 
 3.2.0

+1, nice job!

-Yonik
http://www.lucidimagination.com

 Changes from rc1 are mostly packaging issues that testers found:
 * SOLR-2557       ensure example configuration files have the correct
 LUCENE_MATCH_VERSION
 * SOLR-2558       remove apache lucene version from solr changes.txt
 Versions of major components
 * SOLR-2559       All solr contrib/*/CHANGES.txt have 3.2-dev as the
 release header.
 * LUCENE-3009     binary packaging: lucene modules/contribs that
 depend on jars are confusing
 * LUCENE-3154     remove version references from the versioned website
 * LUCENE-3155     possibly improve includes/excludes for packages files
 * LUCENE-3156     remove references to contribs that dont exist from docs
 * LUCENE-3157     packaging is sometimes .tar.gz, sometimes .tgz
 * LUCENE-3158     ensure binary artifacts contain the necessary licensing 
 files
 * LUCENE-3159     lucene benchmark has some unnecessary files
 * LUCENE-3160     lucene source build doesn't work correctly by itself
 from the src dist
 * LUCENE-3161     consider warnings from the source compilation
 * LUCENE-3162     NOTICE.txt refers to .jar files which are not
 included in the binary archives.
 * LUCENE-3163     CHANGES.txt has no release date for 3.1.0
 * Included Changes2Html output
 * KEYS files in both releases (also registered my key with id.apache.org)

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042177#comment-13042177
 ] 

Stefan Matheis (steffkes) commented on SOLR-2459:
-

{quote}Perhaps it could be:
logging.category=org.apache.org.solr.core.JmxMonitoredMap
logging.level=INFO{quote}
What would really mean, that we can just update one Logger (per Step) -- 
changing five of them will result in: click, change; save, click, change, save; 
click, change, save .. and so on? We could autosave every change instantly, 
but that's something we don't have anywhere else yet - so i guess users were 
wondering about that behaviour?

{quote}Or, as an alternative:
logging.category.org.apache.solr.core.JmxMonitoredMap=INFO
logging.category.org.apache.solr.update.UpdateHandler=FINEST{quote}
{quote}I'd implement both approaches - the latter might allow Stefan more 
flexibility in building a UI on top of it. {quote}
It's of course possible, but it would be easier to have something like that:
{code}logging[category.org.apache.solr.core.JmxMonitoredMap]=INFO
logging[category.org.apache.solr.update.UpdateHandler]=FINEST{code}
There it's possible to setup an initial Hashmap and just put all the Loggers 
into it. Or is that really difficult to handle on the Server-Side? 

 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042184#comment-13042184
 ] 

Luca Stancapiano commented on LUCENE-1344:
--

Ryan the lucene core is the parent for all modules poms, so this fixing 
could be not important

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (PYLUCENE-10) Building Pylucene is way too difficult

2011-06-01 Thread Philippe Ombredanne (JIRA)

Building Pylucene is way too difficult
--

 Key: PYLUCENE-10
 URL: https://issues.apache.org/jira/browse/PYLUCENE-10
 Project: PyLucene
  Issue Type: Bug
 Environment: Linux, Windows Mac
Reporter: Philippe Ombredanne


The amount of work needed to make a redistributable build for a few common os 
is rather big
Could there be an effort to provide these pre-built?


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042185#comment-13042185
 ] 

Ryan McKinley commented on SOLR-2459:
-

what about somethign like:
{code}
/admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFO
{code}
and setting multiple items with:
{code}
/admin/logging?set=category.org.apache.solr.core.JmxMonitoredMap:INFOset=category.org.apache.solr.update.UpdateHandler:FINEST
{code}

This could work better on the server side then having to iterate though all the 
parameters and checking if they are relevant.



 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


[ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042189#comment-13042189
 ] 

Upayavira commented on SOLR-2459:
-

Ryan - that could work, and it makes it clear that it is an 'action'.

Stefan - I'm trying to make a decent public API that is consistent with the 
rest of Solr. Sorry if that makes it harder for you!!

 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial

 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042196#comment-13042196
 ] 

Ryan McKinley commented on LUCENE-1344:
---

bq. lucene core is the parent for all modules poms

lucene yes, but not solr

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042207#comment-13042207
 ] 

Luca Stancapiano commented on LUCENE-1344:
--

OkI testedit's ok now Solr packages too are OSGI bundle

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2399) Solr Admin Interface, reworked


[ 
https://issues.apache.org/jira/browse/SOLR-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042202#comment-13042202
 ] 

Stefan Matheis (steffkes) commented on SOLR-2399:
-

Shawn,

bq. b) Can the XML display code be made smart enough to deal with xinclude? My 
solrconfig.xml file is mostly made up of xincludes. If there's no good way to 
expand them inline, just making it possible to click on them to see the 
included file would be awesome.
Thanks for your Config-Files. I'd say it's possible -- but not while using an 
absolute path to reference the file you want to include. The 
[ShowFileRequestHandler|http://svn.apache.org/repos/asf/lucene/dev/trunk/solr/src/java/org/apache/solr/handler/admin/ShowFileRequestHandler.java]
 works only for files in SOLR's {{conf/}}-Directory and (additionally) requires 
an relative path for the {{file=}}-Parameter!

I'll try to create an quick Prototyp, so that we can have a look next Week. 

Stefan

 Solr Admin Interface, reworked
 --

 Key: SOLR-2399
 URL: https://issues.apache.org/jira/browse/SOLR-2399
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-2399-admin-interface.patch, 
 SOLR-2399-wip-notice.patch, SOLR-2399.patch


 *The idea was to create a new, fresh (and hopefully clean) Solr Admin 
 Interface.* [Based on this 
 [ML-Thread|http://www.lucidimagination.com/search/document/ae35e236d29d225e/solr_admin_interface_reworked_go_on_go_away]]
 I've quickly created a Github-Repository (Just for me, to keep track of the 
 changes)
 » https://github.com/steffkes/solr-admin 
 Quick Tour: [Dashboard|http://files.mathe.is/solr-admin/01_dashboard.png], 
 [Query-Form|http://files.mathe.is/solr-admin/02_query.png], 
 [Plugins|http://files.mathe.is/solr-admin/05_plugins.png], 
 [Logging|http://files.mathe.is/solr-admin/07_logging.png], 
 [Analysis|http://files.mathe.is/solr-admin/04_analysis.png], 
 [Schema-Browser|http://files.mathe.is/solr-admin/06_schema-browser.png], 
 [Dataimport|http://files.mathe.is/solr-admin/08_dataimport.png], 
 [Core-Admin|http://files.mathe.is/solr-admin/09_coreadmin.png], 
 [Replication|http://files.mathe.is/solr-admin/10_replication.png]
 Newly created Wiki-Page: http://wiki.apache.org/solr/ReworkedSolrAdminGUI

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Building is too difficult and release of a first pre-built egg

2011-06-01 Thread Philippe Ombredanne


Howdy!
I think it is way too hard to build PyLucene for the mere mortals.
Getting eggs is yet another level of difficulties

I created an issue:
https://issues.apache.org/jira/browse/PYLUCENE-10

and started an Apache extra project, releasing a first egg for the Linux 
64/Python 2.5.2/Oracle JDK 1.5 combo


http://code.google.com/a/apache-extras.org/p/pylucene-extra/downloads/list

I hope that can help some folks.

--
Cordially
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://twitter.com/pombr
http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com

Re: [jira] [Assigned] (LUCENE-1344) Make the Lucene jar an OSGi bundle

2011-06-01 Thread Bill Bell

Should we just have something like ant   osgi? Keep it separate?

Bill Bell
Sent from mobile


On Jun 1, 2011, at 6:43 AM, Ryan McKinley (JIRA) j...@apache.org wrote:

 
 [ 
 https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
  ]
 
 Ryan McKinley reassigned LUCENE-1344:
 -
 
Assignee: Ryan McKinley
 
 Make the Lucene jar an OSGi bundle
 --
 
Key: LUCENE-1344
URL: https://issues.apache.org/jira/browse/LUCENE-1344
Project: Lucene - Java
 Issue Type: Improvement
 Components: general/build
   Reporter: Nicolas Lalevée
   Assignee: Ryan McKinley
   Priority: Minor
Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-r679133.patch, 
 LUCENE-1344-r690675.patch, LUCENE-1344-r690691.patch, 
 LUCENE-1344-r696747.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 MANIFEST.MF.diff, lucene_trunk.patch
 
 
 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.
 
 --
 This message is automatically generated by JIRA.
 For more information on JIRA, see: http://www.atlassian.com/software/jira
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (LUCENE-1344) Make the Lucene jar an OSGi bundle


 [ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan McKinley resolved LUCENE-1344.
---

   Resolution: Fixed
Fix Version/s: 4.0
   3.3
Lucene Fields:   (was: [Patch Available, New])

merged with 3.x in r1130173

However this still does not have OSGi support in the official build.

For that, it seems like the right approach would be with bndtools.  I will 
resolve this issue, and we can make a new issue if someone wants to bite off 
integrating with the ant build.  The one thing i am against is somethign that 
needs manual maintance everytime something changes.


 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2569) Enable facile moving of cores

Enable facile moving of cores
-

 Key: SOLR-2569
 URL: https://issues.apache.org/jira/browse/SOLR-2569
 Project: Solr
  Issue Type: Improvement
  Components: multicore, replication (java)
Affects Versions: 4.0
Reporter: Jason Rutherglen


Spin-off from this thread: 
http://search-lucene.com/m/5CO7Z1oOrh6/elastic+searchsubj=Solr+vs+ElasticSearch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042221#comment-13042221
 ] 

Luca Stancapiano commented on LUCENE-1344:
--

Can you maintain two different binaries, one from ant and one from maven for 
each module? It would very useful for who don't develope with lucene/solr 

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

managing CHANGES.txt?

2011-06-01 Thread Ryan McKinley

I know we have talked about this a few times, but not sure where we left off.

My understanding was that if we change something in trunk and merge to
3.x we *only* add it to the 3.x CHANGES.  If it is only for 4.x it
gets added to the 4.x CHANGES.  But it looks like we are actually
keeping the two versions in sync.  Is this just extra work?

I'm sure this has been discussed before, but can trunk changes only
track changes in trunk and keep anything before that in the 3.x
branch?

Can we delete everything past line 441 in:
https://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/CHANGES.txt
and add a comment saying to look at:
https://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x/lucene/CHANGES.txt

When trunk gets moved to branch_4x, the 3.x changes would get copied
over (and presumably not changed anymore)

thoughts?
ryan

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042232#comment-13042232
 ] 

Ryan McKinley commented on LUCENE-1344:
---

bq. Can you maintain two different binaries

Not sure what that means... are you asking if Apache will release two versions 
of the same thing?  If so, no.

The maven integration is an officially unsupported developer build tool, so 
will not be part of the official release -- but it does let someone easily 
build OSGi bundles, so it is a good step forward.  If there is an ant way to do 
this, that could become part of the official release process.


 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042238#comment-13042238
 ] 

Luca Stancapiano commented on LUCENE-1344:
--

yes it is... so I open a new ticket

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042241#comment-13042241
 ] 

Ryan McKinley commented on LUCENE-1344:
---

ok -- my assumption was that integrating with ant is difficult (and requires 
knowing all the dependencies) -- we can keep using this ticket if you want.  
simply hit the 'reopen issue' button at the top

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant

Make lucene/solr a OSGI bundle through Ant
--

 Key: LUCENE-3167
 URL: https://issues.apache.org/jira/browse/LUCENE-3167
 Project: Lucene - Java
  Issue Type: New Feature
 Environment: bndtools
Reporter: Luca Stancapiano


We need to make a bundle thriugh Ant, so the binary can be published and no 
more need the download of the sources. Actually to get a OSGI bundle we need to 
use maven tools and build the sources. Here the reference for the creation of 
the OSGI bundle through Maven.

Bndtools could be used inside Ant

https://issues.apache.org/jira/browse/LUCENE-1344

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant


 [ 
https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Stancapiano updated LUCENE-3167:
-

Description: 
We need to make a bundle thriugh Ant, so the binary can be published and no 
more need the download of the sources. Actually to get a OSGI bundle we need to 
use maven tools and build the sources. Here the reference for the creation of 
the OSGI bundle through Maven:

https://issues.apache.org/jira/browse/LUCENE-1344

Bndtools could be used inside Ant


  was:
We need to make a bundle thriugh Ant, so the binary can be published and no 
more need the download of the sources. Actually to get a OSGI bundle we need to 
use maven tools and build the sources. Here the reference for the creation of 
the OSGI bundle through Maven.

Bndtools could be used inside Ant

https://issues.apache.org/jira/browse/LUCENE-1344


 Make lucene/solr a OSGI bundle through Ant
 --

 Key: LUCENE-3167
 URL: https://issues.apache.org/jira/browse/LUCENE-3167
 Project: Lucene - Java
  Issue Type: New Feature
 Environment: bndtools
Reporter: Luca Stancapiano

 We need to make a bundle thriugh Ant, so the binary can be published and no 
 more need the download of the sources. Actually to get a OSGI bundle we need 
 to use maven tools and build the sources. Here the reference for the creation 
 of the OSGI bundle through Maven:
 https://issues.apache.org/jira/browse/LUCENE-1344
 Bndtools could be used inside Ant

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-1344) Make the Lucene jar an OSGi bundle


[ 
https://issues.apache.org/jira/browse/LUCENE-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042244#comment-13042244
 ] 

Luca Stancapiano commented on LUCENE-1344:
--

I've just created:

https://issues.apache.org/jira/browse/LUCENE-3167

 Make the Lucene jar an OSGi bundle
 --

 Key: LUCENE-1344
 URL: https://issues.apache.org/jira/browse/LUCENE-1344
 Project: Lucene - Java
  Issue Type: Improvement
  Components: general/build
Reporter: Nicolas Lalevée
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: LUCENE-1344-3.0-branch.patch, LUCENE-1344-maven.patch, 
 LUCENE-1344-r679133.patch, LUCENE-1344-r690675.patch, 
 LUCENE-1344-r690691.patch, LUCENE-1344-r696747.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, LUCENE-1344.patch, 
 LUCENE-1344.patch, MANIFEST.MF.diff, lucene_trunk.patch


 In order to use Lucene in an OSGi environment, some additional headers are 
 needed in the manifest of the jar. As Lucene has no dependency, it is pretty 
 straight forward and it ill be easy to maintain I think.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: managing CHANGES.txt?

On Wed, Jun 1, 2011 at 11:21 AM, Ryan McKinley ryan...@gmail.com wrote:
 I know we have talked about this a few times, but not sure where we left off.

 My understanding was that if we change something in trunk and merge to
 3.x we *only* add it to the 3.x CHANGES.  If it is only for 4.x it
 gets added to the 4.x CHANGES.  But it looks like we are actually
 keeping the two versions in sync.  Is this just extra work?


you just commit it to the version it was added.

For example, if you are adding something to 3x and trunk, commit it to
the 3x section of trunk's CHANGES.txt
then when you svn merge, there will be no merge conflict, it will just work.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2570) randomize indexwriter settings in solr tests

randomize indexwriter settings in solr tests


 Key: SOLR-2570
 URL: https://issues.apache.org/jira/browse/SOLR-2570
 Project: Solr
  Issue Type: Test
  Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
 Fix For: 3.3, 4.0


we should randomize indexwriter settings like lucene tests do, to vary # of 
segments and such.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2570) randomize indexwriter settings in solr tests


 [ 
https://issues.apache.org/jira/browse/SOLR-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated SOLR-2570:
--

Attachment: SOLR-2570.patch

just a start, creates a randomconfig.incl that test configs can xinclude to get 
random settings.

of course tons of tests fail right now, but these can be fixed.

i only cutover the solrconfig.xml in the test directory, makes sense to 
switch over others too.

by the way it was somewhat messy to switch over the main one because it appears 
to serve a dual purposes, both as a default test configuration and as a LINT 
config showing all options... not sure if the latter is truly the case but its 
annoying since you cannot have comments inside of comments in XML.

 randomize indexwriter settings in solr tests
 

 Key: SOLR-2570
 URL: https://issues.apache.org/jira/browse/SOLR-2570
 Project: Solr
  Issue Type: Test
  Components: Build
Reporter: Robert Muir
Assignee: Robert Muir
 Fix For: 3.3, 4.0

 Attachments: SOLR-2570.patch


 we should randomize indexwriter settings like lucene tests do, to vary # of 
 segments and such.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2193) Re-architect Update Handler

[
https://issues.apache.org/jira/browse/SOLR-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042259#comment-13042259
]

Jason Rutherglen commented on SOLR-2193:

Simon, thanks for opening new issues.

Re-architect Update Handler
---

Key: SOLR-2193
URL: https://issues.apache.org/jira/browse/SOLR-2193
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Robert Muir
Fix For: 4.0

Attachments: SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch,
SOLR-2193.patch, SOLR-2193.patch, SOLR-2193.patch

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-152) [PATCH] KStem for Lucene

2011-06-01 Thread Robert Zotter (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042262#comment-13042262
 ] 

Robert Zotter commented on LUCENE-152:
--

+1

 [PATCH] KStem for Lucene
 

 Key: LUCENE-152
 URL: https://issues.apache.org/jira/browse/LUCENE-152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: unspecified
 Environment: Operating System: other
 Platform: Other
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 3.3, 4.0


 September 10th 2003 contributionn from Sergio Guzman-Lara 
 guz...@cs.umass.edu
 Original email:
 Hi all,
   I have ported the kstem stemmer to Java and incorporated it to 
 Lucene. You can get the source code (Kstem.jar) from the following website:
 http://ciir.cs.umass.edu/downloads/
   Just click on KStem Java Implementation (you will need to register 
 your e-mail, for free of course, with the CIIR --Center for Intelligent 
 Information Retrieval, UMass -- and get an access code).
 Content of Kstem.jar:
 java/org/apache/lucene/analysis/KStemData1.java
 java/org/apache/lucene/analysis/KStemData2.java
 java/org/apache/lucene/analysis/KStemData3.java
 java/org/apache/lucene/analysis/KStemData4.java
 java/org/apache/lucene/analysis/KStemData5.java
 java/org/apache/lucene/analysis/KStemData6.java
 java/org/apache/lucene/analysis/KStemData7.java
 java/org/apache/lucene/analysis/KStemData8.java
 java/org/apache/lucene/analysis/KStemFilter.java
 java/org/apache/lucene/analysis/KStemmer.java
 KStemData1.java, ..., KStemData8.java   Contain several lists of words 
 used by Kstem
 KStemmer.java  Implements the Kstem algorithm 
 KStemFilter.java Extends TokenFilter applying Kstem
 To compile
 unjar the file Kstem.jar to Lucene's src directory, and compile it 
 there. 
 What is Kstem?
   A stemmer designed by Bob Krovetz (for more information see 
 http://ciir.cs.umass.edu/pubfiles/ir-35.pdf). 
 Copyright issues
   This is open source. The actual license agreement is included at the 
 top of every source file.
  Any comments/questions/suggestions are welcome,
   Sergio Guzman-Lara
   Senior Research Fellow
   CIIR UMass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-152) [PATCH] KStem for Lucene

2011-06-01 Thread Yonik Seeley (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated LUCENE-152:


Attachment: lucid_kstem.tgz

OK folks, here's Lucid's optimized version of kstemmer.  Changes by Lucid to 
the original kstemmer are being contributed under the ASL.

This is not a patch, but simply a tarball of Lucid's version.  Not sure what we 
want to do with some of the stuff (like the biggish test files).

IIRC, there were two types of optimizations... one type was efficiency (i.e. 
using CharArrMap, directly using a char[] in the stemmer, etc).  Other 
optimizations actually changed the logic and code paths though, which is one 
reason I tested it over a whole document to ensure it still matched the 
original.

 [PATCH] KStem for Lucene
 

 Key: LUCENE-152
 URL: https://issues.apache.org/jira/browse/LUCENE-152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: unspecified
 Environment: Operating System: other
 Platform: Other
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: lucid_kstem.tgz


 September 10th 2003 contributionn from Sergio Guzman-Lara 
 guz...@cs.umass.edu
 Original email:
 Hi all,
   I have ported the kstem stemmer to Java and incorporated it to 
 Lucene. You can get the source code (Kstem.jar) from the following website:
 http://ciir.cs.umass.edu/downloads/
   Just click on KStem Java Implementation (you will need to register 
 your e-mail, for free of course, with the CIIR --Center for Intelligent 
 Information Retrieval, UMass -- and get an access code).
 Content of Kstem.jar:
 java/org/apache/lucene/analysis/KStemData1.java
 java/org/apache/lucene/analysis/KStemData2.java
 java/org/apache/lucene/analysis/KStemData3.java
 java/org/apache/lucene/analysis/KStemData4.java
 java/org/apache/lucene/analysis/KStemData5.java
 java/org/apache/lucene/analysis/KStemData6.java
 java/org/apache/lucene/analysis/KStemData7.java
 java/org/apache/lucene/analysis/KStemData8.java
 java/org/apache/lucene/analysis/KStemFilter.java
 java/org/apache/lucene/analysis/KStemmer.java
 KStemData1.java, ..., KStemData8.java   Contain several lists of words 
 used by Kstem
 KStemmer.java  Implements the Kstem algorithm 
 KStemFilter.java Extends TokenFilter applying Kstem
 To compile
 unjar the file Kstem.jar to Lucene's src directory, and compile it 
 there. 
 What is Kstem?
   A stemmer designed by Bob Krovetz (for more information see 
 http://ciir.cs.umass.edu/pubfiles/ir-35.pdf). 
 Copyright issues
   This is open source. The actual license agreement is included at the 
 top of every source file.
  Any comments/questions/suggestions are welcome,
   Sergio Guzman-Lara
   Senior Research Fellow
   CIIR UMass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-152) [PATCH] KStem for Lucene


[ 
https://issues.apache.org/jira/browse/LUCENE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042273#comment-13042273
 ] 

Robert Muir commented on LUCENE-152:


{quote}
This is not a patch, but simply a tarball of Lucid's version. Not sure what we 
want to do with some of the stuff (like the biggish test files)
{quote}

I don't think biggish test files are a problem personally, we already have 
these for the snowball stemmers for example.

 [PATCH] KStem for Lucene
 

 Key: LUCENE-152
 URL: https://issues.apache.org/jira/browse/LUCENE-152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: unspecified
 Environment: Operating System: other
 Platform: Other
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: lucid_kstem.tgz


 September 10th 2003 contributionn from Sergio Guzman-Lara 
 guz...@cs.umass.edu
 Original email:
 Hi all,
   I have ported the kstem stemmer to Java and incorporated it to 
 Lucene. You can get the source code (Kstem.jar) from the following website:
 http://ciir.cs.umass.edu/downloads/
   Just click on KStem Java Implementation (you will need to register 
 your e-mail, for free of course, with the CIIR --Center for Intelligent 
 Information Retrieval, UMass -- and get an access code).
 Content of Kstem.jar:
 java/org/apache/lucene/analysis/KStemData1.java
 java/org/apache/lucene/analysis/KStemData2.java
 java/org/apache/lucene/analysis/KStemData3.java
 java/org/apache/lucene/analysis/KStemData4.java
 java/org/apache/lucene/analysis/KStemData5.java
 java/org/apache/lucene/analysis/KStemData6.java
 java/org/apache/lucene/analysis/KStemData7.java
 java/org/apache/lucene/analysis/KStemData8.java
 java/org/apache/lucene/analysis/KStemFilter.java
 java/org/apache/lucene/analysis/KStemmer.java
 KStemData1.java, ..., KStemData8.java   Contain several lists of words 
 used by Kstem
 KStemmer.java  Implements the Kstem algorithm 
 KStemFilter.java Extends TokenFilter applying Kstem
 To compile
 unjar the file Kstem.jar to Lucene's src directory, and compile it 
 there. 
 What is Kstem?
   A stemmer designed by Bob Krovetz (for more information see 
 http://ciir.cs.umass.edu/pubfiles/ir-35.pdf). 
 Copyright issues
   This is open source. The actual license agreement is included at the 
 top of every source file.
  Any comments/questions/suggestions are welcome,
   Sergio Guzman-Lara
   Senior Research Fellow
   CIIR UMass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-152) [PATCH] KStem for Lucene


[ 
https://issues.apache.org/jira/browse/LUCENE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042275#comment-13042275
 ] 

Ryan McKinley commented on LUCENE-152:
--

I'm fine with the 1.2MB history_of_the_united_states.txt in the tests

 [PATCH] KStem for Lucene
 

 Key: LUCENE-152
 URL: https://issues.apache.org/jira/browse/LUCENE-152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: unspecified
 Environment: Operating System: other
 Platform: Other
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: lucid_kstem.tgz


 September 10th 2003 contributionn from Sergio Guzman-Lara 
 guz...@cs.umass.edu
 Original email:
 Hi all,
   I have ported the kstem stemmer to Java and incorporated it to 
 Lucene. You can get the source code (Kstem.jar) from the following website:
 http://ciir.cs.umass.edu/downloads/
   Just click on KStem Java Implementation (you will need to register 
 your e-mail, for free of course, with the CIIR --Center for Intelligent 
 Information Retrieval, UMass -- and get an access code).
 Content of Kstem.jar:
 java/org/apache/lucene/analysis/KStemData1.java
 java/org/apache/lucene/analysis/KStemData2.java
 java/org/apache/lucene/analysis/KStemData3.java
 java/org/apache/lucene/analysis/KStemData4.java
 java/org/apache/lucene/analysis/KStemData5.java
 java/org/apache/lucene/analysis/KStemData6.java
 java/org/apache/lucene/analysis/KStemData7.java
 java/org/apache/lucene/analysis/KStemData8.java
 java/org/apache/lucene/analysis/KStemFilter.java
 java/org/apache/lucene/analysis/KStemmer.java
 KStemData1.java, ..., KStemData8.java   Contain several lists of words 
 used by Kstem
 KStemmer.java  Implements the Kstem algorithm 
 KStemFilter.java Extends TokenFilter applying Kstem
 To compile
 unjar the file Kstem.jar to Lucene's src directory, and compile it 
 there. 
 What is Kstem?
   A stemmer designed by Bob Krovetz (for more information see 
 http://ciir.cs.umass.edu/pubfiles/ir-35.pdf). 
 Copyright issues
   This is open source. The actual license agreement is included at the 
 top of every source file.
  Any comments/questions/suggestions are welcome,
   Sergio Guzman-Lara
   Senior Research Fellow
   CIIR UMass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-152) [PATCH] KStem for Lucene


[ 
https://issues.apache.org/jira/browse/LUCENE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042278#comment-13042278
 ] 

Robert Muir commented on LUCENE-152:


we can zip it anyway, the existing stemmer tests use zipped files for this 
exact purpose.
zipped: all the test data is about 500KB

our snowball test data currently in src/test is zipped 3.1MB... so I think 
500kb is ok.

 [PATCH] KStem for Lucene
 

 Key: LUCENE-152
 URL: https://issues.apache.org/jira/browse/LUCENE-152
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/analysis
Affects Versions: unspecified
 Environment: Operating System: other
 Platform: Other
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 3.3, 4.0

 Attachments: lucid_kstem.tgz


 September 10th 2003 contributionn from Sergio Guzman-Lara 
 guz...@cs.umass.edu
 Original email:
 Hi all,
   I have ported the kstem stemmer to Java and incorporated it to 
 Lucene. You can get the source code (Kstem.jar) from the following website:
 http://ciir.cs.umass.edu/downloads/
   Just click on KStem Java Implementation (you will need to register 
 your e-mail, for free of course, with the CIIR --Center for Intelligent 
 Information Retrieval, UMass -- and get an access code).
 Content of Kstem.jar:
 java/org/apache/lucene/analysis/KStemData1.java
 java/org/apache/lucene/analysis/KStemData2.java
 java/org/apache/lucene/analysis/KStemData3.java
 java/org/apache/lucene/analysis/KStemData4.java
 java/org/apache/lucene/analysis/KStemData5.java
 java/org/apache/lucene/analysis/KStemData6.java
 java/org/apache/lucene/analysis/KStemData7.java
 java/org/apache/lucene/analysis/KStemData8.java
 java/org/apache/lucene/analysis/KStemFilter.java
 java/org/apache/lucene/analysis/KStemmer.java
 KStemData1.java, ..., KStemData8.java   Contain several lists of words 
 used by Kstem
 KStemmer.java  Implements the Kstem algorithm 
 KStemFilter.java Extends TokenFilter applying Kstem
 To compile
 unjar the file Kstem.jar to Lucene's src directory, and compile it 
 there. 
 What is Kstem?
   A stemmer designed by Bob Krovetz (for more information see 
 http://ciir.cs.umass.edu/pubfiles/ir-35.pdf). 
 Copyright issues
   This is open source. The actual license agreement is included at the 
 top of every source file.
  Any comments/questions/suggestions are welcome,
   Sergio Guzman-Lara
   Senior Research Fellow
   CIIR UMass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 8521 - Still Failing

Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/8521/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexReader.testDiskFull

Error Message:
Cannot setNorm for field contents: norms were omitted

Stack Trace:
java.lang.IllegalStateException: Cannot setNorm for field contents: norms were 
omitted
at 
org.apache.lucene.index.SegmentReader.doSetNorm(SegmentReader.java:599)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at 
org.apache.lucene.index.DirectoryReader.doSetNorm(DirectoryReader.java:670)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:963)
at 
org.apache.lucene.index.TestIndexReader.testDiskFull(TestIndexReader.java:942)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1107)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1039)




Build Log (for compile errors):
[...truncated 8473 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2562) Solr binary package should include script files (for backup/replication)

2011-06-01 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042337#comment-13042337
 ] 

Yonik Seeley commented on SOLR-2562:


I think the old replication method that relied on scripts and a unix filesystem 
has been deprecated?

 Solr binary package should include script files (for backup/replication)
 

 Key: SOLR-2562
 URL: https://issues.apache.org/jira/browse/SOLR-2562
 Project: Solr
  Issue Type: Task
  Components: replication (scripts)
Affects Versions: 3.1, 3.2, 4.0
Reporter: Koji Sekiguchi
Priority: Trivial
 Fix For: 3.3, 4.0


 Solr binary package (apache-solr-x.x.x.tgz) should include script files for 
 backup/replication (e.g. abc, snappuller, snapinstaller, ...).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-2496) JSON Update Handler doesn't handle multiple docs properly

2011-06-01 Thread Yonik Seeley (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley resolved SOLR-2496.


   Resolution: Fixed
Fix Version/s: 3.2

 JSON Update Handler doesn't handle multiple docs properly
 -

 Key: SOLR-2496
 URL: https://issues.apache.org/jira/browse/SOLR-2496
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 3.1
Reporter: Neil Hooey
  Labels: json, update
 Fix For: 3.2

 Attachments: SOLR-2496.patch


 The following is the current Solr 3.1 format for sending multiple documents 
 by JSON. It's not analogous to the XML method, and isn't easily generated and 
 serialized from a hash in Perl, Python, Ruby, et al to JSON, because it has 
 duplicate keys for add.
 It's cited at this page: http://wiki.apache.org/solr/UpdateJSON
 Near the text: Here's a simple example of adding more than one document at 
 once:
 {code}
 {
 add: {doc: {id : TestDoc1, title : test1} },
 add: {doc: {id : TestDoc2, title : another test} }
 }'
 {code}
 Here's a better format that's analogous to the XML method of submission, and 
 is easily serialized from a hash to JSON:
 {code}
 {
 add: {
 doc: [
 {id : TestDoc1, title : test1},
 {id : TestDoc2, title : another test},
 ],
 },
 }
 {code}
 The original XML method:
 {code}
 add
 doc
field name=idTestDoc1fieldfield name=titletest1/field
 /doc
 doc
field name=idTestDoc2fieldfield 
 name=titletest2/field/field
 /doc
 /add
 {code}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-1901) bug using distributed search, highlighting and q.alt

2011-06-01 Thread Dylan Etkin (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042341#comment-13042341
 ] 

Dylan Etkin commented on SOLR-1901:
---

I am using solr 3.1.0 and the linked issue SOLR-2121 still exists.

I can confirm that applying the patch from the linked issue causes the NPE to 
go away.

Perhaps this issue is fixed but the linked issue is not really a duplicate.

 bug using distributed search, highlighting and q.alt
 

 Key: SOLR-1901
 URL: https://issues.apache.org/jira/browse/SOLR-1901
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 1.5
Reporter: Marc Sturlese
Priority: Minor
 Fix For: 3.1


 I have noticed when using q.alt even if hl=true highlights are not returned.
 When using distributed search, q.alt and hl, HighlightComponent.java
 finishStage expects the highlighting NamedList of each shard (if hl=true)
 but it will never be returned. It will end up with a NullPointerExcepion.
 I have temporally solved it checking that highlight NamedList is always
 returned for each shard. If it's not the case, highlights are not added to
 the response:
   @Override
   public void finishStage(ResponseBuilder rb) {
 boolean hasHighlighting = true ;
 if (rb.doHighlights  rb.stage == ResponseBuilder.STAGE_GET_FIELDS) {
   Map.EntryString, Object[] arr = new
 NamedList.NamedListEntry[rb.resultIds.size()];
   // TODO: make a generic routine to do automatic merging of id keyed
 data
   for (ShardRequest sreq : rb.finished) {
 if ((sreq.purpose  ShardRequest.PURPOSE_GET_HIGHLIGHTS) == 0)
 continue;
 for (ShardResponse srsp : sreq.responses) {
   NamedList hl =
 (NamedList)srsp.getSolrResponse().getResponse().get(highlighting);
   if(hl != null) {
 for (int i=0; ihl.size(); i++) {
  String id = hl.getName(i);
  ShardDoc sdoc = rb.resultIds.get(id);
  int idx = sdoc.positionInResponse;
  arr[idx] = new NamedList.NamedListEntry(id,
 hl.getVal(i));
 }
   } else {
 hasHighlighting = false;
   }
 }
   }
   // remove nulls in case not all docs were able to be retrieved
   if(hasHighlighting) {
 rb.rsp.add(highlighting, removeNulls(new SimpleOrderedMap(arr)));
   }
 }
   } 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2121) distributed highlighting using q.alt=: causes NPE in finishStages

2011-06-01 Thread Dylan Etkin (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042342#comment-13042342
 ] 

Dylan Etkin commented on SOLR-2121:
---

This issue still exists in solr 3.1.0.

The code snippet in the second comment does stop the NPE from happening.

 distributed highlighting using q.alt=*:* causes NPE in finishStages
 ---

 Key: SOLR-2121
 URL: https://issues.apache.org/jira/browse/SOLR-2121
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man

 As noted on the mailing list by Ron Mayer,  using the example configs and 
 example data on trunk, this query works...
 http://localhost:8983/solr/select?q.alt=*:*hl=ondefType=edismax
 ...but this query causes and NullPointerException...
 http://localhost:8983/solr/select?q.alt=*:*hl=ondefType=edismaxshards=localhost:8983/solr
 Stack Trace...
 {noformat}
 java.lang.NullPointerException
   at 
 org.apache.solr.handler.component.HighlightComponent.finishStage(HighlightComponent.java:158)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:310)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:337)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:240)
   at 
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
 {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 8522 - Still Failing

Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/8522/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexReader.testDiskFull

Error Message:
Cannot setNorm for field contents: norms were omitted

Stack Trace:
java.lang.IllegalStateException: Cannot setNorm for field contents: norms were 
omitted
at 
org.apache.lucene.index.SegmentReader.doSetNorm(SegmentReader.java:599)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at 
org.apache.lucene.index.DirectoryReader.doSetNorm(DirectoryReader.java:670)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:963)
at 
org.apache.lucene.index.TestIndexReader.testDiskFull(TestIndexReader.java:942)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1107)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1039)




Build Log (for compile errors):
[...truncated 8384 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Welcome Martijn van Groningen as Lucene/Solr committer

2011-06-01 Thread Michael McCandless

The Lucene PMC has voted to add Martijn van Groningen as a Lucene/Solr
committer.

The traditional initiation ritual is to introduce yourself with a
brief bio of how it is you came to join us :)

Plus, once your account is set up, to add yourself to the Who We Are
page source, then re-generate and re-publish the site.

Welcome, Martijn!

Mike McCandless

http://blog.mikemccandless.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 8523 - Still Failing

Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/8523/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexReader.testDiskFull

Error Message:
Cannot setNorm for field contents: norms were omitted

Stack Trace:
java.lang.IllegalStateException: Cannot setNorm for field contents: norms were 
omitted
at 
org.apache.lucene.index.SegmentReader.doSetNorm(SegmentReader.java:599)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at 
org.apache.lucene.index.DirectoryReader.doSetNorm(DirectoryReader.java:670)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:963)
at 
org.apache.lucene.index.TestIndexReader.testDiskFull(TestIndexReader.java:942)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1107)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1039)




Build Log (for compile errors):
[...truncated 8384 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2459) LogLevelSelection Servlet outputs plain HTML


 [ 
https://issues.apache.org/jira/browse/SOLR-2459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-2459:


Attachment: sample-output.json
sample-output.xml
LogLevelHandler.patch

Here's a first pass at the handler. I'm sure the output format is wrong, but 
the (limited) tests pass (it changes a value, then puts it back).

I've included an XML and a JSON sample output.

Is this more or less what we're after? 


 LogLevelSelection Servlet outputs plain HTML
 

 Key: SOLR-2459
 URL: https://issues.apache.org/jira/browse/SOLR-2459
 Project: Solr
  Issue Type: Wish
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Trivial
 Attachments: LogLevelHandler.patch, sample-output.json, 
 sample-output.xml


 The current available Output of the LogLevelSelection Servlet is plain HTML, 
 which made it unpossible, to integrate the Logging-Information in the new 
 Admin-UI. Format-Agnostic Output (like every [?] other Servlet offers) would 
 be really nice!
 Just as an Idea for a future structure, the new admin-ui is [actually based 
 on that 
 json-structure|https://github.com/steffkes/solr-admin/blob/master/logging.json]
  :)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-3099) Grouping module should allow subclasses to set the group key per document

2011-06-01 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13042377#comment-13042377
 ] 

Michael McCandless commented on LUCENE-3099:


I think we are close here!  It's great to see you're able to cutover
Solr trunk to the grouping module based on this.

Random things:

  * I think we can in fact use Map... instead of HashMap... in 2nd
pass abstract collector?

  * Can you add @SuppressWarnings(unchecked) for the generic array
creations?

  * Can you fix the other generics warnings?  Eg the copy-ctor in
TopGroups, and TestGrouping has a few warnings.  (ant clean
compile-test should show all these warnings).

  * The class in AllGroupsCollectorTest needs to be renamed

  * OK, let's leave groupDocs as protected in the 2nd pass collector
(remove the nocommit/your response).

  * For AbstractAllGroupsCollector, can we impl the getGroupCount in
the base class as getGroups.size()?


 Grouping module should allow subclasses to set the group key per document
 -

 Key: LUCENE-3099
 URL: https://issues.apache.org/jira/browse/LUCENE-3099
 Project: Lucene - Java
  Issue Type: Improvement
Reporter: Michael McCandless
 Fix For: 3.2, 4.0

 Attachments: LUCENE-3099.patch, LUCENE-3099.patch, LUCENE-3099.patch, 
 LUCENE-3099.patch, LUCENE-3099.patch


 The new grouping module can only group by a single-valued indexed field.
 But, if we make the 'getGroupKey' a method that a subclass could override, 
 then I think we could refactor Solr over to the module, because it could do 
 function queries and normal queries via subclass (I think).
 This also makes the impl more extensible to apps that might have their own 
 interesting group values per document.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 8522 - Failure

Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/8522/

All tests passed

Build Log (for compile errors):
[...truncated 12008 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Martijn van Groningen as Lucene/Solr committer

Welcome Martijn!

On Wed, Jun 1, 2011 at 3:01 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 The Lucene PMC has voted to add Martijn van Groningen as a Lucene/Solr
 committer.

 The traditional initiation ritual is to introduce yourself with a
 brief bio of how it is you came to join us :)

 Plus, once your account is set up, to add yourself to the Who We Are
 page source, then re-generate and re-publish the site.

 Welcome, Martijn!

 Mike McCandless

 http://blog.mikemccandless.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 8522 - Failure

2011-06-01 Thread Michael McCandless

False failure -- once again failure to load:

javadoc: warning - Error fetching URL:
http://java.sun.com/j2se/1.5/docs/api/package-list

Maybe we should switch to the local cache of this package-list... I
mean it's not like it changes that often ;)

Mike McCandless

http://blog.mikemccandless.com

On Wed, Jun 1, 2011 at 3:29 PM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
 Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/8522/

 All tests passed

 Build Log (for compile errors):
 [...truncated 12008 lines...]



 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Martijn van Groningen as Lucene/Solr committer

2011-06-01 Thread Dawid Weiss

Welcome, Martijn!

Dawid

On Wed, Jun 1, 2011 at 9:29 PM, Robert Muir rcm...@gmail.com wrote:

 Welcome Martijn!

 On Wed, Jun 1, 2011 at 3:01 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
  The Lucene PMC has voted to add Martijn van Groningen as a Lucene/Solr
  committer.
 
  The traditional initiation ritual is to introduce yourself with a
  brief bio of how it is you came to join us :)
 
  Plus, once your account is set up, to add yourself to the Who We Are
  page source, then re-generate and re-publish the site.
 
  Welcome, Martijn!
 
  Mike McCandless
 
  http://blog.mikemccandless.com
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 8522 - Failure

On Wed, Jun 1, 2011 at 3:34 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 False failure -- once again failure to load:

 javadoc: warning - Error fetching URL:
 http://java.sun.com/j2se/1.5/docs/api/package-list

 Maybe we should switch to the local cache of this package-list... I
 mean it's not like it changes that often ;)


is this possible to avoid going to java.sun.com? If so, I think we
should do this, now that the tests run so often.
Perhaps the servers are busier during the US workday and it will fail
often if we don't.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-2571) IndexBasedSpellChecker thresholdTokenFrequency fails with a ClassCastException on startup

2011-06-01 Thread James Dyer (JIRA)

IndexBasedSpellChecker thresholdTokenFrequency fails with a 
ClassCastException on startup
---

 Key: SOLR-2571
 URL: https://issues.apache.org/jira/browse/SOLR-2571
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 3.1, 1.4.1, 4.0
Reporter: James Dyer
Priority: Minor
 Fix For: 3.3, 4.0


When parsing the configuration for thresholdTokenFrequency, the 
IndexBasedSpellChecker tries to pull a Float from the DataConfig.xml-derrived 
NamedList.  However, this comes through as a String.  Therefore, a 
ClassCastException is always thrown whenever this parameter is specified.  The 
code ought to be doing Float.parseFloat(...) on the value.

This looks like a nice feature to use in cases the data contains misspelled or 
rare words leading to spurious correct queries.  I would have liked to have 
used this with a project we just completed however this bug prevented that.  
This issue came up recently in the User's mailing list so I am raising an issue 
now.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-3.x - Build # 8524 - Still Failing

Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/8524/

1 tests failed.
REGRESSION:  org.apache.lucene.index.TestIndexReader.testDiskFull

Error Message:
Cannot setNorm for field contents: norms were omitted

Stack Trace:
java.lang.IllegalStateException: Cannot setNorm for field contents: norms were 
omitted
at 
org.apache.lucene.index.SegmentReader.doSetNorm(SegmentReader.java:599)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at 
org.apache.lucene.index.DirectoryReader.doSetNorm(DirectoryReader.java:670)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:963)
at 
org.apache.lucene.index.TestIndexReader.testDiskFull(TestIndexReader.java:942)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1107)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1039)




Build Log (for compile errors):
[...truncated 8378 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-3.x - Build # 8524 - Still Failing

I just committed a fix for this test.

On Wed, Jun 1, 2011 at 3:40 PM, Apache Jenkins Server
hud...@hudson.apache.org wrote:
 Build: https://builds.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/8524/

 1 tests failed.
 REGRESSION:  org.apache.lucene.index.TestIndexReader.testDiskFull

 Error Message:
 Cannot setNorm for field contents: norms were omitted

 Stack Trace:
 java.lang.IllegalStateException: Cannot setNorm for field contents: norms 
 were omitted
        at 
 org.apache.lucene.index.SegmentReader.doSetNorm(SegmentReader.java:599)
        at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
        at 
 org.apache.lucene.index.DirectoryReader.doSetNorm(DirectoryReader.java:670)
        at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:935)
        at org.apache.lucene.index.IndexReader.setNorm(IndexReader.java:963)
        at 
 org.apache.lucene.index.TestIndexReader.testDiskFull(TestIndexReader.java:942)
        at 
 org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1107)
        at 
 org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1039)




 Build Log (for compile errors):
 [...truncated 8378 lines...]



 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-2571) IndexBasedSpellChecker thresholdTokenFrequency fails with a ClassCastException on startup

2011-06-01 Thread James Dyer (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Dyer updated SOLR-2571:
-

Attachment: SOLR-2571.solr3.2.patch
SOLR-2571.patch

Patches attached for Trunk 3.x .

This patch fixes the problem for IndexBasedSpellChecker.
DirectSolrSpellChecker (Trunk only) appears to be correct already.

Should this patch be committed, I will add documentation for
thresholdTokenFrequency to the wiki. Currently it is absent from the wiki
(although documented in SmileyPugh).

IndexBasedSpellChecker thresholdTokenFrequency fails with a
ClassCastException on startup
---

Key: SOLR-2571
URL: https://issues.apache.org/jira/browse/SOLR-2571
Project: Solr
Issue Type: Bug
Components: spellchecker
Affects Versions: 1.4.1, 3.1, 4.0
Reporter: James Dyer
Priority: Minor
Fix For: 3.3, 4.0

Attachments: SOLR-2571.patch, SOLR-2571.solr3.2.patch

When parsing the configuration for thresholdTokenFrequency, the
IndexBasedSpellChecker tries to pull a Float from the DataConfig.xml-derrived
NamedList. However, this comes through as a String. Therefore, a
ClassCastException is always thrown whenever this parameter is specified.
The code ought to be doing Float.parseFloat(...) on the value.
This looks like a nice feature to use in cases the data contains misspelled
or rare words leading to spurious correct queries. I would have liked to
have used this with a project we just completed however this bug prevented
that. This issue came up recently in the User's mailing list so I am raising
an issue now.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Martijn van Groningen as Lucene/Solr committer

2011-06-01 Thread Simon Willnauer

Welcome! :)

On Wed, Jun 1, 2011 at 9:35 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:

 Welcome, Martijn!
 Dawid

 On Wed, Jun 1, 2011 at 9:29 PM, Robert Muir rcm...@gmail.com wrote:

 Welcome Martijn!

 On Wed, Jun 1, 2011 at 3:01 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
  The Lucene PMC has voted to add Martijn van Groningen as a Lucene/Solr
  committer.
 
  The traditional initiation ritual is to introduce yourself with a
  brief bio of how it is you came to join us :)
 
  Plus, once your account is set up, to add yourself to the Who We Are
  page source, then re-generate and re-publish the site.
 
  Welcome, Martijn!
 
  Mike McCandless
 
  http://blog.mikemccandless.com
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Welcome Erick Erickson as Lucene/Solr committer