One more thing.
In the initialize method you do the following:
String solrInstanceTypeParam =
String.valueOf(context.getConfigParameterValue("solrInstanceType"));
assert solrInstanceTypeParam != null;
The assert will always be true since String.valueOf never returns a null
reference, even when
you pass a null reference to it, it will return the string "null".
getConfigParameterValue can actually return null, and we should fail the
initialization if
not all necessary parameters to run it are specified in the descriptor.
It should fail
with a meaningful error message.
Using assert is not a safe way to fail the initialization because
asserts are usually
disabled.
And, in the process method the try-catch statement just wraps the entire
implementation,
but only the calls to SolrServer.add and SolrServer.commit (and
Class.getConstructor, but that
one will vanish when CAS API is used instead, it is better for Solrcas
anyway) can fail
I believe it is always good idea to minimize the scope of try-catch
statements, as long as there
is no reason not to do it. The wrapped and re-thrown exception could
explain that
adding or commiting the document to the solr server failed. That is then
also easier to
debug in my production system where this AE will run and adding a
document to my solr
server will fail for real from time to time for various reasons.
I am not sure what is the best error handling when commit is failing,
because in that
case the document might be added again to solr which might lead to
duplicate documents
in the server.
Jörn
