I'm having a problem using mylyn jira connector with jira 6.1
I have some queries configured, which work, but now I can't add a new query.
I've tried adding the same query as a filter import and using the eclipse form.
In both cases I get the following error message, even though the query itself doesn't contain any percent characters:
Error in the JQL Query: The character '%' is a reserved JQL
character. You must enclose it in a string or use the escape '\u0025'
instead. (line 1, character 13)
com.atlassian.connector.eclipse.internal.jira.core.service.JiraException: Error in the JQL Query: The character '%' is a reserved JQL character. You must enclose it in a string or use the escape '\u0025' instead. (line 1, character 13)
at com.atlassian.connector.eclipse.internal.jira.core.service.rest.JiraRestClientAdapter.call(JiraRestClientAdapter.java:765)
at com.atlassian.connector.eclipse.internal.jira.core.service.rest.JiraRestClientAdapter.getIssues(JiraRestClientAdapter.java:314)
at com.atlassian.connector.eclipse.internal.jira.core.service.JiraClient.findIssues(JiraClient.java:371)
at com.atlassian.connector.eclipse.internal.jira.core.service.JiraClient.findIssues(JiraClient.java:363)
at com.atlassian.connector.eclipse.internal.jira.core.service.JiraClient.search(JiraClient.java:760)
at com.atlassian.connector.eclipse.internal.jira.core.JiraRepositoryConnector.performQuery(JiraRepositoryConnector.java:140)
at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeQueriesJob.synchronizeQuery(SynchronizeQueriesJob.java:311)
at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeQueriesJob.synchronizeQueries(SynchronizeQueriesJob.java:268)
at org.eclipse.mylyn.internal.tasks.core.sync.SynchronizeQueriesJob.run(SynchronizeQueriesJob.java:201)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: com.atlassian.jira.rest.client.RestClientException: Error in the JQL Query: The character '%' is a reserved JQL character. You must enclose it in a string or use the escape '\u0025' instead. (line 1, character 13)
at com.atlassian.jira.rest.client.internal.jersey.AbstractJerseyRestClient.invoke(AbstractJerseyRestClient.java:76)
at com.atlassian.jira.rest.client.internal.jersey.AbstractJerseyRestClient.getAndParse(AbstractJerseyRestClient.java:88)
at com.atlassian.jira.rest.client.internal.jersey.JerseySearchRestClient.searchJqlImpl(JerseySearchRestClient.java:107)
at com.atlassian.jira.rest.client.internal.jersey.JerseySearchRestClient.searchJql(JerseySearchRestClient.java:74)
at com.atlassian.connector.eclipse.internal.jira.core.service.rest.JiraRestClientAdapter$5.call(JiraRestClientAdapter.java:318)
at com.atlassian.connector.eclipse.internal.jira.core.service.rest.JiraRestClientAdapter$5.call(JiraRestClientAdapter.java:1)
at com.atlassian.connector.eclipse.internal.jira.core.service.rest.JiraRestClientAdapter.call(JiraRestClientAdapter.java:730)
... 9 more
Caused by: com.sun.jersey.api.client.UniformInterfaceException: Client response status: 400
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:607)
at com.sun.jersey.api.client.WebResource.get(WebResource.java:187)
at com.atlassian.jira.rest.client.internal.jersey.AbstractJerseyRestClient$1.call(AbstractJerseyRestClient.java:92)
at com.atlassian.jira.rest.client.internal.jersey.AbstractJerseyRestClient.invoke(AbstractJerseyRestClient.java:62)
... 15 more
I know that this is old, by just in case anyone else gets here...
I got this error by missing the 's' in https when setting up task repo. Added the 's' and hit re-validate. It solved the problem.
The error was quite misleading.
Unfortunately I was unable to edit #Jacek anwser, so let me put it here:
The problem was caused by a faulty configuration of Apache server in front of JIRA. If you run into a similar situation rigt-click on the query to open it in the browser - it's much easier to check what's going on that way.
And Atlassian, please make the error reports more intelligible.
A new bug has been created for "Atlassian Connector for Eclipse" to address this issue.
Specifically, let us know your JQL query. I wonder if there is any space character in the place we do not escape.
It turns out that the problem was caused by a faulty configuration of Apache server in front of JIRA. If you run into a similar situation rigt-click on the query to open it in the browser - it's much easier to check what's going on that way.
Related
I am using flutter_localizations to localize my app.
Since updating to Flutter 3.7 i am getting this error:
ICU Syntax Error: Expected "identifier" but found "}".
This =|(){}[] obviously
This =|\(){}[] obviously is the text that i have in my .arb file.
I understand that curly braces "{}" have a special meaning and should be escaped, but i can not find the way to correctly escape them, has anyone managed to do so?
One simple way to reproduce the issue is simply following the steps to add localization support here, and then instead of the hello world string, write anything that includes the character "{".
P.S.: There is a releted issue open on Github. Be sure to go and check there for updates!
There is an escaping syntax that is implemented but not enabled by default as it is a new feature that wasn't completely backward compatible with existing ICU message strings.
First, add the following to your l10n.yaml file:
use-escaping: true
Then, this will allow you to wrap parts of your strings in single quotes to ignore any syntax within the single quotes; to use a single quote normally as a character and not an escape, use a double single quote. For example,
{
message: "This '{isn''t}' obvious"
}
becomes
String get message => "This {isn't} obvious";
See here for information on the syntax. I'll add this to the documentation later.
I'm importing Turtle files into Neo4j with the Neosemantics plugin.
However, I'm getting an error with the fetch() function.
It says "Unexpected character U+1056D6 at index 32", and I think it's an encoding error (maybe I should use UTF-32?)
How do I change encoding settings for Neosemantics or ignore this error? Thanks.
I've been playing around with postgresqls text search capability and I've encountered what I consider weird behaviour. This is on postgresql 8.3 so it may not be current behaviour:
select to_tsvector('some#email.com') ## to_tsquery('some#email.com:*');
select to_tsvector('some#email.com') ## to_tsquery('some#email.c:*');
The first query matches but the second fails...
does anyone know what is going on here?
I've tried escaping the # and . characters but no luck
I can do this:
/<post_id>/comments?filter=stream&limit=100&after=<cursor>
But this doesn't work:
/<post_id>?fields=comments.filter(stream).limit(100).after(<cursor>)
Am I missing something in the syntax? Though cursor-based paging and field expansion were launched a the same time, their respective docs don't reflect each other.
Just figured this out (I think).
Most cursors have an = (equals sign) appended to them. For example: MzA=
This causes this syntax error in field expansion:
Syntax error "Expected ")" instead of '".' at character 79: comments.filter(stream).limit(10).summary(true).fields(id,like_count).after(NDA"
However, stripping the trailing = resolves the syntax error and results seem to paginate as expected.
We have website that uses this query:
SELECT did, kid FROM top_keywords WHERE MATCH('#keyword "^EXAMPLE KEYWORD$"') LIMIT 0,
100;
It works great in 99% times, but with some encoding it doesn't work. Example:
SELECT did, kid FROM top_keywords WHERE MATCH('#keyword "^εργον$"') LIMIT 0, 100;
Produces error:
ERROR 1064 (42000): index top_keywords: syntax error, unexpected '$', expecting
TOK_KEYWORD or TOK_INT near 'εργον$"'
My sphinx version is 2.0.6.
My only idea is that has something to do with conf-charset-type.
I tried copy/pasting your word εργον into
http://software.hixie.ch/utilities/cgi/unicode-decoder/utf8-decoder
It appears to be composed entirely of non-ascii UTF8 chars. (ie the codes are all 255+)
So, ALL those letters whould need to be in charset_table for it to work.
I'm guessing they are not in you charset_table (just setting charset_type=utf8 is NOT enough), in which case they are completely stripped, so the query becomes
SELECT did, kid FROM top_keywords WHERE MATCH('#keyword "^ $"') LIMIT 0, 100;
... as the letters are all taken as seperators, which clearly leaves you an invalid query.
Unfortunately I can't give you any good references for charset_table for international support (dont know any!), but perhaps start on the wiki http://sphinxsearch.com/wiki/doku.php?do=search&id=charset_table