At least I found a good explanation here:
https://issues.apache.org/jira/browse/STANBOL-437
"This is because of the Filter introduced for STANBOL-401. I have seen
this as well have looked into it on more detail and come to the
conclusion that is save.
Quote from the first resource linked below:
> It is informing you that the request entity of media type "application/
> x-www-form-urlencoded" has been consumed by the Servlet layer,
> probably by a servlet filter when one of the methods
> ServletRequest.getParameter* is called.
>
> Servlet does not distinguish between query parameters and form
> parameters when parameters are obtained. So if a form-based request
> entity is present and parameters are obtained it will consume that
> entity thus leaving Jersey with no entity to consume. So Jersey can
> only keep on working in this respect using @FormParam in conjunction
> with the Servlet parameters.
>
> Jersey cannot reliably construct bytes of the request entity because
> query and form parameters are merged together into the servlet
> parameters."
I'm wondering how to solve this now, though... :(
Cheers,
Stefan
Am 03.12.2014 um 17:06 schrieb Michael Sokolov:
Stefan I had problems like this -- and the short answer is -- it's a
PITA. Solr is not really designed to be extended in this way. In
fact I believe they are moving towards an architecture where this is
even less possible - folks will be encouraged to run solr using a
bundled exe, perhaps with jetty embedded (I'm not all up to speed on
this, maybe someone will correct me), and no war file shipped.
So perhaps a better strategy is to wrap the service at the HTTP layer
using a proxy.
Still, you can probably fix your immediate problem by extending Solr's
SolrDispatchFilter class. Here's how I did that:
https://github.com/msokolov/lux/blob/master/src/main/java/lux/solr/LuxDispatchFilter.java
-Mike
On 12/03/2014 08:02 AM, Stefan Moises wrote:
Hi again,
just for reference, here is my filter class (taken from the example
posted earlier) - as soon as I iterate over the request parameters,
Solr gets angry... :(
I have also tried HttpServletRequestWrapper, but that didn't help
either... nor did this:
http://ocpsoft.org/opensource/how-to-safely-add-modify-servlet-request-parameter-values/
(because I don't want to only add some static values, I still have to
iterate over the original request's parameters to get my desired data
out of the request's POST data....)
Here goes...
public final class PostDataDumperFilter implements Filter {
private FilterConfig filterConfig = null;
public void init(FilterConfig filterConfig) throws
ServletException {
this.filterConfig = filterConfig;
}
public void destroy() {
this.filterConfig = null;
}
public void setFilterConfig(FilterConfig fc) {
filterConfig=fc;
}
public FilterConfig getFilterConfig() {
return filterConfig;
}
public void doFilter(ServletRequest request, ServletResponse
response,
FilterChain chain) throws IOException, ServletException {
if (filterConfig == null)
return;
HttpServletRequest httpRequest = (HttpServletRequest) request;
// The variable "postdata" is used in the Solr Tomcat Valve
Enumeration<String> names = httpRequest.getParameterNames();
StringBuffer output = new StringBuffer();
boolean skipRequest = false;
while (names.hasMoreElements()) {
String name = (String) names.nextElement();
output.append(name + "=");
String values[] = httpRequest.getParameterValues(name);
for (int i = 0; i < values.length; i++) {
if (i > 0) {
output.append("&" + name + "=");
}
output.append(values[i]);
// ignore paging requests, where request
parameter "start" is > 0, e.g. "&start=12":
if(name.equalsIgnoreCase("start") &&!
values[i].equals("0")) {
skipRequest = true;
}
}
if (names.hasMoreElements())
output.append("&");
}
if(!skipRequest) {
request.setAttribute("postdata", output);
}
chain.doFilter(request, response);
}
}
Thanks,
Stefan
Am 03.12.2014 um 09:47 schrieb Stefan Moises:
Hi Folks,
I have a problem with an additional servlet filter defined in my
web.xml (Tomcat 7.x).
In Solr 4.2.1. we've successfully used a filter for processing POST
request data (basically, the filter reads the POST data, collects
some parameters from it and writes it back to the request, based on
this example:
http://www.coderanch.com/t/484631/Tomcat/configure-Tomcat-log-POST-data)
To make this work, the filter has to be the first one defined in
the web.xml.
But now in Solr 4.8.0, if we define that filter, Solr complains that
there is a filter before it and claims that we have to remove it:
null:org.apache.solr.common.SolrException: Solr requires that
request parameters sent using application/x-www-form-urlencoded
content-type can be read through the request input stream.
Unfortunately, the stream was empty / not available. This may be
caused by another servlet filter calling
ServletRequest.getParameter*() before SolrDispatchFilter, please
remove it.
at
org.apache.solr.servlet.SolrRequestParsers$FormDataRequestParser.getParameterIncompatibilityException(SolrRequestParsers.java:622)
Here is my web.xml:
<!-- My own filter here... -->
<filter>
<filter-name>post-data-dumper-filter</filter-name>
<filter-class>filters.PostDataDumperFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>post-data-dumper-filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!-- Any path (name) registered in solrconfig.xml will be sent to
that filter -->
<filter>
<filter-name>SolrRequestFilter</filter-name>
<filter-class>org.apache.solr.servlet.SolrDispatchFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>SolrRequestFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Any idea how to solve this? Why does Solr have a problem now if
there is any pre-filter defined?
Thanks a lot,
Stefan
--
Mit den besten Grüßen aus Nürnberg,
Stefan Moises
*******************************************
Stefan Moises
Senior Softwareentwickler
Leiter Modulentwicklung
shoptimax GmbH
Ulmenstrasse 52 H
90443 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
*******************************************
