You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Trejkaz (JIRA)" <ji...@apache.org> on 2009/05/20 03:57:45 UTC
[jira] Created: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
QueryParser throws new exceptions even if custom parsing logic threw a better one
---------------------------------------------------------------------------------
Key: LUCENE-1646
URL: https://issues.apache.org/jira/browse/LUCENE-1646
Project: Lucene - Java
Issue Type: Improvement
Affects Versions: 2.4.1
Reporter: Trejkaz
We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
Problem is, Lucene's QueryParser is doing this:
{code}
catch (ParseException tme) {
// rethrow to include the original query:
throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
}
{code}
Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727212#action_12727212 ]
Michael McCandless commented on LUCENE-1646:
--------------------------------------------
Woops, thanks Uwe.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
> Fix For: 2.9
>
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1646) QueryParser throws new
exceptions even if custom parsing logic threw a better one
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727209#action_12727209 ]
Uwe Schindler edited comment on LUCENE-1646 at 7/4/09 2:09 AM:
---------------------------------------------------------------
Mike: For LUCENE-1713, I recreated the QueryParser with javacc (because some changes in creation of RangeQueries), but the produced QueryParser.java did not contain your changes.
I copied your initCause() lines to QueryParser.jj and then it worked, I commit this together with LUCENE-1713.
By the way: The query parser is only created correctly with JavaCC 4.1, version 4.2 produces some wrong escaped chars.
was (Author: thetaphi):
Mike: After LUCENE-1713, I recreated the QueryParser with javacc (because some changes in creation of RangeQueries), but the produced QueryParser.java did not contain your changes.
I copied your initCause() lines to QueryParser.jj and then it worked, I commit this together with LUCENE-1713.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
> Fix For: 2.9
>
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Trejkaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711412#action_12711412 ]
Trejkaz commented on LUCENE-1646:
---------------------------------
I guess that's true if you look at exceptions as a logging mechanism, but in our case it's a parsing exception for text coming from the user. Because of this, our use case is for the user to get a useful error message, and it's not useful at all if we just tell them their entire query was bad. Thus we have inserted improvements (in our subclass) to make it complain only about the fragment of the query which is actually a problem, so they know which part to fix.
Related, but is there any way it could at least be reduced to the portion of the query which caused the problem? In a way it would be nice if ParseException had methods to get out the problematic fragment (my subclass has it...) I'm guessing this is much easier for exceptions relating to values inside fields which otherwise parsed correctly, but a lot harder to do for exceptions from the parser proper.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Trejkaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711850#action_12711850 ]
Trejkaz commented on LUCENE-1646:
---------------------------------
Our improvements are (so far) specific to our subclass of QueryParser, in that we use it when getFieldQuery() gets a value which doesn't make sense for the given field.
So in a sense, in our case the query was parsed successfully by the parser, but the input was invalid within one of the fields. As such our custom ParseException subclass has the field name and field value, but it isn't useful to the Lucene project as-is, as the only things throwing it are called from our subclass. :-(
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721427#action_12721427 ]
Hoss Man commented on LUCENE-1646:
----------------------------------
As a general rule, code catching an execption and throwing a new exception with more details should (almost always) call initCause (unless the new Exception has a constructor that takes care of that part) to preserve all of the stack history.
Client code that wants to get at the root exception can do so using getCause()
In QueryParser...
{code}
} catch (ParseException tme) {
// rethrow to include the original query:
ParseException e = new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
e.initCause(tme);
throw e;
}
{code}
In Trejkaz's code, something like...
{code}
} catch (ParseException pexp) {
for (Throwable t = pexp; null != t; t = t.getCause()) {
if (t instanceof OurCustomException) {
takeActionOnCustomException((OurCustomException)t);
}
takeActionOnLuceneQueryParserException(exp)
}
}
{code}
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Resolved: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-1646.
----------------------------------------
Resolution: Fixed
Fix Version/s: 2.9
Thanks Trejkaz and Hoss!
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
> Fix For: 2.9
>
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711096#action_12711096 ]
Michael McCandless commented on LUCENE-1646:
--------------------------------------------
I agree it's bad that the root cause (stack trace) is discarded by the exception handler, so we should fix that, but I think adding the query text in the exception's message is in fact useful for debugging -- this exception will likely get captured & generically logged somewhere, only to be seen later at which point you really do want to know which query text caused it.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723265#action_12723265 ]
Michael McCandless commented on LUCENE-1646:
--------------------------------------------
I agree Hoss; I'll fix QueryParser to initCause when it catches & rethrows.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711570#action_12711570 ]
Michael McCandless commented on LUCENE-1646:
--------------------------------------------
bq. I guess that's true if you look at exceptions as a logging mechanism, but in our case it's a parsing exception for text coming from the user. Because of this, our use case is for the user to get a useful error message, and it's not useful at all if we just tell them their entire query was bad. Thus we have inserted improvements (in our subclass) to make it complain only about the fragment of the query which is actually a problem, so they know which part to fix.
I agree, in general an app ought to be catching this ParseException
and messaging something much more succinct/digestible to the end
user.
When QueryParser throws ParseException, it does attempt to explain
what went wrong in many cases. It sounds like you've modified it
further to do a better job? Is this something you could donate back?
I agree we should make it easier to customize the ParseException, but
I think by default having the exception message include the full query
is useful for those apps that simply log the exception. This way we
can have our cake and eat it too...
bq. Related, but is there any way it could at least be reduced to the portion of the query which caused the problem? In a way it would be nice if ParseException had methods to get out the problematic fragment (my subclass has it...) I'm guessing this is much easier for exceptions relating to values inside fields which otherwise parsed correctly, but a lot harder to do for exceptions from the parser proper.
It seems like it already makes some effort here? Eg it has
attrs like currentToken, expectedTokenSequences,
etc., recorded when the exception is thrown. And getMessage()
pulls from these attrs to build up the message? Can you post a patch
with your improvements here?
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions
even if custom parsing logic threw a better one
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727209#action_12727209 ]
Uwe Schindler commented on LUCENE-1646:
---------------------------------------
Mike: After LUCENE-1713, I recreated the QueryParser with javacc (because some changes in creation of RangeQueries), but the produced QueryParser.java did not contain your changes.
I copied your initCause() lines to QueryParser.jj and then it worked, I commit this together with LUCENE-1713.
> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.4.1
> Reporter: Trejkaz
> Fix For: 2.9
>
>
> We have subclassed QueryParser and have various custom fields. When these fields contain invalid values, we throw a subclass of ParseException which has a more useful message (and also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
> catch (ParseException tme) {
> // rethrow to include the original query:
> throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
> }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information about what's actually wrong with the query (it does append getMessage() but that isn't localised. And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what the query string was (they have to have a copy of it because they are passing it in!) so having it in the error message itself is not useful. Furthermore, when the query string is very big, what the user wants to know is not that the whole query was bad, but which part of it was bad.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org