[
https://issues.apache.org/jira/browse/SOLR-9231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15576356#comment-15576356
]
Shawn Heisey edited comment on SOLR-9231 at 10/14/16 8:38 PM:
--------------------------------------------------------------
Interesting problem. I guess the underlying question is ... what sort of API
guarantees do we intend to honor for SolrJ?
I think the removal of the no-arg constructor fits with a policy of "typical
API usage will continue to compile with a minor-version update." IMHO, your
usage is not typical. Classloaders and other things that utilize method
signatures are an advanced kind of Java programming.
A more strict guarantee of "code compiled against SolrJ X.Y will work if the
jar is upgraded in place to version X.Z" would be required for your usage. It
may be reasonable for users to expect this kind of guarantee, but apparently
whoever removed the constructor did not share this opinion, or was not aware
that it could break existing binaries.
was (Author: elyograg):
Interesting problem. I guess the underlying question is ... what sort of API
guarantees do we intend to honor for SolrJ?
I think the removal of the no-arg constructor fits with a policy of "typical
API usage will continue to compile with a minor-version update." IMHO, your
usage is not typical. Classloaders and other things that utilize method
signatures are an advanced kind of Java programming.
A more strict guarantee of "code compiled against SolrJ X.Y will work if the
jar is upgraded in place to version X.Z" would be required for your usage. It
may be reasonable for users to expect this kind of guarantee, but apparently
whoever removed the constructor did not share this opinion.
> SolrInputDocument no-args constructor removed without notice
> ------------------------------------------------------------
>
> Key: SOLR-9231
> URL: https://issues.apache.org/jira/browse/SOLR-9231
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 6.1
> Environment: Lucee (or ColdFusion) loading SolrJ using separate
> URLClassLoader instance)
> Reporter: Tim Parker
>
> In 6.0.1 and previous, SolrInputDocument provided two constructors - one with
> no arguments, the other accepting a Map object. As of 6.1.0, the
> no-arguments constructor is replaced with one that accepts zero or more
> strings.
> With 6.0.1, this worked:
> cls = LoadClass("org.apache.solr.common.SolrInputDocument");
> Constructor foo = cls.getConstructor();
> This fails with Solr 6.1.0
> We get the same error after updating the code to this:
> cls = LoadClass("org.apache.solr.common.SolrInputDocument");
> Class[] argArray = new Class[0];
> Constructor foo = cls.getConstructor(argArray);
> Are we missing something? If not, please restore the missing no-arguments
> constructor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
