: SOLR-133: Adding StaxUpdateRequestHandler.java and mapping it to: : http://localhost:8983/solr/admin/update/stax : in the example solrconfig.xml : : We should test and evaluate this in comparison to the : XmlUpdateRequestHandler before replacing it.
an easy way to sanity check this might be to subclass the existing tests and use the on the fly handler registration to replace the XmlRequestHandler with the new stax one and make sure all the tests pass. One question about this (i wasn't really following the jira issue) ... is there any particular reason why UpdateRequestProcessor is a class constructed using a request instead of using a factory pattern? it seems like there might be common "initialization" stuff the UpdateRequestProcesser might want to do which would make sense in a single init(NamedList) method that the StaxUpdateRequestHandler was required to call in it's init method so it can have some state. -Hoss
