Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-9231

SolrInputDocument no-args constructor removed without notice

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 6.1
    • Fix Version/s: None
    • Component/s: SolrJ
    • Labels:
      None
    • Environment:

      Lucee (or ColdFusion) loading SolrJ using separate URLClassLoader instance)

      Description

      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.

        Issue Links

          Activity

          Hide
          romseygeek Alan Woodward added a comment -

          Does cls.getConstructor(String[].class) work?

          Show
          romseygeek Alan Woodward added a comment - Does cls.getConstructor(String[].class) work?
          Hide
          tparker Tim Parker added a comment -

          not sure, but...even if it did work, it's not viable for a couple of reasons:

          1) this won't work with 6.0.1 - I don't think anyone wants to get into maintaining interface code full of 'if the Solr version is earlier than 6.1.0, do this...' logic

          2) We're calling this from ColdFusion, so it's not trivial to get that specific about types. We have built a wrapper class around URLClassLoader, but this shouldn't be burdened with special cases like "getNewInstanceAndCallConstructorWhichMightTakeArrayOfString()" - nor should we suddenly have to enumerate through all available constructors looking for one that won't throw exceptions if called with a zero-sized array

          Show
          tparker Tim Parker added a comment - not sure, but...even if it did work, it's not viable for a couple of reasons: 1) this won't work with 6.0.1 - I don't think anyone wants to get into maintaining interface code full of 'if the Solr version is earlier than 6.1.0, do this...' logic 2) We're calling this from ColdFusion, so it's not trivial to get that specific about types. We have built a wrapper class around URLClassLoader, but this shouldn't be burdened with special cases like "getNewInstanceAndCallConstructorWhichMightTakeArrayOfString()" - nor should we suddenly have to enumerate through all available constructors looking for one that won't throw exceptions if called with a zero-sized array
          Hide
          elyograg Shawn Heisey added a comment - - edited

          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.

          Show
          elyograg Shawn Heisey added a comment - - edited 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.
          Hide
          tparker Tim Parker added a comment -

          Use of SolrJ with ColdFusion requires a separate classloader because ColdFusion is bundled with an ancient Solr release and some other libraries which aren't compatible with current Solr releases. We do not bundle Solr with our product, so we're trying to maximize the range of Solr releases which can be used with our product - with this in mind, we needed a solution which is able to load a 'SolrInputDocument' object with no constructor arguments. With a no-args constructor, this is easy - just call newInstance() with no arguments. After the API change, however, this failed - updating our logic to change the newInstance() call to pass an (empty) array of strings would have cut off our ability to work with older Solr releases - and we also don't want to add conditional logic based on the Solr release we're using.

          The work-around is to do some gymnastics with reflection if the argument-free newInstance() throws an exception - it's not optimal, but it does get the job done

          Show
          tparker Tim Parker added a comment - Use of SolrJ with ColdFusion requires a separate classloader because ColdFusion is bundled with an ancient Solr release and some other libraries which aren't compatible with current Solr releases. We do not bundle Solr with our product, so we're trying to maximize the range of Solr releases which can be used with our product - with this in mind, we needed a solution which is able to load a 'SolrInputDocument' object with no constructor arguments. With a no-args constructor, this is easy - just call newInstance() with no arguments. After the API change, however, this failed - updating our logic to change the newInstance() call to pass an (empty) array of strings would have cut off our ability to work with older Solr releases - and we also don't want to add conditional logic based on the Solr release we're using. The work-around is to do some gymnastics with reflection if the argument-free newInstance() throws an exception - it's not optimal, but it does get the job done
          Hide
          janhoy Jan Høydahl added a comment -

          Marked as duplicate of SOLR-9373

          Show
          janhoy Jan Høydahl added a comment - Marked as duplicate of SOLR-9373
          Hide
          pat.moody Pat Moody added a comment -

          Tim Parker
          Did you ever get Solr 6.x + with SolrInputDocument working with ColdFusion? I am trying the same with Lucee 5 + Solr 7 and am having real problems with constructors for this object.
          We do have it working with our current Solr 4.6 and Lucee 5 as there are no constructors required.

          I've started work on creating a Lucee extension for Solr 7 and having OSGI issues so may resort to the old Javaloader mechanisms we are using currently for Solr 4.6.
          Here are a couple of references.
          https://dev.lucee.org/t/solr-7-extension/3002
          https://luceeserver.atlassian.net/browse/LDEV-1584

          Any help would be appreciated.

          Cheers
          Pat

          Show
          pat.moody Pat Moody added a comment - Tim Parker Did you ever get Solr 6.x + with SolrInputDocument working with ColdFusion? I am trying the same with Lucee 5 + Solr 7 and am having real problems with constructors for this object. We do have it working with our current Solr 4.6 and Lucee 5 as there are no constructors required. I've started work on creating a Lucee extension for Solr 7 and having OSGI issues so may resort to the old Javaloader mechanisms we are using currently for Solr 4.6. Here are a couple of references. https://dev.lucee.org/t/solr-7-extension/3002 https://luceeserver.atlassian.net/browse/LDEV-1584 Any help would be appreciated. Cheers Pat

            People

            • Assignee:
              Unassigned
              Reporter:
              tparker Tim Parker
            • Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:

                Development