IntelliJ not working with latest main

[Ishan Chattopadhyaya]

Hi all,
I pulled latest commits, but ./gradlew main is resulting in a project that
doesn't load without errors:
ApiMustacheTemplateTests.java: Cannot resolve symbol CollectionsApi,
ListCollectionsResponse.

Any ideas, please?

If I rollback to the commit before the following one, it works fine:

commit 461955f00118c69d06f50e72addeff12c8dd8169
Author: Christos Malliaridis 
Date:   Tue Jun 11 18:15:01 2024 +0200

SOLR-17326: Fix references in generated SolrRequest impls (#2510)

A handful of the v2 SolrRequest implementations generated
by our OAS spec relied on response model classes whose names
conflicted with other (unrelated) classes in solrj.  This caused
errors at request time as JacksonParsingResponse would try to
deserialize the JSON, XML, etc. response body into these
unintended classes.

This commit fixes this by modifying the 'api.mustache' template
so that generated SolrRequest classes now reference their
response model using the fully-qualified classname (i.e. including
the package).  This resolves the ambiguity.

-

Co-authored-by: Jason Gerlowski 

Re: IntelliJ not working with latest main

[Ishan Chattopadhyaya]

I removed the ApiMustacheTemplateTests.java temporarily, and all errors
went away.
However, tried running tests, and ran into this:

BasicFunctionalityTest.java:
java.lang.RuntimeException:
org.apache.solr.core.SolrCoreInitializationException: SolrCore
'collection1' is not available due to init failure: RAMDirectory can only
be used with the 'single' lock factory type.

Any ideas, please?


On Sun, 14 Jul 2024 at 14:17, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Hi all,
> I pulled latest commits, but ./gradlew main is resulting in a project that
> doesn't load without errors:
> ApiMustacheTemplateTests.java: Cannot resolve symbol CollectionsApi,
> ListCollectionsResponse.
>
> Any ideas, please?
>
> If I rollback to the commit before the following one, it works fine:
>
> commit 461955f00118c69d06f50e72addeff12c8dd8169
> Author: Christos Malliaridis 
> Date:   Tue Jun 11 18:15:01 2024 +0200
>
> SOLR-17326: Fix references in generated SolrRequest impls (#2510)
>
> A handful of the v2 SolrRequest implementations generated
> by our OAS spec relied on response model classes whose names
> conflicted with other (unrelated) classes in solrj.  This caused
> errors at request time as JacksonParsingResponse would try to
> deserialize the JSON, XML, etc. response body into these
> unintended classes.
>
> This commit fixes this by modifying the 'api.mustache' template
> so that generated SolrRequest classes now reference their
> response model using the fully-qualified classname (i.e. including
> the package).  This resolves the ambiguity.
>
> -
>
> Co-authored-by: Jason Gerlowski 
>
>
>

Re: IntelliJ not working with latest main

[Christos Malliaridis]

Hey Ishan, I'm sorry to hear that. The test uses a generated class to
verify the bug fix, since the issue occurs in a template fro class
generation.

The error you sent points to one of generated classes that I used
(CollectionsApi) and that is also in SolrJ module. Since it is a generated
class, is maybe something broken with your build cache? If I am not
mistaken, the classes should always be generated in advance for SolrJ.

I also tried to reproduce the error and it said for "./gradlew main" that
main does not exist. Is it maybe "./gradlew dev" what you are trying to
execute?


On Sun, 14 Jul 2024, 11:54 Ishan Chattopadhyaya, 
wrote:

> I removed the ApiMustacheTemplateTests.java temporarily, and all errors
> went away.
> However, tried running tests, and ran into this:
>
> BasicFunctionalityTest.java:
> java.lang.RuntimeException:
> org.apache.solr.core.SolrCoreInitializationException: SolrCore
> 'collection1' is not available due to init failure: RAMDirectory can only
> be used with the 'single' lock factory type.
>
> Any ideas, please?
>
>
> On Sun, 14 Jul 2024 at 14:17, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
> > Hi all,
> > I pulled latest commits, but ./gradlew main is resulting in a project
> that
> > doesn't load without errors:
> > ApiMustacheTemplateTests.java: Cannot resolve symbol CollectionsApi,
> > ListCollectionsResponse.
> >
> > Any ideas, please?
> >
> > If I rollback to the commit before the following one, it works fine:
> >
> > commit 461955f00118c69d06f50e72addeff12c8dd8169
> > Author: Christos Malliaridis 
> > Date:   Tue Jun 11 18:15:01 2024 +0200
> >
> > SOLR-17326: Fix references in generated SolrRequest impls (#2510)
> >
> > A handful of the v2 SolrRequest implementations generated
> > by our OAS spec relied on response model classes whose names
> > conflicted with other (unrelated) classes in solrj.  This caused
> > errors at request time as JacksonParsingResponse would try to
> > deserialize the JSON, XML, etc. response body into these
> > unintended classes.
> >
> > This commit fixes this by modifying the 'api.mustache' template
> > so that generated SolrRequest classes now reference their
> > response model using the fully-qualified classname (i.e. including
> > the package).  This resolves the ambiguity.
> >
> > -
> >
> > Co-authored-by: Jason Gerlowski 
> >
> >
> >
>

Re: Your ZK connection string (3 hosts) is different from the dynamic ensemble config (3 hosts)

[Jan Høydahl]

Hi,

Please do not use the dev mailing list for user questions. This list is for 
discussions regarindg the development of Solr itself. When re-posting your 
question to the users@ mailing list, please include some more details about 
your setup such as the contents of zookeeper config files and a screenshot of 
the error message on Admin UI.

Jan

> 10. juli 2024 kl. 16:18 skrev Storch, Robin :
> 
> Hello,
> 
> I'm trying to migrate from centos7 to rhel9 on a server that is running 
> solr/zookeeper.
> 
> I copied over the configuration and made changes to the config files that 
> listed the server names.  I also copied over the contents of 
> /opt/solr/aerscloud/solr/configsets which apparently contained information 
> about the previous server names.  I have three nodes and solr and zookeeper 
> and starting up and running on all three.  
> 
> The problem is that on the active node, it is showing the old server names 
> when I run this command:
> 
> /usr/lib/zookeeper/bin/zkCli.sh
> config
> 
> The other two nodes show the correct new server names.
> 
> There are currently two configsets under 
> /opt/solr/aerscloud/solr/configsets/, the old one and a new one that was 
> created by the solr admin.  Is there a way to correct this so that the 
> zookeeper config points to the new server names?
> 
> 
> 
> Robin Storch, M.Ed.
> Systems Engineer
> IS Research IT
> Information Services
> Cincinnati Children's
>  Burnet Avenue, Cincinnati, OH 45229

Re: [Solr site] Deployment to production process

[Jan Høydahl]

There was also an update to the infrastructure-actions/pelican@main action that 
required a small config change in our repo. Did that and merged main into prod. 
Hope it is fine now and that your PRs will contain only your own stuff..

Jan

> 12. juli 2024 kl. 17:52 skrev Houston Putman :
> 
> It looks like the build stuff Jan had been working on wasn't merged to
> production I'd definitely wait for him to do that.
> 
> - Houston
> 
> On Fri, Jul 12, 2024 at 10:27 AM Alessandro Benedetti 
> wrote:
> 
>> Hi all,
>> we've been working with my colleagues on adding external Solr blogs to the
>> site and we plan to do this periodically, so that each week more or less a
>> new blog is published.
>> 
>> But I am confused about the deployment pipeline:
>> 
>> 1) Pull Request *from*:  *to*: main
>> That's easy peasy, the review happens and when everyone is happy, merge
>> 
>> Then I'm lost, is it:
>> 
>> 2) Pull Request *from*: main *to*: production
>> https://github.com/apache/solr-site/pull/111
>> Trying that I see many differences and not the only blog post I was
>> supposed to deploy live.
>> 
>> What am I missing?
>> 
>> Cheers
>> --
>> *Alessandro Benedetti*
>> Director @ Sease Ltd.
>> *Apache Lucene/Solr Committer*
>> *Apache Solr PMC Member*
>> 
>> e-mail: a.benede...@sease.io
>> 
>> 
>> *Sease* - Information Retrieval Applied
>> Consulting | Training | Open Source
>> 
>> Website: Sease.io 
>> LinkedIn  | Twitter
>>  | Youtube
>>  | Github
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Re: Vex file 404

[Jan Høydahl]

Hi,

Sorry bout that, was on holiday this week and there were some merging left to 
do. Should be ok now.

Jan

> 13. juli 2024 kl. 14:55 skrev Christos Malliaridis :
> 
> Apparently the file is available at
> https://solr.staged.apache.org/solr.vex.json, but not the production /
> official site. Looking into the commit history, the changes where VEX was
> re-enabled
> 
> are not merged yet into the production branch.
> 
> @Jan Høydahl Is there a reason the changes were not released?
> 
> Best,
> Christos
> 
> On Thu, Jul 11, 2024 at 9:53 PM Gus Heck  wrote:
> 
>> I was just trying to tell someone that we publish a machine readable VEX
>> file and went to show them the link on our security page... but it came up
>> 404..
>> 
>> https://solr.apache.org/solr.vex.json
>> 
>> -Gus
>> 
>> --
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org