I had a manual look through the *org.apache.solr.handler.admin.api* package, and I found that *InstallCoreData* was also missing the @Inject, everything else* looked* okay. https://github.com/apache/solr/pull/3023 - I'm still to add the regression tests (the checks are failing for reasons that appear to be quite unrelated to my tiny changes).
I've not really looked at the BATS tests before. But from a quick look at https://github.com/apache/solr/blob/main/solr/packaging/test/test_post.bats#L145-L151, I take it I can just run curl to poke each API. So they should be quick enough to write when I get back to this next week. Is that the best option then? Or should I use the RestTestBase and go that route instead? I don't mind personally. On Thu, 9 Jan 2025 at 20:05, David Smiley <dsmi...@apache.org> wrote: > Switching BATS should be a new dev list thread. Not saying I'm looking > forward to migrating yet another thing but don't want to cross our > conversations. > > On Thu, Jan 9, 2025 at 10:19 AM Christos Malliaridis < > c.malliari...@gmail.com> wrote: > > > > Maybe should be in "bats" actually. > > > > Before adding more tests to bats we should probably migrate to an > > OS-independent test framework. The missing coverage for Windows is taking > > its toll. > > > > On Thu, Jan 9, 2025 at 2:29 PM David Smiley <dsmi...@apache.org> wrote: > > > > > Definitely +1 to a smoke test (just look for non-failure). Maybe a > > single > > > test class smoke testing all of v2. Maybe should be in "bats" > actually. > > > > > > On Thu, Jan 9, 2025 at 4:24 AM Colvin Cowie < > colvin.cowie....@gmail.com> > > > wrote: > > > > > > > Hi, > > > > > > > > Okay yep, I can probably raise a JIRA and a PR tomorrow. I checked on > > 9.7 > > > > and 9.4, but looking at the source I expect it's always been this > way. > > > > On the testing front, I think it's a good idea to have at least one > > > "smoke" > > > > test on every API just to check that things serialize correctly, even > > > > without doing an exhaustive test - as you say the logic of the code > is > > > > mostly exercised via the v1 API. > > > > > > > > Cheers > > > > > > > > > > > > On Wed, 8 Jan 2025 at 16:50, Jason Gerlowski <gerlowsk...@gmail.com> > > > > wrote: > > > > > > > > > Hi Colvin, > > > > > > > > > > Yep - that's a result of the missing '@Inject' annotation. What > > > > > version are you seeing this on? If you're up for it, can you file > a > > > > > JIRA ticket with the details and hopefully we can address it in an > > > > > upcoming release? > > > > > > > > > > > I guess that there's no tests for going through the v2 API? > > > > > > > > > > I suspect you're correct. Testing the v2 APIs has been a bit of a > > > > > balancing act that we're still trying to feel out. It's not really > > > > > feasible from either a "test run duration" or a "maintenance" > > > > > perspective to cover v2 as comprehensively as we currently cover > v1. > > > > > We've tried to accommodate for this by structuring things so that > the > > > > > v1 APIs make use of the v2 code, under the theory that tests using > v1 > > > > > APIs will be testing the v2 code "implicitly". But that doesn't > > catch > > > > > everything - as you've found with this Jersey dispatching bug. > > > > > > > > > > Maybe we should reconsider the testing strategy here, and try to > > > > > ensure that all v2 APIs are called in at least one test. > > > > > > > > > > Best, > > > > > > > > > > Jason > > > > > > > > > > On Wed, Jan 8, 2025 at 10:25 AM Colvin Cowie < > > > colvin.cowie....@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > Hello, I'm trying to use the v2 > > > > > > > > > > > > > > > > > > > > > https://solr.apache.org/guide/solr/latest/deployment-guide/collection-management.html#collectionprop > > > > > > API. v1 works fine, but v2 fails with a glassfish error. I won't > > > paste > > > > > the > > > > > > full stacktrace here because it's mostly noise. > > > > > > > > > > > > I assume it's because > > > > > org.apache.solr.handler.admin.api.CollectionProperty > > > > > > doesn't have an @Inject annotation on its constructor > > > > > > < > > > > > > > > > > > > > > > https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/handler/admin/api/CollectionProperty.java#L41 > > > > > > > > > > > > - and I guess that there's no tests for going through the v2 API? > > Or > > > is > > > > > it > > > > > > tested, and I'm missing something? > > > > > > > > > > > > ---- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *2025-01-08 14:29:13.089 WARN (qtp1429351083-106-localhost-1) > > [c: > > > s: > > > > > r: > > > > > > > x: t:localhost-1] o.g.j.s.ServerRuntime$Responder An exception > > > > mapping > > > > > did > > > > > > > not successfully produce and processed a response. Logging the > > > > > exception > > > > > > > propagated to the default exception mapper. => MultiException > > > stack 1 > > > > > of > > > > > > > 1java.lang.NoSuchMethodException: Could not find a suitable > > > > > constructor in > > > > > > > org.apache.solr.handler.admin.api.CollectionProperty > > > > > > > class.org.glassfish.hk2.api.MultiException: A MultiException > has > > 1 > > > > > > > exceptions. They are:1. java.lang.NoSuchMethodException: Could > > not > > > > > find a > > > > > > > suitable constructor in > > > > > > > org.apache.solr.handler.admin.api.CollectionProperty class. at > > > > > > > > org.jvnet.hk2.internal.Collector.throwIfErrors(Collector.java:65) > > > > > > > ~[?:?]...Caused by: java.lang.NoSuchMethodException: Could not > > > find a > > > > > > > suitable constructor in > > > > > > > org.apache.solr.handler.admin.api.CollectionProperty class. at > > > > > > > > > > > > > > > > > > > > > > org.glassfish.jersey.inject.hk2.JerseyClassAnalyzer.getConstructor(JerseyClassAnalyzer.java:168) > > > > > > > ~[?:?] at > > > > > > > > > org.jvnet.hk2.internal.Utilities.getConstructor(Utilities.java:157) > > > > > ~[?:?] > > > > > > > at > > org.jvnet.hk2.internal.Utilities.justCreate(Utilities.java:1043) > > > > > ~[?:?] > > > > > > > ... 71 more2025-01-08 14:29:13.106 WARN > > > > > (qtp1429351083-106-localhost-1) > > > > > > > [c: s: r: x: t:localhost-1] o.g.j.i.Errors The following > warnings > > > > have > > > > > been > > > > > > > detected: WARNING: HK2 service reification failed for > > > > > > > [org.apache.solr.handler.admin.api.CollectionProperty] with an > > > > > > > exception:MultiException stack 1 of > > > 2java.lang.NoSuchMethodException: > > > > > Could > > > > > > > not find a suitable constructor in > > > > > > > org.apache.solr.handler.admin.api.CollectionProperty class. at > > > > > > > > > > > > > > > > > > > > > > org.glassfish.jersey.inject.hk2.JerseyClassAnalyzer.getConstructor(JerseyClassAnalyzer.java:168)...MultiException > > > > > > > stack 2 of 2java.lang.IllegalArgumentException: Errors were > > > > discovered > > > > > > > while reifying SystemDescriptor( > > > > > > > > > implementation=org.apache.solr.handler.admin.api.CollectionProperty > > > > > > > > contracts={org.apache.solr.handler.admin.api.CollectionProperty} > > > > > > > scope=org.glassfish.jersey.process.internal.RequestScoped > > > > qualifiers={} > > > > > > > descriptorType=CLASS descriptorVisibility=NORMAL metadata= > rank=0 > > > > > > > loader=null proxiable=null proxyForSameScope=null > > analysisName=null > > > > > id=137 > > > > > > > locatorId=0 identityHashCode=1799286651 reified=false) at > > > > > > > > > > > > > > > > org.jvnet.hk2.internal.SystemDescriptor.reify(SystemDescriptor.java:684) > > > > > > > ...* > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > > > > > > > > > >
